Laboratory Analytical Workflow

Laboratory Analytical Workflow (LAW) Profile

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

Background

IICC

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.

Analysis of LDA Profile

Using the LDA integration profile as a starting point, an IICC Technical Team identified actors and use cases that cover these message exchanges.

Actors

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.

Use Cases

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.

The following is the list of LDA Use Cases that IICC proposes extending:

• Unsolicited new Work Order Step (WOS) download
• Unsolicited WOS update or cancel
• LD query for WOS for specific specimen(s)
• WOS manually entered at LD
• Upload to AM final results generated on LD
• Rerun decided on LD
• Rerun decided on AM

In addition, IICC proposes adding the following new use cases:

• LD query for WOS for all specimens
• LD informs AM about WOS validity status
• Upload to AM preliminary results generated on LD
• Retransmit results to AM
• AM informs LD about observation validity status
• Pooling of patient specimens
• Reflex test decided on LD
• Reflex test decided on AM

Further details about the use cases are discussed ins the sections 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 validity 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: Should schedule follow-up calls to better understand use in industry. Is this molecular diagnostics specific? Blood bank? How is this used and what fields are needed?

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.

Comments from 10/1 IHE Meeting: Unsolicited result recommended. Needs documentation.

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.

Comments from 10/1 IHE Meeting: Needs further discussion with query / broadcast mode. See action items. Should this be represented as an add-on or new WOS?

Use Cases Requiring Extensions

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

Comments from 10/1 IHE Meeting: Part of broadcast / query discussion.

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

Comments from 10/1 IHE Meeting: Accepted. Decision - supporting sequential and overlapping query work.

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

Comments from 10/1 IHE Meeting: AM needs to support unsolicited results.

Use Case 14: Transmit 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

Comments from 10/1 IHE Meeting: Accepted. Needs documentation/message review.

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

Comments from 10/1 IHE Meeting: Accepted. Documentation.

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

Comments from 10/1 IHE Meeting: Accepted. Documentation.

Use Cases Out of Scope

Use Case 6: LD Query Demographics

Scope: Patient

Purpose: This use case is very relevant in Point Of Care scenarios where instruments are not working with preliminary orders.

Synopsis: Message flow initiated by the LD. LD is asking for demographical information related to a particular patient. LD usually identifies the questioned patient by means of its Patient ID. However, other related identifiers are allowed such as Specimen ID, Accession Number, Account Number, etc. AM responds always with the known information if any related to the requested criteria.

IHE LDA: None.

NOTE: Point of Care is out of scope, so this use case will not be considered for future implementation.

Use Case 9: LD informs AM about WOS storage commitment

Scope: Patient & QC

Purpose: This use case allows to acknowledge the storage of the WOS in the LD This message allows AMs to apply a different level of presentation to the WOS that has been confirmed as stored in LD.

Synopsis: Message sent by the LD after storage of WOS sent by AM.

IHE LDA: None.

NOTE: The application level acknowledge of use case #8 covers the persistence of the WOS.

Use Case 10: Specimen is available at LD (a.k.a. Specimen status)

Scope: Patient & QC

Purpose: This use case allows a LD to inform an AM when specimen arrives at LD but without requesting for WOS (generally used when WOS are sent in a unsolicited way to LD. AM is able to track location of specimen(s) in the lab. Could be used to measure workflow efficiency.

Synopsis: Message sent by LD. LD sends a “specimen arrived” notification to the AM.

IHE LDA:

• (Patient) Use Case 5.2.1 c)
• (QC) not mentioned in IHE

Note: This use case will be considered for inclusion in a future version.

Use Case 11: WOS in progress at LD

Scope: Patient & QC

Purpose: This use case allows AM to know the current status of all the WOS sent to LDs. AM able to control the activity of each LD connected (eg pipetting status, error during analytical operation).

Synopsis: Message sent by the LD. As soon as the status of a specimen changes the LD notifies new status to the AM.

IHE LDA:

• (Patient) Use Case 5.2.1 s)
• (QC) not mentioned in IHE

Note: This use case will be considered for inclusion in a future version.

Use Case 12: Unsolicited upload of instrument specimen ID

Scope: Patient

Purpose: This use case allow to properly manage situation when sample ID are frequently reused in a lab and when AM sample identification might be confusing for the LD. The unique identifier is controlled by the LD and not by the AM.

Synopsis: Message sent by the LD. After receiving a WOS from the AM the instrument generates a locally unique identifier for the sample and uploads it the AM. From that moment on this becomes the identifier to refer that sample in later messaging between the LD and AM.

IHE LDA: The AM actively assigns an ID to the WOS to be downloaded.

Note: This use case is excluded.

Use Case 16: Upload to AM results modified on LD after initial send

Scope: Patient & QC

Purpose: This use case allows to update AM about results that have been modified on LD after their initial sending to AM. Operator of the LD is able to update results after sending them to AM.

Synopsis: Message sent by the LD in an unsolicited way to inform AM about updated results.

IHE LDA: None.

Note: This use case is excluded.

Use Case 17: AM informs LD about results modified on AM after initial send

Scope: Patient & QC

Purpose: This use case allows to update LD about results that have been modified on AM. LD able to be a repository of patient results (i.e. to always have up to date patient results)

Synopsis: Message sent by the AM in an unsolicited way to inform LD about updated results. This message is applicable to Patient Observations as well as QC Observations.

IHE LDA: None.

Note: This use case is excluded.

Use Case 19: AM informs LD about observation storage commitment

Scope: Patient & QC

Purpose: This use case allows to acknowledge the storage of the results in the AM system This message allows LDs to apply a different level of presentation to the observations that has been confirmed as stored in AM.

Synopsis: Message sent by the AM after storage of results sent by LD.

IHE LDA: None.

Note: The application level acknowledge of use case #18 covers the persistence of the observation.

Use Case 20: AM queries the LD about results

Scope: Patient & QC

Purpose: Allow the AM to query LD about results.

Synopsis:

IHE LDA: None.

Note: This use case is excluded as it is not common outside of point of care testing.

Use Case 24: Rerun decide on OF (order filler)

Scope: Patient & QC

Purpose:

Synopsis:

IHE LDA:

• (patient) Use Case 5.2.4.3 Rerun decided during clinical validation on the Order Filler
• (QC) none

Note: This use case is excluded as the source of AM or OF are not significant to LD.

Use Case 27: Install and configure interface between AM and LD

Scope:

Purpose: Configure AM and LD through through the exchange of messages across the interface. This could be interfaces configuration, as well as exchanging information about assignment of tests and LD consumables (such as reagents).

Synopsis:

IHE LDA: None.

Note: This use case will be considered for inclusion in a future version.

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 : a new profile LAW : Laboratory Analytical Workflow

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.

“Synchronous” and “Overlapping” Queries

Sequential Query Message Exchange

Attributes

• Mandatory capability (Analyzer and Analyzer Manager)
• Sequential transactions
• Timeout on order reply

Description Two sequential HL7 message exchanges are required for this transaction. In the first exchange, the Analyzer will send a query request to the Analyzer Manager, which will check the syntax of the message and immediately responds with a query response. The response contains no work order steps.

Once the analyzer manager determines there are WOSs for the specimen that the analyzer can perform, it will send an OML^O33 order message containing the work order steps. The analyzer will send an ORL^O34 order response that contains the status of the WOS through the use of the response segment group.

If the analyzer manager determines there are no WOSs for the specimen, it will send an OML^O33 order message indicating that no WOSs exist. The order segment group is not provided in the order message. The analyzer will response with an ORL^O34 order response that does not contain a response segment group.

If the OML^O33 order message is received after the define timeout period, the analyzer will indicate with the ORL^O34 if the “late” order is accepted (OK) or rejected (UA). There is no provision to cancel the query. The profile does not specify whether the analyzer should accept or reject the “late” order.

Lab-XX WOS Sequential Query (equivalent to LDA Lab-22 WOS Query)

Note:

1. SPM-21 is a specimen rejection reason. One options is to use the existing RI (identification problem code). Or, an additional code to table 0490 to include a specimen unknown (no orders exist) reason. This is a CWE data type, so a new code would be required.
2. Use the SAC-8 with U, to indicate unknown. This is not currently supported by IHE. No HL7 changes.
3. An ORC/OBR could be used, but the OBR would contain no information. Plus, there is no field that is intended for the information.

Overlapping Query Message Exchange

Attributes

1. Optional capability
2. Overlapping transactions
3. Timeout on order reply

Description Two HL7 message exchanges are required for this transaction. These two messagae exhanges may overlap with other query message exchanges. In the first exchange, the Analyzer will send a specimen status update SSU^U03 to the Analyzer Manager, which will check the syntax of the message and immediately response with a general acknowledgement. The analyzer can send one or more SSU messages prior to receiving the corresponding OML^O33 order message. It is not required that the order message replies be received in the same order as the specimen status updates.

Once the analyzer manager determines there are WOSs for the specimen that the analyzer can perform, it will send an OML^O33 order message containing the work order steps. The analyzer will send an ORL^O34 order response that contains the status of the WOS through the use of the response segment group.

If the analyzer manager determines there are no WOSs for the specimen, it will send an OML^O33 order message indicating that no WOSs exist. The order segment group is not provided in the order message. The analyzer will response with an ORL^O34 order response that does not contain a response segment group.

If the OML^O33 order message is received after the define timeout period, the analyzer will indicate with the ORL^O34 if the “late” order is accepted (OK) or rejected (UA). There is no provision to cancel the query. The profile does not specify whether the analyzer should accept or reject the “late” order.

NOTE: discuss the order never received as a separate use case.

Lab-XX WOS Overlapping Query

Remark:

The WOS transfer for both response to query information flows described above and for the unsolicited transfer use the same messages (OML^O33 -- ORL^O34) - see below.

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) ==> DONE
3. Change Proposals to existing technical framework (IHE has a form for this).
4. OBX 8-Abnormal flag for repeatability (Andrzej, Francois) ==> DONE
5. SPM14-Specimen description repeatability ==> WITHDRAWN
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) ==> DONE
30. Documentation overlapping and sequential queries decisions on the wiki (Ed, Andrzej) ==> DONE
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) ==> DONE
37. Recruit participants for a call to discuss pooling use case. (Andrzej, Sondra)
38. Review MLLP protocol (1-2 port communication) (Ed H, Andrzej, Francois)