Laboratory Analytical Workflow
Enhanced Laboratory Device Automation (ELDA)
The motivation for developing this enhanced version of Laboratory Device Automation is as follows:
Use Cases
Use Case 1: Unsolicited New Work Order Step Download
Scope: Patient & QC
Purpose: This use case allows the LD to have a list of all the new WOS to be done before specimen (patient or QC) arrival. The AM is the master and decide when to send the information to the LD. Allow the LD and its operator to have a visibility on the work (suggested by the AM) to be done.
Synopsis: Message sent by the AM. The AM sends the WOS to the LD (potentially multiple LDs) as soon as they are available. AM is responsible to distribute the WOSs along all the connected LDs based on capabilities, workload and other distribution stuff rules. The LD confirms (application acknowledge) the reception and the validity of the WOS download message. Criteria for acceptance to be decribed in use case.
IHE LDA: -(Patient) Use Case 5.2. 1 WOS downloaded before specimen arrival -(QC) Use Case 5.2.6.1QC downloaded by AM
Comments from 8/27/09 review meeting with technical comittee Acknowledge #1 (message reception) will be mandatory and covered for all messages (ie all use cases) by the low level protocol
Acknowledge #2 (renamed application acknowledge) will also cover persistence aspect and will be mandatory
Use Case 13: Upload to AM preliminary results generated on LD
Scope: Patient & QC
Purpose: This use case allows to report observations information to the AM as soon as it's available and the internal technical validation rules decide that it is not considered as final observations. Allow AM to report preliminary results (for example to physicians) without waiting final result to be available.
Synopsis: Message sent by the LD in an unsolicited way.
IHE LDA: Not in LDA today.
Use Case 18: AM informs LD about observation validity status (application aknowledge)
Scope: Patient & QC
Purpose: This use case allows to acknowledge the valididy of the results for the AM system (application acknowledge). This message allows LDs to apply a different level of presentation to the observations that has been confirmed as valid by AM.
Synopsis: Message sent by the AM after reception of results sent by LD.
IHE LDA: Not in LDA today.
Use Case 25: Reflex test decided on LD
Scope: Patient & QC
Purpose: LD runs a different test from the previous one. A new result is generated for a WOS that was not asked by the AM.
Synopsis: Refer to rerun above
IHE LDA: Not in LDA today.
Use Case 26: Reflex test decided on AM
Scope: Patient & QC
Purpose: AM triggers a new WOS.
Synopsis: Refer to rerun above
IHE LDA: Not in LDA today.
Messaging Topics
Selection of baseline HL7 version (2.6 or 2.7)
- It has influence on data types (CE vs. CWE/CNE, e.g., MSH-19).
- It has influence on message structure, e.g. use of UAC segment.
“Enhanced acknowledgment” in addition to the “Original Acknowledgment”
- It determines, e.g., cardinality (mandatory) use of MSH-15, MSH-16, ...
- The "Original Acknowledgment Mode" of HL7 v2.6 (ch. 2.9.2) required by IHE (see LAB TF-2 ch- 2.4.4) has only one acknowledgment level reporting positive ack, when the application processed it and the storage is guaranteed.
However in some scenarios the 2 level acknowledgment with following interpretation of acknowledgments levels corresponding to the Enhanced Acknowledgment of HL7 v2.6 (ch 2.9.3) could be advantageous:
- General (accept) acknowledgment: Syntax validated & correct, persistence guaranteed
- Application acknowledgment: Semantics validated, correct and processed by the application for storage in the destination repository (DB with semantically structured information), application specific resources sufficient.
Rationale: The Original acknowledgment limits the design of the laboratory systems, e.g., LD promoting a monolytic design and/or large transactions involving communication services and applications. This Enhance acknowledgment permits design of the system (e.g., LD) having decoupled connectivity services from multiple applications running on the system. The connectivity services of the LD may check the message syntax, persist the message in an unstructured format, respond with the "accept acknowledgment" and pass the message to the subscribing application(s). The application(s) analyze the semantics (e.g., Test Orders fitting the LD system configuration), check resources (e.g., consumables available on the LD system), store the data from the message in a structure format for further processing (e.g., in DB) and send the "application acknowledgment" to the originating system (e.g., AM). Please read the HL7 v2.6 (ch 2.9.3) for more details.
Asynchronous message flow (overlapping queries)
- This asynchronous message flow will be application for all use cases/messages with the exception of low level ack.
Repeatability of certain fields
- “Equipment Instance Identifier” (EQU-1) make repeatable to express nesting change in HL7 required
- “Abnormal flags” (OBX-8) make repeatable as in HL7
- “Specimen Description” (SPM-14) make repeatable as in HL7