Laboratory Analytical Workflow

From IHE Wiki
Revision as of 14:23, 21 September 2010 by Jbenech (talk | contribs)
Jump to navigation Jump to search













Enhanced Laboratory Device Automation (ELDA)

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


Use Cases

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.


Use Case 18: AM informs LD about observation validity status (application aknowledge)

Scope: Patient & QC

Purpose: This use case allows to acknowledge the valididy of the results for the AM system (application acknowledge). This message allows LDs to apply a different level of presentation to the observations that has been confirmed as valid by AM.

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

IHE LDA: Not in LDA today.


Messaging Topics

Selection of baseline HL7 version (2.6 or 2.7)

  • It has influence on data types (CE vs. CWE/CNE, e.g., MSH-19).
  • It has influence on message structure, e.g. use of UAC segment.

“Enhanced acknowledgment” in addition to the “Original Acknowledgment”

  • It determines, e.g., cardinality (mandatory) use of MSH-15, MSH-16, ...
  • 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 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.

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 express nesting  change in HL7 required
  2. “Abnormal flags” (OBX-8) make repeatable as in HL7
  3. “Specimen Description” (SPM-14) make repeatable as in HL7