Skip to end of metadata
Go to start of metadata

Time: 1- 2 PM ET

Coordinates:

Attendees

Name Affiliation
JD NolenMercy Children's Hospital
Ralf HerzogRoche
Craig NewmanAltarum
Kathy WalshLabcorp
Marti VelezisSonrisa/FDA
Dan RutzEpic
Ruby NashLantana
Andrea PitkusUW
Alex GoelLantana
Riki MerrickVernetzt, LLC / APHL












Chair: JD Nolen

Scribe: Riki Merrick

Quorum reached

ANSI Anti-Trust Policy:

Professional Associations, such as HL7, which bring together competing entities are subject to strict scrutiny under applicable antitrust laws. HL7 recognizes that the antitrust laws were enacted to promote fairness in competition and, as such, supports laws against monopoly and restraints of trade and their enforcement. Each individual participating in HL7 meetings and conferences, regardless of venue, is responsible for knowing the contents of and adhering to the HL7 Antitrust Policy as stated in §05.01 of the Governance and Operations Manual (GOM).

Agenda:

  • Agenda Review:
  • Approve Minutes
    • 2021-11-18 Main - Approve as corrected – Kathy Walsh, Riki Merrick, no further discussion, against: 0, abstain: 0, in favor: 7
  • Administrivia:
    • OO Calls Next 7 Days (check if happening)
    • Gender Harmony wants to get OO reps on for WGM – since the Jan meeting is Tue – Fri we just shifted over 1 day – Co-Chairs to doublecheck that we did the agenda correctly!
    • Add Jan WGM to the minute template now – John D.L. Nolen to make sure we have that set up
    • Projects/Feedback:
    • WHO request for public comment for SARS-COV2 reporting with FHIR was submitted by PAC
  • v2
    • Withdraw LOI and LRI from Jan ballot - Motion to withdraw LOI and LRI from Jan 2022 ballot – Riki Merrick, Ralf Herzog, no further discussion, against: 0, abstain: 0, in favor: 8 – Ulrike Merrick to notify Lynn

    • PH WG is reviewing old paperwork to clean up - ELR R2 document expired (this is v2.5.1 – first PH Component in LRI, was published as separate document the first time), but was never withdrawn – this will move it to retired space, but it should no longer be maintained, as it is NOT in regs nor is it the most recent version – this is FYI

  • FHIR
    • Feedback on Lab profile for this:FHIR-31383 - Specify semantic model bindings for Observation - update?
      • Draft for both descriptions in Condition (CI build has the new verbiage) and in Observation - @Rob Hausam to put this together - NOT DISCUSSED
    • Reflex/Follow-Up/Add-On
      • FHIR-34204 - Observation.triggeredBy added, so you can chain observations together – persuasive
      • FHIR-34205 - ServiceRequest.status
        Question: Update that the “valid with” – means that this is ONLY valid with the listed status – we updated the proposed disposition
        Question: We should make sure we cover CLIA requirements – may do that as a block review for projects going forward. CAP has agreed to get these reviewed by a CLIA SME – this will be in R5 ballot (this would be for US only, though, so maybe address in UScore?) – would be also good to learn about LIS that are supporting FHIR for lab results (see this related zulip chat) – persuasive
      • FHIR-34206 - Add-On Orders
        remove the ** after the new – we don’t want to have these as part of the code – persuasive
      • FHIR-34207 - attribute to document confirmation – persuasive

        Motion to find these 4 trackers as persuasive Craig Newman, Ralf Herzog, no further discussion, against: 0, abstain: 1, in favor: 8 – John D.L. Nolen  to update the trackers with votes and assign

    • Specimen in-process code FHIR-33041- Clarify "in process" as part Observation.status="registered" or create a separate status WAITING FOR INPUT
      • Specimen in process is needed for lab – see HL70085 for definition of in progress
        What does registered really mean?  
        Would registered also cover R = Result available, not verified (this is not the same as preliminary, where the 
         
        except for partial we think there should be a 1:1 mapping in most cases (not sure about U – how is that used) – when do you version an existing resource vs create a new one that replaces the old one? 
        V = Verified – this is the update to the final status AFTER verification – make a note that it can only be used with re-evaluate – we may need to create state diagrams – what state can be replaced with V (F for sure, what about C?)
        We are leaning towards option 3, since registered is not clearly understood
        P= preliminary in FHIR has a different meaning than in v2
        Move this to the Lab call
    • Appended code FHIR-33042- Include Observation.status "appended" TRIAGED
      • Appended – this is related to the one above – move to Lab call
    • DOCREF QUESTION: FHIR-32585- WHY DO WE HAVE BOTH RELATED AND RELATEDTO? TRIAGED - – is in a future block vote, please review
    • Proposed FHIR Block Vote for Cancer Pathology Reporting for vote on December 9, 2022: 

       https://jira.hl7.org/browse/FHIR-33940?jql=project%20%3D%20FHIR%20AND%20Specification%20%3D%20%22Cancer%20Pathology%20Data%20Sharing%20(FHIR)%20%5BFHIR-us-cancer-reporting%5D%22%20AND%20Grouping%20%3D%20Block-Vote-3

      ummary

      Issue key

      Resolution

      Reporter

      Description

      Custom field (Grouping)

      Custom field (Resolution Description)

      Binding for Specimen.type

      FHIR-33940

      Not Persuasive with Modification

      RikiM

      I propose to use SCT specimen hierarchy terms (123038009 | Specimen (specimen)  and its descendants - in US edition) as preferred binding in the US version of this profile rather than V2 table terms, which are not as well defined and are missing several important types as we found out when compiling the specimen crossmapping table.

      block-vote-3

      The use of Snomed terminology for Specimen.type is amenable. However, all descendants of Specimen (specimen) is broad.  In an effort to mirror NAACCRv5, this v2 table is the best match. However, the need for a more robust terminology valueset in Snomed is critical future work.



      This IG will continue to use v2-0487 as an example binding for this current version of this IG. However, the concepts in this valueset as represented in Snomed are the desired preferred binding for this Specimen.type. Once this Snomed subset ValueSet exists, it should be incorporated into this profile location at that time.

      Need for lab's accession ID

      FHIR-33939

      Persuasive with Modification

      RikiM

      Specimen.accessionIdentifier should be required - this is the MAIN means that the lab tracks the specimen - specimen.identifier is described as external ID, which is also important to track.

      block-vote-3

      Will update .accessionIdentitifer to be 1..1.



      We will leave .identifier as 1..* in order to allow for the list of multiple identifiers assigned by upstream (previous) labs to be retained within a given reference lab system.



      (will leave both elements as MS)

      Incomplete definition of mustSupport backbone elements in USPathologySpecimen

      FHIR-33938

      Persuasive

      RikiM

      In looking at the snapshotMustSupport view - this only shows that both backbone elements collection and container are MustSupport, but does not give detail on the elements within it that are needed - all are marked as 0..



      I would expect to have these elements listed as required:



      specimen.collection.collected



      at least one of the elements of specimen.container, since the backbone is required.



       



      I would expect to have these elements listed as MustSupport:



      specimen.collection.collector (especially since you have that role concept in your IG specific valueset)



      specimen.collection.bodySite



      specimen.collection.method (though that could possibly be taken care of by a reference to the procedure (I think we have a CR out to make method a codableReference - if not we should maybe consider that?)



       

      block-vote-3

      Specimen.collection.collect[x] should be flagged as MS. Also .collection.bodySite as MS. Also .collection.collector referencing PractitionerRole profile

      Why not use codes from the underlying HL7 code system Provider

      FHIR-33873

      Persuasive

      RikiM

      Why not use these codes from [https://terminology.hl7.org/CodeSystem-v2-0443.html]



      instead of creating a new code system:

      |CLP|Collecting Provider|Collecting Provider|OBR-10 Collector Identifier|



      |OP|Ordering Provider|Ordering Provider|ORC-12 Ordering Provider, OBR-16 Ordering Provider, RXO-14 Ordering Provider's DEA Number, RXE-13 Ordering Provider's DEA Number, ORC-24 Ordering Provider Address|



      |PI|Primary Interpreter|Primary Interpreter|



      |RO|Responsible Observer|Responsible Observer|OBX-16 Responsible Observer|

      block-vote-3

      We will use the suggested code system; we will delete the USPatholigyProviderTypes CodeSystem and replace it with the four codes from the suggested code system within the USPathologyProviderTypes ValueSet

      Include links to referenced value set / extensions

      FHIR-33871

      Persuasive

      RikiM

      * If the information does not exist and the cardinality of the element is >= 1..*, the Sender SHALL use the dataAbsentReason extension where it is defined. Note: populating the element with the value set absent reason or using the dataAbsent Reason SHOULD be handled by the Sending System and not require provider action.



      Include a link to the value set absent reason and the dataAbsentReason extension.

      block-vote-3

      We will add the included verbiage to the MS and Missing Data narrative page.

      Clarify the dataflow that is covered under this specification

      FHIR-33870

      Not Persuasive with Modification

      RikiM

      This may fit here, or create a separate section under specification to describe the use case in particular - it is not clear from reading just this IG who the originator of this FHIR bundle is expected to be - the EHR-s, the LIS, a data mart, HIE? That would also help clarify the relationship woth other standards used in the laboratory data exchange paradigm.



      The NAACCR IG section 1.3. STANDARDS AND GUIDELINES FOR ELECTRONIC TRANSMISSION OF REPORTS FROM PATHOLOGY LABORATORIES TO CENTRAL CANCER

      REGISTRIES makes this very clear a statement like this should be added here:



      The sope of this IG is to define the format for transmitting electronic pathology laboratory reports from pathology laboratories to central cancer registries.

      block-vote-3

      See FHIR-33333 for duplicate ticket.



      Will add the following acknowledgement to the IG: This guide specifies sending of pathology-related information to clinical (EHR) systems as well as to cancer registries.

      Suggest to also add relationship to APSR work

      FHIR-33868

      Persuasive

      RikiM

      Suggest to add section for Relation to IHE Anatomic Pathology Structured Reporting (APSR) on FHIR (work ongoing in Germany) and how to resolve the difference between data representation in the original IHE APSR ([https://www.ihe.net/uploadedFiles/Documents/PaLM/IHE_PaLM_Suppl_APSR.pdf]) and the CAP eCC.



      Here is some background on how APSR is used in Germany with their cancer registry: [http://download.hl7.de/veranstaltungen/jahrestagungen/2016/17-haroskehartz.pdf] and Gunter Haroske is also the person that is working on migrating APSR to FHIR

      block-vote-3

      Will add reference and relationship/context to the provided APSR information.

      It would be nice to get the NAACCR v2.5.1 IG to be balloted at HL7 and harmonized with LRI

      FHIR-33866

      Persuasive with Modification

      RikiM

      This guide leverages the [NAACCR Standards for Cancer Registries Volume V, Laboratory Electronic Reporting Pathology Version 5.0, May 2020|https://www.naaccr.org/wp-content/uploads/2020/07/NAACCR-Vol-V_Revised_20200720.pdf] (Revised 2020).



       



      This IG has not been balloted at HL7, it would be nice if this could get harmonized with the LRI / integrated as a profile component, so the basic message structures for lab reslts are the same, regardless if used for anatomic pathology, chemistry, micro or other lab results reporting - I know there has been comparison to the ELR R1 IG done in the past, and I think a comparison to LRI also exists.

      block-vote-3

      Agreed- will explore options for balloting NAACCR through HL7 process

      Update table format / first row mapping

      FHIR-33864

      Persuasive

      RikiM

      ||ORU Message Segments||HL7 V2 Section||FHIR Cancer Pathology Data Sharing: US Pathology Bundle||



       



      This should be split into 2 rows:



      header names should be = V2 message elements / NAACCR IG section reference / FHIR artifact



      second row should be the first mapping = ORU^R01 message / 2.3.1 / US Pathology Bundle



      Also check the HL7 section references - assuming this is to the NAACCR IG linked on the home page as background:

      |Common Order segment (ORC)|2.6.3 - is actually 2.7.1|US Pathology-Related PractitionerRole|

      |Observations Report ID segment (OBR)|2.6.3 - is actually 2.7.2|US Pathology Diagnostic Report, US Pathology-Related PractitionerRole|

      |Notes and Comments segment (NTE)|2.6.4 - is actually 2.7.4|US Pathology Diagnostic Report|

      |RESULT:| | |

      |Observation/Result segment (OBX)|2.6.4 - is actually 2.7.3|US Pathology Diagnostic Report (results)|

      |Notes and Comments segment (NTE)|2.6.4 - is actually 2.7.4|US Pathology Diagnostic Report|

      |SPECIMEN INFORMATION:| | |

      |Specimen (SPM)|7.4.3 - is actually 2.7.5|US Pathology Specimen|

      |Observation Related to Specimen (OBX)|7.4.2 - could not find this specifically in the TOC|US Pathology Diagnostic Report|

      |Continuation Pointer (DSC)|2 - could not find this specifically in the TOC| |

      block-vote-3

      Will update mapping tables on Background page with correct v2 section numbers (see comment), and will confirm what HL7 v2 (column header) actually refers to. Add ORU to Bundle map as row 1 (additionally). Update headers that specifically describe what is in each column.

      us-pathology-provider-types Code System canonical url should be rooted in terminology.hl7.org (THO)

      FHIR-33737

      Not Persuasive with Modification

      Rongparker

      The us-pathology-provider-types Code System canonical url should be rooted in terminology.hl7.org (THO), not rooted in hl7.org/fhir.  A UTG ticket should be created to register the Code System in THO.



      (*Comment 3 - imported by: Ron G. Parker*)

      block-vote-3

      Comment (FHIR-33873) suggested that this CodeSystem is duplicative and should be removed and instead the existing/underlying v2 CodeSystem concepts should be used. Thierefore, this CodeSystem will not apply to this guide.

      Remove IHE SDC examples

      FHIR-33735

      Not Persuasive with Modification

      Rongparker

      FHIR SDC examples are included, with no context re: inclusion in ePatholoy Reporting other than "section 2.1: Relation to IHE SDC on FHIR".



      h3. Existing Wording:

      Samples of IHE SDC example Observations



      h3. Proposed Wording:

      Remove IHE SDC examples



      (*Comment 1 - imported by: Ron G. Parker*)

      block-vote-3

      This comment was discussed on 11/11 O&O call. Decision: Inclusion of Observation examples in this guide are key for providing clear guidance on the relationship between this guide and SDC on FHIR. SDC on FHIR Observation examples should remain in this guide and will add narrative to 1) explain why Observation examples are included in this guide and 2) add clear, strong verbiage (ie implementers *SHALL* conform to SDC on FHIR Observation StructureDefinitions where applicable) stating expectations regarding conformance to Observation profiles in SDC on FHIR.



      The group discussed the possibility to adding an abstract profile for Observation into this guide, but however it was decided that the value an abstract profile would add to the implemented would be minimal compared to the risk of confusion and discrepant implementation decisions by implementers between this profile and the specific profiles in SDC on FHIR.

      Be sure to align with referenced specs reconciliation

      FHIR-33719

      Persuasive

      GDolin

      This seems to be a neat and clean ballot with adherence to US Core where planned.



      I am just requesting that careful collaboration occurs during ballot reconciliation where specs are referenced that are also under ballot, for example: MedMorph http://hl7.org/fhir/us/medmorph/2021Jan/StructureDefinition-us-ph-messageheader.html

      block-vote-3

      Dependence on (and appropriate use of) the most recent published version of US Public Health MessageHeader will be confirmed preceding publication in order to coordinate the correct use/dependence on this profile.

      Do not re-state properties in “differential” if they have not changed

      FHIR-33512

      Persuasive

      jmandel

      See discussion at [https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/Differential.20table.20bug.20.28or.20.2E.2E.2E.20bug.20in.20my.20brain.29.3F] – for example, {{DiagnosticReport.subject}} should not be included in the differential list, since it hasn’t changed relative to the base profile. I’m not sure if there’s a systematic issue here with other elements appearing in the differential when they shouldn’t (but if so, other instances would be worth cleaning up, too).

      h2.  

      block-vote-3

      Will remove duplicative constraints in this guide's profiles so that they do not inappropriately appear on the differential tab. Specifically, we will remove DR.subject constraint and will check for (and resolve) other profiles where this issue also occurs.

      What is the meaning of “https://CAP.org” Reference.identifier elements?

      FHIR-33511

      Persuasive

      jmandel

      For example in

       

       

      { "reference" : "Observation/42554.100004300-us", "identifier" : { "system" : "https://CAP.org", "value" : "Adrenal.Bx.Res.129_3.002.011.RC1_sdcFDF3d1c4fe4-09c3-4a7e-877f-9ddb160da6db/ver1#42554.100004300" } },

      Is the implication that {{https://CAP.org}} is a global system in which individual specimens are assigned identifiers? Or is this just an example? (If it’s a real system / convention, this should be documented. If it’s just an example, it’d be good to use something with “.example.com” in the {{system}}).

      h2.  

      Block-Vote-3

      cap.org/fhir... is an example CodeSystem. Will update all instances within this IG from [http://cap.org...|http://cap.org.../] to http://example.org/...

      Example Encounters should populate type with a display and a meaningful value

      FHIR-33510

      Persuasive

      jmandel

       

      "class" :



      { "system" : "http://terminology.hl7.org/CodeSystem/v3-ActCode", "code" : "IMP", "display" : "inpatient encounter" }



      , "type" : [ { "coding" : [



      { "system" : "http://snomed.info/sct", "code" : "308335008" }



      ] } ],





      This SNOMED code missing a display; looking it up, it looks like it’s a code for “Patient encounter procedure”. Would be good to include this display name (or better, choose an encoutner type that more closely matches the scenario).

      h2.  

      block-vote-3

      Will add display values wherever possible throughout IG examples (ie for every code/system pair)

      Example Patients should omit Patient.link

      FHIR-33509

      Persuasive with Modification

      jmandel

      The examples show

       

       

      "link" : [ { "other" : { "reference" : "RelatedPerson/pathology-next-of-kin" }, "type" : "seealso" } ]

      … but this contradicts the definition of {{Patient.link}} (“Link to another patient or RelatedPErson resource that concerns the same actual patient”) since my next of kin is not the same actual patient as me. We already have examples of RelatedPerson (next of kin) linking back to the Patient, which is the direction defined/expected in FHIR core.

      h2.  

      block-vote-3

      Will remove Patient.link constraint and will update examples to remove exemplifying .link. Will note in narrative/profile description that 'XML comment also clarifies that use of the standard extension is the direct linkage between the Patient and NOK. Will also acknowledge that existing implementation may only use Patient.contact.relationship CodeableConcept, however use of both (use of extension and relationshipCodeableConcept) is recommended."

       



      <Patient>

      <id value="1" />

      <meta>

      <profile value="http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient" />

      </meta>

      <identifier>...</identifier>

      <name>

      <family value="Smith"/>

      <given value="Patient"/>

      </name>

      <contact>

      <!-- use of this standard extension is the direct linkage between Patient and NOK -->

      <extension url="http://hl7.org/fhir/StructureDefinition/patient-relatedPerson">

      <reference value="RelatedPerson/2" />

      </extension>

      <relationship>

      <coding>

      <code value="N" />

      <system value="http://terminology.hl7.org/CodeSystem/v2-0131" />

      <display value="Next-Of-Kin" />

      </coding>

      </relationship>

      <name>

      <family value="Smith"/>

      <given value="Aunt"/>

      </name>

      </contact>

      </Patient>



       



      <RelatedPerson>

      <id value="2"/>

      <patient>

      <reference value="Patient/1"/>

      </patient>

      <relationship>

      <coding>

      <code value="N"/>

      <system value="http://terminology.hl7.org/CodeSystem/v2-0131"/>

      <display value="Next-Of-Kin"/>

      </coding>

      </relationship>

      <name>

      <family value="Smith"/>

      <given value="Aunt"/>

      </name>

      </RelatedPerson>

      USPathologySpecimen marks Specimen.collection as Must-Support but no child elements are designated Must-Support

      FHIR-33508

      Persuasive

      jmandel

      Are there specific expectations about what elements within {{collected}} must be supported? If not, what is the intention behind marking the {{collected}} field as Must-Support?

      h2.  

      block-vote-3

      Will flag the following .collection child elements as MS: .collectionDateTime, .method, and .bodySite.

      US Pathology Bundle: Repeating pathology-related-practitioner

      FHIR-33507

      Persuasive

      jmandel

      If a given practitioner has >1 related role in the required valueset (e.g., one individual might be admitter, attender, referred, and ordered), this is awkward to express, since it requires supplying multiple PractitionerRole resources each with a single {{code}}. Is this intentional? It would better leverage existing semantics ({{PractitionerRole.code}} is {{0..*}}) to allow multiple codes, rather than constraining each instance to a single code.

      h2.  

      block-vote-3

      Agreed. Will update PractitionerRole.code to 0..*

      Definitions of “Sending Systems” and “Receiving Systems” are unclear

      FHIR-33505

      Persuasive with Modification

      jmandel

      {quote}Sending Systems are defined as Provider Systems and applications.

      {quote}

      {quote}Receiving Systems are defined as Provider Systems and applications receiving transactions from the Sending System.

      {quote}

      Are these terms related to the Actors defined above (“Message Sender” and “Message Destination”)? If so, this should be explicit (e.g. by re-using actor names). If not, the actor list should be expanded to include these additional roles.

      h2.  

      block-vote-3

      Will update sending and receiving systems' definitions to clarify.



      Sending systems are defined as systems that generate and push data within a pathology lab workflow. These systems may be used by clinicians (ie Oncologists) when ordering the pathological analysis for a patient, which will necessarily entail the collection (procedure) of said specimen, and sending of this specimen to a lab. These systems may also be use by Pathologists in cases of completed analysis and reports that need to be sent back to an clinician and/or to a cancer registry. 



      Receiving systems are defined as systems that receive and are expected to process data within a pathology lab workflow. These systems may be used by Pathologists (ie LIS, associated interface engines) when receiving a specimen and a request for analysis. These systems may also be used by Clinicians who ordered the lab analysis/report. Also,these systems may represent central registries who aggregate and analyze pathology lab information.

      Clarify use of dataAbsentReason

      FHIR-33504

      Persuasive

      jmandel

      {quote}If the information does not exist and the cardinality of the element is >= 1…*, the Sender SHALL use the dataAbsentReason extension where it is defined. Note: populating the element with the value set absent reason or using the dataAbsent Reason SHOULD be handled by the Sending System and not require provider action.

      {quote}

      There should be a link to the relevant extension guidance and examples of its use. The terms {{dataAbsentReason}} and {{dataAbsent Reason}} are both used; is one a mistake?



      The meaning of the phrase “populating the element with the value set absent reason” is unclear. What is a “value set absetn reason”?

      h2.  

      block-vote-3

      Examples of dataAbsentReason extension will be added



      Will add link to relevant extension: [https://www.hl7.org/fhir/extension-data-absent-reason.html]



      dataAbsent is a mistake and will be correct (guidance should only refer to dataAbsentReason).



      The ValueSet in reference is the required 'DataAbsentReason' ValueSet (https://www.hl7.org/fhir/valueset-data-absent-reason.html)

      Formatting error in “Must Support and Missing Data”

      FHIR-33503

      Persuasive

      jmandel

      {quote}**All Receiving Systems: **Receiving Systems are defined as Provider Systems and applications receiving transactions from the Sending System.

      {quote}

      The asterisks are offest for “All Receiving Systems”

      h2.  

      block-vote-3

      All Receiving Systems formatting/spacing will be corrected so that this phrase appears bolded (similar to All Sending Systems)

      Clarify “Claiming Conformance to This Specification”

      FHIR-33502

      Persuasive

      jmandel

      Is there any explicit declaration of support in a server’s CapabilityStatement (e.g., via [http://build.fhir.org/capabilitystatement-definitions.html#CapabilityStatement.instantiates] or [http://build.fhir.org/capabilitystatement-definitions.html#CapabilityStatement.implementationGuide])? This should be documented.

      h2.  

      block-vote-3

      CapabilityStatements declaring the expected supported behaviors of FHIR servers for all actors involved will be included in the guide for publication. Cooresponding CapabilityStatements for associated Clients will also be included, where applicable.

      Term “consumer” is unclear in definition of “Message Sender”

      FHIR-33500

      Persuasive

      jmandel

      {quote}Message Sender: An application sending a pathology report message to a consumer.

      {quote}

      Is “consumer” here meant to indicate “Message Destination”? If so, the latter term should be used.

      h2.  

      block-vote-3

      Yes, will update Message Destination in this sentence.

      Table of “FHIR Profiles to Capture NAACCR Volume V” is unclear

      FHIR-33499

      Persuasive

      jmandel

      In the table at [http://hl7.org/fhir/us/cancer-reporting/2021Sep/background.html#background] it’s unclear what’s content and what’s header material. In some cases there appear to be two headers in a row (“PATIENT RESULT”, then “PATIENT:”), and the use of colons after capitalized terms is inconsistent. The FHIR profile column should include links to the relevant artifacts.

      h2.  

      block-vote-3

      This table will be reformatted to clearly represent the intended column headers. Also, hyperlinks to relevant FHIR profiles will be added where possible.

      Reusing provider role codes from Table 0443

      FHIR-33492

      Persuasive

      craig.newman

      Why have you chosen to create your own code system for provider roles rather than reusing the v2 table 0443 which has those same 4 codes? For that matter, table 0443 has the codes for the 4 roles being drawn from the v3 code system that the value set uses. Rather than drawing from two code systems would it make sense to just use the single v2 table?

      block-vote-3

      Will remove US PractitionerRole CodeSystem and will use existing HL7v2 table 0443 for these 4 concepts.

      Contstraint on parent specimen

      FHIR-33484

      Persuasive

      craig.newman

      If Specimen.parent is going to be flagged as Must Support in the profile, does it makes sense to constrain the reference to the US Pathology Specimen profile rather than just the base Specimen resource? If the report is going to contain data on the parent specimen do you want it to use this same profile?

      block-vote-3

      Yes; will update Specimen.parent to reference the Specimen profile defined in this guide.

      .meta.security is Must Support without an indication of how to use them

      FHIR-33481

      Persuasive

      craig.newman

      In the MessageHeader profile, .meta.security is labelled as Must Support but there doesn't seem to be any explanation of how to use this element. Is it sufficient for the sender just to populate the element from the usual value set? Is there something unique about this workflow which requires security labelling? Please clarify the use case specific security requirements.

      block-vote-3

      This is a mistake; .meta.security is not intended to be flagged as MS. There is nothing special about the .meta element for this profile beyond general FHIR security considerations.



      Will remove .meta.security MustSupport flag.

      Should .focus be required in the MessageHeader profile?

      FHIR-33480

      Persuasive

      craig.newman

      In the Bundle profile, a DiagnosticReport entry is required (1..1) but in the MessageHeader profile, the focus which points to the same DiagnosticReport profile is 0..1 and Must Support. Is there any scenario where the DiagnosticReport would be in the Bundle but wouldn't be the focus of the Message Header or should focus be 1..1 as well?

      Block-Vote-3

      There is no such case; MessageHeader.focus should be 1..1. Will update the IG accordingly

  • Project Updates
    • Cancer Pathology Reporting 
      • Working on ballot reconciliation for Cancer Pathology Reporting FHIR IG - NEXT BLOCK VOTE #3 for next call (see above)
      • Project page: Cancer ePathology Reporting
      • Meetings:
        • Every Wednesday 10 - 11 AM ET starting 10/20
    • IHE SDC/eCC on FHIR 
      • no update
      •  Meeting
        • Every Wednesday 2 -4 PM ET
      • Project page: IHE SDC/eCC on FHIR
      • Call is listed on call calendar as 1 hour call, since conference center won't let calls overlap
    • OO on FHIR
      • Working through jiras
      • Meetings:
        • Every Tuesday 2 -3 PM ET
    • LAB (LIVD/LRI/LOI/eDOS) 
      • Topics:
        • How to add the qualitative result value mapping into the IICC spreadsheet

        • Working on FHIR based spreadsheet to help finalize examples and completeness for LIVD - publication still delayed a bit.
        • LabOrder Conceptual Model DAM ballot reconciliation
          • Need to wrap up ballot reconciliation and votes. 
      • Meeting
        • Every Friday, 1-2pm ET
      • Project pages link:
    • Nutrition
      • no update
      • Meetings
        • Every other Wednesday 2-3 ET starting 9/29
      • Topics:
        • Ballot reconciliation
      • Project page link: Nutrition
    • Order Service Catalog
      • given some special build that has to happen for the connectathon, so those IGs that are based on R5 constructs, this could mean these IGs can go to May 2022 ballot (core freeze is March 4, 2022)
      • Meeting
        • Every Friday, 12-1pm ET
      • Topics:
        • Devices and medications
      • Project Page Link: http://wiki.hl7.org/index.php?title=Ordering_Service_Project

    • Specimen
    • CIMI/Concept Modeling
      • No update
      • Will do Vital Sign IG ballot reconciliation on main OO calls
      • Meeting once a month on Tuesdays 2 -3 PM (also overlaps with OO on FHIR)
    • DME
    • Healthcare Product: Device/DeviceDefinition/UDI
      • given some special build that has to happen for the connectathon, so those IGs that are based on R5 constructs, this could mean these IGs can go to May 2022 ballot (core freeze is March 4, 2022)
      • reviewing device, deviceDefiniton, biologicalyDerivedProduct, nutritionProduct
      • normative attributes on several OO owned resources for R5
      • Meeting: Every Monday 3 -4 PM ET
      • Project Page Link: Healthcare Product
    • Supply meeting
    • V2+ 
      • no update
      •  Meetings:
        • Every other Friday, 9-10am ET starting 10/1
      • Topics:
        • Aiming for Jan 2022 ballot, but may need to
        • New stuff for base v2
          • SDOH discussions may need to have V2.9.1 or do we adjust V2+ content – Riki will put on V2 Management agenda
      • Project Page Link: V2+
    • V2-to-FHIR 

From Chat:

From Andrea Pitkus, PhD, MLS(ASCP)CM to Everyone 10:22 AM

CLIA rvw would be needed

From Dan Rutz to Everyone 10:24 AM

Only if it's for the purpose of *replacing* another CLIA-approved result distribution mechanism though, right?

From Andrea Pitkus, PhD, MLS(ASCP)CM to Everyone 10:26 AM

What do you mean Dan? CLIA doesn't specify how, but it applies to all labs (except exempt states of NY and WA)

Alex is checking into more stringent CAP requirements too.

What I'm not clear about in FHIR is where there are corrected results and the original and update need to be sent, how that'd be done.

From Dan Rutz to Everyone 10:27 AM

I mean only if an EMR is consuming the result this way instead of by existing approved v2 or fax or whatever routes.  If some other system (research, process improvement, whatever) kind of system wants to use this data outside of patient treatment, that's not necessarily covered by CLIA right?
From Andrea Pitkus, PhD, MLS(ASCP)CM to Everyone 10:29 AM
No Dan.  Some of CLIA applies to all uses of lab data to the "end user" while others like CAP interface checks apply from the LIS to the first downstream entity only whether it's the EHR, Public Health, a data warehouse, etc.
From Andrea Pitkus, PhD, MLS(ASCP)CM to Everyone 10:31 AM
That's why we need a CLIA review of all lab related FHIR resources similar to what we did for LRI, ELR S&I framework.  I've seen a variety of FHIR implementations, some missing lab reference ranges, specimen info and other details needed for clinical decision making.
From Andrea Pitkus, PhD, MLS(ASCP)CM to Everyone 10:39 AM
Ralf, might this overlap with IHE-LAW too?
From Ruby Nash to Everyone 10:49 AM
Hi all - don't want to interrupt the flow here - just wanted to let O&O members know that we have sent out Block Vote 3 for the Cancer FHIR IG. Please review, as we aim to seek a vote during this meeting next week. Thanks!