Laboratory Analytical Workflow

From IHE Wiki
Jump to navigation Jump to search


Laboratory Analytical Workflow (LAW) Profile

During development of this work, we are using a variety of tools to communicate our progress towards building the IHE supplement with a goal of June 2011 for public comment. For participants that want a centralized view, here is a list of where information can/should be located.


IHE Supplement (In Progress)

Shared Google Group Document mirrors the IHE Supplement template as much as possible for draft work. If you cannot access this link, it is because you are not a member of our IHE Laboratory Domain Google Group. You can request to subscribe here.

IHE FTP LAW Profile Site backup of supplement files and random other documentation that is shared through this work. Where possible we will provide links on this wiki to the FTP documentation.


IHE Supporting Documentation and Decisions

You'll find it all on this wiki page.


IHE Communication Channels

IHE Lab Domain Google Group postings for updates and soliciting feedback.

Regular Teleconferences scheduled with an agenda on a recurring basis for updates, feedback, progress checks, and assignments.


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. Members of IICC include leading IVD manufacturers (Abbott Diagnostics, Beckman Coulter, Becton Dickinson, bioMerieux, Ortho Clinical Diagnostics, Roche Diagnostics, and Siemens Healthcare) and IT companies (Data Innovations, Orchard Software, and Systelab Technologies).

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.

The IVD Industry Connectivity Consortium Website provides additional details about IICC.

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 in the sections below.

Achieving Plug-n-Play Interoperability

To achieve the IICC objective of plug-n-play interoperability, it will be necessary to constrain the LAW profile by identifying the mandatory elements (use cases, transactions, messaging elements, physical connectivity configuration) of the LAW profile that actors must support. Implementations must provide the default set of profile elements, and must behave appropriately in the absence of optional or non-mandatory elements. The following sections highlight key constraints to established in order to achieve out-of-the box connectivity.

Mandatory Use Cases

A minimum set of use cases can be used to establish the essential behavior expected by each actor. Although other use cases are beneficial, it is the minimum set that allows actors to interoperate with little or no configuration.

A potential set of mandatory IICC use cases could be:

  • LD query for WOS for specific specimen(s)
  • WOS manually entered at LD
  • Upload to AM final results generated on LD
  • Retransmit results to AM
  • Rerun decided on LD
  • Reflex test decided on LD

Mandatory Transactions

Mandatory transactions are derived from the minimum set of use cases. It is important to identify the transaction sequences that support the behavior of the required use cases. Transactions associated with the optional use cases may be supported, but each actor must not be dependent on the optional transaction sequences for proper operation.

Potential list of mandatory transactions:

  • Sequential query message exchange
  • Unsolicited test result transmissions from an instrument

Mandatory Messaging Elements

A message protocol must be selected that allows the behavior of the manadatory use cases to be supported, and the content of the protocol messages must be constrained to identify the required message data elements that support the mandatory use cases. All other message elements will be optional.

Mandatory messaging elements include:

  • Selection of HL7 v2 Protocol
    • 2.5.1
    • 2.7
  • Establish message conformance profile
  • Content required to exchange work order steps and test results
  • Information to understand how a result was produced and what produced the result
  • Standardized vocabularies to minimize "mappings". e.g. LOINC for test codes

Standard Approach for Physical Connectivity

A standard configuration ensures that minimal configuration is required to establish physical connectivity between implementations. This set of contraints eliminates variability encountered due to variations in the use of communication level protocols.

A potential configuration for physical connectivity would be:

  • MLLP socket based connections
  • Each actor provides
    • MLLP Client connection (active transient client)
    • MLLP Server connection (passive listener)
  • Transport level acknowledgements are provided by TCP/IP

Ideal Plug-n-Play Scenario

  • Configure IP/Port for physical connections
  • Attach each actor to the network
  • Exchange work order steps and test results
  • Support for optional elements may require additional configuration

Challenges

  • Establishing a standardized vocabulary
  • Aligning on mandatory set of elements (keep it simple)
  • Determining what compromises can/should be made
    • e.g. standardized test codes
    • Too many compromises dilute the standard making it ineffective

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.

The consensus established during ftf meeting on use of Enhanced Acknowledgment topic is as follows:

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.

Transmitting Work Order Steps to an Analyzer

Objective: Selection of Mandatory Mode for Transmitting Work Order Steps

Two modes are commonly used to transmit work order steps from an Analyzer Manager to an Analyzer: Broadcast mode and query mode. In order to achieve plug’n’play for the analyzer interface, one of the modes should be identified as mandatory and as the default mode. This would allow a connection to be established between an Analyzer Manager and Analyzer that supports the delivery of work order steps without the need for configuration changes and concerns that different modes are being used.

Use Case: Broadcast Mode

General Description:

In this mode, the AM (Analyzer Manager) is responsible for initiating the transmission of WOS (Work Order Step) to the A (Analyzer). This mode would also be appropriate for transmission of orders from the Order Filler to the AM.

TBD: Insert Diagram

Behaviors:

It is the assumption of this mode that there may be one or more Analyzers that may be capable of seeing the specimen and running the required tests, so the AM would be required to broadcast WOSs to all of the appropriate Analyzers. It is also assumed that all Analyzers are configured for broadcast mode.

Analyzers should have ample storage to hold all of the WOSs that might be reasonably run on that analyzer.

Transmission of results is initiated by the Analyzer, and if being sent from an AM, will be subsequently initiated by the AM.

Subsequent to receiving completed work from one of the Analyzers, the AM will be responsible for initiating transmission of a cancel WOS to all of the remaining Analyzers that did not run the test.

The design of this mode should support broadcasting of a WOS revision (update or cancel) to which Analyzers should respond if the revision is accepted. If a result has been created, or is in process, the revision may not be accepted, for example. In a multi-analyzer scenario, a single revision rejection probably means a revision is rejected overall.

The design of this mode should also support broadcasting of WOSs for rerun or reflex decided on the AM. The behavior will be the same for a rerun or reflex as it is for a new WOS. The AM will broadcast the rerun to all AMs capable of running the test. Subsequent to receiving completed work from one of the Analyzers, the AM will be responsible for initiating transmission of a cancel WOS to all of the remaining Analyzers that did not run the rerun/reflex test.

Considerations:

Broadcast mode puts a storage burden on the Analyzers, as they must persist more WOSs than will actually be run on the analyzer. Additional communication between Analyzers and the Analyzer Manager is also required due to the transmission of the orders to all potential instruments and the follow up cancel message.

Broadcast mode is commonly used by an Order Filler for transmitting orders to an Analyzer Manager.

Transmissions:

TBD: Insert Diagram.

Use Case: Query Mode

General Description:

When a specimen arrives at the Analyzer, the Analyzer would be responsible for initiating the transmission of a WOS query to the Analyzer Manager. The AM would respond with tests that the Analyzer should perform on that specimen, or with a negative query response indicating there are no tests that analyzer should run on that specimen.

TBD: Insert Diagram

Behaviors:

It is the assumption of this mode that there may be one or more Analyzers that may be capable of seeing the specimen and running the required tests, so the Analyzer Manager must ensure that a WOS is only transmitted to one Analyzer for processing. It is also assumed that all Analyzers are configured for query mode.

Analyzers and Analyzer Managers should have ample processing and communication bandwidth to complete an order query message interaction in a timely manner.

Upon receipt of the WOS, it is assumed the Analyzer will immediately run the specified test. Thus, the Analyzer Manager will consider the test result to be in progress.

Subsequent to sending WOSs to an Analyzer in response to an order query, the AM will be responsible for preventing other Analyzers from receiving a WOS for that same test and specimen in response to additional order queries.

Transmission of results is initiated by the Analyzer, and if being sent from an AM, will be subsequently initiated by the AM.

The design of this mode does not support revising a WOS (update or cancel) once the WOS has been sent to an Analyzer. Because is assumed that a test result is in progress, revisions cannot be accepted.

The design of this mode should also support querying of WOSs for rerun or reflex decided on the AM. The behavior will be the same for a rerun or reflex as it is for a new WOS. The AM will create the rerun/reflex WOS and wait for an order query from an Analyzer for that specimen. Subsequent to sending a WOS for the rerun/reflex to an Analyzer, the AM will prevent that WOS from being transmitted to other Analyzers that generate an order query for the same specimen.

Considerations:

Query mode puts a processing and communication burden on the Analyzer Manager and Analyzers. Once the specimen is presented to the Analyzer, the query must be communicated to the Analyzer Manager and query response must be received in a timely manner. The assumption is that the Analyzer is ready to process the specimen and Analyzer throughput will be impacted by delays in the query response.

Query mode is not commonly used by an Order Filler for transmitting orders to an Analyzer Manager.

Transmissions:

TBD: Insert Diagram.

Recommendation: Query Mode is a Mandatory Capability

Based on an analysis of the two modes, it is recommended that:

  • Query Mode be made be mandatory, and
  • Broadcast Mode be made optional

Query Mode was selected as a mandatory WOS transmit mode for the following reasons:

  • It is supported by most recent generation analyzers and is commonly used
  • It supports the Client-Server paradigm where the analyzer (client) makes a request of the server (Analyzer Manager) for information
  • It reduces the messaging overhead by eliminating unnecessary messages. A message transaction is initiated only when a sample is presented to an analyzer.
  • It minimize the messaging and storage impacts on the analyzer be eliminating the transmission of work order steps and cancellation of work order steps for tests that will not be performed by the analyzer

“Synchronous” and “Overlapping” Queries

Query mode has been identified as a mandatory capability for the transmission of work order steps from and Analyzer Manager to an Analyzer. Two messaging approaches have been identified that support an analyzer query for work order steps, and they are described below.

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

When the Analyzer Manager has no WOSs for the query, then several options are avaliable for the OML^O33 negative query response. The following options are listed in order of preference:

  1. Use SPM-21, which is a specimen rejection reason. One options is to use the existing RI (identification problem code). Another is add 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, but no HL7 changes would be required.
  3. An ORC/OBR could be used, but the OBR would contain no information. Plus, there is no field in the ORC segment that is intended for this information.

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.

The profile does not define the behavior of the Analyzer if query response is not sent: OML^O33 never arrives. The analyzer may decide to requery or to assume there are no WOSs for that specimen.

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


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.

NOTE: The remainder of the message interactions are the same as the Sequential Query Message exchange once the the query and query response messages have been exchanged. The behavior is repeated below.

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.

When the Analyzer Manager has no WOSs for the query, then several options are avaliable for the OML^O33 negative query response. The following options are listed in order of preference:

  1. Use SPM-21, which is a specimen rejection reason. One options is to use the existing RI (identification problem code). Another is add 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, but no HL7 changes would be required.
  3. An ORC/OBR could be used, but the OBR would contain no information. Plus, there is no field in the ORC segment that is intended for this information.

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.

The profile does not define the behavior of the Analyzer if query response is not sent: OML^O33 never arrives. The analyzer may decide to requery or to assume there are no WOSs for that specimen.

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.

Questions

  1. Should the SSU message be used to trigger an overlapping query? Would this cause confusion with the use of the SSU message? for example, what differentiates a status update from a query request, the receiving actor (Automation Manger versus Analyzer Manager)?
Answer proposal
The Container Status (SAC-8) can have following status codes:
I - Identified
P - In Position
O - In Process
R - Process Completed
L - Left Equipment
M - Missing
X - Container Unavailable
U - Unknown
where per definition the Identified status is used by one system to inform another that it has received a container.
This code (I) means that the equipment has seen the container the 1st time and expects work orders (AWOS from Anylyzer Manager or SWOS from Automation Manager) for this container. All other codes are status update.

AWOS Identification

Section 3.5.3 "Relationships between units of work in the LAB-TF" of the Lab Technical Framework describes each unit of work (order group, order, work order, WOS), and who assigns them. In the LAW profile the AWOS definition was refined, and this definition in the update of section 3.5.3 in the LAW draft.

An AWOS represents a unit of work assigned to one precise analyzer on one precise specimen in one precise container.

Thus, an AWOS can be be characterized by the following attributes:

  1. Analyzer performing the work
  2. Specimen information
  3. Container information
  4. Service (or test) to perform
  5. Patient information (patient ID)

However, there are additional characteristics of the AWOS that make it challenging to use any of the above attributes to uniquely identify an AWOS:

  1. Patient information is optional
  2. The Analyzer typically uses container ID information to identify a specimen, because the container ID is the information available to an Analyzer when scanning a container barcode
  3. Container IDs can be reused, thus over an extended period of time a container ID can be associated with multiple specimens
  4. Multiple test results may be reported for a single AWOS test ordered, e.g. a test panel or a hematology CBC test will have multiple test results

The assignment by the Analyzer Manager (AM) of a unique identifier for the AWOS allows the Analyzer to unambiguously report test results associated with the AWOS independent of the nature of the patient, specimen, container, or test ordered information. The Analyzer must memorize this ID and use it when reporting test results to the AM.

The analyzer works with an identifier of the material , which can be a specimen id and/or a container id, and or a gegraphic location (tray, carrier, plate number ...) of this material. Therefore all messages must link the material identifier to the AWOS identifier, in other words, carry both.

Essentially, an AWOS identifier is a unqiue character string assigned by AM and put in all messages into field OBR-2 whose definition in the standard is "placer order number" and will be translated into the message profiles of LAW into "placer AWOS number".

Sometimes there is also a patient, whom the specimen was collected from, in that case, of course, it's important for the analyzer and for the staff operator to know the basic patient information. In other cases (pooling, QC) there is no patient.


Assumptions

  • A rerun is a new AWOS when it is decided on the AM: New step, same test, same specimen, but potentially new conditions (dilution factor) and potentially new analyzer, new operator ...
  • Conversely a rerun decided on the analyzer side fulfills the same AWOS as the first run: This AWOS will have two results coming back for the same test, potentially in the same message or in two distinct messages. Then the content of the result message must clearly distinguish each run (with its own conditions, time, reagent ...)
  • A reflex test fulfills the original AWOS, at least in the case of an extra measurement added to an AWOS ordering a panel.

In other cases, like microbiology, a reflex test (say an antibiogram) is a child AWOS of the original AWOS.

  • There are some cases (e.g., manual entry on the device before the order is even recorded on the LIS or on the middleware) where the analyzer does not know that number, and still must be able to perform tests on the specimen/container and report back the results thereof, without any AWOS id. It will be then the responsibility of the AM and its operator to manually link the orphan results to AWOSs arrived afterwards.

As a result of requiring the Analyzer to include the AM assigned unique identifier for an AWOS when reporting results, the following scenarios described below must be addressed by the LAW profile.

Report single or multiple tests results for a single AWOS

Each test result reported by the Analyzer to the AM must include the AWOS ID. The AM must support receiving test results reported over a period of time in addition to receiving all test results for an AWOS at the same time. 

Question: If several results are returned, it can be helpfull to have a 2nd ID: an "Analyzer generated AWOS ID".
This enable the Analyzer Manager to known if the result has already been received.
Just consider the case where the Analyzer send preliminary results and some time later final results.
Does we have to take in account this scenario?

Report rerun or reflex test results associated with a single AWOS

In this case, the Analyzer is reporting addition test results that are unexpected by the AM due to an evaluation of the original test results for an AWOS. The AWOS ID is included when reporting test results for additional tests performed either due to a rerun (run same test again) or reflex (run test not ordered). The use of the AWOS ID clearly identifies that the extra test results are associated with the specified AWOS. 

Question: Should the analyzer also report that the test results are for a rerun or reflex test?
 
Does a "Analyzer generated AWOS ID" can solve this problem: We will have 1st ID for the result and
another ID for rerun or reflex test => The Analyzer Manager can diferentiate them.

Report reflex test results associated with multiple AWOS

This is the similar to reporting reflex tests for a single AWOS, except now test results for multiple AWOSs were evaluated by the Analyzer in deciding to run an unordered test and report the result. Potential options are:

  • Option 1: When reporting a test result for a reflex test associated with multiple AWOSs, the Analyzer will include the AWOS ID of the most appropriate AWOS.
  • Option 2: When reporting a test result for a reflex test associated with multiple AWOSs, the Analyzer will include the AWOS IDs of all AWOS test results that were evaluated to determine to perform the additional test.

Report test results for tests automatically ordered by an Analyzer for a specimen with known AWOSs

This is similar to reporting reflex test results associated with one or more AWOS. The Analyzer will order additional tests for a specimen/container. Unexpected tests results will be reported, and the Analyzer could associate the tests with one AWOS or with multiple AWOSs. The same two options apply – the analyzer could report the additional test results using a single AWOS ID or report the test results including all AWOS ids for the specimen. 

Question: Should the analyzer indicate that the test results are for “additional” tests?

Report tests results for tests manually ordered at the Analyzer for a known AWOS

This scenario can occur for multiple reasons:

  • Tests are manually ordered at the Analyzer by using an AWOS list generated by the AM. In this case the AM is *expecting the test results for the AWOS.
  • Additional tests are manually ordered at the Analyzer for the specimen
  • Additional reflex tests are manually ordered at the Analyzer based on the test results from one or more AWOSs
  • Additional reruns are manually ordered at the Analyzer based on the test results of an AWOS

These situations are similar to previously scenarios. In these cases, the AWOS ID generated by the AM will be provided by the Analyzer when reporting test results. The AWOS ID is either provided by the user when manually entering the order, or captured by the Analyzer when the AWOS is transferred from the AM. Refer to previous scenarios for expected behavior.

Report tests results for tests manually ordered at the Analyzer for a specimen without any existing AWOSs

This scenario occurs when tests are ordered at the Analyzer for a specimen without any corresponding order existing in the AM for that specimen. In this case an AWOS has not been defined, so no AWOS ID exists. Possible options for this scenario include:

  • Option 1: The analyzer reports the test results for the specimen with all known information (patient, specimen, test) but does not provide an AWOS ID. It is up to the AM to manage the receipt and processing of the test results.
  • Option 2: The analyzer reports the test results for the specimen with all known information and provides an Analyzer generated AWOS ID. It is up to the AM to manage the receipt and processing of the test results.

The LAW profile does not specify what actions the AM should take upon receipt of these unknown test results, as this processing may vary from site to site and is out of scope for the profile. 

Currently, this use case is in the profile, see §X.2.3 AWOS entered with "other information" (that is to
say no AWOS ID available) for example in emergency case => Does we remove it from the profile?

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.

LAW Profile Requirements List

Retrieved from "http://wiki.ihe.net/index.php?title=Laboratory_Analytical_Workflow&oldid=48675"