Laboratory Analytical Workflow

Enhanced Laboratory Device Automation (ELDA)

The motivation for developing this enhanced version of Laboratory Device Automation is as follows:

Background

The IVD Industry Connectivity Consortium (IICC) is an organization founded by the top worldwide IVD manufacturers to catalyze worldwide modernization of standards to reduce the costs and inefficiencies associated with device interfacing. Founding members of IICC include leading IVD manufacturers (Abbott Diagnostics, Beckman Coulter, Becton Dickinson, bioMerieux, Ortho Clinical Diagnostics, Roche Diagnostics, and Siemens Healthcare) and two IT companies (Data Innovations and Systelab Technologies). Subsequent to the founding of IICC, the following companies have become full members: Orchard Software (IT).

Laboratories and their vendors spend a great deal of time and money connecting analyzers and IT systems to one another. This is a worldwide challenge that results from inconsistency in the way that data exchange standards are applied in most modern laboratory equipment.

Through a joint effort with the IHE Laboratory Technical Committee, IICC intends to improve interoperability between IVD testing systems and health informatics systems by reducing complexity and variability in the exchange of information for patient and QC test orders and the exchange of information for patient and QC results. The exchange of any other information is currently out of scope but could be considered in further revisions.

Using the LDA integration profile as a starting point, an IICC Technical Team identified actors and use cases that cover these message exchanges. The IHE Laboratory actors considered relevant for the IICC use cases are:

1. Laboratory Device (LD) – represents the IICC IVD testing system
2. Automation Manager (AM) – represents the IICC health informatics system. IICC recommends this actor be renamed as Laboratory Device Manager to reduce confusion with an automation manager for an automation track.
3. Order Filler (OF) – manages laboratory orders. It is still to be determined if the actor is necessary to define the content of the IICC message exchanges.

A review of Section 5 of the IHE Laboratory Technical Framework, Volume 1 indicated that the LDA use cases were relevant for IICC messaging, with the exception of the use case in Section 5.2.4.3 Rerun Decided During Clinical Validation on the Order Filler. This use case is considered out of scope for the IICC activities.

Proposed new use cases and impacts to existing LDA use cases are described below.

New Use Cases

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.

Comments from 10/1 IHE Meeting: In progress. Work under way to further document use cases (see assigned tasks) and derive suggestions from these use cases. (Rob/Jean/Filip/Ed)

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

Comments from 10/1 IHE Meeting: Accepted. Documentation requirement (see action items - cp). (Francois)

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 committee: the LD operator is the trigger of this information flow.

Comments from 10/1 IHE Meeting: Accepted. Needs documentation. No message change needed.

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 21: Pooling of patient specimens

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:

1. AM is managing the result allocation to patients. The message sent by the LD must contains a reference for the pooled sample.
2. 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

Comments from 10/1 IHE Meeting:

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.

Other 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:

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

Comments from 10/1 IHE meeting: Accepted for inclusion in new LWA profile. QC/Patient will be handled in one transaction.

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

Comments from 10/1 IHE Meeting: Not needed in LAW profile. Recommend analyzer send ORL "UA".

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

Messaging Topics

Selection of baseline HL7 version (2.5.1 or 2.6 or 2.7 or 2.8)

• 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”

Situation: 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 use cases 8 and 18 (see above) may be easily implemented using the Enhanced acknowledgment.
• 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.

Remark: The decision of using Enhanced Acknowedgment influences the cardinality (mandatory) use of MSH-15, MSH-16, ...

The consensus established during ftf meeting on this acknowledgement topic is documented in the decision section below.

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

1. “Equipment Instance Identifier” (EQU-1) make repeatable to ensure this field consistent with OBX-18 and to support the possibility to express hierarchical representation of Equipment Identifiers (recursive hierarchy like in “Russian dolls”) => change for HL7 2.8 required.
2. “Abnormal flags” (OBX-8) make repeatable as in HL7
3. “Specimen Description” (SPM-14) make repeatable as in HL7

Decisions

Meeting September 30, 2010

Actors

Action : Get feedback or confirmation on the proposal of introducing new actors when splitting up the roles within the LDA profile related to Specimens and Analytical Workflow actions.

It is suggested to create 2 separate profiles out of the existing version of Lab device automation (LDA) and renaming the actor Automation Manager into a more explicit actor related to its profile.

• 1) An Analytical oriented profile dedicated for analytical processing devices having 2 actors :

    Analyzer Manager as Analytical Work Order Step Placer [AWOS Placer]
    Analyzer as Analytical Work Order Step Filler [AWOS Filler]. 

• 2) A Specimen oriented profile dedicated for Pre/Post processor devices like Aliquoters, Centrifuges, sorters, tracking devices, having 2 actors :

    Automation Manager as Specimen Work Order Step PLACER [SWOS PLACER] 
    Pre/Post-processor as Specimen Work Order Step FILLER [SWOS FILLER]

The current implementation of Lab device automation (LDA) Can become :

1) Laboratory Analytical Workflow

In cooperation with IICC, a priority shall be given to the profile Laboratory Analytical Workflow with the 2 actors Analyzer Manager and Analyzer.

This new profile shall provide a support to the global world of IVD instruments performing laboratory analytical work.

We would like to hear your comments or confirmation to continue with these naming Profile : Laboratory Analytical Workflow (LAW) Actors : Analyzer Manager (ANM) – Analyzer (AN)

Q :

Do you agree on the suggestion ? Yes 

If not agreed : please provide your feedback and comment your arguments to the group

2) Laboratory Device Automation

The existing profile LDA shall be kept restrained to the non-analytical work order steps, i.e. the two actors "Automation Manager" and "Pre-post processor" and the transactions that flow between them, that is:

• WOS download (LAB-21)
• Query for WOS (LAB-22)
• SWOS status change (LAB-26)

Transaction "AWOS Status Change" (LAB-23) and actor "Analyzer" will be deprecated from this existing profile.

This LDA profile will then be dedicated to all aspects of Devices performing non-analytical tasks on specimens.

For backward compatibility reasons, given that a number of vendors (mostly in Japan), have implemented LDA for some years, the remaining artefacts of this profile shall be kept as they are, with their current names.

Q :

Can we keep the name of the profile LDA (Lab Device Automation) ? Yes
Will we keep the names of the actors : Automation Manager – Pre-Post-processor ? Yes

If not agreed : please provide your feedback and comment your arguments to the group

Enhanced Acknowledgment

Remark: see above for the detailed explanation of the rationale.

For compatibility with implementations relying on LAB profiles, as well as with IT Infrastructure leveraged by the LAB profiles, the IHE LAB TF will stick to its original acknowledgement mode for most of its transactions. The enhanced acknowledgement mode shall be required in the new "Laboratory Analytical Workflow" profile. This mode will be operated as follows: The sending application shall populate field MSH-15 with value "ER" and field MSH-16 with value "AL", thus instructing the receiving application to send an "accept acknowledgement" only in case of error at this level (e.g. syntactical error, communication error) and to send an applicative acknowledgement in all other cases. Thus there shall be always one and only one acknowledgement message coming back to the sending application.

HL7 v2 Mapping

Initial work is being done in our Enhanced Laboratory Device Messaging Google spreadsheet. Members of the IHE Laboratory Google Group have access permissions. You may join the google group from this page IHE Laboratory.

Face to Face Action Items

1. Thursday, Sept 30th Assignments
2. Present the delta of use cases between IHE and IICC (Jean Christophe to do)
3. Change Proposals to existing technical framework (IHE has a form for this).
4. OBX 8-Abnormal flag for repeatability (Andrzej, Francois)
5. SPM14-Specimen description repeatability
6. LTW1-No changes. Clarification of actor of automation manager needed?
7. LDA- documentation changes to make the break of the pre-/post- analytical
8. On the wiki, the decision documented with logic behind the decision going forward. Just written (Filip)
9. Then send out an email on the Google Group about this suggestion asking for comments and feedback.
10. Explanation should include what is planned to be done with LDA (all aspects). Document prior to end of meeting Saturday. (Analytical profile with Analyzer Manager and Analyzer)
11. On the wiki, to add the slides Ed presented with the bullet list. This may be in collaboration with the delta of the use cases. (Ed Heierman)
12. Connectathon opportunities to visit North American connectathon (Chicago) in Jan or the European connectathon (Veneto region) in April or Japanese connectathon. There is a day for visitors, except Japan. (IICC marketing task)
13. On the wiki, add the HL7 decision rationale (v2 vs. v3). Discuss with Hans and report back to IHE Lab (Bill O)
14. Merge the use cases from patients and QC.
15. Add Orchard Software to the wiki pages (2 pages) (Rob)
16. Putting documents on the FTP server. Create a folder for these materials (Sondra). Add to the FTP server additional docs (Ed H and Sondra)
17. Create a link to the Google docs off the ELDA wiki site (Sondra)
18. The profile needs to be named from ELDA
19. Decide on how to switch term in the documents from use case to transaction or scenario?
20. GIR (Francois) with Sondra following up with Mary Jungers?
21. Friday, October 1st Assignments
22. Take Filip’s write on Wiki and link to it to Google groups (Sondra)
23. CP to vol2, section 3.10.2.3 (Francois)
24. To better expand on a use case for the expected behavior (broadcast) when you have multiple devices, but it is only run on a single instrument (Rob) (inventory is out of scope)
25. Add an out of scope section to the wiki (Ed Heierman)
26. Write up the discussion with guidance concerning broadcast mode (Ed Heierman)
27. Enhanced Acknowledgement updated/added to vol 2 to fix MSH 15 and MSH 16 (Francois)
28. CP for vol 2 Table 9.5-2 to change the segment from an X to an Optional. (Francois)
29. Documentation of a decision on the wiki that IICC will take the LDA acknowledgement as OK as is (Andrzej)
30. Documentation overlapping and sequential queries decisions on the wiki (Ed, Andrzej)
31. Follow up on the CPs for LCSD (Filip)
32. Followup on CP for XD Lab (Francois and Sondra)
33. Can specimen collection be attached to the entry level?
34. If there are implications for specimen receiving…
35. Documentation for ID specimen container position time. (Filip)
    1. <draft version>
36. Review TF for use of OBX-18 requirements, write CP (?) (Andrzej)