Laboratory Analytical Workflow

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. Here is a list of references.

LAB CPs Change proposals for the LAB Technical Framework, including LAW proposals.

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

Scope: Patient & QC

Purpose: This use case allows to acknowledge the validity of the WOS by the LD (application acknowledge) 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 acknowledge)

Scope: Patient & QC

Purpose: This use case allows to acknowledge the validity 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 :

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)

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

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. 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 (and sometimes ORC-2) whose definition in the HL7 standard is "Placer Order Number" and and is interpreted in the LAW Profile as "Analyzer Manager AWOS 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 geographic 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..., run id).
• A reflex decided by the Analyzer is considered 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 should 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.

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.

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. No AWOS ID is provided at the time the orders are entered into the Analyzer, so the AM must have provisions to link the AWOS to the Work Order.

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 (ran again). 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.

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.

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.

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

The LAW uses cases describe transfering an AWOS from the Analyzer Manager to the Analyzer when the specimen arrives at the Analyzer, and transfers that occur independent of the arrival of the specimen. An objective of the messaging team was to identify a consistent messaging mechanism for these different scenarios. It was also assumed that a single message exchange can be used to transfer multiple AWOSs for a specimen.

These message scenarios and associated implementation decisions are described below.

Analyzer queries for AWOS when specimen arrives at the Analyzer

The messaging team decided to use the two-part message exchange defined during the September 2010 F2F meeting. Although the transfer could be accomplished with just a QBP/RSP exchange, the two part approach was selected because:

1. Even though the OML structure can be replicated with the RSP, there is no way to send an application level acknowledgement (an ORL) about the OML-like contents delivered by the RSP. Another way to view this request is that the Analyzer has queried for work (AWOS to perform) rather than data (patient information to use), so there are benefits to having the Analyzer acknowledge the work requested.
2. It also could be used to support an asynchronous exchange because the analyzer does not have to block waiting on the response. Even-though the initial description indicates the exchange occurs within a single thread of control, it could be an asynchronous exchange manged by two threads of control. Once the QBP/RSP has been sent, the Analyzer could send additional queries to queue, perform pre-analytical processing on the specimen, or send other HL7 messages. This could improve performance in high-throughput environments.
3. A consistent approach (OML/ORL message exchange) is used to deliver an AWOS from the Analyzer Manager to the Analyzer.

  Question: Should Analyzer Managers be required to support "overlapping queries"? This may be necessary
  in automation scenarios to minimize the impact of communication delays on the system processing.
  Answer: Analyzer Managers will be required to support overlapping queries.

  Question: Should a negative query acknowledgment be sent as part of the RSP or with the OML?
  Answer: The negative query acknowledgment will be sent as part of the OML. This allows the Analyzer
  to send multiple queries to the Analyzer Manager and not have to wait for the Analyzer Manager
  to complete the evaluation of the query.

Analyzer notifies Analyzer Manager when specimen arrives and AM transfers AWOS

This scenario is not addressed by the LAW use cases, and the messaging team considered it to be out-of-scope for the LAW messaging. An implementation was defined during the September 2010 F2F meeting, but this implementation uses a message (SSU) normally associated with an SWOS (specimen) update and not an AWOS (analytical) update. Also, a vendor may choose to implement both the LAW and LDA profiles, and make use of the SWOS to trigger the broadcast of an AWOS, as discussed below. It is left to the vendor to decide how the Automation Manager should communicate to the Analyzer Manager to trigger the transfer.

Analyzer Manager broadcasts AWOS to one or more Analyzers

The OML/ORL message exchange will be used to transfer the AWOS. This transfer occurs at the discretion of the Analyzer Manager, and may be before, after or during the arrival of the specimen at the Analyzer. The key aspect of this message exchange is that the Analyzer has not requested the AWOS. Typically, the broadcast is to one or more instruments prior to sample arrival, but in automation scenarios it may be a transfer to a specific instrument based on knowledge of the specimen location by the Automation Manager.

Analyzer requests AWOS prior to specimen arrival

This is accomplished by a Query All. In this scenario, the Analzyer Manager will broadcast all potental AWOSs to the Analyzer.

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

   Question: Do the use cases in Volume 1 need to be updated to discuss what to do if the AWOS can not be performed? 

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 (OML^O33/ORL^O34), but is not directly supported when an Analyzer performs a query for an AWOS using a QBP/RSP message exchange.

An Application Acknowledgement can be used to send a notification that current analyzer conditions prevent performing a test when the analyzer does not wait for conditions to change or for the operator to correct the situation. A laboratory using automation is one such example. 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 broadcast 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 processing for that container in the context of the entire LAS.

On the other hand, when broadcast mode is used in non-automated 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. In this situation an Application Acknowledgement is not used.

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

• Application Acknowledgements (ORL) can be used to send notifications that an AWOS can not be performed. The main benefit for using it would be for unknown tests, although this is a situation that should rarely occur and most often requires operator intervention. It can also be used in automation scenarios to quickly indicate that a test can not be executed so that it can be rerouted to another instrument. In this case, the Automation Manager and Analyzer Manager may be deployed as part of the same application.

   NOTE: Using the ORL will be allowed only if a consistent set of HL7 segments/fields can be defined 
   for both the ORL and the OUL to state the reason for rejectiong the AWOS. A consistent mechanism should
   be used to reject the AWOS. Otherwise, only the AWOS Status Change (OUL) will be used.  

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

    NOTE: An analyzer may decide to use this approach to provide a simple solution to a scenario that rarely occurs.

• The AWOS Status Change should be used for all failed attempts to perform a test.

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
• Impacts
  • Message content will be constrained to fields supported by 2.5.1.
  • Information not supported by 2.5.1 but provided by later version will be considered for pre-adoption, but will be optional.
  • Change requests will be identified for information that is not supported by any HL7 v2 release.

The IHE Lab Technical Committee should continue to monitor the use of HL7 v2 and HL7 v3 for communication in the healthcare industry. As later versions of hl7 v2.x gain wide-spread adoption, then the committee should consider updating the profile to support later versions. In addition, the recent versions of the HL7 v2.x standard incorporate HL7 v3 concepts in the message content, so the HL7 Orders & Observations Working Group is actively engaged in providing a migration path from HL7 v2 to HL7 v3. As the adoption of HL7 v3 increases, the committee should also evaluate supporting HL7 v3 as a baseline standard.

Provide message element to identify that Rerun/Reflex is scheduled

The messaging team discussed if information should be included in the message for the results of the "first run" of the AWOS that a Rreun/Reflex has been scheduled.

The following options were proposed:

• Do not supply this information
• Extend OBR-25 to include this information
• Submit a change request to send this information to the OUL message

The general consensus of the team is that this information is not needed, and thus no action will be taken.

Use Order Filler Number or Placer Filler Number to hold the AWOS ID

The message team was uncertain on whether the Placer Filler Number or Order Filler Number should be used to hold the AWOS ID.

• IHE takes a client-server approach. Any client requesting work provides an Placer Filler Number. The server accomplishing the work can provide a Filler Order Number in the response. For our purposes, the AWOS ID would be a Placer Filler Number.

   Comment from IHE Lab Committee Co-Chair:
   An OML messages is sent by a placer to a filler. The former requests the latter to perform a service.
   This order to perform the service is identified by the placer in a field which is definitely “placer order number”
   in the message. This logic from the HL7 standard is applied thoroughly by the IHE LAB Technical Framework.
   In the particular case of the LAW profile, the placer is the actor “Analyzer Manager” and the filler is the
   actor “Analyzer”, and the service ordered and uniquely identified with its “placer order number” is an AWOS.
   Another field of the same message, called “filler order number” is of no use in this case. This second field
   might be used to assign a secondary number to the AWOS, this time assigned by the Analyzer. The LAW messaging
   team will have to decide whether the field “filler order number” is totally useless or useful in some precise use cases.

• HL7 O&O Working Group considers the lab to be an Order Filler. Thus, when the Analyzer Manager sends the AWOS to the Analyzer Manager, it populates the Order Filler Number as both the Analyzer Manager and Analyzer are Order Fillers.

Recommendation

A discussion was held with the HL7 O&O WG during the May 2011 Working Group Meetings. The O&O WG fully supports The IHE "client-server" interpretation of the use of Placer Filler Number to identify any client request work of a filler. Therefore, the message team recommends that Placer Order Number be used for the AWOS ID defined by the Analyzer Manager.

Provide a message element to identify a replicate/rerun/reflex

The messaging team discussed if a message element is needed to identify that a subsequent test result for an AWOS is a replicate/rerun/reflex of the original AWOS. One example would be that for some tests, a positive result might result in an automatic retest as a second confirmation. Thus, the Analyzer Manager may want to use the retest as the reported results.

Posiible options incude:

• The Analyzer Manager could use the time stamp in OBX-19. Each AWOS notification has a time stamp, and a simple comparison of the time stamps for two notifications would indicate which result was produced first.
• The Analyzer could use OBX-21. This would need to be pre-adopted from HL7 v2.6
• The Analyzer could use OBR-51 to reference the original result in the follow-on reflex/retest/rerun.

The general consensus of the team was to assume the Analyzer Manager would use the time stamp in OBX-19 and to not provide any other information. Using OBX-21 requires pre-adopting an element from v2.6, and the team prefers not to pre-adopt any elements to maintain compability with v2.5.1. In addition, the use cases describe how the AWOS ID for rerun and reflex tests will be handled, and OBR-51 is not needed to meet the use case requirements.

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

MSH-15 will be ER (Errors, communication) and MSH-16 will be AL (Always).

• 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”). This field is not being used.
2. “Abnormal flags” (OBX-8) make repeatable as in HL7
3. “Specimen Description” (SPM-14) make repeatable as in HL7. This field is not being used.

Messaging Business Objects

Business objects have been identified to support the LAW message implementation. The content of these business objects represents the information required to support the LAW message transactions and Use Cases. The business object content will be mapped to the set of HL7 v2.5.1 segments and messages that support the LAW message transactions.

In support of the IICC plug-n-play objective, the minimum set of message elements to support the LAW transactions will be defined. Optional message elements may also be identified, but will not be required by the Analyzer Manager or Analyzer in order to support the LAW profile. The usage {required, required but may be empty, conditional, optional} for each business object and associated data elements will be documented.

The business objects and potential HL7 segments that support the business object content are listed below:

• Patient
  • PID - PATIENT IDENTIFICATION SEGMENT
  • PV1 - PATIENT VISIT SEGMENT
• Specimen
  • SPM - SPECIMEN SEGMENT
• Specimen Container
  • SAC
• Order (service request)
  • ORC - COMMON ORDER SEGMENT
  • OBR - OBSERVATION REQUEST SEGMENT
• Observation (test result)
  • OBX - OBSERVATION/RESULT SEGMENT
  • NTE - NOTES AND COMMENTS SEGMENT
• Substances (participating in analytics)
  • SID - SUBSTANCE IDENTIFIER SEGMENT

The content for the business objects is captured in the IHE LAW Messaging - Business Object spreadsheet.

Analyzer Responsibilities

Add to Wiki:
Discuss concept of Sending Conservatively and Receiving Liberally?
• “Keep it simple”
	Clarity
	Clear
	Minimum set of capabilities
	Add additional features incrementally
• Don’t let “perfect” be the enemy of good
• Harmonize with the “little guy”
• Solve immediately problems, then increment

Implementable profile is ‘M’. Analyzers must further refine if ‘O’ are supported – constrainable profile..

During the analysis process, the message team realized that the Analyzer actor can have more than one responsibility related to performing tests. In order to clarify these different responsibilities, the usage term "Mandatory" was defined that indicates the set of information necessary for an Analyzer to report a technically valid results. The term "allowed" was defined for information that supports additional responsibilities provided by the Analyzer or Analyzer Manager, such as evaluating a result for clinical validation. It was suggested that conceptually the information to be exchanged could be represented by two interfaces.

Basic Result Interface

A Basic Result interface is designed for lean analyzers that simply run tests. Required fields would include Sample ID and tests to run. We define the standard setup as being query, and establish the job expected of both the Analyzer (instrument) and the Analyzer Manager (host). When using a Basic Result interface, there may be a rules engine evaluating results back on the Analyzer Manager (host) side, but none of the complexity needs to show up in the interface. The Basic Result interface consists of the "Mandatory" transaction elements identified in the LAW Profile.

Enhanced Result Interface

A second interface would be a Result Evaluation interface. In this interface additional information is sent from the Analyzer Manager to allow reasonable processing of rules on the Analyzer. This processing could be done manually by the operator or automatically through the use of a rule engine. In this case, the Analyzer actor could be fulfilled by an instrument or by middleware providing the actor. Information like patient age, ordering physician, or fasting information would all be important for a full set of rules to be valuable. This allowed information would be designated as optional, or "Allowed", transaction elements by the LAW Profile.

The messaging team discussed defining multiple levels of the Result Evaluation interface where the most commonly used data would be part of one interface, and less frequently used data part of subsequent interfaces. However, it was decided to consider just one Result Evaluation interface in order to simplify the transaction descriptions and potentially improve adoption.

The Result Evaluation interface consists of all the elements of the Basic Result interface, plus additional elements necessary for evaluation. Thus, both interfaces could use the same transactions, but the content of those transactions depend of whether the Analyzer or Analyzer Manager is supporting the optional Result Evaluation responsibility.

Impact of Enhanced Result Interface

The LAW use cases do not need to be modified to support the Enhanced Result interface. The behavior associated with rule evaluation and other capabilities are out of scope. However, it does impact the content of the transactions exhanged between the Analyzer Manager and the Analyzer.

The team established the following objectives for supporting an Enhanced Result Interface include:

1. It is acceptable to require the Analyzer Manager to be capable of supporting all "Allowed" elements for the LAB-28 transaction (AWOS Download). Analyzer Managers are typically more sophisticated than the Analyzers, and should have the ability to support the additional elements.
2. Analyzers may only want to support some of the "Allowed" elements. It would probably be unacceptable to require an Analyzer to support all of the "Allowed" elements of LAB-29 if they were only going to process some of the "Allowed" elements.

For testing in the Connectathon, the team assumed the following:

1. An actor has to demonstrate they can send all "Required" and "Required but may be Empty" elements. Thus, if patient information is specified as "RE" in the HL7 messages representing LAB-28, then Analyzer Managers will have to demonstrate sending patient information as part of the connectathon.
2. A receiving actor can choose to ignore "R" and "RE" elements. Thus, if patient information is specified in LAB-28 as "RE", and Analyzer can choose to ignore the information.
3. An actor does not have to demonstrate sending "Optional" elements. In the LDA transactions, the usage of most elements that the messaging team identified as "Allowed" is specified as "Optional". Thus, sending/receiving these elements would not be tested.

Supporting the Enhanced Result Interface

Various options were discused, including:

• Specify an Enhanced Analyer actor that supports the enhanced interface. Create additional transactions for the messages that are impacted by the enhanced interface. A LAB-28E and LAB-29E transaction would be defined, and these transactions would specify "Required by may be Empty" for the "Allowed" business object elements. LAB-28 and LAB-29 would specify "Not Supported" for the "Allowed" elements.
• Define the Enhanced Result transactions, but make these optional transactions that the Analyzer or Analyzer Manager could support. Thus, the elements are tested only if the actor supports the optional transaction.
• Propose a new usage element called "Allowed" to reflect that an actor does not have to be capable of sending the "Allowed" elements of the transactions. Thus, an Analyzer would not have to be capable of sending Patient information in LAB-29. This element would be a more restrive version of "Optional", so it would not be tested for conformance.

The consensus of the team, however, was to take an approach that leverages the existing transactions and HL7/IHE usage terminology:

1. Specify that the "Allowed" elements in LAB-28 transaction sent by the Analyzer Manager are "Required but may be Empty". This requires the Analyzer Manager to be capable of supporting all "Allowed" and "Mandatory" elements. In addition, the Analyzer can choose to ignore "Required but Empty" elements, so it can choose not to process the information.
2. Specify that the "Allowed" elements in LAB-29 sent by the Analyzer as "Optional". The use of the elements are left to the Analyzer vendors.

  NOTE: It may also be possible to modify the use of "Required but may be Empty" or define a new usage of "Allowed" to identify
  an element as allowed to send if capable and data is available. Essentially, for a receiver it is an "RE". This designates
  the intended use of the field without requiring an instrument to be capable of supporting the element. For the connectathon,
  testing would include sending all allowed elements that are being supported."Allowed" is more restrictive than "Optional
  but less restrictive than "Required but may be Empty"

Identifying Equipment

A recommendation has been made to provide additional information with an AWOS Status Change about the equipment that was used to produce the result. Information to include in the messages/information transmitted from the analyzers is the vendor name, instrument model, unique instrument identifier (if available). Many labs often compare testing from the same analyzer model/method for inter-lab quality control and proficiency testing. This would better allow them to capture key information for comparing with themselves and peers. Furthermore, if there was a way to track analyzer identification information, it aids CLIA accreditation requirements for knowing which analyzer results originated. If these fields/info were required as part of the profile, it would allow their automatic collection for those to extract later if needed for QA, public health or even research.

There are also regulatory requirements related to the "Universal Device Identification", which should be taken into consideration. The Universal Device Identifier (UDI) should be

• coded according to ISO 15459 (GS1, HIBCC)
• created and maintained by the manufacturer
• concatenating the Device Identifier (DI) and Production Indentifier (PI)
  • DI (static): manufacturer, make, model
  • PI (dynamic, presence depending on risk class): serial number, lot number, expiration date

For this request, what information should be provided by the Analyzer and what information should be provided by the Analyzer Manager?

OBX-18 can be used to carry Equipment Identification information. This field is repeatable and is of type EI, but it may not support all of the information we want to report. The components of the EI fields are Entity Identifier, Namespace, Universal ID, and Universal ID Type. OBX-18 is repeatable so it supports hierachical clusters of multi-module systems in the version <2.8, but starting from the v2.8 the repeatability has the same meaning as in PRT-10, i.e., it expresses the same instance and the hierarchy should be expressed by the Namespace. We could map the data we want to the fields like this:

• First repetition of OBX-18
  • (Empty) or serial number (in some cases redundant to part of UDI code) -> Entity Identifier
  • (Empty) -> Namespace
  • UDI code -> Universal ID
  • UDI type (e.g., OID by ISO or HL7) -> Universal ID Type

• Second repetition of OBX-18
  • Make, model, serial number, [modul], [sub-modul] -> Entity Identifier
  • Manufacturer -> Namespace
  • (Empty) -> Universal ID
  • (Empty) or 'L' (local) -> Universal ID Type

• Third and next repetition of OBX-18
  • Lab specific -> Entity Identifier
  • Lab specific -> Namespace
  • Lab specific -> Universal ID
  • Lab specific -> Universal ID Type

Remark: the Namespace component is of data type IS, i.e. the length is constrained.

The description in the standard indicates the identifier is a reference to a master list of equipment maintained by the institution, so we should consider that the third and next repetition of the OBX-18 fields should carry the Entity Identifier with the Namespace of the specific laboratory.

A suggestion from HL7 OO is to pre-adopt the PRT segment as a participating entity for the production of the result. This suggestion was from a discussion on modifying the EQU definition so that equipment instance was repeatable. PRT contains a device field, but the data type is EI, i.e., the proposal as above would be applicable too.

Order and Observation Vocabularies

Standardizing on a vocabulary for Orders and Observations was an objective of the messaging team, with LOINC being the preferred vocabulary. However, there are challenges to mandating the use of LOINC.

Historically, Analyzers assign an identifier to the analyte being measured. This identifier is used by the Analyzer Manager to order the test, and then used by the Analyzer to identify the observation when returning the test.

Typically an Analyzer is configured to report an assay in a specific unit, such a g/l. An interpretation (qualitative assessment) can also be sent along with a quantitative value as well as a raw reading from the analyer.

However, the Analyzer codes usually do not differentiate the parts of an observation that require a different LOINC for results obtained by executing the same type of test Analyzer. For example, Analyzer identifiers do not typically differentiate between the Kind of Property (mass, substance, identification)for the same test. This information is carried as part of the observation data. For example OBX-6 contains the units. Thus, there is no way to establish a 1:1 mapping between Analyzer identifiers and LOINC for all assays. Likewise there are aspects of the testing that are unknown or irrelevant to the Analyzer. For example, an Analyzer may perform the same test for a glucose 2-hour, 4-hour, etc. This aspect of the testing does not impact the test processing performed by the Analyzer. Analyzer Managers already have to map Laboratory codes to Analyzer code because they must comprehend the LOINC attributes of the observation that may be unknown to the Analyzer. Thus, even if the Analyzers, Analyzer managers, and other LAW actors all decided to use LOINC, mappings by one or more of the actors would still be necessary to align incoming request identifiers to test identifiers that are performed by the Analyzer.

Finally, LOINC is not the only standard currently used. JLAC10 is mandated for Japan, so JLAC10 mappings will be required by upstream systems when reporting Analyzer observations.

Therefore, LOINC will not be mandated as the order/observation vocabulary for Analyzers. The development life cycle and regulatory constraints on Analyzers make it difficult to release and deploy new software versions/updates. If an Analyzer needs to maintain a list of acceptable LOINC for the test performed, these constraints may delay updating the Analyzer LOINC mapping when new LOINC codes are released. Leaving the mapping in the hands of the Analyzer Managers is more appropriate. The decision on using LOINC or Analyzer codes should be left to the Analyzer vendor. Therefore, the LAW profile will support standardized vocabularies such as LOINC and JLAC10, as well as Analyzer vocabularies.

However, to support this approach, it is important to note that Analyzer vendors must produce LOINC mappings which can easily be obtained by Analyzer Manager vendors. These mappings must clearly establish the relationship between the Analyzer codes and LOINC codes. The process of configuring a laboratory for an instrument would be further simplified if these mappings were available electronically. IICC and Regenstrief have discussed the possibility of Regenstrief serving as an electronic repository for this information. In addition, the FDA is establishing a project to evaluate the viability of a national repository for Analyzer configuration information (test codes, interpretation codes, etc).

Observation Identification for an AWOS

The messaging analysis identified several characteristics of an observation that were important to address with the LAW profile. It is quite challenging to account for these attributes in the HL7 messages. For example, consider the following characteristics associated with the observations of an AWOS:

• Result(s) grouped as a run
• Results composed of multiple fragments (numerical and qualitative, numerical and string numerical, numerical in different units)
• Identification of unique observation instances associated with microbiology

Many of these characteristics are not directly supported by the HL7 message structure. The attributes and the mechanisms used to support them are discussed below.

AWOS status

It is important for the Analyzer Manager to know if the Analyzer completed all work associated with the AWOS. The AWOS status is captured with ORC-5. The Analyzer sets ORC-5 = "CM" (Complete) once it has completed all work for the AWOS. Otherwise the status is reported as "IP" (In Progress).

Result status

It is important to convey that status if an individual result. Is the observation considered a final result, a preliminary result, or a result that could not be validated? The profile supports several statuses that are transmitted in OBX-11: P (Preliminary), R (Not Validated), F (Final), C (Corrected) and X (Could Not Obtain).

Groups of AWOS work

The "groups" of work (multiple runs, progression of tests) the Analyzer did in order to complete the AWOS should be clearly identified. OBX-4 is used so that an Analyzer Manager can properly identify the runs performed by the Analyzer. OBX-4 is populated with a unique positive integer identifying the run, starting with "1" for the first run.

Multiple results of an AWOS

In same cases an AWOS request may result in multiple, but distinct observations. For example, RBC, WBC, etc. are distinct results associated with a Hematology CBC. In this scenario each observation will have a unique OBX-3 value but the same value in OBX-4, as these observations are all part of the same "run" or group of results.

Observation fragments of an AWOS

This approach needs to be finalized. There is conflicting information is the HL7 standard. Section 7.4.2.5 talks about observation fragments having the same OBX-3 and OBX-4 values, yet section 7.4.2.4 seems to imply that two OBX segments cannot have the same values OBX-3 and OBX-4. Should it be possible to identify a primary result?

OK – found the example and personally I like the approach of using the ‘.’ Notation 
described in example 7-4 in this section. From a NIST testing tool perspective sending
2 OBX segments under the same OBR with the same OBX-3 and OBX-4 will cause an error – at
least for the US guides under MU using this conformance statement:

If there are multiple OBX segments associated with the same OBR segment that have the
same OBX-3 values for (OBX-3.1 + OBX-3.3) or (OBX-3.4 + OBX-3.6), a combination of
(OBX-3.1 + OBX3.3) or (OBX-3.4 + OBX-3.6) and OBX-4 SHALL create a unique identification
under a single OBR.

May be this should be brought up to InM, CGIT and OO for input?

It is common for an observation to contain fragments of more than one data type for the same run. Examples include:

• Reporting quantitative values (data type NM) and qualitative values (data type CE or ST)
• Reporting quantitative values (1.43 as a NM) and string representations ( "1.43333" as an ST)

These observations could have the same OBX-3 and OBX-4 (sub-ID is identifying run), but different OBX-2 data types. In this situation, the value of OBX-7, OBX-8, OBX-11, OBX-16, OBX-18, and OBX-19 should be the same for any following OBX segments with the same OBX-3 Observation Identifier and OBX-4 Observation sub-ID. HL7 recommends empty (HL7 v2.5.1 section 7.4.2.5 discussing fragments), but setting them the same seems more appropriate.

Sending a string would seem to imply additional coordination between the two systems to know how to interpret the string, unless a LOINC code that conveys the kind of quantity could be used to establish the expected content.

AWOS result reported in different units

An approach needs to be defined.

A system may desire to report the same observation in different mass and/or substance units. For example, the analyzer may report the same observation in moles/mL, mg/mL, and Log(moles/mL). A mechanism must be established when results with different units for the same Observation ID and group of work need to be reported. In this case OBX-2 (Type), OBX-3 (ID), and OBX-4 (sub-ID/run) could the same, but OBX-6 (Units) is different.In most cases, one of the results is considered the "Primary" result while the other results are considered secondary results. What should be used to identify the primary result? Is location - the first result in the "set" sufficient?

LOINC codes can partially address this because the Observation ID will be different for some units (mass vs. substance).

Unique result instances of an AWOS

This occurs when an observation produces multiple observation results. In other words, observation results with the same OBX-3 (e.g.; “microorganism identified”)should be grouped. In the scenario an AWOS “microorganism identification” with multiple organisms identified on the specimen, you have a series of OBX, all of which with the same OBX-3 and in Final status. These OBX need to be distinguished by a key in OBX-4 (unique in the message and across messages). This is a use case where OBX-4 is not a “run number” but rather an "instance number".

This is consistent with the V251_IG_SIF_LABRESULTS_DSTUR1_2012JUL published by O&O as well as with LAB TF-2x:C.11 “Microbiology Reporting Rules”, except that OIDs are required in OBX-4 instead of integers. OIDs have two advantages:

• Distinct from multiple runs who use integers.
• Really unique identifier for a strain of microorganism, that can be referenced safely and unambiguously in further messages carrying more observations performed on this microorganism. Microbiology IVD vendors should like that.

AWOS supplemental information

This is additional data provided by the Analyzer that laboratory personnel find useful. The challenge was to allow vendors to provide unique observation identifiers, while at the same time classifying the data as a particular type of supplemental data. The goal was to allow Analyzer Managers to be able to interpret the data as supplemental, and understand enough about it to understand how it may be processed (raw, image, graph). It may be possible to provide further guidance with LAW on the use of supplemental data, so an adaptable mechanism was defined. The Alternate Code fields of OBX-3 contain the LAW classification, while the primary Code fields of OBX-3 contain the vendor-specific identifier.

Error Handling

The LAW profile will use Application Acknowledgements to address message and application level errors that occur when messages are exchanged between the Analyzer and Analyzer Manager. The HL7 Enhanced Acknowledgment Mode allows a receiving application to not accept a message because the message contains an error or to reject the contents of the message for processing. In addition, the ORL^O34 Laboratory Order Response supports accepting and rejecting individual AWOS Request, while the RSP^K11 Query Response supports accepting or rejecting a query request. The use of these mechanisms for the LAW profile are discussed below.

No guidance will be provided on application behavior when a message error is detected, a message is rejected, or request is rejected. It is expected that receiving applications will capture the situation in a log and/or notify the user in some manner. In addition, it is also expected that the application will support connection/message recovery logic through the use of retries, user intervention, etc. when appropriate.

Receive a Malformed Message

A message error occurs when malformed HL7 messages are received. Examples include missing or out of order segments, incorrect data types, or unsupported table values.

If a receiving application detects an error in a trigger message, an Application Acknowledgement: Error is reported in the acknowledgement response by setting MSA-1 to "AE". The application will report the location(s) causing the error in the ERR segment.

If an error is detected in an Application Acknowledgement message, the receiving application shall ignore the acknowledgement and assume the transaction has failed.

Receive a Message with Incorrect Message Control Content

The HL7 uses of message control information in the exchanged messages. See HL7 v2.5.1 section 2.9 for additional details. Examples of an invalid content include an unsupported MSH-9 Message Type, MSH-12 Version ID, or MSH-21 Message Profile Identifier. Another example would be the receipt of an acknowledgement and MSA-2 does not match the value of MSH-10 from the originating trigger message.

If a receiving application detects invalid message control content in a trigger message, an Application Acknowledgement: Reject is reported by setting MSA-1 to "AR". The application will report the location(s) causing the message to be rejected in the ERR segment.

If a receiving application detects invalid message control content in an Application Acknowledgement, it shall ignore the acknowledgement and assume the transaction has failed.

Reject an AWOS Request

After receiving an AWOS Broadcast message containing several AWOS requests, an Analyzer might reject an individual AWOS Request. The Analyzer may not be able to support the specific request temporarily due to inventory configuration, or permanently because it is not a request (test) the Analyzer can perform. Or, the message may contain inconsistent information such as a request to cancel an unknown AWOS ID. Some of these situations may occur as part of the normal laboratory workflow, although they should occur infrequently.

The ORL^O34 Laboratory Order Response will be used to individually accept/reject AWOS Requests. MSA-1 ill be set to Application Acknowledgement: Accept to indicate the OML^O33 message was accepted. The ORC-1 Order Control field will be used by the Analyzer to indicate if each AWOS Request has been accepted or rejected.

Receive an AWOS Request Acknowledgement with Inconsistent Content

An example is a response for an AWOS ID that was not in the AWOS Request.

If the Analyzer Manager detects inconsistent data in an ORL^O34 Laboratory Order Response, the Analyzer Manager will ignore the acknowledgement and assume the transaction has failed.

Receive an AWOS Status Change with Inconsistent Content

The Analyzer Manager must check that the AWOS Status Change content is consistent. For example, the values in the SPM, SAC, and OBR segments should be consistent with an OML^O33 message the caused the OUL^R22 to message to be sent. If the OBR-4 Universal Service ID in OUL^R22 does not match value sent in OML^O33, then the Status Change should be rejected. Another example is if the AWOS ID in the OUL^R22 message is not known by the Analyzer Manager. These are unexpected situations that should not occur as part of the normal laboratory workflow.

The General Acknowledgement response for the OUL^R22 message does not support accepting or rejecting individual AWOS status changes, so the entire message must be rejected. Therefore, if the Analyzer Manager detects an OUL^R22 with inconsistent content, the Analyzer Manager shall report an Application Acknowledgement: Reject by setting MSA-1 to "AR". The Analyzer Manager will report the inconsistent location(s) in the ERR segment.

Reject A Query

Although very unlikely, it may be necessary for an Analyzer Manager to reject a query. For reasons other than a message error (covered above) or message rejection due to invalid message header (covered above), the Analyzer Manager will make use of the QAK-2 Query Response Status to indicate the query is rejected or an error occurred when processing the request.

Receive a Query Response with Inconsistent Content

An example is the QAK-1 and QAK-3 fields should be the same as the QPD-2 and QPD-1 values sent in the QBP^Q11 trigger message.

If the Analyzer detects a Query Response with inconsistent content, then the Analyzer will ignore the acknowledgement and assume the query transaction has failed.

Field and Component Lengths

HL7 has recently established new conventions for field and component lengths. HL7 v2.5.1 discusses length as a maximum length to support, but does not address truncation. Lengths can be defined for fields of a segment as well as components of a data type. Profiles are allowed to exceed the lengths defined by the standard. HL7 v2.5.1 seems to infer that truncation at any time is considered an error.

HL7 v2.7 adds the concept of normative and conformance lengths, as well as truncation behavior. The intent is to identify what lengths to support, when truncating is allowed, and what to do to indicate a value was truncated (stuff a ‘#’ at the end). In addition, defining a length for segment fields is no longer provided, because it depends on the components of the data type.

LAW defines that Data Type Lengths are considered minimum conformance values that the receiving application must support. A sender may choose to transmit more and a receiver may choose to support more. So far, the profile is silent on when truncation is allowed.

As an example, the LAW profile uses the standard length of 199 for the CE.2 component of OBX-5. A vendor can decide to increase the value to 275 in their implementation guide, but an LAW conforming application may only support 199 characters. It is probably reasonable to allow applications to truncate this field for Test Exceptions, because it is the text description and not the exception code. On the other hand, an OBX-5 of type ST should not be truncated when supporting a qualitative result, although 199 characters (max length for ST data type)seems more than enough in this situation. We may need to provide truncation guidance in LAW – which fields can be truncated and if a truncation indicator is necessary.

Order Group, Work Order, and AWOS Identifiers

IHE LAB TF Section 3.5.3 discusses the relationships between the laboratory units of work. The following summarizes this discussion in the context of the LAW profile:

• Order Group - a set of Orders grouped together by physician or ward for a patient. This unit of work is identified by a Placer Group Number. The framework also notes that both the Order Placer (assigns) and Order Filler (accessions) define identifiers for the Placer Group Number.
• Orders - a battery or test ordered for a patient. The Order Placer assigns the Order a Placer Order Number, while the Order Filler assigns the Order a Filler Order Number. An Order may be stand-alone or part of an Order Group.
• Work Order - a battery or single test on one or more specimens requested by the Order Filler of the Analyzer (Automation) Manager. It is assigned a Work Order Number by the Order Filler.
• Analytical Work Order Step (AWOS) - an atomic operation requested by the Analyzer Manager to be performed on one specimen by the Analyzer. It is assigned a unique AWOS ID by the Analyzer Manager.

In support of these concepts, the IHE LAB TF describes the usage of ORC-4 Placer Group Number:

• Vol 2 states that field ORC-4 is EIP and has usage required if known (RE), and discuss that EIP.1 holds the Order Placer identifier and that EIP.2 holds the Order Filler identifier.
• Vol 2a:2.4.6.3 describes the condition predicate associated with EIP in ORC-4: “In the context of all transactions dealing with orders, the first sub-component (EIP-1) is populated with the Order Group identifier assigned by the Order Placer application, if known, and the second sub-component (EIP-2) is populated with the Order Group identifier accessioned by the Order Filler application, if known.”

In this case, ORC-4 represents a “placer group”, with ‘placer’ standing for the application of the ordering physician (an EHR or an EMR, ambulatory or hospital). In IHE LAB, this “placer group” is named an"order group” or a “laboratory requisition”. It usually has a unique number assigned by the ordering system. It can also have an accession number assigned by the LIS. It could propagated downstream to the Analyzer Manager and to the Analyzer, but neither of those two actors can define one. It’s only used for traceability purposes, so that if the technician on an analyzer or on a middleware (MW) has a problem with a specimen, he can call the LAB manager or even the ordering department with a number meaningful to his correspondent.

This usage of the field allows an end-to-end sharing [ HIS -> LIS -> MW -> Analyzer ] of the same “Order Group” references.

However, the usefulness of the identifiers for the Order Group is limited on the Analyzer and probably not comprehended by most Analyzer data models. Thus, it is unlikely that an Analyzer would display the information or even persist the identifiers to return as part of the LAB-29 AWOS Broadcast.

However, a scenario was presented where an Analyzer would use the Work Order information of the Analyzer Manager:

The Analyzer is able to perform tests of Creatinine Clearance. That test requires two samples of different sample types, one serum and the other urine (different samples collected from the same patient). The instrument then runs tests on them and generates additional calculated information from the cross reference of the results of both samples. In LAW specification the tests ordered for each sample has its corresponding AWOS ID. But they expected the analyzer to get access to the Work Order ID also, not only Work Order Step IDs to be able to safely relate the samples, since both samples are related by the original work order.

Therefore, it was recommended for LAW that ORC-4 be used to carry information related to the Work Order created by the Analyzer Manager. This field can be used to carry the Work Order identifier that groups AWOS ordered together by the Analyzer Manager and sent to one or more Analyzers. The Analyzer Manager Work Order can encompass more than one sample from the same patient sent to the same or more than one Analyzer. Only the Analyzer Manager establishes a Work Order identifier, and therefore only the first identifier of the EIP data type would be supported. Analyzers are free to use this information when provided by an Analyzer Manager.

This usage allows the visibility of the Work Order on the Analyzers, but loses the visibility of the Order Group on the Analyzers. However, the Placer Group Number would still be visible on the Analyzer Manager, where it is more likely to be used anyway.

Messaging Decisions

Character encoding to use for messages

Status: Closed.

Issue: What character encodings should be supported for MSH-18? There is also a directive from China that GB18030-2005 is a mandatory standard for all operating systems sold in China. Would this apply to the LAW protocol? NOTE: v2.5.1 supports GB 18030-2000, the previous version. It is considered a Unicode Transformation Format - it can represent all Unicode code points.

Resolution: Only support UNICODE UTF-8. This should support all expected character sets.

Populating ORC fields that have an OBR equivalent

Status: Closed.

Issue:Is it necessary to populate the ORC fields that have an equivalent field in the OBR segment?

Resolution: No. To avoid confusion and error handling when the values do not match, the following fields will not be populated: ORC.2, ORC.12, ORC.14,

Order Control Segment with LAB-29

Status: Closed.

Issue: Is the ORC segment Mandatory with the AWOS Status Change?

Resolution: No. The ORC fields that have the same value as the OBR field are not populated, so all remaining values are allowed fields. The ORC is an "Allowed" segment for LAB-29.

Order Control

Status: Closed.

Issue: Modifying an AWOS is not completely covered in Vol 1. Is a section required that discusses how an AWOS can be modified, canceled, replaced? In addition, Order does not include an Order Control field that is used to describe the order type (new, add, etc.).

Resolution: An AWOS is a test or test panel to be performed on a specimen by an Analyzer. Thus, each individual test or panel has its own AWOS ID. Therefore, it seems reasonable that the only modification supported for an AWOS to cancellation. If a new test is to be requested for a sample, it is sent with a new AWOS ID. An update could be performed on the same test, but it is easier to cancel and send a new request. This greatly simplifies the management of AWOSs for the Analyzer. An Order Control (ORC-1) field will be added to the spreadsheet.

Manage only AWOS create and delete (and not update)

Status: Closed.

Issue: In order to simplify the communication, we envisage to have only create and delete AWOS messages.

When the Analyzer receive an AWOS, it create the AWOS. If the AM want to update the AWOS, it send a delete message on this AWOS and then a create message.

Potential issues:

• if the AWOS is in progress on the Analyzer: The Analyzer can't delete the AWOS and then can't perform the "update".
• if the AWOS is ended on the Analyzer: Does we delete the AWOS and associated results ? Does we forbid deletion of AWOS with associated results ?

Resolution: Use LDA approach for cancel. Use the CR - Cancel reject - if WOS in progress or completed by Analyzer.

Enhanced Acknowledgement

Status: Closed.

Issue: Enhanced acknowledgement mode that implements a single acknowledgement must be added to the volume 2 discussions. See [Enhanced Acknowledgement]

Resolution: Enhanced acknowledgement will be used by the profile, but in such a manner so that only one acknowledgement is returned. By setting MSH-15 to be ER (Errors, communication) and MSH-16 to be AL (Always), an Accept Acknowledgement will be sent for message/communication errors and an Application Acknowledgement will be sent otherwise.

Identification of Equipment Instance

Status: Closed.

Issue: Is OBX-18 sufficient to identify the equipment that produced the result? What should the Analyzer provide and what should be captured by the Analyzer manager? The HL7 definition indicates this field is a identifier from an institutions master list. How would an instrument know of such a identifier? Does PRT contain all of the necessary fields? It contains a device field, but the data type is EI.

HL7 OO suggestion is to pre-adopt the PRT segment as a participating entity for the production of the result. If PRT is used for LAW, how would this impact the Order Tracker from LTW?

Resolution: The OBX-18 field will be used in the following manner:

• The first instance is mandatory and will be used to carry the instrument model, manufacturer, and optional UDI information
• The second instance of OBX-18 is also mandatory and will be used to carry the serial number
• The optional third and subsequent instance of OBX-18 will be used to carry manufacturer or site specific information to allow for the identification of the hierarchical configuration of the equipment (cluster of modules, etc.) and site specific identification

Use of LOINC for Universal Service Identifier

Removed. See section 7.12 Order and Observation Vocabularies for a further discussion.

Use of UCUM for Observation Units

Status: Closed.

Issue: Should UCUM (Unified Code of Units of Measure) be mandated for OBX-6? There are gaps. For example, some analyzers may report an "internal unit". It is a grammar to build units. Would need to address these gaps.

Resolution: Mandate the use of UCUM and discuss with Regenstrief on how to solve the gaps.

(JB) Seems ok, but not fully complete: Eg. for mass spectrometry (cf. wikipedia)
"A mass spectrum is an intensity vs. m/z", m/z isn't available

Analyzer Sending Parent/Aliquot Information

Status: Closed.

Issue: If an Analyzer receives SAC-4 (with SAC-3) in LAB-28, is it required to send back SAC-4 in LAB-29? If an analyzer aliquots a sample, is it required to send a value in both SAC-3 & SAC-4 when transmitting the result in LAB-29?

Resolution: No. The Analyzer only needs to send back a SAC-3 or SAC-4 with location information. It does not need to match the information in LAB-28.

Usage Definitions for Field Components

Status: Closed.

Issue: Is it necessary define usage for the components of a field that is composed for multiple elements? For example, SPM=4, Specimen Type, is a CWE that contains 9 components. What needs to be populated?

Resolution: These will be defined as necessary. Many of the existing IHE LAB definitions include the components.

Specimen Action Code

Status: Closed.

Issue: Is Order->Specimen Action code required? If so, how will it be used?

Recommendation: This field will not be supported.

This field seems useless in the LAW scope (we have the specimen)

Support for Reformulated Service Requests (Assays)

Status: Closed.

Issue: It is possible that a test may be reformulated, and The test may have the same LOINC code as an existing test. A lab may want to have both tests installed at the same time on the instrument during the transition from the old to the new test. How can this be supported with LOINC codes? Is it an instrument-only issue?

Resolution:If both are present, then it has to be represented by a unique code.

Convention for IVD Vendors to Identify Supported Allowed Fields

Status: Closed.

Issue: Should guidelines be defined that discuss how a vendor should indicated what allowed fields are supported?

Resolution: A vendor should published a constrained profile that identifies the allowed fields that are supported, as well as any additional constraints that may be applied.

Field Values for Controls

Status: Closed.

Issue: Need to confirm QC samples, orders, and result values are adequately handled by the interface. What value should be used in Specimen->Specimen Type (SPM-4) for a QC sample? Specimen->Specimen Role (SPM-11) would be Control. Do the business object fields clearly identify the fields required to order an control and to transmit a control test result? For example, does a Control Level need to be specified in LAB-28 or LAB-29? The INV segment is probably needed in LAB-29 to provided detailed substance information for the control, and additional fields should be added to the business object definition for these fields (currently added to Specimen object).

Resolution: SPM-4 will be NULL for a control, and the INV segment was added to the LAB-29 definition.

Sample Identification

Status: Closed.

Issue: There is no clear data element specified to uniquely identify a sample. Specimen and Specimen Container both contain fields that could be used.

Resolution: The fields of Specimen Container will be used to uniquely identify a sample.

The approach defined in HL7 v2.51 Chapter 13 for Specimen Container will be used as predicates for the field values:

• Specimen Container->Container Identifier (SAC-3) is a conditional element for LAB-28 & LAB-29. It is assumed this is the value read from the container bar code, RFID tag, etc.
• Specimen Container->Primary Container Identifier (SAC-4) is a conditional item for LAB-28 & LAB-29. It is assumed this is a value read from the container bar code, RFID tag, etc. for a parent container.
• The predicate for both fields is that Container Identifier, Primary Container Identifier, or both must be populated. See the table with SAC-3 in HL7 v2.5.1, Chapter 13.
• Specimen->Specimen Identifier (SPM-2) ] and Specimen->Specimen Parent Identifier (SPM-3) are allowed fields that can be populated with a specimen identifier or parent identifier(s).
• Specimen Container will be used to carry location information: carrier/carrier location and tray/tray location.

(JB) - Just to be sure:
 - Is the Specimen Identifier (SPM-2) useless in this case or not ?
 - If the Specimen Identifier (SPM-2) is not sent by LIS, is it right to consider that the 'default' value 
   is the Specimen Container Identifier ?
 
In blood culture, the sample can be taken directly in the "blood culture bottle".
Generaly speaking, we take at least 2 bottle for one patient. Each bottle have a unique barcode.
 -> Some customer consider that the bottle bar code (ie. Speciment Container Identifier) is the 
Sample identifier (ie. The sample is not the same in the two bottle). 
 -> Other want to have one Specimen Identifier shared for both bottle.
 => I want to be sure we can manage this case.

Answer: SAC-3 is the field that will hold the barcode identifier read from the bottle. If each bottle has a
a unique container identifier they are considered a unique sample. SPM-2 is not required because SAC is 
is used to identify the sample. Both bottles can have the same value for SPM-2, but it is SAC-3 that will be 
used to determine the tests to perform.

Specimen, Specimen Container, and Aliquots (Parents)

Status: Closed.

Issue: The use of the Specimen->Specimen Identifier, Specimen Parent Identifier and Specimen Container->Container Identifier, Primary (parent) Container Identifier are not very clear.

Resolution: The Specimen fields are only used to describe the relationships between specimens, but are not necessary for sample identification. The Specimen Container' fields maintain the relationship between the containers and identification, and are used to identify the sample for testing purposes. The Specimen->Specimen Parent Identifier can be used to indicate the specimen is from a parent specimen, or to list the specimens that were combined for pooled patient specimens.

For LAB-28, if only Specimen Container -> Primary Container Identifier is provided, then either SAC-10/SAC-11 (Carrier location) or SA-13/SAC-14 (Tray location) must be populated. This information indicates that the sample has been aliqoted into a container that is not barcoded (e.g. tube or micotiter well).

QPD Structure for Query

Status: Closed.

Issue: What QPD parameter fields should be supported for the query? The QPD definition for LAB-22 could be used, but shouldn't SPM-2 be removed since the SAC fields are used to identify the sample?

Resolution: Follow the SAC conventions for OML^O33. SAC-3 is provided when SAC-10 and SAC-13 are not provided. SAC-10/SAC-11 or SAC-13/SAC-14 must be provided if SAC-3 is not provided.

QBP Trigger Event for Query

Status: Closed.

Issue: What trigger event should be used for the Order Query? Q11 is the standard query trigger, but should a unique local trigger be defined?

Resolution: Use the WOS trigger defined for LAB-22.

Query Name

Status: Closed.

Issue: What query name should be populated in QPD-1?"

Resolution: Use the query tag WOS^Work Order Step^IHE_LABTF defined for Lab-22.

Query All

Status: Closed.

Issue: What query fields should be populated for a Query All?

Resolution: Use the query tag WOS_ALL^Work Order Step All^IHE_LABTF defined for Lab-22. No container information is required, so only QPD-1 and QPD-2 are requred.

Support for Batch Queries

Status: Closed.

Issue: Should the capability to support batch queries (query for more than one sample) be supported? Some analyzers may want to query for all samples in a carrier. The query structure does not really support this concept, and it makes negative query acknowledgements more difficult.

Resolution: Rather than supporting a batch query, asynchrnous queries will be supported. See Asynchronous Queries Question. This supports batch query as individual, but asynchronous, query messages.

Sending a Negative Query Response

Status: Closed.

Issue: Should a negative query response be carried by the query response or by the OML^O33? See Negative Query Response Question.

Resolution: Use OML^O33 with an ORC-1 set to DC for specimens with no work. Its usage will be discussed in the profile.

Query Response Parameters

Status: Closed.

Issue: What values should be populated in RCP-1, RCP-2, and RCP-3?

Resolution: RCP-1 and RCP-3 should be populated the same as LAB-22: RCP-1 = I, RCP-3 = R. RCP-2 should not be populated since the response does not contain the orders.

Matching a Query Response

Status: Closed.

Issue: Should QPD-2 (Query Tag) be sent back as part of the OML^O33 message to cleary identify the message is in response to the query? If so, where in the message?

Resolution: No. Any OML with the same SAC information that follows, within an Analyzer-defined query timeout, will be consider a match to the Query.

Query Support for Multiple Samples

Status: Closed.

Issue: Does the Query support including multiple sample IDs, or only one? Volume 1 of the profile draft describes querying one sample, but the use case descriptions in this wiki indicates multiple samples. Also, the LDA profile supports a query for multiple samples.

Resolution: Because asynchronous queries are supported, the query will only be for one sample. Multiple samples can be submitted as individual, but asynchronous, queries.

Analyzer Does Not Support a Request

Status: Closed.

Issue: The profile supports multiple styles of instrument, so an Analyzer may further restrict the possible set of values (usually by restricting supported tables values) for a field based on its capabilities. Thus, it is possible that the message may contain a request that an Analyzer cannot support. For example, if an AWOS Download containing a Specimen Type (SPM-4) of urine is sent to a hematology instrument or a Request Priority (TQ1-9) of STAT that is not supported, what should the reply to the Analyzer Manager contain? Does the Analyzer respond with an "Application Reject" (AR)? Does it ignore the invalid data and assume all service requests are for blood sample? Does it responds with an "Application Error" (AE)? Another example would be that a microtiter tray identifier and well is sent in the Specimen Container as the identifier for the sample, but the Analyzer does not process microtiter plates.

Resolution: Follow the same approach as with other service requests (Placer - Filler). In the Application Acknowledgement, send the "Application Error" response code and include in the response the location of the unacceptable data element. This is found in the IT Infrastructure Technical Framework.

The reason AE is sent is because SPM-4 and TQ1-9 are of type CWE and the allowed
values are specified in a table. An AE is used when unsupported table values are used.
Another possible proposal: Send a result/status with an X status
Answer: Decided to use same convention as other profiles.

Pooled Patient Samples

Status: Closed.

Issue: The usage of the Specimen->Grouped Specimen Count field is "Conditional". The condition is to set the value when the sample is pooled. What is the predicate for "Is Sample Pooled?".

Resolution: The predicate is Specimen->Role = Pooled, or when SPM-11 = "L".

Dilution Factor

Status: Closed.

Issue: Specimen Container->Dilution Factor is an "Allowed" data element. However, the dilution factor may be mandatory for some testing.

Resolution: It is common practice for Analyzers to assume this value is "1:1" when not provided. Thus, it will continue to be a "Allowed" data element, because it may not be used by all Analyzers and will continue to be part of the enhanced result interface.

Usage for Substances

Status: Closed.

Issue: The usage for the fields of Substances need to be reviewed. What goes in the Mandatory Application/Method Identifier? What is the predicate for Substances->Substance Container Identifier?

Resolution: The team determined that Application/Method Identifier should be Mandatory and would be used to identify the substance (e.g. a "reagent"). In addition, some type of identifier is also necessary, so the Substance Lot Number and Substance Container Identifier were made conditional and one or both must be provided. The type of substance, and the lot or container identifier is what uniquely identifies the substance.

Update 4/2/2013: Subsequently, the team submitted CR-115-735 to HL7 to support the use of the INV segment rather than the SID segment. INV has additional fields to better support the identification of contributing substances. The INV segment, and not the SID segment, will be used. In addition, the INV segment is used to identify the substance, rather than provide details about the substance itself (expiration date, etc.). Details about the substance are out of scope for LAW.

Multiple representation of a result and grouping of results

Status: Closed.

Issue: Transmission of additional graphical representation of results, like Images, Scattergrams, X-Y plots etc., where the results can be a representation of a singular WOS or can be related to multiple WOS.

(Remark 1: Grouping of results related to a WOS is already realized by the OBX-3.)

(Remark 2: The data types are not sufficiently specific for differentiation among different representations, e.g., ED may be a graphic or a CDA-doc.)

Requirements, which we try to respond to:

1. Differentiate between the first result (multiple representation) and the repeated result (multiple representation) of the same WOS
2. Differentiate easily between the different representations of the same result
3. Express relation of a graphics to multiple results

To fulfill the above requirements and avoid ambiguities in case of a set of repeating observations within a group and distinguish each of the repeats within one type, we recommend the HL7 suggestion from chapter 7 to use of a dot and a string notation for the "Observation Sub-ID" (OBX-4 of ST data type). This means we would partition the OBX-4 field, where:

• the 1st part is grouping OBX segments,
• the 2nd part is defining results representation and
• the 3rd part is listing the OBX groups in relation to this OBX (optional).

The notation of the OBX-4 we recommend is: |group.result-representation.related-group-x_related-group-y_related-group-z|, where the '.' (dot) is a part separator and the '_' (underscore) is the list separator, different from the regular HL7 separators. Alternative we could define a XML structure, which would express the same idea instead of these additional separators. If the OBX-4 is empty, then the OBX segment has neither grouping nor relations other than defined by the OBX-3 and the OBR. Later we may discuss with HL7 introduction of a data type supporting this structure as fields components.

It means that for transmission of graphical results, like Images, Scattergrams, X-Y plots etc. following is recommended:

• After the OBR segment of the corresponding test order (Work Order Step) use a series of OBX segments, each representing different value type of the observation.
  • The 1st OBX segment is mandatory and contains the usual observation, e.g., numeric value, code, etc.
  • The next OBX segment is optional, but if present it contains the graphical image as the HL7 "Encapsulated Data (ED)" data type with MIME content. The graphic may be of reduced resolution, e.g., a thumbnail to reduce the transmission throughput and storage requirements.
  • The next OBX segment is also optional, but if present it contains the pointer to the graphic as the HL7 "Reference Pointer (RP)" data type. Suggestion: use an Uniform Resource Identifier (URI) for an HTTP(S) or FTP(S) anonymous access. The receiver has only a read access and the sender is responsible for the file management (e.g. deletion after 24 hours or any other defined retention time).
  • Another optional OBX segment may contain the series of values representing coordinates of individual points of the graphic as the HL7 "Numeric Array (NA)" data type. The NA data type may represent multidimensional arrays, e.g. X-Y or X-Y-Z plots.

• Major characteristics of the OBX segments in context of the transfer of multiple representation of an observation :
  • The OBX segments will have different "Value Type" (OBX-2), e.g., CWE, ED, RP and NA as described above.
  • Each OBX segment has the same "Observation Identifier" (OBX-3) -- LOINC code .
  • The OBX segments are grouped and put into relation by the "Observation Sub-ID" (OBX-4) as described above.

Example

	OBR|1|...<cr>
	OBX|1|CWE|11156-7^Leukocyte morphology finding^LN|1.1|...<cr>
	OBX|2|ED|58407-8^Leukocyte morphology panel^LN|2.2|...<cr>
	OBX|3|RP|58407-8^Leukocyte morphology panel^LN|2.3|...<cr>
	OBX|4|NA|58407-8^Leukocyte morphology panel^LN|2.4|...<cr>
	OBX|5|ED|58408-6^Erythrocyte morphology panel^LN|3.2|...<CR>
	OBX|6|RP|58408-6^Erythrocyte morphology panel^LN|3.3|...<CR>
	OBX|7|NA|58408-6^Erythrocyte morphology panel^LN|3.4|...<CR>
	OBX|8|ED|58410-2^Complete blood count (hemogram) panel^LN|4.2.2_3|...<CR>
	OBX|9|RP|58410-2^Complete blood count (hemogram) panel^LN|4.3.2_3|...<CR>

 Is this proposal compatible with what is defined in the current volume 2 at chapter 3.11 for 
 microbioloy result ?
 - OBX-4 is used with only the group meaning (eg. to group the antibiogram result 
 with the identification result).
 - OBX-3 vary in the group (for the various drugs for example) §3.11.3.2 

Resolution: A simpler approach was chosen that supports multiple observations of the same WOS and multiple representations of the same observation. It was decided not to express the relation of a representation to multiple observations. In addition, it is assumed a representation will contain the necessary metadata to distinguish it from other representation if necessary. The dot separator is not required with this approach.

The grouping of multiple observations related to an AWOS is accomplished by defining multiple OBX segments each having a unique value for OBX-3 Observation Identifier. The grouping of multiple representations of the same observation is accomplished by defining multiple OBX segments that have the same value for OBX-3, but unique values for OBX-4 Observation Sub-ID. It is recommended that OBX-4 be populated with consecutive numerical values, although any unique identifier can be used.

Date/Times and Time Stamps

To ensure consistency across the message contents, the MSH-7 Date/Time of message shall require the time zone information. All other time stamps in the message are assumed to be in the same time zone as MSH-7.

Individual time stamps will be handled as follows:

• MSH-7 Date/Time of Message, OBX-14 Date/Time of Observation, OBX-19 Date/Time of Analysis, ORC-9 Date/Time of Transaction, SPM-17 Specimen Collection Date/Time, and SPM-18 Specimen ReceivedDate/Time will require the date and the time. These are fields commonly generated and managed by a software system and these time stamps naturally contain the date and the time. In addition, the time is usually an important value to know for these fields. The degree of precision will be to the seconds. Rather than defining optional format elements, (e.g. [HH[MM[SS]]]), the profile assumes a sending system will populate unknown time precision values with 0's. For example, a sending system would send '125900' for a HHMMSS value where seconds are unknown, '120000' when minutes and seconds are unknown, etc.
• ORC-27 Filler's Expected Availability Date/Time and PID-7 Date/Time of Birth will require the date and support an optional time. The time may not always be available or useful for these fields, so it will not be required. For example, the time associated with Date/Time of Birth is usually only important for pediatric testing.The profile assumes a sending system may also populate unknown time precision values with 0's.

Security Analysis

TBD.

Draft for Trial Implementation Issues

The following are issues identified with the draft for trial implementation of the LAW supplement. These will be discussed and converted into change proposals as necessary.

MSH-9 Value for LAB-27 MSH-9.2 Trigger Event Is Unclear

Location: Line 2365

Issue: The diagram in Q.4 seems to indicate that "WOS" will be used for the Trigger Event component of MSH-9, but line 2380 states "Q11" will be used. Is "Q11" the trigger? Need to either correct the diagrams and tables or the statement defining MSH-9.2.
François: The figure is wrong (it's an abusive copy/paste from LAB-22 of LDA profile). So correct the figure only.

Status: CP #176

Missing Behavior When Data Not Valid For The Actor

Location: Line 1475

Issue: The profile does not state what an actor (mainly the Analyzer) should do when a message is received for a capability not supported by that actor. For example, if an Analyzer Manager identifies a sample by sending SAC-13 and SAC-14, but the Analyzer does not process trays should an "Accept Acknowledgment" or an "Application Acknowledgment"? The Analyzer may define a specification that further contrains the LAW profile due to intrument capabilites.
François: As is always the case in an IHE profile leveraging HL7 v2 messages, if the receiving application cannot operate on some data of the message, it will send back a negative application acknowledgement, with MSA-1 = AE and ERR segment specifying which data is in trouble, and why (in the example above, ERR-3 = 204 "unknown key identifier" and ERR-2 referencing field SAC-13

Status: CP #176

Message Structure for Enhanced Acknowledgment Mode Needs Clarification

Location: Line 1515

Issue: Additional clarification is needed about the message structure to use when sending "Accept Acknowledgments". For example, what is the structure of an "Accept Acknowledgment" when sent in response to an OML^O33?
François: As is always the case in an IHE profile leveraging HL7 v2 messages, most acknowledgements are application acknowledgemens. These are described in detail across all IHE domains in section C.2.3 of ITI TF Vol 2x.
The only case where there is an accept acknowledgement is when the lower communication layer had a problem or when the safe storage of the message cannot be done and thus the message cannot be committed. And it is thus always a "communication error" or "commit error" message, ORL^O33 in the example above.
See also Closed Issue LAW-02 in the LAW supplement, as refined by CP #176.

Status: Closed.

Missing Behavior for Invalid MSH-15, MSH-16 Values

Location: Lines 1475, 1650, and 1655

Issue: The profile should define the behavior of the actor when receiving a message with invalid values for MSH-15 and MSH-16. Should an "Accept Acknowledgement" of "Error" be returned?
François: That would be an "application error"

Status: CP #176

Clarification needed for MSH-15 and MSH-16 using in an Acknowledgment

Location: Lines 1475, 1650, and 1655

Issue: The profile does not state what the values for MSH-15 and MSH-16 should be for the acknowledgment response. These fields should be set to "NE" so that an Accept Acknowledge is not sent in response to an Application Acknowledgment. For example, an Accept Acknowledgment is never sent for an OML^O34.
François: MSH-15 ans MSH-16 are empty in all kind of acknowledgement messages. There is never such monstrous thing as an acknowledgement of an acknowledgement.

Status: CP #176

Missing Behavior for Invalid MSH-3, 4, 5, and 6

Location: Lines 1590, 1595, 1600, and 1605

Issue: What should a receiver do if the values in these fields are not correct. For example, if the value in the Receiving Application field does not match the value defined by the receiving actor, should the message be rejected?
François: That would be an "application error"

Status: CP #176, which refers to the reading of ITI TF-2x:C.2.3. The contraints for these checks were eliminated by the CP for the 2013 release. A section was added that discussed message identification.

Missing Behavior when MHS-21 Is Incorrect

Location: Line 1715 Issue: Does the profile need to address what to do if the value in this field is incorrect? The assumption would be that the message is rejected and "Accept Acknowledgement" or "Error" is returned. Any additional messages would need to be negotiated between the actors.

François, since MSH-21 is Mandatory with a fixed content. This would naturally be an application error. "AE"

Status: CP #176.

Need Additional Discussion on Error Severities

Location: Line 1510

Issue: What are the scenarios that would cause a W or an I to be sent? What should an actor do if a W or I is received?

François, If MSA-1 = "AE" or "AR", then ERR-4 SHALL be equal to "E". ERR-4 MAY be W or I only if MSA-1 = "AA". ITI TF-2x does not sat anything more than the standard on ERR-4. I would recommand not to use W nor I. I add this to CP 176.

Status: CP #176

Size of OBX-18 Is Incorrect

Location: Line 1795 Issue: The length of OBX-18 is defined to be 22, but the total size of the components of the field are greater than 22.

François: Corrected by CP176: Take the max length of datatype EI, which is 427.

Status: CP #176

Add Additional Clarification on Use of ORC-1

Location: Line 1910 Issue: Futher clarification of the Order Contol Codes may be benficial. Some codes (e.g. NW) are only sent by the Analyzer Manager, while other codes (e.g. UC) are only sent by the Analyzer.

François: and by the way, the most important one "SC" was missing for LAB-29.

Status: CP #176

Usage of ORC Segment in LAB-29 Needs Clarification

Location: Line 2675

Issue: The ORC segment is shown as an optional segment for OUL^R22. The discussion should define when the segment is sent. The assumption is that it is only sent when supporting the enhanced bi-directional interface elements. In most cases, it is not required when sending the OUL^R22 message.

The ORC segment is now mandatory for LAB-29. No change was required.

Status: Closed.

Conditionals in Table Q.5-3 Do Not Follow Conventions

Location: Line 2455

Issue: The conditionals to do not use the convention of C (a/b) identified in Section W.1.3, line 1365. The usage entries for QPD-3 to QPD-8 should be updated to match the pattern used with other segement definitions.

Status: CP #182.

Missing Discussion on Behavior for Invalid QPD

Location: Line 2440

Issue: The profile states that the QPD segment received in the RSP response should be the same as the QPD sent in the QBP message. What is the expected behavior if the segment is not the same?

Status: CP #182.

TQ1 Segment Usage in LAB-28 Does Not Match Cardinality

Location: Line 2525

Issue: The Segment definition for TQ1 should be [TQ1] to match the Cardinality of [0..1].

Status: Closed. Combined with Segment Definitions in LAB-28 Do Not Match Cardinality.

Use of SFT segment in LAB-27 Is Inconsistent

Location: Line 2430 Issue: SFT is defined as an optional, repeating segment for the LAB^27 messages. This is inconsistent with the LAB-28 and LAB-29 message profiles. Need to decide if SFT will be used in the message definitions. It does contain information that might be useful for audits, etc. If it is not supported, need to remove this segment from the LAB-27 message profile.

François : SFT is a Loyd McKenzie very special segment. Should not be used in our profile. Actually it was LAB-28, which was mentioning it, not LAB-27.

Status: CP #176

Segment Definitions in LAB-28 Do Not Match Cardinality

Location: Lines 2580 and 2610

Issue: For OML^O33, [{SAC}] should be SAC to match the cardinality of [1..1]; TQ1 should be [TQ1] to match the cardinality of [0..1].For ORL^O34 the PATIENT group should be Required and not Optional and the cardinality is [1..1] - because the RESPONSE group is optional; PID should be [PID] to match the cardinality of [0..1]; [{SAC}] should be SAC to match the cardinality of [1..]; "[{" for ORDER group should be "{" because the group has cardinality of [1..*].

 Usage and cardinality for PATIENT Group for ORL^O34 should be corrected. All other suggestions are due to the
 HL7 message structure being further constrained by the usage and cardinality, so no changes are necesary. 

Argument against (FM April 10): In message static definition tables, do not confuse the meaning of "[" and "{" in column 1 "Segment", with the content of columns 3 (Usage) and 4 (Cardinalities): Column 1 is simply a reminder of the optionality and repeatability of the field in the original HL7 message structure whereas columns 3 and 4 specify the additional constraints brought by the static definition of the message profile built by IHE. Hence The columns 3 and 4 are often more constraining the field that column 1 does.

(EH April 16th): This is covered in HL7 2.5.1 section 2.12.7 and LAB TF Volume 2 section 2.3.1.

Status: Closed without change to the supplement (FM, April 10). Message tables should be reviewed to confirm the segment columns match the HL7 message structure definitions. Correction to ORL^O34 usage should be applied (EH, April 16). CP #178.

Missing Ability to Add Comments to An Order in LAB-28

Location: Line 2525

Issue: It should be possible to add comments to an order. The NTE segment should be added as an optional segment under the [TCD] segment in the OBSERVATION REQUEST group.

Status: CP #176 (FM April 10).

Missing Support for Inventory Version Number

Location: Lines 2095, 1515, and 205

Issue: SID-1 has been modified from the HL7 definition to support a Substance Version and Substance Type. The INV segment supports a Substance Type with INV-3. However, The INV segment does not support a Substance Version. Need to align the elements Substance Identifier, Substance Type, and Substance Version between these two segments. Ideally, an approach consistent with HL7 v2.5.1 would be taken. This is partially covered by Open issue LAW-22.

NOTE: Being addressed with an HL7 change request CR115-735 that deprecates the SID segment and replaces with INV segment.

Status: Closed.

Equipment Instance Identifier Definitions are Incorrect

Location: Lines 1795 and 1890

Issue: The Cardinality for OBX-18 should be [2..*]in the OBX Segment table. Two instances are mandatory to transmit Model and Serial Number. In the table containing the definition of OBX-18 for Entity Identifier the usage for the "Second repeat" should be R. The comment of "User defined" for "Subsequent repeats" should be "Vendor defined".

Status: CP-186.

Definition of QPD-1 is Incorrect

Location: Lines 2460 and 2465

Issue: The QPD Segment definition does not indicate that table 0471 will be used for QPD-1. In the definition of QPD-1, the values for table 0471 are not described. These should be WOS and WOS_ALL.

Status: CP #182.

Definition of QAK-3 Does not Match QPD-1

Location: Lines 2535 and 2500

Issue: The length of QAK-3 in the QAK segment table does not match the length of QPD-1 in the QPD segment table. The definition for QAK-3 is incomplete; it is missing the Text and Name of Coding System components.

Status: CP #182.

Enhance Discussion on Sending Multiple AWOS

Location: Lines 725, 775, and 795

Issue: The profile supports sending multiple AWOS in a message. Lines 725 and 795 discuss this for Broadcast and Query All, but sending multiple AWOS in response to a Query near line 795 is not discussed. The use case discussion should be enhanced to clarify that multiple AWOS can be sent in a response to a Query.

Status: CP-182.

Clarify Discussion on Negative Acknowledgment for LAB-27

Location: Lines 2390-2395, 2405-2415, 2540, 2580, 2590

Issue: The use of the acknowledgement sent as part of LAB-27 message exchange needs to be clarified. The supplement is not very clear on the meaning of the negative acknowledgment: it is used to indicate the Analyzer Manager does not accept the query, rather than it has no work for that sample. The OML^O33 sent with ORC-1 set to "DC" indicates there is no work for the sample container. These discussions are spread across several sections.

The use of the values for QAK-2 should also be clarified in Table 0208. The value "OK" does not mean data was found, but rather that the query is accepted. The value "NF" does not seem to apply, as "no work" (no data found) is sent by using LAB-28.

In addition, the OML^O33 message definition does not completely support sending the "no work" message. The SPM segment is required (also required by HL7 2.5.1), so the SPM-4 and SPM-11 fields are mandatory. However, the Analyzer Manager has no information about the specimen and thus no values for these fields. A recommedation is that SPM-4 be set to "UNKNOWN" and user defined table 0369 be extended with "U" for unknown so that SPM-11 can be set to "U".

  Need to insert an example message for OML^O33 here that can also be used in the profile.

Finally, the use of DC should be discussed as part of the Expected Actions section for LAB-28. No guidance is given on the use of "DC" and expected reply from the analyzer. Table 119 in Chapter 2.C of HL7 v2.7 describes that "CR" should be returned in the ORL^O34 response. However, the consensus is that the ORL^O34 response should be a general acknowledgement consisting of a MSH and MSA segment only.

Status: CP #182.

Update QPD-3 Predicate

Location: Line 2475

Issue: In the QPD-3 section, it saids : "Predicate : When QPD-1.1 is "WOS", QPD-3 must be populated if QPD-4 or QPD-6 is not populated. Usage is Not Supported when QPD-1.1 is "WOS_ALL"". Is it not simpler to say : "Predicate : When QPD-1.1 is "WOS", QPD-3 must always be populated. Usage is Not Supported when QPD-1.1 is "WOS_ALL"", according to the QPD-4 and QPD-6 field predicate definition ?

Recommend enhancing LAB-27 Expected Actions with a discussion clarifying the use of the QPD fields.

Ed Heierman: The current description is correct and follows the same rules as the corresponding SAC segment fields. The query can be based on a sample container ID (QPD-3), a sample location in a carrier (QPD-4 and QPD-5), a sample location in a tray (QPD-6 and QPD-7), or for all potential samples (QUERY ALL). The following table provides examples for usage of the QPD fields. The predicates were defined based on the the same concepts used for the SAC field definitions and predicates (see lines 2035 - 2100 in the supplement and HL7 v2.5.1 Section 13.4.3).

QPD field	Sample container with barcode	Sample container without barcode in rack	Sample in microtiter well	Query All
"Mesage Query Name.Identifier" QPD-1.1	WOS	WOS	WOS	WOS_ALL
“Container ID” QPD-3	Container barcode ID e.g., 987654
"Carrier Identifier" QPD-4		Carrier barcode ID e.g., 12345
"Position in Carrier" QPD-5		One dimensional e.g., 3
"Tray Identifier" QPD-6			Tray barcode ID e.g., 45678
"Position in Tray" QPD-7			Two dimensional e.g., 13^8
"Location" QPD-8		Populate if necessary to clarify location	Populate if necessary to clarify location

Status: CP #182.

QPD-9 Should be QPD-8

Location: Lines 2510-2520

Issue: The field is QPD-8 rather than QPD-9 for all uses of QPD-9 in this section.

Status: Closed, added to CP #176 (FM April 10).

Support Related Results in Lab-28

Location: Line 2580

Issue: The OBSERVATION group consisting of the segments QBX, TCD, and NTE should be included as an optional group in the segment definition for LAB-28 (OML^O33). These segments can be used to transmit related results associated with the sample that are necessary to perform the requested test. The OBSERVATION group is right before the PRIOR RESULTS group.

Status: Closed, added to CP #176 (FM April 10).

Support Notes for Observation Request in Lab-28

Location: Line 2580

Issue: The OBSERVATION_REQUEST group should also include an optional and may repeat [{NTE]} segment for notes/details releated to the observation request.

Status: Closed, added to CP #176 (FM April 10).

Correct Description of OBX-19

Location: Line 1895

Issue: The description of OBX-19 is incorrect. The field is mandatory for both the Analyzer and Analyzer Manager.

Status: Closed, added to CP #176 (FM April 10).

Correct PID-3 Sub/Component Usage

Location: Line 1975

Issue: The data type of PID-3 is "CX", and in the Laboratory TF Volum 2, section 2.4.6.1, it is specified that the assigning authority element (CX.4) usage is Required.

THe LAW profile does not require an exhaustive list of patient identifiers or other attributes due to the "local" nature of the communication between the Analyzer Manager and the Analyzer. In section 2.A.14 of the HL7 v2.5.1 standard, only the Identifier (CX.1) is required. The LAW would not prohibit an Analyzer Manager or Analyzer from populating CX.4, but it does not consider it an error if the sub-component is not populated. The LAW profile does differ from other Lab profiles in the usage of segments fields.

The PID-3 discussion should be enhanced to discuss the approach to patient identification for the LAW profile and the handling of the CX fields mandated by the LAB TF.

Status: CP-Message Syntax Updates.

Correct OBR-25 Usage

Location: Line 1725

Issue: OBR-25 is not supported in the current OBR segment definition.

The HL7 v2.5.1 TF in the 4.5.3.25 section : "This field contains the status of results for this order. This conditional field is required whenever the OBR is contained in a report message. It is not required as part of an initial order." So, for the OUL_R22 message, I think that the OBR-25 field should be Required.

However, 4.5.3.25 is also ambiguous in that it states: "This field would typically be used in a response to an order status query where the level of detail requested does not include the OBX segments. When the individual status of each result is necessary, OBX-11-observ result status may be used. Refer to HL7 Table 0123 - Result Status for valid entries." This seems to imply that it is not required when using OBX-11 to report the individual status of each result.

Response from HL7 Orders and Observation group list server:

OBR-25 is useful in all circumstances in results messages from the filler (in this case our Actor Analyzer) to the placer (in this case our Actor Analyzer Manager). OBX-11 provides the status of the individual observation whereas OBR-25 provides the consolidated order result status. There is a necessary correlation of status between the two. I mean that not all combinations make sense. These licit correlations as well as the licit status transitions diagrams of each of these fields have been defined in the IHE LAB Technical Framework Vol 2, section 3.10 (downloadable from http://www.ihe.net/Technical_Framework/index.cfm#laboratory), and were discussed with HL7 OO at the time they were produced (2004). My point of view is that the LAW profile being part of this framework should conform to this section 3.10 of Vol 2.

Final Resolution: OBR-25 will not be used. The ORC segment will be mandatory and ORC-5 will be used to identify the status. The only change was to correct the definition of OBX-11 and references to HL7 User-defined Table 0085. This is not a user defined table.

Status: CP-184.

Clarification on OBX-14 and SPM-17 Usage

Location: Line 1795, 1875, 2190, 2288

Issue: The HL7 standard indicates that OBX-14 should be used when observations have different dates/times or when OBX segments are being sent to the filler. For LAW, observations are sent in LAB-29(OUL^R22) and are grouped by sample. Prior results can be sent as part of LAB-28 (OML^O33).

In LAB-28 the OBX-14 field is used to convey a date/time associated with the prior test, and not the current sample being tested. The standards also states that the collection date/time should be used for tests performed on specimens. Using OBX-14 in LAB-28 seems clear. However, the field seems unnecessary for LAB-29. SPM-17 carries the date/time the specimen and any OBX used in LAB-29 is associated with a SPM segment so the value in OBX-14 would be the same as SPM-17. SPM-17 will need to be mandatory when reporting results with LAB-29.

[Francois] 1) Transaction LAB-29 will stick to this specimen-centered message OUL^R22 even in the future. 2) SPM-17 is required in this transaction. This does not seem to be the case in the current release of the supplement. Moreover there is a condition predicate based on the content of field SPM-11, which seems to be a typo: <<Analyzer Predicate: Usage is Optional when SPM-11 is “O”. Otherwise usage is Not Supported.>> What is this value "O" for SPM-11? [Ed] Probably does not need to be required, as it does not seem to be a value an analyzer is required to send. The "O" should probably be "P".

Final Resolution: SPM-17 will be required for LAB-29 and predicate will be corrected.

Status: CP-184.

Identifying Multiple Parents For a Reflex Test with OBR-29

Location: Line 1785

Issue: OBR-29 is used to identify the parent AWOS for a reflex test. However, there is no way to identify that multiple AWOS resulted in the reflex. A Change Request should be submitted to HL7 that makes OBR-29 repeatable.

Another change request, CR072-723, was submitted to the HL7 OO WG. The CR changes the intent of the OBR-29 and ORC-8 fields. HL7 has recommended using ORC-8, and a request has been submitted to make ORC-8 repeatable.

Status: CP-180, and HL7 CR075-725.

Change Usage of ERR segment

Location: Line 2435, 2610, 2680

Issue: The ERR segment should be conditional for the ORL^O34, RSP^K11^RSP_K11, and ACK^R22 acknowledgements. It is only provided when MSA-2 is not equal to "AA".

Status: Corrected in v1.3.

Clarify Predicate for ERR-2

Location: Lines 1530

Issue: The predicate is not testable. How can it be confirmed that an error was within an HL7 field, component, or subcomponent? Need to refine the predicate.

Status: Changed to RE in v1.3.

Complete Definition for SPM-2

Location: Line 2205

Issue: The definition for SPM-2 is incomplete. There are no lengths provided in table W.3.12-2. Need to confirm that the Filler Assigned Identifier is not needed.

Status: CP-186.

Add definitions for the EIP and EI Data Types

Location: Line 1925

Issue: Need to provide a consistent use of the EI and EIP data type. May want to provide a definition for the EIP data type and the EI data type for use within the LAW profile. For example, ORC-4 only uses EI.Entity Identifier. No guidance is provided for ORC-2. Need to confirm that usage of the EI and EIP components and subcomponents across the different segment fields.

Status: CP-Message Syntax.

Make Container Group Mandatory for LAB-29

Location: Line 2675

Issue: The CONTAINER group usage in the static definition of OUL^R22 should be Required because the SAC segment must be provided.

Status: CP-184.

Provide Guidance on use of Optional Segments in LAB-29

Location: Line 2675

Issue: No guidance is given as to when the Optional segments defined in LAB-29 should be used. This should be added to the discussion on the message semeantics.

Status: CP-184.

Undefined Footnote in LAB-29 Static Message Definition

Location: Line 2675

Issue: The usage for the TCD and SID segments contain an "*1" footnote reference. However, the footnote is not defined.What is the condition for these segments? Should the convention for conditions be used?

Status: CP-184.

Mismatches in Patient Data

Location:

Issue: The profile should discuss how the Analyzer Manager should handle mismatches in patient data received from an Analyzer.

Status: CP-231 and others. New section W.2.9.9.

Supporting a Test Message

Location:

Issue: The profile should support the use of a test message to test a connection. This may involve the ITI domain.

Status: Closed. Out of scope of LAW.

Discussions on Dilutions

Location:

Issue: Add additional discussions on sending dilutions needed with TCD in section R.5.

Status: CP-228.

Mismatches in Test Code

Location:

Issue: Is a discussion needed on how the Analyzer Manager should handle mismatches in data received from an Analyzer? For example, OBR-4 Universal Service Identifier in LAB-29 does not match value sent in LAB-28.

Status: Addressed in v1.3, W.2.5.5.

Retransmitting Results

Location:

Issue: Guidance should be provided on field values when retransmitting results.Should also discuss that results may be retransmitted as part of a transmitting a reflex. For example, the original AWOS observations are sent, the Analyzer performs a reflex, and then when sending the reflex observation is sends the original observations as well.

Status: Addressed in v1.3.

Gudiance in OML^O33 on Cancelling an AWOS

Location: 2585

Issue: Provide additional guidance on cancellation of tests and segment usage (ORC-OBR), field values, etc. near lines 2585 where the OML^O33 message is discussed. Details are provided in OML for receiving cancels and under Expected Actions, but no guidance is provided in the ORL.

Status: Addressed in v1.3.

Profile Includes/Excludes Calibration Results

Location: 660

Issue: Update Scope to clearly state that this profile covers or does not cover calibration results. The profile states it covers Patient and QC results, but CP-LAB-179 has a proposed update to section W.2.5.4 Transmitting Raw Values that speaks to sending Calibration Linear Curve parameters.

Status: Closed.

AWOS ID Uniqueness

Location: 725

Issue: Clarify guidence on AWOS ID uniqueness. If an lab has multiple Analyzer Managers, is each AM supposed to ensure that its generated AWOS IDs are unique only for itself, or ensure that they are unique across all AMs in the lab?

Status: Closed.

Profiling Conventions - use of M and O

Location: 1360

Issue: Clarify usage of M and O usage coded values. Discussion in Section W.1 does not seem to match with usage. For example, for message definitions at the segment level why is not M used to specify that MSH segment is Mandatory? Is the intent that M is used only for elements within Segment?. Also, in W.1.2, it is stated that O is used only for data elements that can be sent by the analyzer, but is also shows up in message segment tables indicating which segments the Analyzer Manager may send (e.g. CP-LAB-176 Section R.5, OML^O33 Message)

Status: CP-Message Syntax Updates.

OBX-11 Observation Results Status

Location: 1870

Issue: Table W.3.6-7 should be revisited. It does not match usage described in CP-LAB-179.

Status: CP-222.

Meaning of "Preliminary" Results

Location: 755

Issue: Use cases discuss sending of Preliminary results. Not clear on what Preliminary result are. In past interfaces, took this to mean the raw response value produced by the instrument that was then used to generate the Final result. Other potential meaning is that is a result value that has not gone through some sort of approval or review on the instrument. Can the term be clearly defined as to its meaning?

Status: CP-222.

Guidance on how many specimens can be sent in OML^O33 or OUL^R22 message

Location: 2580, 2675

Issue: Message definition indicates that message can contain 0 or 1 PATIENT segment group, and 1 to * SPECIMEN segment group which implies that a message can contain one or specimens for a single patient. Since the PATIENT segement group is optional, any guidance on how many SPECIMEN groups can be sent if there is no PATIENT info known?

Status: Closed. Any number can be sent because there is no PATIENT group, thus they are not associated with any Patient.

Guidance on how multiple query messages

Location:

Issue: Can an analyzer send a second LAB-27 message before it has gotten the LAB-28 response in reply to a first LAB-27? Can an Analyzer Manager send a single LAB-28 message containing AWOSs for multiple LAB-27 messages? Or must there be a one to one corresponance between a LAB-27 and LAB-28?

Queries can overlap. The profile is silent on sending on LAB-28 for a LAB-27. As long as they are for the same patient, it is allowed. Additional clarification could be beneficial.

Status: Closed.

Meaning of Worklist term

Location: CP-LAB-182 X.2.2

Issue: The term "worklist" is used in various use cases (e.g AM provides a single worklist to the Analyzer). Not clear what this term means and if it can imply multiple specimens sent in multiple LAB-28 messages, or does it represent what can be sent with a single LAB-28 message.

Status: Clarifications added to v1.3.

Analyzer result order status/result status for reruns decided on analyzer

Location: CP-LAB-179 W.2.5.2

Issue: There is discussion in the CP around the analyzer being able to know amongst multiple reruns, which of them is "Reportable". There are situations describing how the analyzer in one case knows that one run among many is reportable, while another situation the analyzer leaves it up to the AM to know which is reportable. If an analyzer must integrate with different AMs in different labs, how does it gain the knowledge of which result is reportable or know if the analyzer makes the decision or the AM makes the decision. In addition, the existing discussion seems to indicate that somehow the last run is always the reportable one. Consider instead that what is really needing to be communicated to the AM about a result is two things: 1) if the result is a rerun of an AWOS, how to indicate that fact along with a run number. 2) if a result is being reported now but a rerun is underway, how to communicate that information (if at all). The decision of what result among many reruns is "reportable" by the lab is likely out of scope for the analyzer.

Status: CP-222.

Transmitting Alternate Representations

Location: CP-LAB-179 W.2.5.3

Issue: How does an analyzer send the following result and alternate representations for an AWOS ID for a screening assay: Result (analyte concentration) = 0.55 Interpretative Result = NON-REACTIVE Response Value (raw instrument response value that is used to calculate the concentration) = 456.874

The current discussion indicates that alternate result representations are always of a different data type, which may not be true, as in this example. Also, currently indicates that raw result values are either structured or a series of values, which is not true in this example.

Is there something in the result message that identifies the "primary" result vs. the alternative results?

Status: CP-226.

Identifying Profile Transactions

Location: W.1.3.x

Issue: When identifying transactions in the profile message elements table (for example, table W.1.3.2-1) the message structure is listed for LAB-28 and not LAB-29. We differentiate between OML and ORL for LAB-28, but do not need to do this for LAB-29. Should the structure for LAB-29 be included? LAB-29 only has OUL because it uses the general acknowledgment.

Status:

Identifying Profile Options in MSH-21

Location: W.1.3.16

Issue: This is the first time the use of LAW_POOL_AN is called out for MSH-21. We need to add an indicator in table Table X.5-1: Laboratory Analytical Workflow - Actors and Options that MSH-21 must be used to indicate that option is used, vs options, that don’t require this.

Status:

Pre-adopt ED datatype values

Location: W.2a.3.

Issue: Need to state from which HL7 version tables 0834 and 0291 are preadopted.

Status: Covered by October 2015 CPs.

Establish that LAW does not use Snapshot mode

Location: W.2.5.3.1

Issue: The text "Note that only the values to be corrected are transmitted because each observation is uniquely identified by the values of OBX-3 and OBX-4. The message is interpreted as the values for run number two (specified by OBX-4) of the observations specified by each OBX-3 are to be corrected" implies that LAW does not use snapshot mode. Need to further discuss.

Status: Done. Reviewed in 2015 Paris F2F meeting and determined no action needed.

LAW Support for Multiple Order Groups

Location: Table W.3.5-1

Issue: Question: "We are not supporting the set ID but we are supporting multiple Order groups?"

Status:No need for OBR-1, since OBR-2 is unique – set ID has no bearing on message parsing in this arena – in LDA OBR-1 is R – in the future may want to harmonize LAW and LDA.

Predicate for OBX-2

Location: Section W.3.6, OBX-2 field definition.

Issue: Change the CP to "If OBX-11 is not valued “X”?" Used "NULL" so that the OBX could consist only of OBX-8 interpretation codes without an OBX-5 value. This appears to be supported by the HL7 discussions for OBX-5.

Status: Predicate will not be changes so that can send empty OBX-5 and use only OBX-8 for the interpretation codes. LAW supports ability to send only OBX-8 for valid results.

Preadopted use of EIP for ORC-4

Location: Section W.3.7, ORC-4 field definition.

Issue: Why was EIP preadopted from HL7 v2.8 when only the first EI is used by LAW?

Status: Leave as is – no reason remembered as to why this was done…came from LTW, where it is being used – hence LAW also uses.

Preadopted Repeat of ORC-8

Location: Section W.3.7, ORC-8 field definition.

Issue: The repeat usage is pre-adopted from v2.9, but need a well written use case to get this passed. Confirm this is approved in v2.9.

Status: Parents of a reflex – in LAW the instrument wants to track which AWOS contributed to the reflex ordered on the analyzer. This has been approved; http://wiki.hl7.org/index.php?title=OO_CR075-725_Repeat_ORC.8_and_OBR.54. Referenced added with a CP.

Use of Profile Modifiers

Location: Section 3.R.5.2, 3.Y.5.2

Issue: Immediately after table 3.R.5.2, need to improve discussion for MSH-21 to include information on the pooling options that are populated in MSH-21. For both 3.R.5.2 and 3.Y.5.2 could include that MSH-21 is also used to communicate profile options. Is it needed for LAB_29 though?

Status:

Use of SGH,SGT Segments

Location: 3.R.5.4, 3.R.5.5

Issue: Should these segment definitions be included in section W.3 where the other LAW segments are described? Or, consider the same as the Query segments?

Status: Leave as-is. Location in current supplement is fine.

Use NULL for CE and CWE data types

Location: Various

Issue: Assume NULL ("") covers the entire data type, and not just CE.1 or CWE.1. This eliminates the need for condition predicates saying no to populate the other fields when "" is used.

Status: NULL does cover the entire data type. Reviewed profile to confirm consistent usage across the CE and CWE datatypes. Coordinated with Gazelle Tool developers.

Analyzer Compliance with Truncatable Conformance Lengths

Location: W.1.2b

Issue: The section allows Analyzers to define a non-truncatable conformance length less than the value defined by LAW for some fields. Recommend The same capability should be allowed for fields with truncatable lengths. The Analyzer should be able to specify a length less than than value specified by LAW, and would truncate values received that exceed the Analyzer specified length. LAW has already identified that loss of information in these fields does not impact the messaging.This will help support legacy systems.

Status: Created CP to adjust lengths to lower value agreed upon by the committee. Agreed to adjust the length than allow individual systems to deviate.

Proposed Changes to LAW v1.3

The following changes recommended for LAW v1.3 are under consideration. This section will be used to collaborate on the proposed changes prior to the creation of a formal Change Proposal.

Clarifications

Status: CP Submitted

File:LAW 1.3 CP Clarifications.docx

Coding Systems

Status: CP Submitted

File:LAW 1.3 CP Coding System.docx

Error Handling

Status: CP Submitted

File:LAW 1.3 CP Error Handling.docx

Length

Status: In Development

File:LAW 1.3 CP Length.docx

Comments: New file version 08/07/2014

Highlights:

• HL7 v2.7 length conventions will be used
  • HL7 v2.7 lengths will be used for primitive data types (eg, ST, NM)
  • The lengths for composite data types will not be specified
• Normative Lengths will be used
  • Examples include fields based on fixed set of identifiers or codes (eg, OBX-11 Observation Result Status)
  • Truncation is not allowed
  • A system that cannot support the Normative Length will generate an error for a value with a length it cannot support
• Conformance Lengths that cannot be truncated will be used
  • Examples include fields used as primary identifiers (eg, Universal Service ID)
  • A system that cannot support the Conformance Length will generate an error for a value with a length it cannot support
  • The Conformance Length of fields used as Keys/Primary Identifiers must be established
• Conformance Lengths that can be truncated will be used
  • Examples include fields that provide additional information (eg, Family Name)
  • A system may truncate any value with a length greater than the conformance length
  • The truncation character "#" will be used with a field is truncated
  • A system that cannot support the Conformance Length will generate an error for a value with a length it cannot support
  • The Conformance Length of these type of fields must be established

Orders and Observations

Status: CP Submitted

File:LAW 1.3 CP OBR Fields.docx

File:795.docx -- HL7 change proposal on TCD fields

File:TCD-IN-LAW.docx -- Meeting Minutes on TCD discussions

Background:

• Siemens has requested the following TCD fields be reviewed for inclusion into LAW:
  • TCD-2: Dilution factor (which says how much sample needs to be diluted before running the test could be number like 20,30,3.4 etc.). Ni changes are necessary as this is already included in LAW.
  • The following local extensions to the TCD segment defined by Siemens:
    • TCD-9: Result Aspect (same result could have various aspect like CONC, INDEX, RLU, INTR, etc.), it should be free text and may be of length 20.
    • TCD-10: Replicate Number (Number of repeat for a test)
    • TCD-11: Dilution Protocol (Similar to dilution factor, but a name defined on instrument for particular factor so for ex. D1 = 20, D2 = 30 etc.)
    • Changes to the HL7 v2.x standard would be required to support these new TCD fields
• Roche has requested the following TCD fields be reviewed for inclusion into LAW:
  • The TCD-5 ("Endogenous Content of Pre-Dilution Diluent"), is relevant in conjunction with the TCD-4 "Pre-Dilution Factor". Some diluent solutions used in the laboratory are not biochemically neutral and introduce the side-effect of a shift in addition to the multiplication/division of the factor. Correct calculations will not be possible without the TCD-5.
    • Simplified example: If you dilute cream with milk, you cannot calculate the resulting fat as multiplication of the cream fat with the dilution factor, because the milk has an endogenous fat content.
    • Recommend that TCD-5 elements in Table W.3.13-6 be updated with the same information as TCD-4.
  • Update The component definition for TCD-2 so that the field can be used to indicate dilution factor can be determined by the Analyzer when sent in LAB-28.
  • Pre-adopt TCD-9 Specimen Consumption Quantity be from HL7 v2.9.
  • Pre-adopt TCD-nn Pool Size from HL7 v2.9.

Highlights:

• Additional elements of the XBN data type for OBR-16 will be supported. A discussion will be added describing when and how the additional elements will be used.
• Clinical Information will be supported with OBX segments and pre-adoption of OBX-29.
• The use of the SGH and SGT data segments will be pre-adopted from v2.8 and used to clarify the PRIOR RESULT segment group.
• The corrected message structure for ORL^O34 will be pre-adopted from v2.8.1, CR 126-748
• Add additional LAW use case for "Analyzer Manager Allows Analyzer to Pool Specimens"
  • The Analyzer Manager must indicate which specimens can be pooled
  • The Analyzer Manager must indicate how many specimens can be pooled
  • This should be established as a profile option
• Define TCD values for pooling
• Add discussion for Analyzer Manager Orders Replicates of a Test
  • Analyzer Manager wants a test to be performed n-times
  • The Analyzer must send a separate AWOS for each replicate
• Define TCD field for Auto-Dilution Type and Specimen Consumption Quantity

Patient Demographics

Status: CP Submitted

Background:

With LAW, we intentionally limited the amount of patient information being exchanged between the two systems. We decided the Analyzer Manager should be considered the “owner” of the patient information, and the Analyzer only needs a subset of information if it performs rule evaluations. Essentially we defined a small amount of information to cover common rule-evaluation needs : date of birth, sex, race.

Beckman Coulter has noted the following:

1. In rev 1.3 of the IHE LAW supplement for LAB-28 there are NTE segments that can be added after the Specimen, Specimen Container, Common Order, Observation Request, and Observation/Result. There is no NTE segment for the Patient. DxH stores and displays patient demographics including comments about the patient. How can the DxH receive the patient comments from the Analyzer Manager?
2. For the LAB-29, NTE segments can only be added after the Observation Result segments. However the DxH can originate patient demographics and orders that may have comments associated with them. How can these be transmitted to the Analyzer Manager? On the DxH vendor specification, I added the NTE segments as needed but I realize now that they do not fit with the current LAW specification.

The comments received from the Analyzer Manager or input at the Analyzer are for informational purposes. They are additional information for the operator. For an Analyzer that can originate orders, it should not be considered the originator of the patient demographic information. Thus, only minimal information to identify the patient (when necessary) should be provided with a result. This minimizes situations where patient data reported by the Analyzer does not match the Analyzer Manager.

Possible options to consider are:

• Add the patient-related NTE segments to LAW. They would be RE (Analyzer Manager) and Optional (Analyzer), so no guarantee the Analyzer Manager would send or process them.
• Define the NTE segments as extensions to the vendor implementation guide. Once again, there is no guarantee that an Analyzer Manager would make use of these because they are not part of the standard.

Highlights:

1. A CP will be created to have NTE added as an optional segment for the patient demographic segment groups.
2. The use of the segments (along with other patient demographic data) should be evaluated as part of the Profile Options to determine if a Patient Demographic option is needed and what data elements would be comprehended.

Profile Options

Status: CP Submitted

Highlights:

Analyzer’s have varying capabilities. Currently LAW supports a bi-directional option. The profile may need to differentiate between some capabilities:

• Reflex
• Query
• Query ALL
• Pooling of Patient Specimens
• Imaging
• LOINC and terminologies?
• Different specialties? For example, a Microbiology option.

When deciding on the options, the impact on manual configuration of the options must be understood.

How should optional data provided for the "enhanced interface" be handled for certification/conformance? Should these be covered by one or more options, and an Analyzer or Analyzer Manager would certify (test) with an option? Could limit the amount of “extra” data that is sent with each AWOS Broadcast by the Analyzer Manager if it does not support that option. However, this could mean numerous options depending on the enhanced data to be used.

Comments:

Query for Isolate

Status: CP Submitted

Background:

It’s not possible to query the Analyzer Manager for a dedicated isolate (a pure colony of a microorganism)used in Microbiology.

An isolate is defined with SAC-3 field and SAC-4 field. The SAC-3 field only is not sufficient to cleary identify it.

In microbiology, you start with a specimen that you need to streak manually or automatically in one or more plates. Each plate will have an unique plate number. After 24 or 48 hours, you have to check what is growing in the plate. This is the reading step. During the reading, you have to identify in the plate what part is interesting to study further.

For each selected part, we need an isolate number. In almost all labs, this is a running number starting from 1. The identifier is in this case is Specimen Number + Isolate Number. It will be difficult to ask them to generate a unique number per isolate.

The next step is to break up the identify part and to put it in a Vitek2 card in order to run the test. We do that in what we call a prep station. This is here that we need to query the analyzer manager in order to know what type of test do we need to do with this identify part of the plate.

This is the reason why in order to query the analyzer manager, we need the Specimen ID + the Isolate Number.

Questions/notes for discussion:

1. So far, LAW has emphasized the use of Container Identification and not Specimen Identification. The expectation is that the Analyzer Manager understands what Specimen is associated with a Specimen Container. Does this hold for Microbiology?
2. Is the Vitek2 card a Container with an ID?
3. It does not seem that the Analyzer is actually querying based on a Container ID or Container Location in this instance. Is a separate set of Query fields or even a new query required?
4. How does the Analyzer determine the Specimen ID and Isolate values? The typical scenario is that the Analyzer has read a container barcode to determine the Container ID. What is the scenario for Microbiology?

Highlights:

• A new CP will be created that covers a query for isolate
• New options and query names will be defined each query type
  • Query by Rack
  • Query by Tray
  • Query by Isolate

Result Aspects

Status: CP Submitted

File:LAW Result Identification.docx

Background:

LAW currently covers the following mechanisms:

1. An observation set supporting multiple Observation IDs for an AWOS (each aspect has a unique Observation ID)
   1. Panel
   2. CBCs
   3. Supplemental Results (raw, graph, image)
2. An observation set supporting multiple observations for the same Observation ID, associated with the AWOS (Result Fragments)
   1. Different types (NM, CE, NA, ST) – the type represents the aspect
   2. Same type, but different result value and the result value differentiates the observation (micro organism detection)
   3. Different runs or progression of tests (OBX-4)

Siemens has requested that LAW define a new TCD field Result Aspect because the same result could have various aspect like CONC, INDEX, RLU, INTR. The Analyzer Manager should be able to distinguish between these result observations. The LAW approach for Result Fragments will not work because the same data type may be used and the different observation type cannot be differentiated.

Highlights:

• Each of these observation types (CONC, INDEX, RLU, INTR) shall be identified by a unique OBX 3 Universal Identifier.
• The use of suffix will be be discussed.
  • Specific value, such as "C","I",etc
  • Rolling numbers, such as 1,2,3,etc
• The discussion of observation fragments will be modified based on these recommendations.
• If LOINC codes are used, these observation types are more than likely covered by unique codes.
• The LAW convention for raw values shall be used.
• OBX-8 should be used to report Interpretations and Abnormal Flags.
• If OBX-8 is not used, then individual OBX segments with a unique OBX-3 Observation ID is required.

Result Progression

Status: CP Submitted

File:LAW 1.3 CP Result Progression.docx

Highlights:

Section C.10.2.3 (in Vol 2x) of the IHE LAB Technical Framework defines the transition of the ORC-5 Order Status and the OBX-11 Observation Result Status. However, the result progression for the Analyzer results is different than the progression of a reportable result for the LTW profile. Similar diagrams for LAW may be needed.

The HL7 O&O working group may have more guidance on the progression of these status values.

Comments:

Analysis completed and initial CP drafted.

Standardized Image For Graphs

Status: In Discussion

File:LAW 1.3 CP Standardized Graphs.docx

Highlights:

• Standardization for images will be provided
  • Recommendation for 800x600 size
    • 5K of data
    • Thumbnail resolution
    • Prints 2.5" by 2" at 300dpi
  • Supported core set of image data types
    • JPG
    • PNG
    • BMP
  • Can be used as standardized way to send graphs and plots
• Limited meta data required for image
  • Title
  • Category
  • Related information
    • Notes
    • Comments
• No standardization for sending graph/plot points will be provided

Testing Strategy

A comprehensive testing strategy for the LAW Profile is needed to:

• Uncover gaps/issues with LAW to prepare the profile for release
  • Use cases/message content
  • Domain Coverage
    • Immuno Assay
    • Clincial Chemistry
    • Hematology
    • Microbiology
    • Molecular
    • Hemostatis
• Help vendors prepare for IHE Connectathons
• Provide a path for certification of vendor interface implementations
  • ICSA (International Computer Security Association) Labs
  • Certification pilot held at 2013 IHE North America Connectathon
• Develop a set of tools/simulators to support long-term testing activities
  • Vendor testing of implementations based on vendor product timelines
    • Basic interface
    • Configurable enhanced interface
    • Multiple result types
    • Error conditions
  • Laboratory virtual testing of new Analyzer and Analyzer Manager products

It is expected that the IHE tools used for Connectathon testing can be extended to support the LAW Testing Strategy.

Testing Capabilities

The following testing capabilities have been identified for the LAW testing strategy.

[1] Cloud-based testing tools

• [a] Connections can be made from system under test to cloud-hosted tools
• [b] Tools available independent of Connectathon schedule

[2] Static Message Validation

• [a] Trigger
• [b] Acknowledgement

[3] Simulators

• [a] Analyzer
• [b] Analyzer Manager

[4] Analyzer Configuration

• [a] MLLP type (simulator only)

1. Persistent
2. Short-lived

• [b] Enhanced message interface

1. Optional segments supported
2. Optional fields supported

• [c] LOINC mappings for tests
• [d] Supplemental results supported

[5] Analyzer Manager Configuration

• [a] MLLP type (simulator only)

1. Persistent
2. Short-lived

[6] Use Case Support

• [a] X.2.1.1 AWOS broadcast by the Analyzer Manager before specimen arrival

1. Initial part 1 - Multiple specimens per AWOS Broadcast
2. Final part c - results in multiple messages
3. Exception handling b.1, b.2 - accept AWOS cancel
4. Exception handling b.3 - unable to accept AWOS cancel

• [b] X.2.1.2 AWOS query by the Analyzer for ALL specimens before specimen arrival
• [c] X.2.2 AWOS Query by the Analyzer at specimen arrival

1. Exception handling a - no AWOS
2. Exception handling c - AWOS already queried

• [d] X.2.3 AWOS created at the Analyzer
• [e] X.2.4.1 Rerun decided on the Analyzer immediately after the first run
• [f] X.2.5.1 Reflex decided on the Analyzer
• [g] X.2.6 Retransmit results from Analyzer
• [h] X.2.8 QC performed on an analyzer
• [i] X.2.9 Pooling of patient specimens

[7] Dynamic Message Exchange

• [a] Basic interface message exchange
• [b] Enhanced interface message exchange

1. RE segments and fields for Analyzer Manager
2. Analyzer configured enhanced interface elements
   1. Patient Identification
   2. Prior Results
   3. Contributing substances

[8] Complex Message Transactions

• [a] Definition of Order dataset for Analyzer testing with Analyzer Manager simulator

1. Basic interface elements
2. Enhanced interface elements

• [b] Definition of Query and Result dataset for Analyzer Manager testing with Analyzer simulator

1. Basic interface elements
2. Enhanced interface elements

• Query-AWOS Broadcast-AWOS Status Update
• AWOS Broadcast-AWOS BroadCast (cancel)
• ...

[9] Message Scenarios

• [a] MLLP Connections

1. Short-lived
2. Persistent

• [b] Asynchronous queries from Analyzer
• [c] Unable to accept AWOS
• [d] Supplemental results

1. Image
2. Plot
3. Raw
4. Other

• [e] Dilutions
• [f] Error handling

1. Malformed message
2. Invalid message header

• [g] Data validation (AWOS ID, Sample ID, Test ID)

1. Analyzer sends AWOS Status Update with inconsistent Sample ID
2. Analyzer sends AWOS Status Update with inconsistent Test ID
3. Analyzer Manager sends Query response with inconsistent query data

• [h] Observation Identification

1. Microbiology result identification using OIDs
2. Hematology CBC parameters
3. Corrected results
4. Observation fragments
5. Preliminary/progression of results
6. Results that are not validated

• [i] Retransmit orders
• [j] Performance (large number of orders, etc.)
• [k] Prior results
  • Analyzer Manager sends prior results
  • Assumption is that most Analyzer Managers will not send prior results
• [l] UCUM

[10] Automatic Monitoring of Peer Testing

• [a] Logging of transmitted messages
• [b] Conformance verification of individual transmitted messages
• [c] Conformance of multi-message transaction

Release Plans

The following milestones for the testing tools have been identified. The testing capabilities were prioritized and assigned to one of the milestones.

AACC Houston 2013

• Week of July 28th, 2013
• Analyzer Participants
  • Abbott
  • Siemens
  • Beckman Coulter
  • ...
• Analyzer Manager Participants
  • Orchard
  • Sunquest
  • Roche
  • ...
• Tool capabilities
  • Based on existing Order Manager and External Validation Service (EVS) components
  • Leverage existing test cases
  • Upgrade to latest LAW supplement version
  • Simulator testing (Analyzer/Analyzer Manager)
  • Peer-to-peer testing
• Deployment
  • Primary: Cloud-based instance
    • No local management
    • Firewall considerations
    • Expected configuration for vendor testing
  • Back-up: Local instance with some cloud-based components
    • Local support required (remote access to virtual machine)
    • No firewall considerations
• IHE Support
  • Virtual machine configuration
  • Support demonstration participants (rehearse testing, etc.)
  • Remote support for local instance
• Support the following capabilities
  • [1]
  • [2]
  • [3]
  • [6a] (no extensions), [6c], [6d], [6e], [6f]
  • [7a]
  • [10a], [10b]

IHE NA 2014 Connectathon

• January 13th, 2014
• Participants - TBD
• Extend to cover additional LAW use cases elements
• Target connectathon and certification testing
• Support the following capabilities
  • [4b], [4c], [4d]
  • [6a] (extensions), [6b], [6g]
  • [7b.1]

Publication of Standard

• Late 2014?
• Extend tools to support advanced vendor testing
• Finalize tool capabilities
• Support the following testing capabilities
  • [4a]
  • [5a]
  • [6h], [6i]
  • [7b.2]
  • [8]
  • [9]
  • [10c]