GMSIH, HL7 France H’, HL7 Germany, IHE-J, JAHIS, SFIL, IHE Italy

Integrating the Healthcare Enterprise

IHE Laboratory Technical Framework
Supplement 2004-2005

10

Laboratory Information
Reconciliation(LIR)

Public Comment Version
June 15, 2005
Comments due July 15, 2005

Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________

20

Foreword
Integrating the Healthcare Enterprise (IHE) is an initiative designed to stimulate the integrationof the information systems that support modern healthcare institutions. Its fundamental objective
is to ensure that in the care of patients all required information for medical decisions is bothcorrect and available to healthcare professionals. The IHE initiative is both a process and aforum for encouraging integration efforts. It defines a technical framework for the
implementation of established messaging standards to achieve specific clinical goals. It includes
a rigorous testing process for the implementation of this framework. And it organizes
educational sessions and exhibits at major meetings of medical professionals to demonstrate thebenefits of this framework and encourage its adoption by industry and users.

30

The approach employed in the IHE initiative is not to define new integration standards, but rather
to support the use of existing standards, HL7, DICOM, IETF, and others, as appropriate in theirrespective domains in an integrated manner, defining configuration choices when necessary.
IHE maintain formal relationships with several standards bodies including HL7, DICOM andrefers recommendations to them when clarifications or extensions to existing standards arenecessary.

40

50

This initiative has numerous sponsors and supporting organizations in different medical specialty
domains and geographical regions. In North America the primary sponsors are the American
College of Cardiology (ACC), the Healthcare Information and Management Systems Society(HIMSS) and the Radiological Society of North America (RSNA). IHE Canada has also been
formed. IHE Europe (IHE-EUR) is supported by a large coalition of organizations including theEuropean Association of Radiology (EAR) and European Congress of Radiologists (ECR), theCoordination Committee of the Radiological and Electromedical Industries (COCIR), Deutsche
Röntgengesellschaft (DRG), the EuroPACS Association, Groupement pour la Modernisation duSystème d'Information Hospitalier (GMSIH), Société Francaise de Radiologie (SFR), Società
Italiana di Radiologia Medica (SIRM), the European Institute for health Records (EuroRec), andthe European Society of Cardiology (ESC). In Japan IHE-J is sponsored by the Ministry of
Economy, Trade, and Industry (METI); the Ministry of Health, Labor, and Welfare; and MEDISDC; cooperating organizations include the Japan Industries Association of Radiological Systems(JIRA), the Japan Association of Healthcare Information Systems Industry (JAHIS), Japan
Radiological Society (JRS), Japan Society of Radiological Technology (JSRT), and the Japan
Association of Medical Informatics (JAMI). Other organizations representing healthcare
professionals are invited to join in the expansion of the IHE process across disciplinary andgeographic boundaries.
The IHE Technical Frameworks for the various domains (IT Infrastructure, Cardiology,
Laboratory, Radiology, etc.) defines specific implementations of established standards to achieve
integration goals that promote appropriate sharing of medical information to support optimal
patient care. It is expanded annually, after a period of public review, and maintained regularly__________________________________________________________________________
1
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________
through the identification and correction of errata. The current version for these Technical
Frameworks may be found at www.rsna.org/IHE or http://www.himss.org/IHE.
60

The IHE Technical Framework identifies a subset of the functional components of the healthcare
enterprise, called IHE Actors, and specifies their interactions in terms of a set of coordinated,
standards-based transactions. It describes this body of transactions in progressively greater
depth. The volume I provides a high-level view of IHE functionality, showing the transactionsorganized into functional units called Integration Profiles that highlight their capacity to address
specific clinical needs. The subsequent volumes provide detailed technical descriptions of each
IHE transaction.
This supplement to the IHE Laboratory Technical Framework V1.2.1 is submitted for
Public Comment between June 15, 2005 and July 15, 2005, per the schedule announced in
February 2005.

70

Comments shall be submitted before July 15, 2005 on the “Public Comment
Lab Supplement” sheet, addressed by email to:
Francois.macary@gwi-medica.fr
takagi-yoshimitsu@naka.hitachi-hitec.com
karima.bourqard@gmsih.fr
eric.poiseau@univ-rennes1.fr
The IHE Laboratory Technical Committee will address these comments and publish the
Trial Implementation version in November 2005.
80

Document production
Principal editor:
Last update:Nicola Ferrari – Omnilab
June 15, 2005

Introduction
Laboratory Information Reconciliation (LIR) is a new integration profile added to Volume I of
the IHE Laboratory Technical Framework in 2005. As LIR implements only transactions alreadycreated and described in the LSWF or the LDA, no new transaction is associated with thisprofile; consequently therefore there is no need to add new descriptions and chapters to Volume
II of the IHE Laboratory Technical Framework.

__________________________________________________________________________
2
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________

Open Issues and Questions
90•

Where a patient is not known to the healthcare system and orders are entered directly by theOrder Placer (OP) then it is logical for the OP to initiate ADT transactions. However, inmany implementations this information is ‘mastered’ by the ADT actor and subordinate
systems are not trusted to initiate ADT patient demographic updates.

•

How can the OF update the patient details through an OML message?? How does the AM
understand that it is a Pt update??

Closed Issues•

100

Case 3: in case of Work Order created by the AM, LAB 5 could not be possible if theTechnical validation is not performed due to patient information absence.
The solution is to send the results to the OF which will perform both technical and clinicalvalidation.

Profile Abstract
The Laboratory Information Reconciliation profile seeks to extend the Laboratory ScheduledWork Flow to permit the management of special cases that are commonly treated every day by
the laboratory staff (such as the trauma cases, the unidentified or misidentified patient analysis
and the unsolicited test results).

110

120

This profile offers the possibility to match the clinical lab observations, produced on specimens
collected from misidentified or unidentified patient, with the correct patient’s record. This could
happen in a typical trauma case when the proper patient details are not available and some
temporary general information is entered into an ADT.
This profile also deals with the urgent lab analyses that cannot be requested of the laboratory
because neither real nor temporary patient information is available in the main actors (ADT, OF,OP).
By means of this profile unsolicited clinical lab observations, produced on specimens, and orders
created afterwards can be matched in the AM or in the Order Filler application and then sharedwith the Order placer and the Order Result Tracker systems.
Finally this integration profile is designed to support the reconciliation of the patient record withlab results that are produced (either without a prior registration or under a generic registration)
before the patient’s identity can be determined. Thus, observations can be produced, validated,
immediately used and then, when the patient’s official registration and order information isentered into the laboratory main actors, the identity information is matched with the previously
obtained result set.

__________________________________________________________________________
3
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________GLOSSARYLDA: Laboratory Device Automation profile
LIR: Laboratory Information Reconciliation profile
LIS: Laboratory Information System
LSWF: Laboratory Scheduled Work Flow profile
ADT: Admit, Discharge, Transfer
130

OP: Order Placer
OF: Order Filler
AM: Automation Manager
ORT: Order Result Tracker
LD: Laboratory Device__________________________________________________________________________
4
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________

Volume I – Integration Profiles<This section describes the changes required in Volume I of the Technical Framework that
result form including this Integration Profile.>

Changes to Sections 1 – 1.X<Include a subsection for each section/ subsection changed>
140

1.6 History of Annual Changes
Add the following bullet to the end of the bullet list in section 1.7•

Added the Laboratory Information Reconciliation Profile which extends the LSWF and the
LDA to what can be considered as the Unscheduled Work Flow. Misidentified orunidentified patients can have their analysis performed and unordered analyses can be
executed in case of urgency.

2.1 Scope
Add the following text somewhere at the end of paragraph:

150

The LIR profile deals with unexpected but typical situations in which the patient is not correctly
registered in the hospital information system or is not present at all so that no order can becreated to require a lab analysis. This profile solves most of the cases that cannot be managed by
the LSWF because they are considered “unscheduled workflow”.

2.3 Integration Profiles overview
Add the following line to the existing table:
Integration Profile
Laboratory Information
Reconciliation

Depends on
Laboratory Scheduled
Workflow

Laboratory Device Automation

Comments
Laboratory Information
Reconciliation is an extension
to this profile requiring thatthe process be completely
supported.
Laboratory Information
Reconciliation relies on all thetransactions of LDA.

__________________________________________________________________________
5
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________

2.4 Actors in Laboratory Technical Framework
NO new actor is needed by the profile but some extra information should be added to someactors160
Add the following lines to the AM
The Automation Manager can match unexpected results produced by an analyzer with theappropriate incoming Work Order, or create a new Work Order to fit the unsolicited observations
and send them to the OF.
Add the following lines to the OF

170

Only in the case of urgent analyses, can this actor create a new patient with a local (labidentified) Id to permit the creation of a Filler Order. This local patient Id must be restricted to
the laboratory domain (transactions possible only with AM) and no transactions regarding thislocal patient will take place with OP and ORT until such time as the patient details are entered in
the ADT system and distributed by that system. At which point the enterprise identified Id ismatched with the local one.
OF checks all the previously created Filler Orders or enters a new one to manage unexpected
Order Results originating from AM.

X Laboratory Information Reconciliation
X.1 Use cases
X.1.1 Unidentified Patient registered at ADTThis use case seeks to give a simple but concrete solution to the very common case of themisidentified or unidentified Patient in a healthcare center. As this use case is a natural extensionof chapter 3.5.3 (see LSWF), the following sub cases will describe only the most critical cases.
180

As the patient information is an important part of an Order, this use case can impact into two
different scenarios which involve either the Placer Order or the Filler Order:-

Clinical lab tests ordered at Order Placer-

Clinical lab tests ordered at Order Filler

X.1.1.1 Clinical lab tests ordered at Order Placer.
Initial part of the scenarioa) The operator (admission staff) registers an unidentified or misidentified patient at ADT.
__________________________________________________________________________
6
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________b) This information is transmitted to Order Placer, Order Filler and Order Result Tracker.
Middle part of the scenario
190c) The operator (ward staff) enters an order at Order Placer.
d) The order is transmitted to Order Filler and then consequently to other recipients, i.e.
Automation Manager and Laboratory Devices if needed.
Final part of the scenarioe) The operator (admission staff) updates patient data at ADT. During this process thepatient may…
… need a correction of name, address or other known but incorrect data
⇒ Update Patient.
…be identified as a formerly known patient⇒ Merge or link source patient Id and target patient ID

200f) This information is submitted to Order Placer, Order Filler and Order Result Tracker.
If specimen examination is not finished or the final results have not been returned yet, theAM shall be sent the new patient details by the Order Filler (LAB-4).
g) The recipients are required to execute the update / merge request or simply integrate theirrecords.
NOTE 1: the LD will be forwarded the patient new details according to the AM internal rules incase a patient is updated or merged by the OF.
X.1.1.2 Clinical lab tests ordered at Order Filler.

210

The initial part and final part of this scenario are the same as in the previous use case. Only the
middle part has a specific development:
Middle part of the scenarioc) The operator (laboratory staff) enters an order at Order Filler.
d) The order is submitted to the Order Placer which returns the placer order number. The
Automation Manager is informed about the order creation.
NOTE 1: same as NOTE 1 in X.1.1.1.

220

X.1.2 Patient not registered at ADT.
This use case considers the situation of a ward staff or user of an order entry system that needs tocreate a laboratory request to have urgent analyses performed, but where the patient is not yet
registered. Neither the patient Id nor details are available and consequently no order can beentered.
X.1.2.1 Clinical lab tests ordered at Order Placer.
__________________________________________________________________________
7
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________

230

The IHE LAB Committee assumes that there is always a patient record created by the ADT if thepatient references (Id, name, date of birth, …) must be used to share information among different
facilities, multiple domains or in separated healthcare units. Consequently, as the OP is not a lab
specific actor but a shared multi-domain actor, no new local patient can be registered by the OP
operator.
This approach avoids the risk of spreading the Id or details of a patient who is unknown to the
ADT among the healthcare enterprise systems.
In order to work around this limitation, the ward staff or the lab staff may have to use the ADT
application to create a patient record and then use it to insert a new lab order.
X.1.2.2 Clinical lab tests ordered at Order Filler.

240

In this use case there is no limitation to create a new local patient record because this local Id isrestricted to the lab actors only.
The enterprise patient registration may arrive from the ADT actor at any point in time, however
this is of no consequence to the workflow because the new patient details will be reconciled withthe lab Id when the results are stored in OF, or during the clinical validation stage.
In this case the patient details and a filler order are reconciled within the laboratory.
Initial part of the scenarioa) Specimen of an unregistered patient must be examined.
b) The patient is registered at Order Filler with a local Id.
Middle part of the scenarioc) The operator (lab staff) enters a Filler Order into OF.
d) A Work Order is sent to the AMe) The AM splits the Work Order into several Work Order Steps and sends them to the
Laboratory Devices, i.e. Analyzers and Pre/Post Processors.

250f) The Analyzer returns the test results.
g) Results are sent back to the OF.
Final part of the scenarioh) After the correct patient details have arrived, the filler order is matched with the rightpatient information by the lab staff or by the expert system (e.g. LIS). This step may beundertaken either before or at the same time as the clinical validation (step i).
i) The clinical validation is performed.
j) The Filler Order is sent to the OP by means of a Filler Order Management Transaction(LAB-2).
k) The Filler Order and its results are submitted to the ORT (LAB-3).

260__________________________________________________________________________
8
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________
Note 1: the LAB-2 (step j) and LAB-3 (step k) transaction could take place before the clinicalvalidation but never before the patient and the order is matched. A very strict assumption is madein this use case; no transaction towards OP or ORT can be performed unless the patient isregistered by the ADT and the lab Id is correctly matched with the enterprise Id (ADT patient
id).
Note 2: the local Id policy is defined within the laboratory which has sole responsibility for it.
The patient Identity can have various status such as “lab identified” (= local), “enterprise
identified” (= valid) or whatever the lab authority would decide.
270

Note 3: where the lab identified patient is matched with an enterprise identified patient (manuallyor automatically) then it will be a laboratory governed decision whether to transmit prior results
or orders for the matched patient.
Note 4: it is strongly recommended that the local and enterprise patient reconciliation be
performed after the final results have been produced. This recommendation excludes the need to
inform the technical actors of lab (i.e. AM, LD) about the new patient identity and avoids a
repeated LAB-4 transaction in case the matching process is not successful.
X.1.3 Clinical lab tests performed on laboratory devices before creation of theorder.

280

Typical case of a very urgent specimen examination. The examination request can arise when thelab systems are not in an active state and so the process should start from the Laboratory Devices
or, if possible, from the AM.
X.1.3.1 Starting point on the analyzer
Initial part of the scenarioa) The specimen is placed on an analyzer, with a specimen Id scanned or entered manuallyb) The tests are selected by the technician
Middle part of the scenarioc) The analyzer processes the results and sends them to the Automation Managerd) AM stores these results flagged with “results not matched with a Work Order”.

290

Final part of the scenario: see chapter X.1.3.3__________________________________________________________________________
9
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________
X.1.3.2 Starting point on the Automation Manager
Initial part of the scenarioa) A Work Order is created manually and flagged as “unsolicited Work Order” at the AM.
b) The specimen is placed on a Laboratory Device, which can query for a WOS (LAB-22)
or wait for a WOS download (LAB-21) by the AM.
300

Middle part of the scenarioc) The analyzer processes the results and sends them to the Automation Managerd) AM stores these results in the manually created Work Order.
Final part of the scenario: see chapter X.1.3.3
NOTE 1: the term “flagged” does not necessarily mean that a specific real flag has to be createdfor such a Work Order but, depending on the system rules, it could simply be the absence of aPlacer Order Number. The final goal is the easy identification of this unsolicited Work Order.
X.1.3.3 Final part of the scenario

310

Once the AM has received the results from the Lab Devices, the final task is to perform atechnical validation and to submit them to the OF for the clinical validation. These final steps canbe performed in two different ways which are based on the usual workflow. The first approachconsiders the AM as a passive actor which cannot initiate a transaction without a prior OF Work
Order. The second approach considers the AM as an active actor that can force the OF toproduce a Filler Order although a Work Order has never arrived.

OPTIONS:
1) AM waits for the incoming Work Order
320e) The OF schedules a Filler Order and produces the suitable Work Orders for AM.
f) AM receives the Work Order and matches it with the flagged stored results or
Work Order.
g) AM sends the Order Results to OF which behaves in the usual way, like in LSWF,
and informs both the OP and the ORT.
NOTE 1: it does not matter the way the Filler Order has been generated (by OP orinternally by OF ); the OF will have a new Work Order to deal with in both cases.

__________________________________________________________________________
10
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________
2) AM submits the results with no reference to a Work Order produced by OF
330e) AM performs the technical validation depending on the initial part of the scenario:- The unsolicited Work Order is technically validated as usual.
- A new Work Order is created to fit the stored results (flagged “results notmatched with a Work Order”). This Work Order is validated and also flagged as“unsolicited Work Order”.
f) AM sends the Order Results to OF which generates a Filler Order to permit theconsequent results distributed among the actors. From this point, the procedure
follows that described by the LSWF profile.
NOTE 1: As a consequence of this approach, the OUL Message from AM to OF will
not carry the OBR-2 and ORC-2 fields.

340
NOTE 2: good practice for the OF would be the preliminary check of the alreadyexisting Filler Orders to discover if one of them can match the incoming results. This
practice could avoid an unnecessary Filler Order creation.
NOTE 3: if the technical validation is not performed due to the lack of patient
information, the AM will submit the results anyway, so that the technical and clinicalvalidation will be performed by OF. In this case the PID segment of the OUL message
will be absent.

__________________________________________________________________________
11
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________
350

X.2 Transactions / Actors
There is neither new actor nor transaction defined by this integration profile but it derives all theactors from the LSWF and the LDA profiles as displayed in figure X.2-1.

LSWF
RAD-1. Pt registration
RAD-12. Pt Update

ADT
RAD-1. Pt registration
RAD-12. Pt Update

LAB -1.
Placer Order Mgmt
RAD -1. Pt registration
RAD -12. Pt Update

Order Placer

Order Filler
LAB -2.
Filler Order Mgmt
LAB - 5. Test Results Mgmt

LAB -3. Order Results Mgmt

LAB -4. Work Order Mgmt

Order Result Tracker

LDA

Automation Manager

LAB -23. AWOS
Status Change
LAB -26. SWOS
Status Change

LAB -21.
WOS
Download

LAB -22.
Query for
WOS

Laboratory Device

Figure X.2-1. LIR Actors and Transactions Diagram360

In the LDA box the Pre/Post-processor and the Analyzer are collapsed into one unique Actor: theLaboratory Device. Consequently, in case of LAB-21 LAB-22 the collapsed actor can represent
either the Analyzer or the Pre/Post-processor whereas a LAB-23 will certainly deal with an
Analyzer and a LAB-26 with a Pre/Post-processor.
Although in this profile the Laboratory Device is mostly represented by the Analyzer, thisgeneral notation is preferred to take into account the possibility for the OF interacting with a
Pre/Post-processor.
As the support of this profile can be claimed only if the LSWF and the LDA are contemporarily
supported, the optionality on the transactions are the same as described in those profiles.
__________________________________________________________________________
12
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________
Table X.2-1 lists the transactions for each actor involved in the LDA Profile. To claim support ofthis Integration Profile, an implementation of an actor must perform the required transactions(labeled “R”).
370
Table X.2-1. LIR Integration Profile - Actors and Transactions
ActorsADT
Order Placer

Order Result Tracker

Order Filler

Automation Manager

Laboratory Device

Optionality

Section in Vol. 2

RAD-1 : Patient Registration

Transactions

R

Radiology TF sect 4.12

RAD-12 : Patient Update

R

Radiology TF sect 4.12

RAD-1 : Patient Registration

R

Radiology TF sect 4.12

RAD-12 : Patient Update

R

Radiology TF sect 4.12

LAB-1 : Placer Order Management

R

Laboratory TF sect 4

LAB-2 : Fillerer Order Management

R

Laboratory TF sect 5

RAD-1 : Patient Registration

R

Radiology TF sect 4.12

RAD-12 : Patient Update

R

Radiology TF sect 4.12

LAB-3 : Placer Order Management

R

Laboratory TF sect 6

RAD-1 : Patient Registration

R

Radiology TF sect 4.12

RAD-12 : Patient Update

R

Radiology TF sect 4.12

LAB-1 : Placer Order Management

R

Laboratory TF sect 4

LAB-2 : Fillerer Order Management

R

Laboratory TF sect 5

LAB-3 : Placer Order Management

R

Laboratory TF sect 6

LAB-4 : Work Order Management

R*

Laboratory TF sect 7

LAB-5 : Test Results Management

R*

Laboratory TF sect 8

LAB-4 : Work Order Management

R

Laboratory TF sect 7

LAB-5 : Test Results Management

R

Laboratory TF sect 8

LAB-21 : WOS Download

R

Laboratory TF sect X

LAB-22 : WOS QueryR

Laboratory TF sect Y

LAB-23 : AWOS Status Change

R

Laboratory TF sect W

LAB-26 : SWOS Status Change

O

Laboratory TF sect Z

LAB-21 : WOS Download

O

Laboratory TF sect X

LAB-22 : WOS QueryO

Laboratory TF sect Y

LAB-23 : AWOS Status Change

R

Laboratory TF sect W

LAB-26 : SWOS Status Change

R

Laboratory TF sect Z

Note 1: See tables regarding the LSWF and the LDA__________________________________________________________________________
13
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________

X.3 Integration Profile Options
Options that may be selected for this Integration Profile are listed in the table X.3-1 along with
the Actors to which they apply.
Table X.3-1 Evidence Documents - Actors and Options
Actor

Options

Vol & Section

ADT

No options defined--

Order Placer

No options defined--

Order Filler

No options defined--

Order Result Tracker

No options defined--

Automation Manager

Wait for an incoming Work Order fromOF to match the results

Vol. 1 Ch. X.1.3.3
option 1

Active submission of unsolicited results
to the OF

Vol. 1 Ch. X.1.3.3
option 2

Laboratory Device

No options defined

--

380

__________________________________________________________________________
14
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________

X.4 LIR Integration Profile Process Flow
The workflow diagrams shown in this section represent each of the use cases described in section
X.1. This is a high level work flow that tends to explain graphically what was already expressedin the referenced chapters.
X.4.1 Unidentified Patient registered at ADT. Clinical lab tests ordered at Order
Placer.
This process flow is based on use case X.1.1.1.
ADT

Order Placer

Order Filler

Automation
Manager

Order Result
Tracker

Registration
Of John Doe
RAD-1
Patient Registration
Placer Ordercreation
LAB-1
Placer Order
Mgmt

Filler Orderscheduled
LAB-4
Work Order
Mgmt

Patient Reconciliation
John Doe ->Bob Smith

LAB-5
Test Results
Mgmt

LAB-3
Order Results Mgmt
Work Order
Step Sent to
LDs
Work Order
Processed

Results postprocessing

RAD-12
Patient Update /
Merge

390
Figure X.4-1. LIR Profile: process flow for unidentified or misidentified patient

In this sequence diagram the assumption is that the Patient Update/Merge is executed after theAM has finished processing the specimen and the results are already stored with a final status(OBX11 = F or C) by the OF actor.
In case the Patient Update/Merge arrived before AM finished, this diagram would be affected
exactly as described in the next section.
__________________________________________________________________________
15
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________
X.4.2 Unidentified Patient registered at ADT. Clinical lab tests ordered at Order
Filler.
This process flow refers to the use case in chapter X.1.1.2.
400
ADT

Order Placer

Order Filler

Automation
Manager

Order Result
Tracker

Registration
Of John Doe
RAD-1
Patient Registration

LAB-2
Filler Order Mgmt
LAB-1
Placer Order Mgmt
Patient Reconciliation
John Doe Ö
Bob Smith

Filler Ordercreated
Filler Orderscheduled

LAB-4
Work Order
Mgmt

LAB-3
Order Results Mgmt
Work Order
Step Sent toLDs

RAD-12
Patient Update /
Merge
LAB-4
Work Order Updatewith new Pt details

LAB-5
Test Results
Mgmt

Work Order
Processed

Results postprocessing

Figure X.4-2. LIR Profile : process flow for unidentified or misidentified patientThis process flow considers the case of Patient Update / Merge while the AM is still processing a
specimen or the final results are missing in the OF actor.
As the AM actor is not directly connected to the ADT system, it must be informed by the OF
about the new patient identity or details. Conversely, when the Work Order process is complete,
the technical actors of the laboratory are no longer concerned with the patient’s identity, until a
new work order comes down for the same patient, with the correct identity.
410__________________________________________________________________________
16
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________

X.4.3 Patient not registered at ADT. Clinical lab tests ordered at Order Filler.
This process flow is based on the use case in chapter X.1.2.2.

ADT

Order
PlacerOrder
FillerOrder Result
Tracker

Automation
Manager

Analyzer

Local Patientregistered at OF
Filler order
created
LAB-4
WorkOrder Mgmt
Work Order splitted
into WOS

LAB-21
WOS download
WOS completed
LAB-23AWOS status change

LAB-5
Test Result Mgmt

Correct Enterprise
Patient
Registered

technical
validaton

Clinical validaton: local patient
matched with the enterprise pt
LAB-2
Filler Order Mgmt

LAB-3
Order Results Mgmt

Figure X.4-3. LIR Profile : local patient Id reconciled with enterprise Id

The Analyzer could query for a WOS instead of waiting for the WOS download.
420

This sequence diagram considers a manual reconciliation of the local patient with its enterprise
identity. As a human intervention is needed, the most convenient moment to reconcile could be
during the clinical validation step.

__________________________________________________________________________
17
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________

430

X.4.4 Clinical lab tests performed on laboratory devices before creation of theorder. Starting point on the analyzer
The following diagrams are based on the use case in chapter X.1.3.1 but they consider separately
the two possible final parts of the scenario.
X.4.4.1 First final part of the scenario
Use case in chapter X.1.3.1 and 1st option in chapter X.1.3.3.

ADT

Order
PlacerOrder
FillerOrder Result
Tracker

Automation
Manager

Analyzer

Urgent specimen to analyze:
WOS entered manually by the lab techncian
Placer Ordercreation

LAB-23AWOS Status
ChangeLAB-1
Placer Order Mgmt
Filler Orderscheduled
LAB-1
Placer Order Mgmt

LAB-3
Order Results Mgmt
LAB-4
WorkOrder Mgmt

Clinicalvalidaton
LAB-1
Placer Order Mgmt

LAB-5
Test Result Mgmt

Technical validation:Work Order matchedwith the pending results

LAB-3
Order Results Mgmt

Figure X.4-4. LIR Profile: process started on Analyzer and reconciliation at AM

In this case the Filler Order is produced due to an OP request, and the ‘technical validation’ stepis the point at which matching the pending results with the incoming Work Order is undertakenon the AM.
440__________________________________________________________________________
18
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________

X.4.4.2 Second final part of the scenario
Use case in chapter X.1.3.1 and 2nd option in chapter X.1.3.3.

ADT

Order
PlacerOrder
FillerOrder Result
Tracker

Automation
Manager

Analyzer

Urgent specimen to analyze:
WOS entered manually by the lab techncian

LAB-23AWOS Status
Change
LAB-5
Test Result Mgmt

Technical Validation:
Patient information entered.

New Filler Order:
the incoming Work Orders anda new Filler Order are matched.
LAB-2
Filler Order Mgmt

LAB-3
Order Results Mgmt

Figure X.4-5. LIR Profile : process started on Analyzer and reconciliation at OF

450

In this case the OF cannot find an existing Order to match the incoming Test Results and so a
new Filler Order will necessarily be created.

__________________________________________________________________________
19
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________
X.4.5 Clinical lab tests performed on laboratory devices before creation of theorder. Starting point on the Automation Manager
The following diagrams are based on the use case in chapter X.1.3.2 but they consider separately
the two possible final parts of the scenario (see chapter X.1.3.3).
460

X.4.5.1 First final part of the scenario
Use case in chapter X.1.3.2 and 1st option in chapter X.1.3.3.

ADT

Order
PlacerOrder
FillerOrder Result
Tracker

Automation
ManagerLaboratory
DeviceWork Order
Manual Creation
LAB-21
Placer Ordercreation
LAB-2
Filler Order Mgmt

WOS Download
Filler Ordercreation
LAB-23
Filler Orderscheduled

LAB-1
Placer Order Mgmt

AWOS Status
ChangeLAB-3
Order Results Mgmt
LAB-4
WorkOrder Mgmt

Clinicalvalidaton
LAB-1
Placer Order Mgmt

LAB-5
Test Result Mgmt

Technical validation:Work Order matchedwith the pending results

LAB-3
Order Results Mgmt

Figure X.4-6. LIR Profile : process started on AM and reconciliation at AM

As the Work Order exists in the AM, the laboratory device can perform a Query for WOS (LAB22) if it does not know what action to perform on the loaded specimen.
In this case the Filler Order is produced by the OF (see X.1.3.3 option 1 Note 1). This process
does not change the initial part of the scenario defined at chapter X.1.3.2 but just gives further
options for creating the Filler Order.
470__________________________________________________________________________
20
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Technical Framework Supplement - Profile Draft______________________________________________________________________________
X.4.5.2 Second final part of the scenario
Use case in chapter X.1.3.2 and 2nd option in chapter X.1.3.3.

ADT

Order
PlacerOrder
FillerOrder Result
Tracker

Automation
ManagerLaboratory
DeviceWork Order
Manual Creation
LAB-22
Query for WOS

LAB-23
Technical
Validation

AWOS Status
Change

LAB-5
Test Result Mgmt
Matching Filler Order found in OF:
the AM Work Orders andthe identified Filler Order are matched.
LAB-2
Filler Order Mgmt

LAB-3
Order Results Mgmt

Figure X.4-7. LIR Profile: process started on AM and reconciliation at OF

As a consequence of the Work Order manual creation in AM, the specimen can be placed on alaboratory device that can query the AM for the suitable operation sequence to perfom on it.
Once the results are sent, the OF can find an existing Order to match the results and so no newFiller Order is created (see X.1.3.3 option 2 Note 2).
480__________________________________________________________________________
21
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy