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 Details
Date: 2023-07-28
Time: 10AM ET
Coordinates: Join Zoom meeting: https://zoom.us/j/5100467805 | Meeting ID: 510 046 7805 | +1 929-436-2866-US (New York)
Attendees: JD Nolen, Andrea Pitkus, Rob Hausam, Robert Dieterle, Annie Raval, Christina Gallegos, Dan Rutz, Gelu Comanescu, John King, Kathy Walsh, R. Michael Lingenfelter, Ralf Herzog
Chair: Ralf Herzog
Scribe: Ralf Herzog
- Quorum Met
AGENDA
- Workflow Topics
- JIRA Tickets
- AOB?
Meeting Resources
PSS: PSS-2101
IG Proposal: Clinical Order Workflow (COW)
JIRA Tickets: OO Workflow JIRAs
Background Materials
- Review of Existing Workflow Approaches
- Generic Referral: https://build.fhir.org/ig/hl7-be/referral/
- Lab Order Sequence Diagram: http://build.fhir.org/examplescenario-example-laborder.html
- Lab Order slides: (link to >Filespace<
- Belgium
MEETING MINUTES
- Discussion around the topic how data should be transferred to public health (currently done via Order Message to the Lab, then send by the Lab to Publich Health)
- Should not be necessary, because the information is available at the Order Placer, so the reference via the ServiceRequest should be sufficient (but there is a need for the implementation on Public Health side and there is a need to have the appropriate control mechanisms implemtened)
- With FHIR it is possible to only grab data that is needed (i.e. only the "Needed" Patient information - control mechanisms needs to be implemented and followed, but from a conceptual point of view this is available)
- Current Potassium Workflow is way too complex (separate ServiceRequest for Phlebotomist, Subordinate ServiceRequest for Laboratory, ...). Ralf will create a simplified version.
- General approach:
We create one ServiceRequest on the OrderPlacer side, the information is communicated via Task, and Task.output is used to communicate back the results of the Task (from Phlebotomist the Specimen, from Lab the DiagnosticReport, ...)
If needed on the OrderFiller side a FillerServiceRequest is needed for internal handling of the Order, but not communicated to the OrderPlacer, the OrderPlacer only gets via Task the DiagnosticReport where all necessary information is either in or is referenced.
- General approach: