Established Profile for connectathon 2005: L aboratory S cheduled W ork F low

February 7-10, 2005 IHE Interoperability Workshop1

Established Profile for connectathon 2005:

Laboratory Scheduled WorkFlow

Francois Macary GWI Medica France (Agfa Healthcare IT)cochair IHE Laboratory Committee

The other cochair is Yoshimitsu Takagi (Hitachi)

Integrating the Healthcare EnterpriseIntegrating the Healthcare Enterprise


Laboratory Technical Framework Volume 1


Scope of LSWF profileScope of LSWF profile

Integrate the clinical laboratory in the healthcare

enterprise

Workflow: Ordering, placing, scheduling, performing

clinical laboratory tests, and delivering the results.

In vitro testing: All specialties working on specimen, not

on the patient itself.

Bound to clinical biology (anatomo-pathology excluded)


LSWF: Three major use casesLSWF: Three major use cases

Externally placed order with identified specimens The ordering provider collects the specimens and uniquely identifies them

(in the message placing the order as well as on the container with a barcode label)

Externally placed order with specimens unidentified or to be collected by the laboratory The specimens are unidentified within the message placing the order

Filler order with specimens identified by the laboratory The order is created in the laboratory, and afterwards a number is

assigned to it in the placer application.


Laboratory Scheduled WorkflowLaboratory Scheduled WorkflowActorsActors

ADT - Manages patient related information (demography, location, visit). Provides other actors with up to date information.

Order Placer - Registers orders for clinical laboratories, places an order to the selected Order Filler. Keeps the order status up to date along the process.

Order Filler - Receives orders, schedules them and splits them into Work Orders addressed to one or more Automation Managers. Performs the clinical validation. Sends the results to one or more Order Result Trackers.

Automation Manager - Receives Work Orders from Order Filler, processes ordered tests, stores the results, performs the technical validation, and sends results back to the Order Filler.

Order Result Tracker - Centralizes the results from one or more Order Fillers.


LSWF: Actors and TransactionsLSWF: Actors and Transactions

Order FillerOrder Placer

Order Result Tracker

ADT

Lab-1: Placer orderLab-2: Filler order

Rad1, Rad-12: Patient Demographics

Lab-5: Results

Rad-1, Rad-12

Lab-3: Results

Lab-4: Work order

Clinical Laboratory

Automation Manager Technical

validation

Clinicalvalidation


Actors Transactions Optionality

ADT Patient demographics [RAD-1, RAD-12] R

Order Placer Patient demographics [RAD-1, RAD-12] R

Placer Order management [LAB-1] R

Filler Order Management [LAB-2] R

Order Filler Patient demographics [RAD-1, RAD-12] R

Placer Order management [LAB-1] R

Filler Order Management [LAB-2] R

Order result management [LAB-3] R

Work Order management [LAB-4] R*

Test results management [LAB-5] R*

Automation Manager

Work order management [LAB-4] R

Test result management [LAB-5] R

Order Result Tracker

Patient demographics [RAD-1, RAD-12] R

Order result management [LAB-3] R

* In case the LIS encompasses both Order Filler and Automation Manager transactions LAB-4 and LAB-5 are irrelevant.


Order management in LSWF profileOrder management in LSWF profile

Two parallel flows to keep synchronized

Electronic: The order Material: The specimen(s) required to perform the order

A dynamic process

Specimen added by the placer to a running time study Specimen rejected by the filler (damaged or spoiled), tests held in

wait for a new specimen Unordered test added by the filler (e.g. antibiogram in

microbiology)

Order Placer and Order Filler must keep the same vision of the order (content and status) all along the process


Results management in LSWF profileResults management in LSWF profile

Results can be transmitted at various steps

After technical validation (by the lab technician) After clinical validation (by the clinical expert)

Requirement to keep Order Result Tracker informed with all changes occurred to results previously sent

Send corrections Send validation or un-validation Send cancellation

Other characteristics

Result type: Numeric, coded, textual, graphical (electrophoresis) Results are sent in recapitulative mode, appropriately sorted

See Change Proposal 24


Laboratory Technical Framework Volume 2


Choice of the standardChoice of the standard

Need for an international standard, fully implementable with guides and tools ready for use

Excluded HL7 v3

Supporting specimen and container management

Excluded v2.3.1 and v2.4

Choice of HL7 v2.5, released a while before IHE Lab TF (end 2003)

HL7 v2.5 Transactions LAB-1, LAB-2, LAB-3, LAB-4, LAB-5

HL7 v2.3.1 Transactions RAD-1, RAD-12

Vertical bar encoding shall be supported. XML encoding may be supported

See Vol 2 section 1.1


HL7 v2.5 profiling conventionsHL7 v2.5 profiling conventions

Static definition: Usage of segments and fields R: Required RE: Required but may be empty O: Optional = Usage not defined yet C: Conditional (condition predicate in the textual description) X: Not supported. Must not be sent.

For a better readability: Segments with usage X do not appear in message tables Fields with usage O do not appear in segment tables

Cardinalities of segments, segment groups and fields: Min and max between square brackets: [0..*] * stands for “no upper limit”



Example of message static definitionExample of message static definition

Specimen Segment group


Example of segment descriptionExample of segment description


Condition predicates for « usage C » fields Condition predicates for « usage C » fields

This field contains a unique identifier for the specimen, enterprise-wide.

Condition predicate: This field shall be populated in OML messages of transaction LAB-1, in the context of the use case "Externally placed order with identified specimens" defined in volume 1. This field is required in OML messages of LAB-2 transaction. It may also be used in transaction LAB-3. This field is required if known (RE) in transactions LAB-4 and LAB-5. Please refer to section 2.3.5.1 for the details of the data type.

SPM-2 Specimen ID (EIP), conditional.



Common segments descriptionsCommon segments descriptions

MSH – Message Header

MSA – Message Acknowledgement

ERR – Error

NTE – Notes and Comments

PID – Patient Identification

PV1 – Patient Visit

ORC – Common Order

TQ1 – Timing Quantity Only one TQ1 per order One single execution per order

SPM – Specimen

SAC – Container Detail

OBX- Observation/Result

See Vol 2 section 3


HL7 conventions on empty fields HL7 conventions on empty fields See Vol 2 section 3.9

PID|1||6543210 If the value of a field is not present, the receiver shall not change corresponding data in its database.

OBX|1|NM|14996-3^^LN||””|umol/l

If the sender defines the field value to be the explicit NULL value (i.e. two double quotes ""), it shall cause removal of any values for that field in the receiver's database. This convention is fully applied by the Laboratory Technical Framework.Of course this is forbidden with fields marked with usage R


VocabularyVocabulary

a CBC (complete blood count) an electrolye (Na, K, Cl) a creatinine clearance

Order Placer allocates an Identifier to each ordered battery

Order Filler allocates an Identifier to each accepted battery

The physician places a lab request. The Order Placer allocates the unique Id “123” to this request consisting of:

Laboratory request 123

Placer Order Number

(ordered battery)

12345

12346

12347

ordered battery 12347

Filler Order Number

(accepted battery)

F101

F102

F103

accepted battery F103


Watch the 4 examples of section 9Watch the 4 examples of section 9

Each example is using the same layout:

Storyboard

List of human actors and organizations

Ids and numbers

List of interactions

Interaction diagram

Messages with key information highlighted.

For implementers: One of the most helpful parts of Laboratory Technical Framework.


1st example: Two hematology batteries1st example: Two hematology batteries


Two hematology batteries: One messageTwo hematology batteries: One message


Acknowledgements with MLLP (1)Acknowledgements with MLLP (1)

An OML message shall be acknowledged by one single ORL message.

An OUL message shall be acknowledged by one single ACK message.

These acknowledgements are application-level acknowledgements (i.e. not transport acknowledgements) and must be generated by the receiving application after it has processed the message semantic content, according to its own business rules.

Intermediate message brokers do not have this capacity and therefore shall not be used to generate the contents of application acknowledgements.

The receiving application shall automatically generate the application-level acknowledgement messages without waiting for human approval of the contents of the message that was received



Acknowledgements with MLLP (2)Acknowledgements with MLLP (2)

A MLLP (Minimal Lower Layer Protocol) network connection is unidirectional. Event-triggered messages flow in one direction and related acknowledgement messages flow in the other direction.

The acknowledgement message to an event-triggered message shall be sent immediately to the sender on the same MLLP connection that carried the event-triggered message.

Results validated

Order Filler Application

MLLP Accepting

module

MLLP Initiating module

Order Result Tracker Application

<SB> acknowledgement <EB><CR>

ACKACK

<SB> message <EB><CR>

Message OUL Message OUL


Accepting module

Initiating module

Accepting module

Initiating module

Order Placer application

Acknowledgements with MLLP (3)Acknowledgements with MLLP (3)Transactions with trigger events on both sides (e.g. LAB-1)Transactions with trigger events on both sides (e.g. LAB-1)

New placer order

OML^NW OML^NW

OML^NW

ORLÔK

ORLÔK

ORLÔK

ORLÔK

ORLÔK

ORLÔK

Order Filler application

Order Status change

OML^SC

OML^SC

OML^SC


Approved change proposals for connectathon 2005 Approved change proposals for connectathon 2005

CP #

Content

17 Acknowledgements in LAB-1 and LAB-2 deliver an order number. These applicative acknowledgments have to be generated by the receiving application immediately, not by message brokers (which can still be used for transport)

18 Incorrect message type in LAB-3 messages of the “Glucose tolerance study” example: Message structure OUL^R22 is to be replaced with OUL^R24

19 Typo in “Glucose tolerance study” example: “Gucose” “Glucose”

20 Inversion of segment order in some of the example messages (9.3, 9.4, 9.5.3.3). In OUL messages, OBR must precede ORC, because OBR is the required segment. Underlying reason given in HL7 chapter 2: 2.8.1 c): « c) The first segment in a newly-defined segment group, as of v 2.5, must be marked as required.”

21 Correct the position of OBX in the LAB-3 example messages of “glucose tolerance study”.


Approved change proposals for connectathon 2005 Approved change proposals for connectathon 2005

CP #

Content

24 Precision on recapitulative mode in Lab-3: the Order Filler shall transmit all available results for the battery (if OUL^R24) or specimen (if OUL^R22) in recapitulative mode whether they have already been transmitted or not.

27 OBR-10 « Collector Identifier » in LAB-3 messages should be RE instead of X

28 Clarifies condition of use of SPM/SAC segment group within OML^O21 in LAB-4

29 Correction of some ISO+ units in the example messages

These Change Proposals will be integrated in version 1.2 FT published on www.ihe-europe for March 1st

Volume 2 version 1.1 FT

CPs 17-21, 24, 27-29

Volume 2 version 1.2 FT


Thank you for your attention…

Established Profile for connectathon 2005: L aboratory S cheduled W ork F low

Documents

Transcript of Established Profile for connectathon 2005: L aboratory S cheduled W ork F low