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.

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 :

20100930 ELDA.jpg

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 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 a response from the Analyzer on the ability to perform the work order step.

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)


WOS-SyncQuery.png

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

WOS-AsyncQuery.png

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.

WOS-Unsolicited.png

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. The AWOS definition has been refined in the LAW draft and is summarized below.

An AWOS represents a unit of work allocated from a Work Order and assigned to one precise analyzer on one precise specimen in one precise container. Sometimes there is also a patient, whom the specimen was collected from, so it may be beneficial for the analyzer and for the staff operator to know the basic patient information. In other cases (pooling of patient specimens, QC) there is no patient.

The following attributes can be used to characterize an AWOS:

  1. Analyzer performing the work
  2. Specimen being analyzed
  3. Container holding the specimen
  4. Service (the unit of work) to perform - a test, a test panel
  5. Patient information (in some cases)

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

  • Patient information is optional
  • The Analyzer typically uses container ID information to identify a specimen, because the container ID is the information available to an Analyzer when identifying the specimen
  • Container IDs can be reused, thus over an extended period of time a container ID can be associated with multiple specimens
  • There are multiple ways to identify a container, for example:
    • assigned ID readable by the Analyzer via a barcode label applied to the container
    • a slot/position number in a carrier that holds the container presented to the Analyzer
  • 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; an analyzer might produce multiple results for the same test ordered.

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 assignment of an AWOS ID requires the Analyzer to memorize the ID and use it when reporting test results to the AM.

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

Is AWOS ID a "placer order number" or "filler order number"?

Assumptions

  • The use of an AWOS ID is primarily beneficial for the Analyzer Manager so that it can unambigously associate results reported by an Analyzer to the appropriate AWOS or update/cancel an AWOS transferred to an Analyzer. It is up to the Analyzer Manager to guarantee (e.g. use of unique IDs or establishing a reasonable period of time for the reuse of IDs that prevents incorrect identification of an AWOS) that the assignment of AWOS IDs can be used to uniquely identify each AWOS.
  • The Analyzer does not generate an AWOS ID, as it has minimal benefits for the Analyzer. If a service is performed by an Analyzer that can not be associated with a AWOS, then no AWOS ID is reported. The analyzer will report all known information, and it will be up to the AM and if necessary the operator to associate the results with a Work Order.
  • The analyzer works with an identifier of the material, such as specimen id,container id, and or a gegraphic location (tray, carrier, plate number ...). Therefore all messages must include both the material identifier and the AWOS ID (when available).
  • A rerun of a test or reflex of a new test requires 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 etc.
  • A rerun decided by the Analyzer of a test 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. The content of the result message must clearly distinguish each run with its own conditions(time, reagent ...).
  • A reflex decided by the Analyzer is consindered new work. In microbiology, a reflex test (say an antibiogram) is treated as work related to an original AWOS. Thus, when a test result for reflex work is reported a reference to an AWOS can be provided.
  • 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 has not been given the AWOS, and still must be able to perform tests on the specimen/container and report back the results without an AWOS ID. It will be then the responsibility of the AM and its operator to manually link the orphan results to AWOSs that arrive afterwards.

Impacts of AM Assigned AWOS ID

  • Legacy AM and Analyzer implementations may not easily support an AWOS ID. This may require a change to the underlying data model in order to support the assignment and persistence of an AWOS ID.
  • The Analyzer must memorize the AWOS ID so that it can be used to report all results associated with the AWOS. This does levy additional work on the analyzer.
  • The AM must manage the assignment of the AWOS ID, and use that ID for all communication to the Analyzer. This includes providing the AWOS ID for updates and cancellations.
Are the impacts enough to decide that an AWOS ID will not be used or that an AWOS ID is optional?

AWOS ID Scenarios

The scenarios that result from the assignment of an AWOS ID by the Analyzer manager generally fall into one of the following categories discussed below. 

Comment: For the Rerun / Repeat and particularly for the Reflex test decided by the Analyzer an indication from the
Analyzer that a follow-up result will be coming should be send with the first result. This indication should also
relate the follow-up result with the original result. In the messaging context we could use the
OBR-51 (Observation Group ID (EI)) of v2.7
Transfer New or Updated AWOS to the Analyzer

This is the expected scenario for most work performed by the Analyzer. The AM will break down a Work Order into multiple AWOSs and transfer the AWOSs to the Analyzer. The AM will include an AWOS ID as part of the AWOS information. The AWOS ID will be included for all subsequent messages about the AWOS that is sent by the AM (cancel an AWOS, update an AWOS).

Report single or multiple tests results for an AWOS

These are the test results expected by the AM for the service requested. The AM may expect a single test result or multiple test results (CBC, test panel). 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 multiple test results for an AWOS at the same time. The reported test results can include both preliminary results and a final result for a given test.

This scenario also covers the situation where the AWOS work is manually ordered at the Analyzer by using an AWOS list generated by the AM. The AWOS ID would be provided at the time the orders are entered into the Analyzer. 

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?
Answer: No. The results are associated with the AWOS assigned by the AM to the Analyzer. The result attributes
 (preliminary, final, etc.) can be used by the AM to characterize the result.
Report rerun test results associated with an AWOS

In this case, the Analyzer reports additional test results for a specific test because the same test was performed more than once (reran). The rerun could be automatically decided by the Analyzer, or manually ordered by the operator through the Analyzer. The extra test results are unexpected by the AM, because more than one final test result is reported for the same test. The AWOS ID is included when reporting test results for a rerun, as the AWOS ID clearly identifies that the extra test results are associated with the original AWOS request. When rerun test results are reported, it is up to the AM and operator to determine which test result (original or rerun) to report as the "clinically valid" test result. 

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.
Answer: The Analyzer Manager does not need the Analyer to generate another AWOS ID to differentiate a rerun
 test results for a specimen

It would be good for the AM to differentiate between the replicate results (e.g., if 1st measurement returned HIV positive, 
then the 2nd measurement will be done automatically by the Analyzer). 
The OBX-21 (Observation Instance Identifier (EI)) could be used (v2.6 and v2.7).
Report reflex test results

The Analyzer or Operator reviews one or more test results for work request by the AM and determines that additional work is required. These unordered, or reflex tests, are considered new work/services performed by the Analyzer. Because it is unordered, and thus unexpected work, no AWOS ID will be transmitted with the test result.

The Analyzer reports the unexpected test results for the specimen with all known information (patient, specimen, container, test). If known, the Analyzer will also include reference AWOS IDs that were used to determine extra work should be performed. It is the responsibility of the AM to manage the receipt and processing of the test results and associate them to a Work Order. 

Question: Should the analyzer indicate that the test results are for “additional” tests?
Answer: Yes. This is done by include the reference AWOS IDs when reporting the test results
Report test results for work not requested by the AM

This scenario covers any situation where work is performed by the Analyzer on a sample/conatiner that was not ordered by the AM. Possible situations include:

  • Analyzer generated tests for a known specimen. In this case the AM will receive unexpected test results for the known specimen - a specimen with an existing Work Order and possibly AWOSs. For example, the Analyzer may be configured to run a specific set of tests for all specimens, regardless of what was ordered. In this situation, the Analyzer reports the test results for the specimen with all known information (patient, specimen, container, test). It is up to the AM to manage the receipt and processing of the test result and to associate the test result with a Work Order.
  • Analyzer generated tests for an unknown specimen. In this case the AM will receive unexpected results for a specimen with no existing Work Order. For example, all tests were ordered directly at the instrument due to time constraints, connectivity issues, etc. The analyzer reports the test results for the specimen with all known information (patient, specimen, test). It is up to the AM to manage the receipt and processing of the test result and to associate the test results with a Work Order.

The LAW profile does not specify what actions the AM should take upon receipt of these unknown test results (automatically generate a new work order, request operator intervention), 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?
Answer: Yes. Only the Analyzer Manager will generate an AWOS ID.

Messaging

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.

AWOS Transfer from AM to Analyzer

A consistent messaging mechanism should be used to transfer an AWOS from the Analyzer Manager to the Analyzer. Ideally, a similar message exchange could be used for both query-initiated transfers and broadcast-initiated transfers.

Note: a single message can be used to transfer multiple AWOSs for a single specimen.

TBD.

Analyzer Notifications When An AWOS Cannot Be Performed

When an Analyzer cannot perform an AWOS request from the Analyzer Manager, it should notify the Analyzer manager that the test could not be performed. The following are situations that prevent an Analyzer from performing an AWOS:

  • The Analyzer receives an invalid or corrupted AWOS transfer message and is unable to determine that a test has been requested. This situation should be handled at the messaging level.
  • One of the tests in the message is not a test that can be performed by the Analyzer (unknown test). In this instance, the Analyzer Manager has incorrectly allocated work to the Analyzer. This may be the result of misconfiguration of the Analyzer Manager or a software error. There is no automatic resolution to this problem, as operator intervention will be required to correct the situation. This scenario should rarely occur as it is an abnormal situation. Thus, this situation probably does not need to be handled with messaging.
  • The current Analyzer condition prevents the Analyzer from attempting to perform one of the tests and the analyzer will not wait for the condition to change. For example, the reagent for the test is not loaded, the test is not caliabrated, etc.
  • The Analyzer attempts to perform one of the tests but encountered a problem. For example, an attempt to aspirate the sample failed.

The following messaging mechanisms are available for use by the Analyzer to notify the Analyzer Manager that one or more of the tests in the AWOS Transfer message could not be performed:

  • Application Acknowledgement to the AWOS Transfer Message
  • AWOS Status Change

These mechanisms will be discussed below and the recommendation provided for the use of the mechanisms.

Application Acknowledgment

An Application Acknowledgement can be sent by the Analyzer in response to the AWOS transfer to inform the Analyzer Manager of the acceptance or rejection of each test in the AWOS transfer message. Because the acknowledgement is sent at the time the AWOSs are transfered, a notification can be sent in only the following situations:

  • The test is an unknown test
  • The current analyzer conditions prevent performing the test

For HL7 communication, this style of notification is supported for unsolicited transfer of an AWOS to the Analyzer, but is not directly supported when an Analyzer performs a query for an AWOS.

Using an Application Acknowledgement to send a notification for current analyzer conditions can be used if it is preferable, that the analyzer will not wait for conditions to change or for the operator to correct the situation. E.g. a Laboratory Automation System (LAS) consisting of multiple analyzers connected with sample transport system can automatically redirect the transport of specimen container to next analyzer with the same test available. In this case the download of the AWOS request by the Analyzer Manager is performed usually after Analyzer Manager receives notification from the Analyzer (or LAS-transport), that this container has arrived at the Analyzer (is being transported to the Analyzer). If that Analyzer sends a "negative" Application Acknowledgment the Analyzer manager can automatically make decision about the best procesing for that container in the context of the entire LAS.

On the contradictory, in a broadcast mode in manually operated laboratory, it would be possible that the condition (e.g. controls have not been ran) preventing the Analyzer from performing the test could be corrected by the operator (e.g. runs controls) prior to the sample arriving.


AWOS Status Change

The Analyzer notifies the Analyzer Manager by sending an AWOS Status Change that the AWOS was not performed. This notification is sent after the exchange of messages to transfer the AWOS has completed, so it can be used to send notifications for the following situations:

  • The test is an unknown test
  • The current analyzer conditions prevent performing the test
  • The Analyzer attempted to perform the test but failed (e.g. sample aspiration failed)

Using the AWOS Status Change for an unknown test can be a complex capability to implement for the Analyzer because it does not have information about that test. Thus, it would need to preserve this information in order to send the AWOS Status Change for the unknown test. For example, if a CBC request was sent to an IA Analyzer, the Analyzer would need to preserve the CBC information outside of the normal tables it might use to manage the AWOS request because CBC is not a known test code.

The AWOS Status Change cannot be used, if the response-to-query message is garbled, so that the AWOS id cannot be retrieved. Because HL7 does not support acknowledgment to a response, this miscommunication would not be noticed by the Analyzer Manager.

Using the AWOS Status Change for notifications related to current analyzer conditions does support scenarios where the situation is corrected by the operator, because the AWOS Status Change will not be sent until the sample arrives. In Query mode where the sample has arrived, a minimal delay would be encountered in notifying the Analyzer Manager because the sending of the AWOS Status Change would be a separate message exchange.

The AWOS Status Change is the only notification mechanism that can be used for failures that occur during execution of the test.

Recommendation

Low throughput systems with manual operation

  • Application Acknowledgements should not be used to send notifications that an AWOS can not be performed. The main benefit for using it would be for unknown tests or messages with not readable AWOS id, but this is a situation that should rarely occur and most often requires operator intervention (see additional discussion below).
  • Use the AWOS Status Change for all notifications that are sent provides a consistent notification mechanism for all AWOS execution failures.
  • Using the AWOS Status Change to send notifications that the Analyzer conditions prevent execution of an AWOS provides a consistent mechanism for situations where the sample already arrived and the Analyzer is immediately rejecting the test, as well as situations where no decision is made until the sample arrives or the Analyzer waits for operator intervention.
  • The AWOS Status Change should not be used to send notifications for unknown tests. Instead, the Analyzer should notify the operator of the error. This approach eliminates the need for Analyzers to manage a complex transaction, eliminates the need for analyzers to remember information about tests it cannot perform, provides consistency between the broadcast and query styles of AWOS transfers, and provides a simple solution to a scenario than rarely occurs.
  • The AWOS Status Change should be used for all failed attempts to perform a test.


High throughput systems with automated operation

  • To facilitate fully automated high throughput systems following principles should be supported:
    • All data exchanges between the Analyzer Manager and the Analyzer should be acknowledged to minimize uncertainty of the information state and processing capabilities of the communication partner..
    • The Analyzer Manager should receive current information about the location and status of specimen containers.
    • The Analyzer Manager should receive current information about the processing intent of the Analyzer of specific AWOS.
    • The impact of communication delays on the processing by the entire system should me minimized.
  • Recommended message exchange:
    • The Analyzer sends to the the Analyzer Manager the specimen status message (Sample Arrival). The Analyzer Manager acknowledges the receive of the specimen status update message (application ack). The Analyzer may start processing of this sample as well as register the arrival of next sample and send corresponding message. Messages: SSU^U03-ACK^U03.
    • The Analyzer Manager sends the AWOS request as an unsolicited order message to the Analyzer reporting the Sample Arrival or at any time, e.g., for add-on tests. The Analyzer acknowledges (application ack) the order message confirming also the intent to perform the requested AWOS or it's part. The Analyzer Manager may adjust the fulfillment of the work order based on the acknowledgment. Messages: OML^O33-ORL^O34.
    • If at any time during the processing the Analyzer determines that it's processing capabilities changed, it sends the AWOS Status Change to the Analyzer Manager.
  • The recommended exchange fulfills the principles above, by minimizing the binding of the processing to the communication protocol, e.g., Analyzer waiting with processing until a synchronous query will be answered.
  • The additional advantage of this type of communication flow is the aligned implementation of AWOS requests messages for:
    • unsolicited transfer of original AWOS,
    • transfer of original AWOS in response to Sample Arrival at the instrument,
    • unsolicited transfer of induced AWOS (add-on, reflex, etc.).

Selection of HL7 v2.5.1 for Messaging

The selection of the version of HL7 v2.x for messaging was limited to the selection of either HL7 v2.5.1 or the use of the most current version, which is expected to be HL7 v2.8 by the time the LAW profile is complete. An analysis was performed between HL7 v2.7 and HL7 v2.5.1 to determine their differences in the following document HL7 v2.X Analysis. The following is a summary of the messaging team's decision based upon this analysis and other factors.

  • Benefits to using most current version
    • HL7 v2.7 contains additional fields that could be used to support the use cases
    • Change proposals for v2.8 could be submitted for elements required by the use case and not currently supported
    • Some Analyzer Managers and Analyzers may need to upgrade regardless the version of HL7 v2 selected
  • Benefits to using HL7 v2.5.1
    • This version has wide-spread use
    • v2.7 was just released and more than likely is not widely implementated
    • IHE profiles are based on v2.5.1
    • Future versions of the LAW profile could support later versions of HL7 v2.x (the use of v2.5.1 is an incremental step)
    • It is possible to pre-adopt features of later versions of HL7 v2.x if necessary as optional elements if critical elements are not supported by v2.5.1
  • Messaging Team Recommendation
    • The concensus of the messaging team was to use v2.5.1
    • The use of versions after v2.5.1 might be considered an obstacle to adoption
    • The team's experience indicates that v2.5.1 contains the core elements necessary to support the Vol I use cases

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

EnhAck-Seq.png

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

LAW Profile Requirements List

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