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 IICC 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. See Messaging Topics
Use Case 2: Unsolicited Work Order Step Update or Cancel
Scope: Patient & QC
Purpose:
- In the time between the WOS first download and the specimen (Patient and QC) recognition by the LD, the content of the parent order and Work Order may be modified (suppressing some tests, adding some others, shifting the target LD with another LD) or even canceled.
- For patient only, in case of a broadcast of WOS to multiple LDs, when the results are sent by a given LD, the AM might inform the other LDs that the WOS are now cancelled.
Allow the LD and its operator to have an up to date visibility on the work to be done
Synopsis: Message sent by the AM. The AM sends the updated or cancelled WOS to all the LDs that need to received this information (prior to LD process completion). AM is responsible to track the information that was previously sent to the LDs in order to allow the proper updates and cancellations messages. The LD may confirm (acknowledge) the reception of the updated information.
IHE LDA:
- (Patient) Use Case 5.2. 1 WOS downloaded before specimen arrival
- (QC) not mentioned in IHE
Comments from 8/27/09 review meeting with IICC technical comittee: This use case is not for reflex test (which is a specific use case listed below). This use case applies to WOS updates that happen prior to execution. This update can include demographic update. Note: the IHE approach to uniquely identify each WOS will be used (so that for example patient will be garanteed to the the same patient as initial WOS).
Use Case 3: LD Query for WOS for Specific Specimen(s)
Scope: Patient & QC
Purpose: This use case allows the LD to have a list of all the new WOS to be done when specimen(s) (patient or QC) arrives (is identified). The LD knows the up to date work to be done when specimen(s) arrives. Sometimes Host Query response is critical in time since the instrument sampling process work flow depends on such response to properly proceed.
Synopsis: Message flow initiated by the LD. LD is asking actively for the related WOS associated to specific specimens (patient or QC). AM responds always with all pending WOS related to the requested specimens even if they were previously downloaded.
IHE LDA:
- (Patient)Use Case 5.2.2 Query the WOS when specimen arrives
- (QC) Use Case 5.2.6.2 QC scheduled by the AM, queried by the LD
Comments from 8/27/09 review meeting with IICC technical comittee: Container should be uniquely identified. Primary key definition is out of scope of IICC.
A time out will be defined to manage answering timing.
LD strategy to adopt in case of time out is LD responsibility (ie outside of IICC scope).
Use Case 4: LD Query for WOS for ALL Specimens
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 LD is the master and decide when to receive the information from the LD. Allow the LD and its operator to have a visibility on the work (suggested by the AM) to be done Note: This service is especially interesting (non-exclusive) for instruments that are non-permanently connected and want to manage locally the load list.
Synopsis: Message flow initiated by the LD automatically (i.e. a timer event) and / or manually (i.e. an operator action on the LD). LD is asking for the complete set of WOS associated to the specific device and regardless any specimen. AM response is based on previous responses to the same LD. In this manner, an already downloaded WOS should not be downloaded again in a subsequent request. Typically this message is triggered by a periodical timer or manually by the instrument operator. Instrument used to have a ‘Load List’ view where all pending WOS appears.
IHE LDA: Not mentioned in IHE
Comments from 8/27/09 review meeting with IICC technical comittee: This use case will be kept in IICC (as optional use case) Note: HL7 standards don't fully support this query all use case.
Use Case 5: LD Query Cancel
Scope: Patient & QC
Purpose: Since a Host Query could be critical in time for some LDs (high throughput instruments; non-stop rack conveyors; non-stop sampling systems; etc...) a host query response cannot spend too much time. If for any reason a Host Query is not responded at a time, the LD is able to send a query cancellation in order to allow other interoperability actions for the same communication channel.
Synopsis: Message sent by the LD. It allows the cancelation of the host query when the response has no longer sense for the device.
IHE LDA:
- (Patient) Use Case 5.2.2 specifies update and cancel should not be considered in this use case.
- (QC) not mentioned in IHE
Comments from 8/27/09 review meeting with IICC technical comittee: This use case will be kept in IICC. A time out answer will be equivalent to a WOS cancel.
Asynchronous message flow (overlapping queries) will be allowed in IICC. This asynchronous message flow will be application for all use cases/messages with the exception of low level ack.
Use Case 6: None
Use Case 7: WOS Manually entered at LD
Scope: Patient & QC
Purpose: This use case allows an operator to enter WOS manually on the LD without having an AM sending WOS
Note: The relevance of this use case is to justify that other use cases (such us "Upload to AM final results generated on LD") can be based on manually created orders.
Synopsis: No explicite message flow, just a means to manually enter the WOS. One situation is that AM is not available to send WOS and the operator wants to start the process. Another situation is when LD and AM are not bi-directionally connected. Other situation is for managing STAT samples
IHE LDA:
- Use Case 5.2.3 WOS manually input on LD
- Use Case 5.2.6.3 Unsolicited QC results uploaded to the Automation Manager
Comments from 8/27/09 review meeting with IICC technical comittee: LD will not send the orders back to AM. AM will be informed of these orders when results will be sent. One of the typical use case application is when AM is not able to send information to LD and the operator decide to run a test "manually".
Use Case 8: LD informs AM about WOS valididy status (application aknowledge)
Scope: Patient & QC
Purpose: This use case allows to acknowledge the validity of the WOS by the LD (application aknowledge) This message allows AMs to apply a different level of presentation to the WOS that has been confirmed as accepted by the LD
Synopsis: Message sent by the LD after reception of WOS sent by AM.
IHE LDA: ?
Comments from 8/27/09 review meeting with IICC technical comittee: The notion of application ack will be mandatory (see above)
Use Case 9 to 12: None
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 14: Upload to AM final 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 considered as final observations. AM knows final results as determined by LD.
Synopsis: Message sent by the LD in an unsolicited way. It reports observation information to the AM as soon as it passes the technical validation procedure in the instrument. This message is applicable to Patient Observations as well as QC Observations. The AM may confirm (acknowledge) the reception of the results upload message.
IHE LDA:
- (patient) Use Case 5.2.1 s and 5.2.2 s
- (QC)Use Case 5.2.3 Unsolicited QC results uploaded to the AM
Use Case 15: Retransmit results to AM
Scope: Patient & QC
Purpose: This use case allows to retransmit observations information to the AM in case AM was not able to receive initial send or for testing purpose of the connection to AM.
Synopsis: Message sent by the LD in an unsolicited way. This message is applicable to Patient Observations as well as QC Observations.
IHE LDA: ?
Comments from 8/27/09 review meeting with IICC technical comittee: the LD operator is the trigger of this information flow.
Use Case 16 to 17: None
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.
Comments from 8/27/09 review meeting with IICC technical comittee: The notion of application ack will be mandatory (as for WOS) and will cover persistance (ie storage) aspect.
Use Case 19 to 20: None
Use Case 21: Pooling of patients
Scope: Patient & QC
Purpose: This use case allow to manage situations where multiple patients are pooled into the same sample. This pooling is usually used to screen a large number of samples with high sensitive (and expensive) test and a high number of negative values (eg molecular biology application). In case of negative result, all the patients are declared negatives. In case of positive value as initial result, the lab continues the testing by performing individual testing (or sub poolings).
Synopsis: 2 situations:
- AM is managing the result allocation to patients. The message sent by the LD must contains a reference for the pooled sample.
- LD is managing the result allocation to the patients. The WOS message must include the list of patients (or a reference of the patients) in the pool. The result message (one result per patient) must include a reference of the pooled sample.
IHE LDA: None
Use Case 22: Rerun decided on LD
Scope: Patient & QC
Purpose: This use case allows the LD to inform the AM that a rerun occurred prior to have result upload to AM. The rerun is decided automatically or manually, at the end of the first run. The reason may be:
- Results could not be obtained, due to a flaw on the Analyzer: reagent shortage, needle blocked up, calibration failure…
- Results out of range, triggering a rerun with automatic dilution of the specimen.
AM able to track the LD operations, and to register the reagent consumption.
Synopsis: Message sent by the LD in a unsolicited way containing the result of the initial run and including that the rerun will be executed. The results of the first run either does not exist or are improper. This message is applicable to Patient Observations as well as QC Observations.
IHE LDA:
- (Patient)Use Case 5.2.4.1Rerun decided on LD
- (QC) none
Use Case 23: Rerun decided on AM
Scope: Patient & QC
Purpose: This use case allows the AM to inform a LD that a new run is required. The control (rerun) is decided during the technical validation of the results of the first run, compared with normal ranges, patient’s prior results, and other clinical information, or technical information such as drifting or out of range quality control detected. This decision is taken by the technical staff, or automatically by the Automation Manager application. LD knows rerun to be done
Synopsis: Refer to the sending of a new WOS to the AM in either unsolicited way or query mode or manually entered. The mode depends on instrument configuration and on the localisation of the specimen when the new order is triggered. This message is applicable to Patient Observations as well as QC Observations.
IHE LDA:
- (Patient) Use Case 5.2.4.2 Rerun requested by AM during technical validation
- (QC) none
Use Case 24: None
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