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).

MEETING MINUTES

• Bob shared IG review with FMG
  • Here is the summary document: https://confluence.hl7.org/download/attachments/4489770/FHIR%20Orders%20Exchange%20Review.docx?api=v2
  • FMG agreed with that – they request to get buy-in from the other guides to agree that that is the foundational guide – but need to do the work first
  • FHIR IG proposal has been approved
  • Calls will start back up next week Monday from 12 - 1 PM ET = https://www.hl7.org/concalls/CallDetails.cfm?concall=64276
    • first month topics will be evaluating the other IGs
    • Riki will make sure that calls are on the calendar till September
  • Intent is to ballot in September
• IG Proposal -Clinical Order Workflow (COW)
  • Revisiting the Grouping of Orders topic from last week:
    • Powerpoint shows these options:
      • Group
      • RequestOrchestration
        • (to support complex chemotherapy orders and other complex orders- so in the lab world this may only be needed if this orchestration is prescribed by the placer)
      • CarePlan
      • Requesition
      • The grouper task resource
    • For representing an order Set
    • Grouping of several doctor orders (for instrument use maybe) – do we need to have ServiceRequest here, or would that be grouping via tasks?
    • What about for pooling of samples?
    • What about grouping for specimen processing / testing?
  • Is ServiceRequest just for medicol-legal aspects, so should the filler side even create a serviceRequest?
    • Filler side does track what they get – they call it accession is defined by the receiving lab
      • Can be associated to the sample, or the panel or the requisition
  • Panels are also defined by the testing labs (and maybe also by some billing perspective), they can be on the same panel
  • Placer ServiceRequest exists in the FHIR server of the placer does the filler need to have a copy?
    • Filler MUST retain the businessidentifer of the placer in the ServiceRequest
    • In V2 we have choices for communicating when a order is not the right one – so maybe have to make changes?
    • For Lab task may be good enough, would ServiceRequest be needed in other settings?
      • Radiology
      • Services
    • It may depend on whether the order is across multiple systems vs the same system at the performing lab
    • EHR-s CPOE use their own order names – not the order names of the performing labs -is that a change?
    • Maybe we treat the lab as a black box
  • We do want to report out status updates (order received / order accepted / specimen received / testing started / some results available / final / corrected)?
    • Do we need to create a status resource to do this, since FHIR is essentially stateless
      • the <resource>.status attribute is for the resource instance, not necessarily for the thing the resource is about – similar to the business identifier vs the <resource>.id
    • In V2 ORC-1 is so important (and also the result statuses) and we always send snapshots (though we can also support dynamic updates)
    • If you have multiple statuses for one order how do you deal with the multiplicity – decide what needs to come up in a meaningful way and where does it need to go
    • Maybe create a pattern to help drive subscription?
    • Maybe create a backbone and subscribe to that?
    • Could we make the task on the filler side exposable?
    • Task has
      • focus as reference to the resource - in our case the ServiceRequest from the placer
      • businessStatus as codeable concept without a defined value set (which may be related
      • statusReason (codable reference) – free floating not clear if this is for the business status or the resource status
      • status (for the resource) – code
    • We may need profiles on
      • serviceRequest based on the use case
      • task based on the focus being referenced

Next meeting: March 10, 2023 

FROM CHAT:

• Andrea Pitkus 10:20 AM
  • https://build.fhir.org/ig/HL7/fhir-order-catalog/exlabservices.html
• Andrea Pitkus 10:27 AM
  • Example E5 involves two different specimens which would have different accession numbers. It begins with a single parent order
• Riki Merrick 10:28 AM
  • I don't know if that is ALWAYS 2 different accession numbers for all labs?
• Andrea Pitkus 10:28 AM
  • Have all the use cases in mind been listed out where order grouping is desired?
• Riki Merrick 10:29 AM
  • I don't think we have them all listed
• Andrea Pitkus 10:31 AM
  • IT might help delineate where the different "grouping" models may/may not work for the use cases.
  • Especially if IVD differences, PH differences vs reference lab, hospital lab, clinic lab, etc settings so all are implementable.
  • Assume medications would use FHIR Medication Request: http://hl7.org/fhir/medicationrequest.html
  • for medication orders that are grouped in an order set, say with lab orders
  • or radiology (such as imaging with contrast)
  • or the lab challenge testing (stimulant or depressant)
• Andrea Pitkus 10:39 AM
  • Here's a challenge (see special instructions for dosing, stimulated result, etc.): https://www.labcorp.com/tests/140761/cortisol-acth-stimulation
• Dan Rutz 10:45 AM
  • So worth noting, ORC-1 and ORC-16 are currently not possible to model in FHIR - right?
• Andrea Pitkus 10:45 AM
  • Has that been addressed in the v2 to FHIR WG, Dan?
• Dan Rutz 10:46 AM
  • I do not know, I haven't been closely involved in that project.
• Andrea Pitkus 10:46 AM
  • Me neither ;)
• Andrea Pitkus 10:49 AM
  • ORC-1 lists FHIR Service Request.status and intent.
  • ORC 16 lists FHIR ServiceRequest.extension-request-statusReason
• Dan Rutz 10:50 AM
  • I don't think that's actually right.
• Andrea Pitkus 10:50 AM
  • https://hl7.org/fhir/uv/v2mappings/2020Sep/ConceptMap-segment-orc-to-servicerequest.html
  • Perhaps Ballot comments are needed to fix?
  • this version has even more variety for those items: http://build.fhir.org/ig/HL7/v2-to-fhir/ConceptMap-segment-orc-to-servicerequest.html
  • IT also lists ORC- Diagnostic Report maps: http://build.fhir.org/ig/HL7/v2-to-fhir/ConceptMap-segment-orc-to-diagnosticreport.html
  • ORC 1 doesn't have a map, while ORC 16 has DR extensions
  • There should be a single way of handling for labs
• Andrea Pitkus 11:00 AM
  • Start fleshing out examples from order catalog lab?