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

Integrating the Healthcare Enterprise

IHE Laboratory Technical Framework
Supplement 2004-2005

10

Laboratory Point Of Care Testing(LPOCT)

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 for Public Comment (June 15 to July 15)______________________________________________________________________________

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 for Public Comment (June 15 to July 15)______________________________________________________________________________
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.gmsih.fr/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:

François Macary – GWI (Agfa Healthcare IT)
June 15, 2005

Introduction
Laboratory Point Of Care Testing (LPOCT) is a new integration profile that will be added toVolume I of the IHE Laboratory Technical Framework. Associated with this profile come three
new transactions that will be added to Volume II of the IHE Laboratory Technical Framework.
Abbreviations used in this document:•

CLSI: Clinical and Laboratory Standards Institute•

DML: Device Message Layer from standard POCT1-A__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
90•

LIS: Laboratory Information System. This system usually implements the actor
Order Filler in the IHE Laboratory Technical Framework.

•

LPOCT: Laboratory Point Of Care Testing Integration Profile•

Order Filler: Actor of the IHE Laboratory Technical Framework, called theObservation Recipient in the POCT1-A standard.

•

ORI: Observation Reporting Interface between the Observation Reviewer and theObservation Recipient in the POCT1-A standard.

•

POCDM: Point Of Care Data Manager: actor of this LPOCT profile, named theObservation Reviewer in the POCT1-A standard.

•

POCRG: Point Of Care Result Generator: actor of this LPOCT profile, named theDevice in the POCT1-A standard.

•

POCT: Point Of Care Testing•

POCT1-A: Point Of Care Connectivity approved standard published by CLSI•QC: Quality Control. More generally: Non-patient results.

100

Open Issues
This LPOCT profile of IHE Laboratory Domain, uses the standard POCT1-A from CLSI. This
IHE LPOCT profile shows some usage variations with the original standard POCT1-A. Thesevariations are highlighted in yellow in this document, and will have to be resolved during the
public comment period. Comments from CLSI are particularly expected to help in thisresolution.
110

Closed Issues
Minimal organizational requirements
The LPOCT profile assumes that the two actors Point Of Care Data Manager and Order Filler areprovided with up-to-date patient demographics and visit data. The Order Filler achieves this goalby participating also to the Laboratory Scheduled Workflow (LSWF) described in the Laboratory
Technical Framework. The POCDM may use ADT transactions of LSWF profile or transactions
from other profiles such as Patient Demographics Query (PDQ) or Patient Administration
Management (PAM) both described in the IT Infrastructure Technical Framework.
Results management in LPOCT process

120

Given that the POCT observations are used at once by the care provider or the clinician, theprofile does not handle cancellations or corrections of previous point of care observations. The
second run of a specimen on a point of care device produces a new set of observations. Thissecond run is performed because the observations produced by the first run have been rejected by__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
the POCDM, and therefore have not been transmitted to the Order Filler (LIS). The results
uploaded to the LIS are assumed to have been technically validated (by a human or an automatic
process) on the POCDM.
Minimal information to provide by the POCRG or by the POCDM

130

The following information SHALL be carried in the transactions, when available:- POCRG ID- Patient ID- Ward staff ID- Ordering provider ID- Date time of specimen collection- Reagent lot number- Date time of observation- Observations: Test, result (numeric, coded or textual), unit, abnormal flags, related
alarms and comments
Matching a POCT set of observations with a previoulsy existing placer order

140

When the Order Filler receives a point of care observation set from the POCDM, with theindication “match an existing order”, the Order Filler will search in its data base for an existingorder for the same patient, same specimen type, same tests, ordered at the same date andapproximately the same time as the observation set, and waiting for results. If it does not find any
it will generate a new order.

Profile Abstract
In some situations clinical laboratory testing can be performed straightforwardly on the point ofcare instrument or the patient’s bedside by the ward staff, or even by the patient themself, forinstance in home care. This organization allows the ward staff to obtain immediate access toobservations for some common tests, whose specimen does not need pre-analytic preparation.
The results are used immediately in clinical decisions by the care givers.
150

In some areas such as North America and Europe, this point of care testing process is supervised
by a clinical laboratory of the healthcare enterprise. The point of care analyzers of several wards
are connected permanently or periodically to a central Point Of Care Data Manager. This central
system collects point of care tests and results, related to patient specimens and QC specimens.
The POCDM controls the point of care testing process and registers all the results. In addition it
forwards the patient results to the LIS of the clinical laboratory supervising the point of caretesting process.

__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
Except for their quick availability and use, point of care observations are stored just likelaboratory observations within the LIS.
160

LPOCT Integration Profile is designed to support this point of care testing process. This profile
assumes that the LIS and the POCDM are both provided with up-to-date patient data.

__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________

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

GLOSSARY
These definition shall be added to the Glossary chapter of volume 1:
CLSI: Clinical and Laboratory Standards Institute organization
DML: Device Message Layer defined by the standard POCT1-A
HL7: Health Level Seven consortium
LCSD: Laboratory Code Set Distribution profile
170

LDA: Laboratory Device Automation profile
LIR: Laboratory Information Reconciliation profile
LIS: Laboratory Information System
LPOCT: Laboratory Point Of Care Testing profile
LSWF: Laboratory Scheduled Work Flow profile
MLLP: HL7 Minimal Lower Layer Protocol (see IHE Laboratory Technical Framework)
ORI: Observation Reporting Interface defined by the standard POCT1-A
PAM: Patient Administration Management Integration Profile in IT Infrastructure Technical
Framework
PDQ: Patient Demographics Query Integration Profile in IT Infrastructure Technical Framework

180

POCDM: Point Of Care Data Manager actor
POCRG: Point Of Care Results Generator actor
POCT: Point of care testing
QC:

Quality Control
Internal Quality Control: Tests performed on an identified control specimen, withusually known target values.
External Quality Control: Tests performed on an identified control specimen whosetarget values are hidden, in order to control the proficiency of the organization. External
QC specimens are provided by an external institution that controls and compares theresults obtained by multiple healthcare enterprises. This is also called proficiency testing.

190__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________

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

1.4 Relationship to Real-world architectures
Add the following paragraph to the end of this section
Core difference between LPOCT and LDA
When the clinical testing workflow is initiated by the analytic testing producing a set ofobservations, and when there is neither significant pre-analytic nor post-analytic process,then the analytic part of this workflow will be treated within the Laboratory Point Of
Care Testing profile.
200

In all other cases the analytic workflow is covered by Laboratory Device Automation
profile. This LDA profile supports the clinical testing workflow when it is initiated by anorder, irrespective of whether this order is created at the Order Placer level or at theOrder Filler level, and wherever the analyzers are located (on the point of care or in alaboratory).
Renumber section 1.6 to 1.7
Renumber section 1.7 to 1.8
Renumber section 1.8 to 1.9

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

Added the Laboratory Point Of Care Testing Profile which integrates the workflow related toclinical laboratory tests performed on the point of care or on patient’s bedside.

1.8 Copyright permissions
Add the following copyright statement
The Clinical and Laboratory Standards Institute (CLSI) has granted to IHE the permission to
reproduce tables and figures from the POCT1-A standard. The POCT1-A tables and figures inthis document are copyrighted by CLSI. All rights reserved.
IHE grants permission to CLSI to reproduce either parts of this document or the document in its
entirety.

2.1 Scope220

Remove the last paragraph of this section, and add the following text at the end of it:__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________The exchange of code sets and associated rules shared by multiple actors is beyond the scope of
this integration profile. It is however assumed that the actors use common code sets whenrequired.
The exchange of code sets and associated rules shared by multiple actors is within the scope of
this Technical Framework, and covered by one of its profile: LCSD.
Another profile (LPOCT) of this Technical Framework covers the situation of clinical tests
performed on the point of care or on patient’s bedside by the ward staff or even by the patient
itself (in home care settings).

2.2 Laboratory specialties
230

Remove the text before the table, and replace it with the following text:

Not all laboratory specialties will be covered by the current framework: The 2003-2004 IHE
cycle covers the workflow of disciplines that perform tests on specimens drawn from the patient,and not on the patient itself.
The table below, constructed from a subset of HL7 v2.5 Table 0074 “Diagnostic Service Section
ID”, points out the lab specialties addressed by the 2003 – 2004 cycle of IHE Laboratory
Technical Framework. Other specialties may be added by future IHE cycles.
The Laboratory Technical Framework covers the laboratory specialties that perform tests on “invitro” specimens taken from the patient, rather than tests performed on patients themselves.
240

The table below, constructed from a subset of HL7 v2.5 Table 0074 “Diagnostic Service Section
ID”, points out the laboratory specialties addressed the IHE Laboratory Technical Framework, inthe role of the Order Filler. Other specialties may be added by future IHE cycles.
The excluded specialties in this table may not appear in the role of Order Filler. However someof them can still get involved in this framework in the role of Order Placer. It is the case of bloodbanks that order immuno-haematology tests.

2.3 Integration Profiles overview
Replace the text of this section by the following text, and add the table below:

250

The Laboratory Technical Framework contains the following Integration Profiles:• Laboratory Scheduled Workflow (LSWF): covers the workflow related to tests performed bya clinical laboratory, fulfilling an order for a well-identified patient.
• Laboratory Device Automation (LDA) describes the workflow between the Automation
Manager and a set of laboratory equipment involved in the testing process.
• Laboratory Point Of Care Testing (LPOCT) covers the workflow related to clinicallaboratory tests performed on the point of care or on patient’s bedside, by ward staff.

__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________•

260

Laboratory Information Reconciliation (LIR): covers the workflow related to tests performed
by a clinical laboratory under exceptional situation: patient unidentified or misidentified,order not existing...
• Laboratory Code Set Distribution (LCSD) provides a way for an application owning a code
set in the domain of clinical laboratory (battery, test and observation codes) to send it to otherapplications.
Table 2.3: Integration Profiles Dependencies
Integration Profile
Depends on
Comment
Laboratory Scheduled
none
Workflow
The reconciliation of observations with orders
Laboratory Information Laboratory
Reconciliation
Scheduled Workflow and patients requires transactions defined inboth profiles LSWF and LDA
Laboratory Device
Automation
Laboratory Code Set
none
Distribution
Laboratory Device
Laboratory
Automation
Scheduled Workflow
The system implementing the Order Filler
Laboratory Point Of
Laboratory
Care Testing
Scheduled Workflow actor in LPOCT shall also implement theOrder Filler actor in LSWF profile.
The POCDM actor shall be grouped witheither the Patient Demographics Consumer
actor of PDQ profile or the Patient Encounter
Consumer of the PAM profile. These two
profiles are defined in the IT Infrastructure
Technical Framework.

2.4 Actors in Laboratory Technical Framework
Add the following actors at the end of the list defined in section 2.4
Point Of Care Result Generator (POCRG):
This actor used in LPOCT profile is a system that produces results by automatic measure,manual entry or calculation. It identifies the results with the related patient or QC specimen ID,
the operator who performs the tests, the ordering provider and the care unit. It sends thisinformation to the POCDM. The POCRG is able to send its internal process control information
to the POCDM.

__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
270

Point Of Care Data Manager (POCDM):
This actor used in LPOCT profile is an application managing a set of POCRG and centralizing
their results. The POCDM is ready to react to any conversation from a POCRG. The POCDM
receives point of care observations from POCRG actors. It controls these observations within
their context, stores them and forwards them to the Order Filler.
The POCDM is supporting the technical review (technical validation) of the results.
The application implementing a POCDM actor shall also implement the Patient Demographics
Consumer actor either in PDQ profile or in PAM profile in order to have access to up-to-datepatient demographics and encounter data.

280

The POCDM offers features to control the activity of its set of POCRG. It stores the quality
control results of each POCRG and supervises this QC on all POCRG actors. The POCDM lets
the authorized staff configure its application, and its related set of POCRGs.

Complement the definition of the Order Filler actor with the following text:

290

In LPOCT profile this actor receives the point of care observation sets from the POCDM, andstores them within orders, either matched or generated for the occasion. These POCT orders arealso submitted to clinical validation, and are archived for quality assurance and responsibility
purposes only, since they have already been used by the medical staff in its care decisions. The
clinical validation process triggers the sending of these results to the Order Result Tracker, usingtransaction LAB-3 of profile LSWF. POCT orders are associated to orders on the “placer side”
by means of transactions LAB-1 or LAB-2 of profile LSWF.

__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________

5 Laboratory Point Of Care Testing Integration Profile
5.1 Summary of LPOCT
In some situations clinical laboratory testing can be performed straightforwardly on the point ofcare device or the patient’s bedside by the ward staff, and even by patients themselves, in homecare. These organizations enable the ward staff immediate access to common tests, whose
specimen does not need any pre-analytic preparation. The results are used immediately in clinicaldecisions.
The point of care analyzers located in the wards send their observations to a central Point Of
Care Data Manager, using a connection that can be persistent or intermittent.
300

This profile mainly addresses organizations, where point of care testing is placed under theoverall supervision of a clinical laboratory of the healthcare enterprise. This supervision includes
clinical validation of POCT results, internal and external Quality Control (QC) surveillance,reagent delivery, and education on good testing practices delivered to the ward staff. In theseorganizations (laboratory led), the laboratory clinical expert surveys the QC results on the
POCDM application.
This profile can also support organizations that leave point of care testing under the
responsibility of the ward medical staff using the point of care analyzers, and do not involve anylaboratory in this process. These organizations will be referred as non-laboratory led
organizations. (A subset of this profile will likely apply to these organizations.)

310

To fulfill the laboratory led need, the POCDM must be able to forward point of care patientresults to the Order Filler application of the clinical laboratory supervising the POCT process.
The workflows covered by this LPOCT profile depend upon the kind of organization chosen, andupon the type of connection (persistent or intermittent) used by point of care devices.
LPOCT profile uses the Order Filler actor defined in LSWF profile, and introduces two newactors: Point Of Care Result Generator (POCRG), Point of Care Data Manager (POCDM).

5.2 Examples of POCRG•

Portable analyzers enable the testing of usual parameters such as blood gas or electrolyte,
from two drops of capillary blood drawn from the finger tip of a baby in a neo-natology unit.

•

Analyzers installed in the surgery theatre measuring the blood gas every ten minutes during apatient operation.

•

Analyzers installed at patient’s bedside in intensive care unit.

•

Glucose meter operated by the patient in the context of home nursing.

•A work station at which the nurse manually enters a pregnancy test, HIV stick test (noninstrumented test)…

320__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________

5.3 Benefits of LPOCT
Point of care testing enables the medical staff to obtain observations quickly, thus improving
efficiency. LPOCT is especially useful in emergency wards and intensive care wards.

330

The tests are performed immediately on a specimen barely collected from the patient. There is no
pre-analytic operation needed (preparation of the specimen, transport, identification). In case of
tests performed on a blood specimen, the required quantity of blood is usually lower than inlaboratory testing. Minimizing the amount of blood taken from the patient is another advantage
of LPOCT, which explains its common use within neo-natology and pediatric wards.
Point of care testing may also be worthwhile in home care: Tests performed by patientsthemselves, with the results sent to the central POCDM of the healthcare enterprise.

5.4 Scope of Laboratory Point Of Care Testing Integration Profile

340•

Point of care testing within a healthcare enterprise, or in home care under the control of ahealthcare enterprise.

•

All specialties of clinical laboratory that can be performed on the point of care.

•

Testing on in vitro specimen, not on patients themselves.

•

Tests of short time execution that do not need any significant pre-analytic process.

•Tests performed by the ward staff on the patient bedside or the point of care, or tests
performed by patients themselves in home nursing. In both cases the healthcare enterprisecollects and records on a central system all POCT observations.

•Observations produced by a point of care analyzer, or manually entered on a system, or
calculated by a system.

•

Point of care devices with persistent or intermittent link to the central point of care data
manager.

•

Overall supervision of the point of care testing process: This supervision may include QC
surveillance, reagent management, operator certification, and centralization of results on the
point of care data manager.

•

This profile enables to place this supervision under the responsibility of a clinical laboratory,
including uploading to the LIS all patient results.

•

Currently, the remote control of the point of care testing devices by the central point of caredata manager (remote commands) is left out of the scope of this profile.

•

The identification process of the operators is currently not in the scope of this profile.

•

The uploading of QC results from the POCDM to the LIS is currently out of scope.

350__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________•

360

When a POCT set of observations reaches the Order Filler, these results have already beenused by the care provider at the point of care, and these results are assumed to be technicallyvalidated by the POCDM. Due to these two characteristics, LPOCT profile does not handle
corrections or cancellations of observations.

5.5 Use cases
The 5 following use cases cover the various organizations and situations mentioned in thesummary of this profile.
5.5.1 Observations to match with an existing order, patient identity checking
This use case involves a real-time patient identity checking. It requires a persistent link between
the point of care testing device (POCRG) and the point of care data manager (POCDM).

370

The scenario covers the situation in which the order for point of care testing is created on theOrder Placer application prior to the testing. The order number, though, is not entered on the
POCRG, and is transmitted neither to the POCDM nor to the Order Filler. The Order Filler has tomatch an existing order in its data base.
Note 1:The use case in which the order number would be entered on the point of care device and transmitted to the
POCDM and then to the Order Filler, is considered by the IHE Laboratory Technical Framework as a normal use
case of scheduled clinical laboratory testing, supported by the Integration Profiles Laboratory Scheduled
Workflow and Laboratory Device Automation. The point of care device in this use case is considered as ananalyzer of the clinical laboratory, even if it is remote. See Volume 1 section 1.4 “Relationship to real worldarchitectures”.

Part 1 of the scenario

380

The physician orders point of care tests for a patient. This order is entered on the Order Placer
application and is assigned a placer order number. As part of the LSWF profile, the Order Placer
sends this new point of care order to the Order Filler, which assigns a filler order number to it,
and waits for point of care observations.
Part 2 of the scenario
To fulfill this order, the operator (physician, nurse, patient) sets a patient specimen on the pointof care device implementing the POCRG actor. The operator initiates the operation, providing its
own identification, a patient/visit identifier and all information relevant for testing. In addition
the operator enters the indication that an order already exists for the tests to perform.
Part 3 of the scenario

390

The POCRG notifies this information to the POCDM (on the persistent link between the two) tocheck all the information provided, and to get the patient name. This patient name sent back to
the point of care device is displayed so that the operator can check that he has entered the correct
patient/visit identifier. If the patient is unknown to the POCDM or in other error cases, theoperator will follow the enterprise policies. For instance the operator could key in the patient__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
identity on the device so that this information be transmitted with the results in part 4 of the
scenario.
Part 4 of the scenario
The point of care device performs the tests on the specimen, produces the results and displaysthem to the user.
The POCRG sends the observation set with its related data to the POCDM, including theindication “existing order to be matched”.
400

The POCDM checks the received observations against its own rules (result compared withnormal ranges or scale limits, QC results obtained and correct …), accepts them, stores them, andacknowledges them to the POCRG (results accepted). The POCRG displays the acknowledgment
received from the POCDM. In case the POCDM detected an erroneous or suspicious result, it
rejects the results, and sends back a negative acknowledgement to the POCRG.
If the results are accepted they are immediately available to inform the clinical and medical careof the patient.
Part 5 of the scenario: – order matched
Having accepted the observation set, the POCDM forwards it to the Order Filler, accompaniedby the indication “existing order to be matched”.

410

The Order Filler searches for the existing order in its own data base, by matching a point of caretesting order for the same patient, containing the same tests, and placed by the same ordering
provider, at approximately the same time. It stores the received observation set into this order. If
the Order Filler can’t match any existing order in its data base, it generates a new order as in use
case 5.5.2.
The Order Filler acknowledges the observation set to the POCDM, sending in theacknowledgment message its filler order number.
As part of the LSWF profile, the Order Filler notifies the Order Placer that the results for the
POCT order have arrived (status change of the order).
Part 6 of the scenario: Clinical validation

420

Later on, the clinical validation of the results is performed. In the LSWF profile, this triggers thesending of these results to the Order Result Tracker, and the notification “order completed” sent
to the Order Placer.

__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________

5.5.2 Unordered observations with patient identity checking
This use case involves a real-time patient identity checking. It requires a persistent link between
the point of care testing device (POCRG) and the point of care data manager (POCDM). The
tests are performed before the order is created. The order will be created automatically by the
LIS on reception of the POCT observations.
Part 1 of the scenario
430

The operator (physician, nurse,) sets a patient specimen on the point of care device implementing
a POCRG actor. The operator initiates the operation, providing its own identification, a patient
identifier and all information relevant for testing.
Part 2 of the scenario
Same as Part 3 of use case 5.5.1.
Part 3 of the scenario
The point of care device performs the tests on the specimen, produces the results and displaysthem to the user. The POCRG sends the observation set with its related data to the POCDM.

440

The POCDM checks the received observations against its own rules (result compared withnormal ranges or scale limits, QC results obtained and correct …), accepts them, stores them, andacknowledges them to the POCRG. The POCRG displays the acknowledgment received from the
POCDM. In case the POCDM detected an erroneous or suspicious result, it rejects the results,
and sends back a negative acknowledgement to the POCRG.
If the results are accepted they are immediately available to inform the clinical and medical careof the patient.
Part 4 of the scenario: supervision by a clinical laboratory – order generated
Having accepted the POCT observation set, the POCDM forwards them to the Order Filler of thelaboratory supervising the point of care testing process. The Order Filler stores the received
results into a new filler order generated right away. The Order Filler acknowledges theobservation set to the POCDM, sending in the acknowledgment message its assigned filler ordernumber.

450

Being also involved in LSWF profile, the Order Filler obtains a placer order number from theOrder Placer, using transaction LAB-2. During this transaction, the Order Placer application
creates a placer order for this point of care observation set, and sends back the placer ordernumber assigned.
In the case of an unknown patient, the reconciliation will be the task of the Order Filler
application.
Part 5 of the scenario: Clinical validation
Same as Part 6 of use case 5.5.1.
__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
5.5.3 POCRG with intermitent link – supervivion by lab – generate order
460

This variant of scenario 5.5.2, is met with POCT devices intermittently connected to thehealthcare enterprise’s network. In such a configuration, the tests are performed offline without
real-time patient identity checking.
Part 1 of the scenario
The operator (physician, nurse,) sets a patient specimen on the point of care device implementing
a POCRG actor. The operator initiates the operation, providing local identification, a patient
identifier and all information relevant for testing.
Part 2 of the scenario
The POCRG performs the tests on the specimen, produces the results, qualifies them against its
own rules (such as normal ranges) displays them, and stores them in its memory. The results are
immediately available to inform the clinical and medical care of the patient..

470

Part 3 of the scenario
Later on, when a connection is established with the POCDM, the POCRG sends all the POCT
observations accumulated in its memory.
The POCDM receives the observation sets, checks their information, including patient IDs,
stores them, and acknowledges them to the POCRG.
The POCRG displays the acknowledgment received from the POCDM.
Part 4 and 5 of the scenario
Same as in scenario 5.5.2
5.5.4 Manual entry of point of care patient observations – generate order

480

Some point of care observations are read and entered manually (e.g. urine sticks). This scenario
is met when such POCT observations are entered manually directly on the system implementing
the POCDM actor. In this case the central POCT system supports – grouped with the POCDM
actor – a POCRG actor dedicated to the manual entry of point of care observations.
Part 1 of the scenario
The nurse identifies herself on the POCRG (grouped with POCDM) and enters the patient ID.
The POCRG (grouped with POCDM) checks this patient ID and displays the patient full identity,and visit information, enabling the operator to verify the patient’s identity.
The operator enters the observations on the POCRG. The POCDM controls the observation set
against its configuration rules, rejects them or accepts them, and stores them in the latter case.
Part 2 and 3 of the scenario

490

Same as part 4 and 5 of scenarios 5.5.2 and 5.5.3__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
5.5.5 QC Testing on a POCRG – intermitent or persistent link with POCDMPart 1 of the scenario
The operator initiates the operation by identifying himself (or herself) to the POCRG, entering(or scanning) the QC specimen ID.
The operator enters additional information required, such as specimen type, reagent lot number,
tests to be performed.
Part 2 of the scenario
The POCRG performs the tests on the QC specimen and produces the results.
500

At once if the POCRG has a persistent connection, or when the next connection with POCDM isestablished, the POCRG sends the set of QC observations to the POCDM.
The POCDM receives the set of observations, verifies it against its configuration rules, stores it,
and acknowledges it to the POCRG.
If the QC results fail verification the POCDM and POCRG might hide the results, justdisplaying “QC failed”, and block further process from this device on patient specimens. The
operator performs the corrective action, and starts again the QC test.

5.6 Actors/ Transactions
POCDM
LAB-30:Initiate pointof caretesting on apatient
specimen

LAB-31:
Produced observation set

POCRG
LAB-32:
Accepted observation set

Order Filler
Figure 5.6-1: LPOCT Profile: Actors/Transactions Diagram

510

Figure 5.6-1 shows the actors directly involved in the Laboratory Point Of Care Testing
Integration Profile and the relevant transactions between them.
__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
Note 2:520

As stated in the table 2.3 “Integration Profiles dependencies”, IHE LPOCT profile assumes that the Order Filler isalso involved in LSWF profile. It is also assumed that the POCDM actor is provided with up-to-date patient data,using either Patient Administration profile, or Patient Demographics Query Profile from IT Infrastructure
Technical Framework.

Table 5.6-1 lists the transactions for each actor directly involved in the LPOCT Profile. In orderto claim support of this Integration Profile, an implementation must perform the required
transactions (labeled “R”). Transactions labeled “O” are optional. A complete list of options
defined by this Integration Profile and that implementations may choose to support is listed inVolume I, Section X.2.
Table 5.6-1. LPOCT Integration Profile - Actors and Transactions
Actors

Optionality

Order Filler

Transaction LAB-32

R

Point Of Care Data Manager

Transaction LAB-30

O (see note 3)

Point Of Care Result Generator

Note 3:530

Transactions

Transaction LAB-31

R

Transaction LAB-32

R

Transaction LAB-30

O (see note 3)

Transaction LAB-31

R

Section in
Vol. 2

Transactions LAB-30 is required for POCRG and POCDM supporting the “patient identity checking” option. See
section 5.7

LAB-30: Initiates point of care testing for a patient specimen on a persistently connected
POCRG: A POCRG sends to the POCDM a message containing: its own ID, the care unit ID, theordering provider ID, the operator ID, the patient/visit ID (or QC ID) and other information
related to the test to start. The POCDM identifies the operator, and checks the patient
identification. It then sends the answer back to the POCRG. The answer may be positive andcarry the patient’s identity, or negative and carry the reject reason.
LAB-31: POCT observations produced. The POCRG sends an observation set to the POCDM.
The POCDM checks the content of this observation set, stores it and acknowledges it to the
POCRG.
LAB-32: POCT observations accepted. The POCDM sends an observation set completed withthe patient information, to the Order Filler. The Order Filler acknowledges it. The
acknowledgement carries the filler order number attributed to this observation set.

5.7 LPOCT Integration Profile Options

540

Options that may be selected for this Integration Profile are listed in the table 5.7-1 along with
the Actors to which they apply. Dependencies between options when applicable are specified innotes.
__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
Table 5.7-1 Laboratory Point Of Care Testing - Actors and Options
Actor
Order Filler

Options

Vol & Section

No options defined

Point Of Care Data Manager

Patient identity checking

Vol 2, x.x.x

Point Of Care Result Generator

Patient identity checking

Vol 2, x.x.x

Patient identity checking:This option requires a persistent link between the point of care device implementing the POCRG
actor and the central point of care data manager implementing the POCDM actor. In thissituation, the POCRG and the POCDM use transaction LAB-30 to check the patient’s identity,
before performing the tests, ensuring that the correct patient/visit ID has been entered (orscanned) on the point of care device.

__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________

550

5.8 LPOCT Integration Profile Process Flow
The workflow diagrams shown in this section represent each of the five use cases described in
section 5.5.
Comments on the workflow diagrams of this section:

560•

A transaction in IHE Volume 1 is represented by a single arrow, even if it implies several
messages in both directions. The arrow goes from the actor that sends the initial message tothe actor that receives it. The time length of the transaction is only expressed by the height of
the rectangular box centered on the actor vertical dashed line.

•

The actors involved in LPOCT profile appear in light yellow boxes. The actors involved onlyin LSWF profile appear in white boxes.

•

The chronological parts of each scenario are represented as vertical rectangular orange boxeson the right border of the figure.

•

The actors Order Filler, POCDM, Order Placer, Order Result Tracker are supposed to beprovided with up-to-date patient demographics data. The transactions delivering this patient
data are not shown.

__________________________________________________________________________
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
5.8.1 Real-time patient identity checking – supervivion by lab – pre-existing orderThis workflow diagram represents use case 5.5.1

Order Placer

OrderenteredOrder Filler

POCDM

POCRG

Order Result
Tracker

LAB-1:New POCT
order

Part
1

LAB-30:
Check patient
identity

LAB-1:
Order Resultsreceived

LAB-1:
Order
completed

LAB-32
Accepted
observations set

LAB-31:
Produced
observations
set

Specimento test fora patient

Part
2
Part
3

Test
performed,
observations
produced

Perform
clinicalvalidation of
POCT
observations
LAB-3: Results validated__________________________________________________________________________
21
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

Part
4
Part
5

Part
6

IHE Technical Framework Supplement - Profile for Public Comment (June 15 to July 15)______________________________________________________________________________
570

5.8.2 Unordered observations with patient identity checking
This workflow diagram represents use case 5.5.2

Order Placer

Order Filler

POCDM

POCRG

Order Result
TrackerPart

LAB-30:
Check patient
identity

LAB-2:Createplacer order

LAB-1:
Order
completed

LAB-32
Accepted
observations set

LAB-31:
Produced
observations
set

Specimento test fora patient

1
Part
2

Test
performed,
observations
produced

Perform
clinicalvalidation of
POCT
observations
LAB-3: Results validated__________________________________________________________________________
22
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

Part
3
Part
4

Part
5

IHE Technical Framework Supplement - Profile for Public Comment (June 15 to July 15)______________________________________________________________________________

5.8.3 POCRG with intermitent link – supervivion by lab – order generated
This workflow diagram represents use case 5.5.3

Order Placer

Order Filler

POCDM

POCRG

Order Result
TrackerPart
Specimento test fora patient

1
Part
2

LAB-2:Createplacer order

LAB-1:
Order
completed

LAB-32
Accepted
observations set

LAB-31:
Produced
observations
set

Connection
establishedwith POCDM

Perform
clinicalvalidation of
POCT
observations
LAB-3: Results validated__________________________________________________________________________
23
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

Part
3
Part
4

Part
5

IHE Technical Framework Supplement - Profile for Public Comment (June 15 to July 15)______________________________________________________________________________

5.8.4 Manual entry of point of care patient observations – order generated
580. This workflow diagram represents use case 5.5.4.

Order Placer

POCDM groupedwith POCRG

Order Filler

LAB-2:Createplacer order

Order Result
Tracker

Point of careobservations for apatient manuallyentered, checked
and stored
LAB-32
Accepted
observations set

Part
1

Part
2

LAB-1:
Order
completed

Perform
clinicalvalidation of
POCT
observations
LAB-3: Results validated__________________________________________________________________________
24
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

Part
3

IHE Technical Framework Supplement - Profile for Public Comment (June 15 to July 15)______________________________________________________________________________

5.8.5 QC Testing on a POCRG – intermitent or persistent link with POCDMThis workflow diagram represents use case 5.5.5

POCDM

POCRG

QC
Specimen to
test

LAB-31:
Produced QC
observations set

QC testperformed,
observations
produced__________________________________________________________________________
25
Rev. 0.1 - 2005-06-15 Copyright © 2005: GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

Part
1

Part
2

IHE Technical Framework Supplement - Profile for Public Comment (June 15 to July 15)______________________________________________________________________________

Volume 2 - Transactions
590

IHE Transactions
1.1 Rationale for the choice of the standards to be used
Replace the entire text of this section with the following text:
For the transactions of integration profiles LSWF, LCSD, LIR, the candidate standards were:
HL7 v2.3.1, v2.4, v2.5, v3.
HL7 v3 was not available in 2003 when the first profile LSWF was released. This oriented the
choice towards HL7 v2.5 – the only available version of HL7 supporting both specimen andcontainer.

600

In mid-2005, when the new profiles LCSD and LIR are released, the HL7 v3 Laboratory domain
is not a balloted standard. Hence these profiles LCSD and LIR use also HL7 v2.5, which is still
the most recent available version of HL7.

610

For LPOCT profile there are in 2005 two candidate standards: E1394 from ASTM and POCT1-A
from CLSI. The ASTM standard is more oriented towards connections of clinical analyzers to an
Automation Manager within the clinical laboratory, whilst the CLSI standard is dedicated topoint of care testing, and appears more likely to be implemented in point of care analyzers anddata managers by the major manufacturers in this area. Moreover, the standard POCT1-A from
CLSI, uses HL7 V2.5messages between the Point Of Care Data Manager and the Order Filler.
By choosing this standard, the IHE Laboratory Committee ascertains that a large number ofmanufacturers will be able to implement the LPOCT profile, and offers a homogeneous solutionof interoperability to laboratory information systems implementing the actor Order Filler, fully
based on HL7 v2.5 messages.
For LDA profile there are in 2005 two candidate standards: E1394 from ASTM and HL7 v2.5
with its chapter 13 “Laboratory Automation” that brings some new useful segments. ASTM
E1394 is limited to the connection of analyzers, whilst the LDA profile covers the connection of
all robotic devices. For this reason HL7 v2.5 is the chosen standard for this profile. Anotheradvantage of this choice is to have a homogeneous solution of interoperability for the system
implementing the actor Automation Manager.

620

In 2005, the Laboratory Technical Framework still uses two transactions from the Radiology
Technical Framework: "Patient Registration [RAD-1]" and "Patient Update [RAD-12]". These
two transactions adopted without change, with their messages using HL7 V2.3.1, are notdescribed in this document, and the reader is referred to the "Radiology Technical Framework
Volume 2". However, the transaction "Patient Update [12]" triggers a specific action from theOrder Filler that sends a specific message of transaction LAB-4 to the Automation Manager (Seechapter 7 of this document). These two transactions RAD-1 and RAD-12 will be replaced in__________________________________________________________________________
26
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
2006 by a reference to the new IHE IT Infrastructure profile “Patient Administration
Management” also based on HL7 v2.5
For backward compatibility with HIS implementing the ADT actor, and supporting only the pipe
encoding mechanism, this encoding mechanism is required for the messages described in thisvolume. The XML encoding of these messages is optional and is usable when peer actors support
it.
630

2 CONVENTIONS
Add the following section at the end of this chapter

2.4 Implementation notes for POCT1-A Device Messaging Level (DML)
The transactions LAB-30 and LAB-31 between the actors POCRG and POCDM rely on Device
Messaging Level interface defined in Appendix B of the standard POCT1-A.. In this DML
interface the POCRG actor is called the “Device” and the POCDM actor is called “Observation
Reviewer”.
All messages of DML are encoded in XML (eXtended Markup Language). The syntax of each ofthese messages is defined by a DTD (Document Type Definition).
640

The Device communicates with the Observation Reviewer through an Access Point, which canbe part of a Device persistently connected to the network, or be a subsystem that consolidates
data from one or more Devices onto an established communication link with the Observation
Reviewer (POCDM).
A ccess Point

DeviceLAN

Observation
Reviewer

Cabled or Infrared Link

Figure excerpt from POCT1-A
This IHE LPOCT profile does not describe the protocol between the Device and the Access
Point, and recommends that manufacturers refer to and adopt the standard POCT1-A
specification for this layer.
650

This IHE LPOCT profile describes the use of the DML, which is the top layer of the interface
between the Device (POCRG actor) and the Observation Reviewer (POCDM actor). The lower
layer protocols are not described in this IHE profile. IHE recommends the use of the MLLP
transport protocol between the Device Access Point and the POCDM, as this protocol is used by
all profiles of IHE Laboratory Technical Framework.

__________________________________________________________________________
27
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
2.4.1 IHE usages for DMLThis IHE profile defines a usage for the objects and components of the DML interface. The
conventions of this usage are the same as those defined for HL7 messages (see the IHE
Technical Frameork):
R:

Required. The sender shall populate it.

RE:

Required if available. The sender shall populate this component if it has relevant
information for it.

C:

Conditional. The usage of this component depends upon a condition predicate defined inthis profile.

O:

Optional. The usage of this component is not specified by this IHE profile.

X:

Not supported. This component is not supported by this IHE profile.

660

2.4.2 Conversations and topics
Appendix B of POCT1-A defines two terms:

670

Conversation: A prescribed flow of messages between the Device and Observation Reviewer,
having both an initialization and a termination phase. A Conversation is made up
of a series of ‘Topics.’
Topic:

The flow of messages to exchange a complete set of data within a Conversation(e.g., Observations, Device Events). A Topic is composed of a series of‘Messages.’

This IHE LPOCT Profile describes only the Topic Observations which is used by Transactions
LAB-30 and LAB-31. It is assumed that the systems implementing a POCRG actor or a POCDM
actor support the other Topics listed below, according to the standard POCT1-A.
For a better understanding, an overview of the Topic Hello is also given in this section.

680

This IHE Profile LPOCT does not describe the lower layer protocols (transport, device accesspoint) to be used between POCRG and POCDM actors. It assumes that the implementers follow
the recommendations of the standard POCT1-A for the transport protocol.

__________________________________________________________________________
28
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 for Public Comment (June 15 to July 15)______________________________________________________________________________

2.4.2.1 POCT1-A “basic profile” for transaction LAB-31
To support Transaction LAB-31 of LPOCT Integration profile, a Device (POCRG actor) and an
Observation Reviewer (POCDM actor) must support at least the “Basic Profile”, as defined inAppendix B section 4.1 of POCT1-A.. This “Basic Profile” specifies a minimum set of “Topics”
that Devices and Observation Reviewers must support. These Topics are:

690

•
•
•
•

Hello
Device Status
Observations
Terminate
POCRG
Hello
Topic
Device Status
Topic

POCDM
Hello
Acknowledgement
Device Status
Acknowledgement
Request Observations

Observations
Topic

Terminate
Topic

Observations
Acknowledgement
Observations
Acknowledgement
End of Topic
Terminate
Acknowledgement

Figure 25. Error-Free Basic Profile Flow, POCT1-A – Appendix B

The “Terminate” topic can also be performed in reverse, with the POCRG sending a Terminate
message and the POCDM acknowledging it. This termination can occur at any time. See section
4.1.11 of POCT1-A, Annex B.
__________________________________________________________________________
29
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
2.4.2.2 Continuous Mode to support Transactions LAB-30 and LAB-31
700

To support the “Patient Identity Checking” option of this Profile (i.e. the transaction LAB-30
between POCRG and POCDM) the Device (POCRG) and the Observation Reviewer (POCDM)
must support the “Continuous Mode”, as defined in Appendix B section 4.2 of POCT1-A.. This
Continuous Mode requires that Devices and Observation Reviewers support a more complete setof Topics:• Hello• Device Status• Directives (with at least START_CONTINUOUS Directive)• Observations• Keep Alive• Termination

710
POCRG

POCDM
Basic profile…

Directives
Topic

Observations
Topic

Device Status
Topic
Keep alive
Topic
Keep alive
Topic
Terminate
Topic

Directive (START_CONTINUOUS)
Acknowledgement
Observations
Acknowledgement
Observations
Acknowledgement
Device Events
Acknowledgement
Keep alive
Acknowledgement
Keep alive
Acknowledgement
Terminate
Acknowledgement

Figure 30. Ideal Continuous Mode Message Flow, POCT1-A – Appendix B__________________________________________________________________________
30
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
2.4.3 Characteristics of DML messages
2.4.3.1 Notation
DML messages are encoded in XML. As any XML document, a DML message is a hierarchic
tree. The POCT1-A standard uses the following representation for this hierarchic structure:
ParentParent-child(containment)
relationship+Required : TN
#Required may be empty : TN
-Optional : TN

Child
+Required : TN
#Required may be empty : TN
-Optional : TN

Sibling
relationship

Sibling+Required : TN
#Required may be empty : TN
-Optional : TN

Grandchild (1...*)+Required : TN
#Required may be empty : TN
-Optional : TN

Figure 32. Message Model Example, excerpt from POCT1-A – appendix B
720
Each element is represented as an object. Object cardinality is noted as part of the object name:• (0…1) – zero or one instance• (0…*) – zero or more instances• (1…*) – one or more instances• The absence of a cardinality notation indicates one, and only one, instance.

730

The component of the object are sub-elements of the XML element.
• sub-elements prepended with ‘+’ are Required• sub-elements prepended with a ‘-’ are Optional• sub-elements prepended with ‘#’ are Required if available (may be empty if there is no
relevant data (which corresponds to the HL7/IHE “RE” usage code).

__________________________________________________________________________
31
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
2.4.3.2 Use of the Header object in DML messages
Every message of the DML starts with a mandatory Header object encoded with the XML<HDR> element. This IHE profile defines the following usage for this object:
Attribute

Data
Type

IHE
Usage

IHE
Cardinalities

Description

message_type

CVX[0..0]A code made up of the message name and trigger value. Examples:“OBS.R01”, “ACK.R01”. This field is redundant with the root
element of the message. It is not supported by IHE.

control_id

STR[1..1]

A string guaranteed to uniquely identify this message instancethroughout the conversation

version_id

STR[1..1]

Set to “POCT1” for all messages that adhere to this standard

creation_dttm

TSR[1..1]The sender’s time when the message was sent.

encoding_chars

ST

X[0..0]

Not used by IHE

Example of the beginning of a message of the Hello Topic:<HEL.R01><HDR><HDR.control_id V="10001"/>740<HDR.version_id V="POCT1"/><HDR.creation_dttm V="2001-11-01T16:30:00-08:00"/></HDR>…

2.4.3.3 Hello Topic in DML
The Hello Topic contains two messages: The Hello message sent by the Device (POCRG) andthe acknowledgement message sent by the Observation Reviewer (POCDM).

750

A Device sends the Hello message only once as the first message in a Conversation. Thismessage identifies the Device, its capabilities, its status, and the Access Point with its unique
network address and port number.
•

The root element of this message is <HEL.R01>•

The header element of this message, is mike in any message <HDR>•

The element representing the Device (POCRG) is <DEV>•

The element representing the Device capabilities is <DCP>•

The element representing the Device static capabilities is <DSP>•

The element representing the Access Point is <AP>.
__________________________________________________________________________
32
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 for Public Comment (June 15 to July 15)______________________________________________________________________________OBJECT MODELXML DTD FRAGMENT

Header-message_type : CV+control_id : ST+version_id : ST
+creation_dttm : TS-encoding_chars : ST<!ELEMENT HEL.R01 (HDR, DEV, AP?)><!ELEMENT HDR (HDR.message_type?, HDR.control_id,
HDR.version_id,

HDR.creation_dttm,

HDR.encoding_chars?)>

Device+device_id : ST-vendor_id : ST-manufacturer_name : ON
-hw_version : ST
-sw_version : ST
-device_name : ST
-vmd_name : ST
-vmd_id : ST
Device Capabilities (0...1)+application_timeout : REAL
-vendor_specific : ED<!ELEMENT DEV (DEV.device_id, DEV.vendor_id?,
DEV.manufacturer_name?,
DEV.hw_version?,
DEV.sw_version?, DEV.device_name?, DEV.vmd_name?,
DEV.vmd_id?, DCP?, DSC?)><!ELEMENT DCP (DCP.application_timeout,
DCP.vendor_specific?)><!ELEMENT DSC (DSC.connection_profile_cd,
DSC.topics_supported_cd*,

Device Static Capabilities (0...1)+connection_profile_cd : CS
+topics_supported_cd : SET(CV)+directives_supported_cd : SET(CV)+max_message_sz : INT

DSC.directives_supported_cd*,

DSC.max_message_sz)><!ELEMENT AP (AP.ap_id, AP.port_nbr)>

Access Point (0...1)+ap_id : ST
+port_nbr : INT

Figure 42. Hello Message Model, excerpt from POCT1-A – appendix B

Example of Hello message taken from POCT1-A – appendix B:
760

770

780

<HEL.R01><HDR><HDR.control_id V="10001"/><HDR.version_id V="POCT1"/><HDR.creation_dttm V="2001-11-01T16:30:00-08:00"/></HDR><DEV><DEV.device_id V="0A-00-19-00-00-00-23-84"/><DEV.vendor_id V="BCHMX"/><DEV.model_id V="8000A"/><DEV.serial_id V="42367C"/><DEV.manufacturer_name V="Biochemtronix"/><DEV.hw_version V="8000A-C"/><DEV.sw_version V="2001-10-04"/><DEV.device_name V="ICU-4 Glucose"/><DCP><DCP.application_timeout V="60"/></DCP><DSC><DSC.connection_profile_cd V="SA"/><DSC.topics_supported_cd V="DTV"/><DSC.topics_supported_cd V="OP_LST"/><DSC.directives_supported_cd V="SET_TIME"/><DSC.directives_supported_cd V="LOCK"/><DSC.directives_supported_cd V="UNLOCK"/><DSC.max_message_sz V="800"/></DSC></DEV>__________________________________________________________________________
33
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 for Public Comment (June 15 to July 15)______________________________________________________________________________

790

<AP>
<AP.ap_id V="00-10-9D-FF-FF-23-45-67"/><AP.port_nbr V="0"/></AP></HEL.R01>

2.4.5 Key data types in DML for the IHE LPOCT profile
2.4.5.1 PN – Person name
The PN data type is used to communicate the elements of a person’s name. This data type may
carry:•One single attribute “V” that contains a formatted for display version of the name.

•Any of the child elements described below.
ELEMENT
GIV
MID
FAM
PFX
SFX
DEL

800

USE
The given name component
The middle name component
The family name component
A prefix component (e.g., “Dr.”)A suffix component (e.g., “Ph.D”)
A delimiter character used to separate components

Example: The following XML fragment illustrates how the OPR.name field can be used to
encode the operator “Dr. John Ebert.”<OPR.name V="Dr. John Ebert"><FAM V="Ebert"/><GIV V="John"/><PFX V="Dr."/><SFX V="MD"/></OPR.name>

2.4.5.2 PQ – Physical Quantity
810

The PQ data type is used to communicate a measured value, with the units of measure. The
attributes this data type may use are described in the following table. Either the ‘V’ and the ‘U’attributes or the ‘NULL’ attribute must be specified.

__________________________________________________________________________
34
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
Table 72. PQ Data Type Attributes
FIELD

REQUIRED

USE

V

No

Contains the string representation of the value (1)UNo

Indicates the units of measure for the value (2)

NULL

No

Indicates one of the values from Table 70(1) Trailing zeros may be used in the ‘V’ attribute to indicate precision.
(2) The HL7 “ISO+” units code set, defined in a section of the HL7 v2.5 specification, comprises
the default values for the PQ units attribute. This specification defines an abbreviation for asingle case unit (ISO 2955-83) plus extensions, which do not collide with ISO abbreviations.
820

The following XML fragment illustrates how a device could communicate a pCO2 value of 71.1
mmHg.
<OBS.value V="71.1" U="mmHg"/>

The following XML fragment illustrates the communication of a patient’s height value of 1.85 m<PT.height V="1.85" U="m"/>2.4.5.3 TS – Point in time
This data type is used to communicate a point in time. This data type may use one and only oneof these two alternative attributes:
‘V’:
830

String representation of a point in time:
YYYY-MM-DDTHH:MM:SS.SSxOH:OM
Where:YYYY = four-digit year;
MM = two-digit month of the year;
DD = two-digit day of the month;
HH = 24-hour representation of the hour;
MM = minute;
SS.SS = second (optional decimal digits may follow the ‘.’ separator);x = ‘+’ if time is GMT plus offset; ‘-‘ if time is GMT minus offset;
OH = hours offset from GMT; andOM = minutes offset from GMT.

840
‘NULL’:

One of the values from Table 70:__________________________________________________________________________
35
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
Example: The following XML fragment illustrates how a device could communicate that an
observation was made on June 1, 2005 at 5:09:10 PM, in the time zone of Tokyo that is nine
hours prior to GMT:
<SVC.observation_dttm V="2005-06-01T17:09:10+09:00"/>

2.4.5.3 Table 70: Null Code Values
VALUE
NI
NA
UNK
NASK
ASKU
NAV
OTH
PINF
NINF

USE
No Information
Not Applicable
Unknown
Not Asked
Asked But Unknown
Not Available
Other
Positive Infinity
Negative Infinity__________________________________________________________________________
36
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 for Public Comment (June 15 to July 15)______________________________________________________________________________

850

30 Transaction LAB-30: Initiate POCT on a patient specimen
This section describes Transaction LAB-30 of the IHE Technical Framework, used in the
LPOCT profile, between the POCRG and POCDM actors.

30.1 Scope
This transaction is used within LPOCT profile with the option “Patient Identity Checking”: The
POCRG and POCDM actors are assumed to have a persistent link between them.
The point of care devices often work with a patient (or visit) identifier scanned or typed on theiruser interface. The purpose of this transaction is to provide a real-time control of this patient/visit
identifier, and to avoid any risks of mistyping.
860

This transaction is used by a POCRG in a ward to inform the POCDM that a new point of careset of tests is about to start on a patient specimen. The POCRG delivers the relevant information
related to the testing, including a patient/visit identifier. The POCDM checks the information
received, and particularly verifies that the patient/visit identifier is associated with this ward. Itthen sends back an acknowledgement carrying a note, containing either the patient’s name or atextual error (e.g. “Patient unknown”) . The POCRG displays the note received in theacknowledgement, enabling the operator to check that he is testing on the right patient.

30. 2 Use Case Roles
Point Of Care
Results Generator(POCRG)

Point Of Care DataManager(POCDM)

LAB-30Initiate POCT on apatient specimen

Actor: POCRG
870

Role: Informs the POCDM that a new set of tests is starting, giving all relevant information
related to this point of care testing. Waits for the patient identity in the acknowledgement, anddisplays this identity on its user interface.
Actor: POCDM
Role: Checks the information received related to the point of care testing, searches for the patient
data related to the patient identifier received, and sends an acknowledgement back to the__________________________________________________________________________
37
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
POCRG. The acknowledgement carries either the patient’s name, or an error (e.g. “Testunauthorized on this device”)

30.3 Referenced Standard
POCT1-A : Device Message Layer (DML) defined in Appendix B of POCT1-A standard.
880

In the POCT1-A standard, the POCRG actor of IHE is called the Device and the POCDM
actor of IHE is called the Observation Reviewer.
This transaction LAB-30 uses the Continuous Mode defined in section 4.2 of Appendix
B of POCT1-A. This continuous mode is usable if the POCRG has a persistent link with
the POCDM, which is the prerequisite for using transaction LAB-30.

30.4 Interaction Diagram
POCRG

POCDM

Initiate POCT on a patient
specimen : OBS.R01
Acknowledgement withpatient’s name : ACK.R01

30.4.1 Patient identity checking

890

The POCT1-A standard currently does not describe this interaction for real-time patient identity
checking. Transaction LAB-30 of this IHE profile will use as initial message a “patient-related
observation message” OBS.R01 as defined in POCT1-A Appendix B. The status of the Service
object will be valued to “INI” (as “initiate a point of care testing”), and no results will be
provided in the message. This value “INI” is added by IHE to the table of service status definedin POCT1-A.
The Acknowledgement message ACK.R01 from the POCDM to the POCRG, will carry thepatient’s name as a note related to the acknowledgement, within the note_txt field of the
Acknowledgement object.
The two messages are exchanged within a “Observations” Topic within the Continuous Mode of
POCT1-A Device Messaging Level.

30.5 Trigger Events
900

An operator (caregiver or patient) sets a patient specimen on the point of care device (thePOCRG actor supporting the option “Patient identity checking”), and enters relevant information__________________________________________________________________________
38
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
including the operator’s ID and the patient’s ID. This triggers the initial message of Transaction
LAB30: “Initiate POCT on a patient specimen”.

30.6 Message Semantics
30.6.1 Initiate POCT on a patient specimen – Message OBS.R01, status_cd = ‘INI’
The figure below describes the use of message OBS.R01 in Transaction LAB-30. It respects theformalism of POCT1-A, Annex B.

__________________________________________________________________________
39
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 for Public Comment (June 15 to July 15)______________________________________________________________________________OBJECT MODEL
Header-message_type : CV+control_id : ST+version_id: ST+creation_dttm: TS-encoding_chars: ST

XML DTD FRAGMENT

OBS.R01
Patient-relatedObservations

Service+role_cd : CS
+observation_dttm: TS-status_cd: CS-reason_cd: CS-sequence_nbr: INT

Patient+patient_id : ST
-location_dttm: ST-name: PN-birth_date: TS-gender_cd: CS-weight: PQ-height: PQ<!ELEMENT OBS.R01 (HDR, SVC+)><!ELEMENT HDR (HDR.message_type?,
HDR.control_id, HDR.version_id, HDR.creation_dttm,
HDR.encoding_chars?)><!ELEMENT SVC (SVC.role_cd,
SVC.observation_dttm, SVC.status_cd?,
SVC.reason_cd?, SVC.sequence_nbr ?, PT, OPR?,
ORD?, SPC?)><!ELEMENT PT (PT.patient_id, PT.location?,
PT.name?, PT.birth_date?, PT.gender_cd ?, PT.weight?,
PT.height?)><!ELEMENT OPR (OPR.operator_id, OPR.name?)><!ELEMENT ORD (ORD.universal_service_id,
ORD.ordering_provider_id?, ORD_order_id?)><!ELEMENT SPC (SPC.specimen_dttm,
SPC.specimen_id?, SPC.source_cd?, SPC.type_cd?)>

Operator [0..1]+operator_id : ST
-name: PN
Order [0..1]+universal_service_id : CE
-ordering_provider_id: ST-order_id: CV

Specimen [0..1]+specimen_dttm : TS
-specimen_id: CV-source_cd: CE-type cd: CE__________________________________________________________________________
40
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
30.6.1.1 Use of the Service object
One and only one occurrence of this object must appear in the context of Transaction LAB-30.
Attribute

Data
Type

IHE
Usage

IHE
Cardinalities

Description

role_cdCSR[1..1]

Value “OBS”: Patient test observation

observation_dttm

TSR[1..1]Starting date/time of the test

status_cd

STR[1..1]

Value “INI”: The point of care test is about to start. No
observation produced yet.

reason_cd

STX[0..0]

This code is not used in the context of LAB-30.

sequence_nbr

ST

X[O..0]

This number is not used in the context of LAB-30.

910
Table 48 of POCT1-A: Service Status code Field Values
Code

Meaning

Description

NRM

NormalThis test was performed under normal conditions

OVR

OverrideThis test was performed in an ‘override’ or ‘stat’ circumstance. Some normal
procedures (e.g., QC) may not have been followed.

UNK

Unknown

It is not known under what circumstances this test was performed.

INI

Test starting

This test is going to start for this patient. Value added by IHE to this table

The last value “INI” is added by this LPOCT IHE profile, for the unique purpose of thisTransaction LAB-30.
30.6.1.2 Use of the Patient object
One and only one occurrence of this object must appear in the context of Transaction LAB-30.
Data
Type

IHE
Usage

IHE
Cardinalities

Description

patient_id

STR[1..1]A unique identifier for the patient, supposed to be known fromthe POCDM actor

locationST

RE[0..1]

Location of the patient

name

PN

X

[0..0]

Patient name. Not used in the context of LAB-30.

birth_date

TSX[0..0]

Patient date of birth. Not used in the context of LAB-30.

gender_cd

CSX[0..0]

Patient gender. Not used in the context of LAB-30.

weightPQ

X[0..0]

Patient weight. Not used in the context of LAB-30.

heightPQ

X[0..0]

Patient height. Not used in the context of LAB-30.

Attribute

30.6.1.3 Use of the Operator object
One and only one occurrence of this object must appear in the context of Transaction LAB-30.
Attribute
operator_id

Data
Type

IHE
Usage

IHE
Cardinalities

STR[1..1]

Description
A unique identifier for the operator__________________________________________________________________________
41
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
Attribute
name

Data
Type

IHE
Usage

IHE
Cardinalities

PN

RE[0..1]

Description
Operator’s name. Required if available on the POCRG.

30.6.1.4 Use of the Order object
Zero or one occurrence of this object may appear in the context of Transaction LAB-30.

920

Attribute

Data
Type

IHE
Usage

IHE
Cardinalities

Description

universal_service_id

CER[1..1]

Identifies the service provided by these observations.
LOINC is the preferred encoding scheme. The CE data typeallows transmission of two encodings, if appropriate.

ordering_provider_id

STRE[0..1]

An identifier that uniquely identifies the provider whoordered this service.

order_idCVO[0..1]

An identifier that uniquely identifies this service instance.
This field may contain an order id, accession number, orother such identifier.

30.6.1.5 Use of the Specimen object
Zero or one occurrence of this object may appear in the context of Transaction LAB-30.
Data
Type

IHE
Usage

IHE
Cardinalities

specimen_dttm

TSR[1..1]

Time the specimen was drawn.

specimen_id

CVO[0..1]

Code identifying the specimen

source_cd

CEO[0..1]

Location of the specimen. Coded in table 51 of POCT1-A

type_cdCEO[0..1]

Type of the specimen. Coded in table 52 of POCT1-A

Attribute

Description__________________________________________________________________________
42
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
30.6.1.6 Example message OBS.R01: Initiate POCT on a patient specimen<OBS.R01><HDR><HDR.control_id V=“12345”/><HDR.version_id V=“POCT1”/><HDR.creation_dttm V=“2005-05-16T16:30:00+01:00”/></HDR><SVC><SVC.role_cd V=“OBS”/><SVC.observation_dttm V=“2005-05-16T16:30:00+01:00”/><SVC.status_cd V=“INI”/><PT><PT.patient_id V=“888888”/>
</PT>
<OPR>
<OPR.operator_id V=“Nurse007”/><OPR.name V=“Nancy Nursery”>< GIV V=“Nancy”/>< FAM V=“Nursery”/></OPR.name></OPR><ORD><ORD.universal_service_id V="BG-OXI-ELECT"/><ORD.ordering_provider_id V="Facility1"/></ORD></SVC></OBS.R01>

In this example, the operator Nancy Nursery, wants to start a blood gas test on a patient specimen
for a patient whose enterprise id is « 888888 ». The device is in a hospital in Palermo one hourahead GMT.
30.6.2 Acknowledgement with patient name – Message ACK.R01
The figure below is extracted from POCT1-A, Annex B.

__________________________________________________________________________
43
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 for Public Comment (June 15 to July 15)______________________________________________________________________________

930

30.6.2.1 Use of the Header object
Attribute

Data
Type

IHE
Usage

IHE
Cardinalities

message_type

CVX[0..0]

Not used: Redundant with the root element of the message

control_id

STR[1..1]

unique identifier of the instance of this acknowledgement message

version_id

STR[1..1]“POCT1”

creation_dttm

TSC[O..1]

date/time of creation of this acknowledgement

Description

30.6.2.2 Use of the Acknowledgement object
Data
Type

IHE
Usage

IHE
Cardinalities

type_cdCSR[1..1]

ack_control_id

STR[1..1]The unique identifier of the acknowledged message

note_txt

STR[1..1]

This field is required in the context of IHE Transaction LAB-30. It
contains either the patient’s name in case of Application Accept

Attribute

Description
AA: Application Accept
AE: Application Error

or a text describing the error condition in case of Application
Error.
error_detail_cd

CVR[1..1]A code detailing the error. Described in Table 14 of Annex B of
POCT1-A.

Condition predicate for the field note_txt:
If the POCDM has matched an existing patient, and has controlled that the information received
within the OBS.R01 message is consistent with this patient and that the test for this patient on
this device by this operator is authorized, then the POCDM sends back a positive
acknowledgement (type_cd = “AA”, error_detail_cd = “0”). In this case, the note_txt is required
and shall be valued with the patient’s name, using any display oriented string format.
Example of positive acknowledgement for patient Jeanne DUPONT:__________________________________________________________________________
44
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 for Public Comment (June 15 to July 15)______________________________________________________________________________<ACK.R01><HDR>< HDR.control_id V=“45678”/>< HDR.version_id V=“POCT1”/>< HDR.creation_dttm V=“2005-05-16T16:30:00”/></HDR><ACK>< ACK.type_cd V=“AA”/>< ACK.ack_control_id V=“12345”/>< ACK.note_txt V=“ DUPONT Jeanne ”/>< ACK.error_detail_cd V= “0”/></ACK></ACK.R01>

940
If the POCDM has failed to match a patient from the patient identifier received within the
OBS.R01 message, then it sends back a negative acknowledgement (type_cd = “AA”,
error_detail_cd = “202”), with the field note_txt containing a text explaining the error condition.
Example of negative acknowledgement:<ACK.R01><HDR>< HDR.control_id V=“45679”/>< HDR.version_id V=“POCT1”/>< HDR.creation_dttm V=“2005-05-16T16:30:00”/></HDR><ACK>< ACK.type_cd V=“AE”/>< ACK.ack_control_id V=“12345”/>< ACK.note_txt V=“ Unknown patient identifier 888888”/>< ACK.error_detail_cd V= “202”/></ACK></ACK.R01>

30.7 Expected Actions
When receiving the message “Initiate POCT on a patient specimen”, the POCDM must search
for the patient using the patient ID, and must check the information related to the testing. Thenthe POCDM builds its Acknowledgement message and sends it to the POCRG.
950

When receiving the message “Acknowledgement with patient identity”, the POCRG must
display as much of the patient identity as possible, to allow the operator to verify this identity.

__________________________________________________________________________
45
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 for Public Comment (June 15 to July 15)______________________________________________________________________________

31 Transaction LAB-31: Produced observation set
This section describes Transaction LAB-31 of the IHE Technical Framework, used in the
LPOCT profile, between the POCRG and POCDM actors.

31.1 Scope
This transaction is required within LPOCT profile.

960

The POCRG sends a set of observations to the POCDM. The POCDM checks the content of thisset of results. If it is acceptable, the POCDM stores it and acknowledges it to the POCRG;
otherwise the POCDM rejects the set of results and sends a negative acknowledgement back to
the POCRG that will display it to its user.
The set of observations may be obtained on a patient specimen or on a QC specimen.

31. 2 Use Case Roles
Point Of Care
Results Generator(POCRG)

Point Of Care DataManager(POCDM)

LAB-31
Produced observation
set

Actor: POCRG
Role: Sends to the POCDM a new set of observations obtained on a patient specimen or a QC
specimen. Waits for the acknowledgement of this set of observations
Actor: POCDM

970

Role: Checks the information received with this set of observations, controls the results against
its own business rules, accepts them or rejects them, stores the accepted results, andacknowledges them to the POCRG.

31.3 Referenced Standard
POCT1-A : Device Message Layer (DML) defined in Appendix B.
This LPOCT profile describes the upper-layer messaging protocol (DML) of POCT1-A.
The POCRG actor of IHE is called the “Device” in POCT1-A. The POCDM actor of IHE
is called “Observation Reviewer” in POCT1-A.
__________________________________________________________________________
46
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
This transaction LAB-31 can be used on the Basic Profile defined in section 4.1 ofAppendix B of POCT1-A, or on the Continuous Mode defined in section 4.2 of the same
document.

31.4 Interaction Diagram
POCRG

POCDM

Patient related set ofobservations
Acknowledgement

QC related set ofobservations
Acknowledgement980
31.4.1 LAB-31
The message “Patient related set of observations” of the diagram above uses the Observations
message OBS.R01 defined in Appendix B – section 6.10 of POCT1-A.
The message “QC related set of observations” uses the Observations message OBS.R02 definedin the same section of POCT1-A.

31.5 Trigger Events

990•

The “Patient related set of observations” message is triggered by any new patient
observations obtained on the POCRG actor.

•

The “QC related set of observations” message is triggered by any new non-patient
observations (internal or external QC, calibration) obtained on the POCRG actor.

When using the “Continuous Mode” of POCT1-A the above events trigger the Observations
messages at once.
__________________________________________________________________________
47
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
When using the “Basic Profile” of POCT1-A the sending of these Observation messages
requires these prior conditions:

1000

•

Establishment of a Conversation between POCRG and POCDM. (Topic Hello)•

The sending of the message “Device status” by the POCRG actor and its
acknowledgement by the POCDM actor. (Topic Device Status)•

The sending of the message “Request Observations” by the POCDM to the POCRG (ifthe Conversation is not in continuous mode).

31.6 Message Semantics<detailed description of the meaning of the transaction including any IHE specific clarificationsof the message format, attributes, etc.>
31.6.1 Message OBS.R01: Patient-related set of observations
The figure below is extracted from POCT1-A, Annex B.

__________________________________________________________________________
48
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 for Public Comment (June 15 to July 15)______________________________________________________________________________OBJECT MODELXML DTD FRAGMENT

HeaderOBS.R01-message_type : CV Patient-relatedObservations+control_id : ST+version_id : ST
+creation_dttm : TS-encoding_chars : ST<!ELEMENT OBS.R01 (HDR, SVC+)><!ELEMENT HDR (HDR.message_type?, HDR.control_id,
HDR.version_id, HDR.creation_dttm, HDR.encoding_chars?)>

Service (1...*)+role_cd : CS
+observation_dttm : TS-status_cd : CS-reason_cd : CS-sequence_nbr : INT<!ELEMENT SVC (SVC.role_cd, SVC.observation_dttm, SVC.status_cd?,
SVC.reason_cd?, SVC.sequence_nbr?, PT, OPR?, ORD?, SPC?,RGT*, NTE*)>

Patient+patient_id : ST
-location : ST
-name : PN
-birth_date : TS-gender_cd : CS
-weight : PQ
-height : PQ<!ELEMENT PT (PT.patient_id, PT.location?, PT.name?, PT.birth_date?,
PT.gender_cd?, PT.weight?, PT.height?, OBS+)><!ELEMENT OBS (OBS.observation_id, OBS.value?,
Observation (1...*)+observation_id : CE
-value : PQ
-qualitative_value : CV+method_cd : CS-status_cd : CS
-interpretation_cd : CS
-normal_lo-hi_limit : IVL<PQ>-critical_lo-hi_limit : IVL<PQ>

OBS.qualitative_value?, OBS.method_cd, OBS.status_cd?,
OBS.interpretation_cd?, OBS.normal_lo-hi_limit?,
OBS.critical_lo-hi_limit?, NTE*)><!ELEMENT OPR (OPR.operator_id, OPR.name?)>

Note (0...*)+text : ST
Operator (0...1)<!ELEMENT ORD (ORD.universal_service_id,
ORD.ordering_provider_id?, ORD.order_id?)>+operator_id : ST
-name : PN
Order (0...1)+universal_service_id : CE
-ordering_provider_id : ST
-order_id : CV
Specimen (0...1)+specimen_dttm : TS
-specimen_id : CV-source_cd : CE
-type_cd : CE<!ELEMENT SPC (SPC.specimen_id?, SPC.specimen_dttm,
SPC.source_cd?, SPC.type_cd?)><!ELEMENT RGT (RGT.name, RGT.lot_number, RGT.expiration_date)><!ELEMENT NTE (NTE.text)>

Reagent (0...*)+name : ST
+lot_number : CV
+expiration_date : TS
Note (0...*)+text : ST

Figure 44. Patient-related Observation Message Model, POCT1-A – Appendix B__________________________________________________________________________
49
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
31.6.1.1 Use of the Service object
Attribute

Data
Type

IHE
Usage

IHE
Cardinalities

Description

role_cdCSR[1..1]

Value “OBS”: Patient test observation

observation_dttm

TSR[1..1]

production date/time of this set of observations

status_cd

STR[1..1]

One of the values listed in table 48 of POCT1-A, Annex B

reason_cd

STR[1..1]

One of the values listed in table 49 of POCT1-A, Annex B

sequence_nbr

ST

O[O..1]

An optional number to indicate the position of this service in ahistorical list of services performed by this Device. This number
is unique only across a single Device, and may wrap (e.g., a ‘usecounter’).

Table 48 of POCT1-A: Service Status code Field Values
Code

Meaning

Description

NRM

NormalThis test was performed under normal conditions

OVR

OverrideThis test was performed in an ‘override’ or ‘stat’ circumstance. Some normal
procedures (e.g., QC) may not have been followed.

UNK

Unknown

It is not known under what circumstances this test was performed.

Table 49 of POCT1-A: Service Reason Code Field Values
Code

Meaning

Description

NEW

New

Default. This is a new set of observations.

RES

ResentThis set of observations is being resent.

EDT

EditedSome fields of this set of observations have been edited since last transmission

31.6.1.2 Use of the Patient object
1010

One and only one occurrence of Patient per Service:
Data
Type

IHE
Usage

IHE
Cardinalities

Description

patient_id

STR[1..1]A unique identifier for the patient, supposed to be known fromthe POCDM actor

locationST

RE[0..1]

Location of the patient. Required if known.

name

PN

RE

[0..1]

Patient name. Required if known.

Attributebirth_date

TSRE[0..1]

Patient date of birth. Required if known.

gender_cd

CSRE[0..1]

Patient gender. Required if known.

weightPQ

C[0..1]

Patient weight. Required if known and relevant for the test.

heightPQ

C[0..1]

Patient height. Required if known and relevant for the test.

__________________________________________________________________________
50
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
31.6.1.3 Use of the Observation object
One or more occurrences of Observation per Patient:
Attribute

Data
Type

IHE
Usage

IHE
Cardinalities

Description

observation_id

CER[1..1]The test identifier, preferably coded with LOINC

value

PQ

C

[0..1]

qualitative_value

CVC[0..1]

method_cd

CSR[1..1]

status_cd

CSR[1..1]

interpretation_cd

CSC[0..1]

normal_lo-hi_limit

IVL<PQ>

R[1..1]The observation result, if expressed quantitatively (i.e. anumerical value with units).
The observation result, if expressed qualitatively.
POCT1-A, Annex B provides a list of codes in table 35.
This list is extensible.
Origin of the result. Coded in table 36 of POCT1-A,
Annex B. This LPOCT profile authorizes only thesevalues:C = Calculated (The value was calculated)
D = Default (The value is a default value)
E = Estimated
I = Input (The value was externally input to the POCRG)
M = Measured (The value was measured on the POCRG)
Status of the result. Coded in table 37 of POCT1-A, Annex
B. This IHE LPOCT profile authorizes only this value forpatient-related results: A = AcceptedInterpretation of the result (abnormal flags). Coded in table
38 of POCT1-A, Annex B:
L = below low normal
H = above high normal
LL = below lower panic limits
HH = above upper panic limits< = below absolute low-off instrument scale> = above absolute high-off instrument scale
N = normal
A = abnormal (applies to nonnumeric results)
AA = very abnormal (applies to nonnumeric results)
null = no range defined or normal ranges don’t apply
U = significant change up
D = significant change down
B = better (use when direction not relevant)W = worse (use when direction not relevant)
The low and high limit range for a normal result

critical_lo-hi_limit

IVL<PQ>

R[1..1]The low and high limit range outside which clinical review
is required

Condition predicate for fields value, qualitative_value and interpretation_cd:
Every Observation object instance must contain either a value or a qualitative_value field.
The interpretation_cd field may be used to provide additional information about thequantitative or qualitative value.

__________________________________________________________________________
51
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
31.6.1.4 Use of the Note object related to the Observation object
1020

Zero or one occurrence of this object may appear below an observation. The note is a comment
related to the observation.
Attribute

Data
Type

IHE
Usage

IHE
Cardinalities

STR[1..1]

text

Description
Comment of the observation

31.6.1.5 Use of the Operator object
One and only one occurrence.
Data
Type

IHE
Usage

IHE
Cardinalities

operator_id

STR[1..1]A unique identifier for the operator

name

PN

RE

[0..1]

Operator’s name. Required if available on the POCRG.

Attribute

Description

31.6.1.6 Use of the Order object
One and only one occurrence.
Attribute

Data
Type

IHE
Usage

IHE
Cardinalities

Description

universal_service_id

CER[1..1]

Identifies the service provided by these observations.
LOINC is the preferred encoding scheme. The CE data typeallows transmission of two encodings, if appropriate.

ordering_provider_id

STRE[0..1]

An identifier that uniquely identifies the provider whoordered this service.

order_idCVO[0..1]

An identifier that uniquely identifies this service instance.
This field may contain an order id, accession number, orother such identifier.

31.6.1.7 Use of the Specimen object
Zero or one occurrence.
Attribute

Data
Type

IHE
Usage

IHE
Cardinalities

Description

specimen_dttm

TSR[1..1]

Time the specimen was drawn.

specimen_id

CVO[0..1]

Code identifying the specimen

source_cd

CEO[0..1]

Location of the specimen. Coded in table 51 of POCT1-A,
Annex B

type_cd

CER[1..1]

Type of the specimen. Coded in table 52 of POCT1-A, Annex
B__________________________________________________________________________
52
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
31.6.1.8 Use of the Reagent object
Zero or one occurrence.
Data
Type

IHE
Usage

IHE
Cardinalities

name

ST

RE

[0..1]The manufacturer’s name for the reagent

lot_numberCVR[1..1]The lot number of reagent used

expiration_date

TSRE[0..1]The date past which the reagent should not be used

Attribute

Description

31.6.1.9 Use of the Note object
1030

Zero or more occurrences of this object may appear below the Service object. The note is acomment related to the service (i.e. the set of observations).
Attribute
text

Data
Type

IHE
Usage

IHE
Cardinalities

STR[1..1]

Description
Comment of the observation__________________________________________________________________________
53
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
31.6.1.10 Example message of patient observations<OBS.R01><HDR><HDR.control_id V=“12345”/><HDR.version_id V=“POCT1”/><HDR.creation_dttm V=“2005-05-16T16:30:00+1:00”/></HDR><SVC><SVC.role_cd V=“OBS”/><SVC.observation_dttm V=“2005-05-16T16:30:00+1:00”/><SVC.status_cd V=“NRM”/><SVC.reason_cd V=“NEW”/><PT><PT.patient_id V=“888888”/><PT.location V=“ICU-Bed3”/><PT.name V=“Pat Patient”><GIV V=“Patrick”><FAM V=“Patient”></ PT.name ><PT.birth_date V=“1958-10-31”/><PT.gender_cd V=“M”/><OBS>< OBS.observation_id V=“2703-7” SN=“LN” DN=“Oxygen”/><OBS.value V="110" U="mmHg"/><OBS.method_cd V="M"/><OBS.status_cd V="A"/><OBS.interpretation_cd V="H"/><OBS.normal_lo-hi_limit V="[83;108]" V="mmHg"/><OBS.critical_lo-hi_limit V="[40;130]" V="mmHg"/></OBS><!-- See the end of the message on next page -->__________________________________________________________________________
54
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 for Public Comment (June 15 to July 15)______________________________________________________________________________<OBS>< OBS.observation_id V=“11557-6” SN=“LN” DN=“Carbon Dioxyd”/><OBS.value V="33.2" U="mmHg"/><OBS.method_cd V="M"/><OBS.status_cd V="A"/><OBS.interpretation_cd V="L"/><OBS.normal_lo-hi_limit V="[35.0;48.0]" V="mmHg"/><OBS.critical_lo-hi_limit V="[20.0;60.0]" V="mmHg"/></OBS><NTE><NTE.text V=“result below reference ranges, within critical ranges”/></NTE><OBS>< OBS.observation_id V=“11558-4” SN=“LN” DN=“pH”/><OBS.value V="7.47"/><OBS.method_cd V="M"/><OBS.status_cd V="A"/><OBS.interpretation_cd V="H"/><OBS.normal_lo-hi_limit V="[7.35;7.45]" V="mmHg"/><OBS.critical_lo-hi_limit V="[7.00;7.60]" V="mmHg"/></OBS></PT><OPR><OPR.operator_id V=“Nurse007”/><OPR.name V=“Nancy Nursery”>< GIV V=“Nancy”/>< FAM V=“Nursery”/></OPR.name></OPR><ORD><ORD.universal_service_id V="BG-OXI-ELECT"/><ORD.ordering_provider_id V="Facility1"/></ORD><SPC><SPC.specimen_dttm V="2005-05-19T10:20:00-1.00"/><SPC.source_cd V="LLFA"/><SPC.type_cd V="BLDA"/></SPC><NTE><NTE.text V=“Battery approved by Dr Esclapios”/></NTE></SVC></OBS.R01>

31.6.2 Message OBS.R02: QC related set of observations
The figure below is extracted from POCT1-A, Annex B.
__________________________________________________________________________
55
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 for Public Comment (June 15 to July 15)________________________________________________________________________________________________________________________________________________________
56
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 for Public Comment (June 15 to July 15)______________________________________________________________________________

1040

31.6.2.1 Use of the Service object
Attributerole_cd

Data
Type

IHE
Usage

IHE
Cardinalities

Description

CSR[1..1]

The following values are authorized within OBS.R02 message,
taken from table 47 in POCT1-A, Annex B:
LQC = Liquid QC (observation from a liquid QC test)
EQC = Electronic QC (observation from an electronic QC test)
CVR = Calibration verification
CAL = Calibration
PRF = Proficiency test
production date/time of this set of observations

observation_dttm

TSR[1..1]

status_cd

STR[1..1]

One of the values listed in table 48 of POCT1-A, Annex B (seesection Y.6.1.1 in this document)

reason_cd

STR[1..1]

One of the values listed in table 49 of POCT1-A, Annex B (seesection Y.6.1.1 in this document)

sequence_nbr

ST

O[O..1]

An optional number to indicate the position of this service in ahistorical list of services performed by this Device. This number
is unique only across a single Device, and may wrap (e.g., a ‘usecounter’).

31.6.2.2 Use of the Control/Calibration object
One and only one occurrence of Control/Calibration per Service:
Data
Type

IHE
Usage

IHE
Cardinalities

name

ST

RE

[0..1]The manufacturer’s name for the QC/Calibration material

lot_numberCVR[1..1]The vendor-specific lot number of the QC/Calibration material

expiration_date

TSRE[0..1]The date past which the reagent should not be usedlevel_cdCVC[0..1]The level for the QC test or for the calibration verification test.
Not applicable to proficiency tests nor to calibration tests.

cal-ver_repetition

INT

C[0..1]

Only applicable to calibration verification: If tests within alinearity sequence are repeated at a given level, this fieldindicates the repetition count for this particular test.

Attribute

Description

31.6.2.3 Use of the Observation object
At least one occurrence of Observation below Control/Calibration:
Attribute

Data
Type

IHE
Usage

IHE
Cardinalities

observation_id

CER[1..1]The test identifier, preferably coded with LOINC

value

PQ

C

[0..1]The observation result, if expressed quantitatively (i.e. anumerical value with units).

qualitative_value

CVC[0..1]The observation result, if expressed qualitatively.

Description__________________________________________________________________________
57
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
Data
Type

IHE
Usage

IHE
Cardinalities

Description

method_cd

CSR[1..1]

status_cd

CSR[1..1]

interpretation_cd

CSC[0..1]

Origin of the result. Coded in table 36 of POCT1-A,
Annex B. This LPOCT profile authorizes only thesevalues:C = Calculated (The value was calculated)
D = Default (The value is a default value)
E = Estimated
I = Input (The value was externally input to the POCRG)
M = Measured (The value was measured on the POCRG)
Status of the result. Coded in table 36 of POCT1-A, Annex
B. This LPOCT profile authorizes only these values forpatient-related results:
A = Accepted
D = Discarded
R = RejectedInterpretation of the result (abnormal flags). Coded in table
38 of POCT1-A, Annex B (See section Y.6.1.3 above)normal_lo-hi_limit

IVL<PQ>RE[0..1]The low and high limit range for a normal result

critical_lo-hi_limit

IVL<PQ>RE[0..1]The low and high limit range outside which clinical review
is required

Attribute

Condition predicate for fields value, qualitative_value and interpretation_cd: Same as in section
Y.6.1.3 above.
31.6.2.4 Use of the Note object related to the Observation object
1050

Zero or one occurrence of this object may appear below an observation. The note is a comment
related to the observation.
Attribute

Data
Type

IHE
Usage

IHE
Cardinalities

STR[1..1]

text

Description
Comment of the observation

31.6.2.5 Use of the Operator object
One and only one occurrence.
Attribute

Data
Type

IHE
Usage

IHE
Cardinalities

Description

operator_id

STR[1..1]A unique identifier for the operator

name

PN

RE

[0..1]

Operator’s name. Required if available on the POCRG.

31.6.2.6 Use of the Reagent object
Zero or one occurrence.
Attribute
name

Data
Type

IHE
Usage

IHE
Cardinalities

STRE[0..1]

Description
The manufacturer’s name for the reagent__________________________________________________________________________
58
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
Data
Type

IHE
Usage

IHE
Cardinalities

lot_numberCVR[1..1]The lot number of reagent used

expiration_date

TSRE[0..1]The date past which the reagent should not be used

Attribute

Description

31.6.2.7 Use of the Note object
Zero or more occurrences of this object may appear below the Service object. The note is acomment related to the service (i.e. the set of observations).
Attribute
text

Data
Type

IHE
Usage

IHE
Cardinalities

STR[1..1]

Description
Comment of the observation

31.7 Expected Actions
1060

1070

The POCDM receiving a message OBS.R01 (patient related observations) must check this set ofobservations against its own configuration rules (comparison with normal ranges, QC performed
and OK, operator allowed to proceed, patient known in this point of care …). It then accepts or
rejects this set of observations, and sends its reply in an Acknowledgement message. If the set ofobservations was accepted, the POCDM stores it in its data base. If the option “Supervision bylaboratory” is supported, the POCDM initiates a Transaction LAB-32 with the Order Filler toforward this accepted set of observations.
The POCDM receiving a message OBS.R02 (non-patient related observations) must check thisset of observations against its own configuration rules. It then accepts or rejects this set ofobservations, and sends its reply in an Acknowledgement message. If the set of observations (QCor calibration results) was accepted, the POCDM stores it in its data base.

__________________________________________________________________________
59
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 for Public Comment (June 15 to July 15)______________________________________________________________________________

32 Transaction LAB-32: Accepted Observation Set
This section describes Transaction LAB-32 of the IHE Technical Framework, used in the
LPOCT profile, between the POCDM actor and the Order Filler actor.

32.1 Scope
This transaction is used within LPOCT profile with the option “Supervision by laboratory”: The
POCDM forwards all accepted sets of patient observations to the Order Filler.

32. 2 Use Case Roles
Point Of Care DataManager(POCDM)

Order Filler

LAB-32
Accepted observation
set

Actor: POCDM
1080

Role: Forwards to the Order Filler each set of observations accepted for a patient specimen.
Waits for the acknowledgement of this set of observations and stores the filler order number thatit contains.
Actor: Order Filler
Role: Receives the set of patient observations, and according to the trigger event, either stores
this set in an existing order, or generates a new order for it. In either case it will return the filler
order number in the associated acknowledgement sent back to the POCDM.

32.3 Referenced Standard

1090

POCT1-A : Observation Reporting Interface (ORI) defined in Appendix C of this standard. The
POCT1-A standard names “Observation Reviewer” the IHE POCDM actor, and names“Observation Recipient” the IHE Order Filler actor.
HL7 v2.5: The ORI of POCT1-A relies on HL7 v2.5 messages structures ORU defined inchapter 7 of the HL7 standard.
All implementation rules and notes specified in the Volume 2 of IHE Laboratory Technical
Framework fully apply to the messages of this transaction LAB-32. More precisely:__________________________________________________________________________
60
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 for Public Comment (June 15 to July 15)______________________________________________________________________________•

Section 2.2 “HL7 profiling conventions”•

Section 2.3 “HL7 implementation notes”•

Section 3 “Common message segments for Laboratory Technical Framework”. Thissection provides the common description of segments MSH, MSA, NTE, ERR, PID,
ORC, that are also applicable to this transaction LAB-32.

1100

32.4 Interaction Diagram
POCDM

Order Filler

ORU^R30:
Unordered observations,generate order
ACK^R33:
Acknowledgement

ORU^R31:
New observations,search for an existing order
ACK^R33:
Acknowledgement

32.4.1 LAB-32
Transaction LAB-32 offers two distinct message structures to support the various use cases
described in Volume 1:

1110

•

ORU^R30 (Unordered observations) is used in part 4 of scenarios 5.5.1 and 5.5.3, as wellas in part 2 of scenario 5.5.4. The Order Filler SHALL generate a new order when
receiving this message.

•

ORU^R31 is used in part 4 of scenario 5.5.2: The POCDM instructs the Order Filler tomatch an existing order to store the observations.

The acknowledgement to both message structures is ACK^R33. this acknowledgement is anapplication acknowledgement that sends back the filler order number of the order generated ormatched by the Order Filler, to store this set of POCT results.
Note 5:The trigger event ORU^R32 “preordered observations” described in POCT1-A’s ORI, is not part of the IHE
LPOCT profile. As explained in Volume 1 of this profile, section 1.4 “Relationship to real world architectures,and in Volume 2, section 5.5.2, Note 1, this event corresponds to the normal scheduled workflow and is
supported by the two IHE profiles LSWF and LDA.

__________________________________________________________________________
61
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 for Public Comment (June 15 to July 15)______________________________________________________________________________

32.5 Trigger Events
1120

The POCDM integrates a set of point of care observations for a patient, received from a POCRG
on LAB-31. The option “Supervision by laboratory” being supported, this event triggers amessage of LAB-32 that sends these observations to the Order Filler.
If the indication “existing order” is present in the set of observations, the message is ORU^R31,
otherwise the message is ORU^R30.

32.6 Message Semantics
32.6.1 Common static definition for ORU^R30 and ORU^R31
Table 32.6.1-1 : static definition for ORU^R30 and ORU^R31
Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

PID

Patient IdentificationR[1..1]

3

ORC

Common Order informationR[1..1]

4

OBR

Observation Request

R[1..1]

4[{NTE}]

Notes or Comments for order/Result

RE[0..1]

4[{--- RESULT begin

O[0..*]

OBX

Observation related to OBR

R[1..*]

7[{NTE}]

Comment of the result

C[0..1]

2}]--- RESULT end

32.6.1.1 Usage of MSH segment

1130

The MSH segment has a common definition for all HL7 messages of IHE Laboratory Technical
Framework. This common definition is presented in section 3.1 of L-TF Volume 2. Below aresome additional recommendations for the usage of this segment within the context of this
LPOCT profile.
MSH-9 – Message Type, shall have its three components valued as follows:

1140

•

ORU^R30^ORU_R30 for the unordered point of care observations•

ORU^R31^ORU_R31 for the point of care observations to match with a possibly existingorder

Fields MSH-15 and MSH-16 are not used by any IHE profile of the Laboratory Technical
Framework: This framework uses only the HL7 original acknowledgement mode (see section
2.3.3 of Volume 2). The acknowledgement sent back by the receiver is always an applicative
acknowledgement (see section 2.3.5 of Volume 2 for IHE Laboratory Technical Framework
acknowledgement policies). The Order Filler will then behave as if it had received MSH-15
valued “NE” and MSH-16 valued “AL”__________________________________________________________________________
62
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
32.6.1.2 Usage of PID segment
The PID segment has a common definition for all HL7 messages of IHE Laboratory Technical
Framework, in section 3.1 of Volume 2. Below are some additional recommendations for theusage of this segment within the context of this LPOCT profile.
PID-3 – Patient Identifier List, is required (R) and must contain a patient unique ID sharedwithin the healthcare enterprise.
PID-5 – Patient Name, is required if available (usage RE) and shall contain the patient identity.
1150

PID-7 – Date/Time of Birth, is required if available (RE) and will be valued if the POCDM
knows the patient’s date of birth.
PID-8 – Administrative Sex, is required if available (RE) and will be populated with theappropriate value taken from HL7 user-defined Table 0001:
Value

Description

F
M
O
U
A
N

FemaleMale
Other
Unknown
Ambiguous
Not applicable

PID-18 – Patient Account Number, is required if available (RE) and will be valued if therelevant account number is known to the POCDM actor.
32.6.1.3 Usage of ORC segment
The common definition of segment ORC in Volume 3 – section 3.7, does not apply to this
LPOCT Integration Profile: The ORU^R30 message structure instructs the recipient to generate
the order, and the ORU^R31 message instructs to match an existing order, without identifying it.
Hence, the usage definition of ORC segment within this LPOCT profile, below:
1160

Table Z.6.1.3-1 : ORC Segment
SEQ

LEN

DT

Usage

Card.

TBL#

ITEM#

1

2

ID

R

[1..1]

0119

00215

Order Control

2

22

EI

X

[0..0]

00216

Placer Order Number

3

22

EI

C

[0..0]

00217

Filler Order Number

4

22

EI

X

[0..0]

5

2

ID

X

[0..0]

7

200

TQ

X

8

200

EIP

9

26

TS

10

250

11
17

Element name00218

Placer Group Number

00219

Order Status[0..0]

00221

Quantity/TimingX[0..0]

00222

ParentX[0..0]

00223

Date/Time of Transaction

XCN

X[0..0]

00224

Entered By

250

XCN

X

[0..0]

00225

Verified By

250

CE

X

[0..0]

00231

Entering Organization

0038__________________________________________________________________________
63
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
SEQ

LEN

DT

Usage

Card.

TBL#

ITEM#

0339

Element name

20

250

CE

X

[0..0]

01310

Advanced Beneficiary Notice Code

21

250

XON

RE

[0..1]

01311

Ordering Facility Name

25

250

CWE

X

[0..0]

01473

Order Status Modifier

26

60

CWE

X

[0..0]

01641

Advanced Beneficiary Notice Override
Reason

27

26

TS

X

[0..0]

01642

Filler's Expected Availability
Date/Time

0552

ORC-1 Order Control (ID), required. This field shall be valued to “NW” (new order) both in
ORU^R30 and ORU^R31 message structures.
ORC-3 Filler Order Number (EI): This LPOCT profile applies the condition predicate
specified by POCT1-A: “The POCDM may supply an external identifier in this field that othersystems can use to reference this result set. This specification places no restrictions on theformat or content of this field’s value. For example, some POCDM might expose a database key
in this field while others might use a combination of Device name, serial number and thetimestamp of the result as the unique external identifier”.
ORC-21 Ordering Facility Name (XON), required but may be empty (RE).
1170

For this LPOCT profile, this field contains the facility (ward) where this point of careobservation set has been performed. These three components shall be valued:•

1st = Organization name.

•

7th = Identifier Type Code whith the value “FI”, which means “Facility ID” as statedby HL7 table n° 0203.

•

10th = Organization Identifier.

Example: Urology^^^^^^FI^^^UR01
32.6.1.4 Usage of OBR segment
Table Z.6.1.4-2 : OBR Segment
SEQ

LEN

DT

Usage

Card.

TBL#

ITEM#

Element name

2

22

EI

X

[0..0]

00216

Placer Order Number

3

22

EI

X

[O..0]

00217

Filler Order Number

4

250

CE

R

[1..1]

00238

Universal Service Identifier

5

2

ID

X

[0..0]

00239

Priority – OBR

6

26

TS

X

[0..0]

00240

Requested Date/Time

7

26

TS

X

[0..0]

00241

Observation Date/Time

8

26

TS

X

[0..0]

00242

Observation End Date/Time

9

20

CQ

X

[0..0]

00243

Collection Volume

10

250

XCN

X

[0..0]

11

1

ID

R

[1..1]

0065

00244

Collector Identifier

00245

Specimen Action Code__________________________________________________________________________
64
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 for Public Comment (June 15 to July 15)______________________________________________________________________________

1180

SEQ

LEN

DT

Usage

Card.

TBL#

ITEM#

Element name

12

250

CE

X

[0..0]

00246

Danger Code

13

300

ST

X

[0..0]

00247

Relevant Clinical Information

14

26

TS

X

[0..0]

00248

Specimen Received Date/Time

15

300

SPS

RE

[0.1]

00249

Specimen Source or Segment SPM

16

250

XCN

RE

[0..1]

00226

Ordering Provider

17

250

XTN

X

[0..0]

00250

Order Callback Phone Number

18

60

ST

X

[0..0]

00251

Placer Field 1

19

60

ST

X

[0..0]

00252

Placer Field 2

20

60

ST

X

[0..0]

00253

Filler Field 1

21

60

ST

X

[0..0]

00254

Filler Field 2

22

26

TS

X

[0..0]

00255

Results Rpt/Status Chng – Date/Time

23

40

MOC

X

[0..0]

00256

Charge to Practice

24

10

ID

X

[0..0]

0074

00257

Diagnostic Serv Sect ID

25

1

ID

R

[1..1]

0123

00258

Order Result Status

26

400

PRL

X

[0..0]

00259

Parent Result

27

200

TQ

X

[0..0]

00221

Quantity/Timing

28

250

XCN

X

[0..0]

00260

Result Copies To

00261

Parent00262

Transportation Mode

00263

Reason for Study

29

200

EIP

X

[0..0]

30

20

ID

X

[0..0]

31

250

CE

X

[0..0]

32

200

NDL

C

[0..1]

00264

Principal Result Interpreter

33

200

NDL

X

[0..0]

00265

Assistant Result Interpreter

34

200

NDL

RE

[0..0]

00266

Technician

37

4

NM

X

[0..0]

01028

Number of Sample Containers *

38

250

CE

X

[0..0]

01029

Transport Logistics of Collected Sample

39

250

CE

X

[0..0]

01030

Collector's Comment *

40

250

CE

X

[0..0]

01031

Transport Arrangement Responsibility

41

30

ID

X

[0..0]

0224

01032

Transport Arranged

42

1

ID

X

[0..0]

0225

01033

Escort Required

43

250

CE

X

[0..0]

01034

Planned Patient Transport Comment

44

250

CE

X

[0..0]

0088

00393

Procedure Code

45

250

CE

X

[0..0]

0340

01316

Procedure Code Modifier

46

250

CE

X

[0..0]

0411

01474

Placer Supplemental Service Information

47

250

CE

X

[0..0]

0411

01475

Filler Supplemental Service Information

48

250

CWE

X

[0..0]

0476

01646

Medically Necessary Duplicate Procedure
Reason.

49

2

IS

X

[0..0]

N

01647

Result Handling0124

OBR-4 Universal Service Identifier (CE): This field identifies either a battery (panel) or anindividual test. The first sub-field (the code), and the third (the coding system) are required.
__________________________________________________________________________
65
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
OBR-11 Specimen Action Code (ID): This required field will be valued to ‘O’ (Specimen
obtained by service other than lab).
OBR-15 Specimen source (CM): This field is required if available within LPOCT profile,because the messages of this profile do not embed any SPM segment, given that very little
information is needed on the specimen in point of care testing. This profile applies the POCT1-A
recommendations of use for this field. The following components should be valued:•

1st component: Specimen Source Name or Code (CWE), called “Specimen Type” in
POCT1-A. Codes are given by table 107 in POCT1-A.

•

4th component: Body Site (CWE), called “Location” in POCT1-A. Code are given bytable 108 in POCT1-A.

•

7th component: Specimen Role (CWE), valued to ‘P’ (Patient specimen).

1190

OBR-16 Ordering Provider (XCN): This field is required if available (RE). The POCDM shallvalue it with the ordering physician if it knows this information.
OBR-25 Order Result Status (ID): The set of observations is considered as reviewed (i.e.
technically validated) either automatically or interactively by the POCDM application (called theObservation Reviewer in POCT1-A). Therefore the status shall be valued to “F” (Final results).

1200

OBR-32 Principal Interpreter (NDL): The field identifies who validated (reviewed) the results,
and when this technical validation was performed. It shall be valued if this review has been
performed interactively by a human reviewer using the POCDM actor; in this case only the two
first components are required:•

Name (CNN):o First sub-subcomponent = ID number of the reviewer
o Second sub-component = Family nameo Third component = Given name•Stat Date/Time (TS): Date/Time of the review.

OBR-34 Technician (NDL): The field is required if available (RE). It identifies the operator
who produced the set of observations on the point of care device (the actor POCRG). It also
locates the point of care, room, bed, facility, and dates this production. The following
components are to be valued if the information is known:
1210•

1st component: Name (CNN):o First sub-subcomponent = ID number of the reviewer
o Second sub-component = Family nameo Third component = Given name•

2nd component: Stat Date/Time (TS): Date/Time of the testing.

__________________________________________________________________________
66
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 for Public Comment (June 15 to July 15)______________________________________________________________________________•

4th component: Point Of Care (IS)•5th component: Room (IS)•6th component: Bed (IS)•7th component: Facility (HD)32.6.1.5 Usage of OBX segment
1220

Table Z.6.1.5-3 : OBX Segment
SEQ

LEN

DT

Usage

Card.

TBL#

1

4

SI

R

[1..1]

2

2

ID

R

[0..1]

3

250

CE

R

[1..1]

4

20

ST

X

[0..1]

00572

Observation Sub-ID

5

99999

VariesR[0..1]

00573

Observation Value

6

250

CE

C

[0..1]

00574

Units

7

60

ST

RE

[0..1]

00575

References Range

8

5

IS

RE

[0..1]

00576

Abnormal Flags

9

5

NM

X

[0..0]

00577

Probability

10

2

ID

X

[0..0]

0080

00578

Nature of Abnormal Test

11

1

ID

R

[1..1]

0085

00579

Observation Result Status

12

26

TS

X

[0..0]

00580

Effective Date of Reference Range

13

20

ST

X

[0..1]

00581

User Defined Access Checks

14

26

TS

R

[0..1]

00582

Date/Time of the Observation

0125

0078

ITEM#

Element name00569

Set ID – OBX

00570

Value Type

00571

Observation Identifier

15

250

CE

X

[0..1]

00583

Producer's ID

16

250

XCN

X

[0..1]

00584

Responsible Observer

17

250

CE

RE

[0..1]

00936

Observation Method

18

22

EI

RE

[0..0]

01479

Equipment Instance Identifier

19

26

TS

RE

[0..0]

01480

Date/Time of the Analysis

OBX-1 Set ID - OBX (SI), required. This field contains the sequence number of the OBX,
below the OBR.
OBX-2 Value Type (ID), required.
The Value Type field should be filled according to HL7 Version 2.5 standard (table 0125). For
example, if the result is ">300" the Value Type "SN" (Structured Numeric) SHALL be usedinstead of the "ST" (String) value type that was used in previous versions of HL7. A simple
numeric observation shall be typed “NM”. See the details and the examples in the HL7 V2.5
(7.4.2). For an observation that consists of a time measurement (e.g. bleeding time) the TM
Value Type is preferred to NM but this is not made mandatory.
1230

OBX-3 Observation Identifier (CE), required__________________________________________________________________________
67
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 for Public Comment (June 15 to July 15)______________________________________________________________________________The usage of LOINC(r) test codes for the identification of tests is recommended by IHE. Detailsof this free vocabulary can be found at http://www.loinc.org .
The first and third sub-fields “Identifier”, and “Name of Coding System” are required in alltransactions. The value of the “Name of Coding System” in the case of LOINC is “LN”.
OBX-4 Observation Sub-ID (ST). This field is not used in transaction LAB-32.
OBX-5 Observation Value (varies), required.
OBX-6 Units (CE), conditional.
This field in required if the Value Type field (OBX-2) is valued either with "NM", or "SN". Ifvalued, this field should identify SI or SI-derived units only.
1240

OBX-7 References Range (ST), required if available.
This field should be valued as described in HL7 V2.5 for all observations for which it is relevant.
The References range that figures in this field is supposed to be related to age and sex of thepatient or to other parameters such as number of weeks of pregnancy when applicable, whichmakes the OBX-10 field (nature of abnormal test) unnecessary.
The format of the reference ranges is as follows:
for numeric values in the format:a) lower limit-upper limit (when both lower and upper limits are defined, e.g., forpotassium 3.5 - 4.5)b) > lower limit (if no upper limit, e.g., >10)1250c) < upper limit (if no lower limit, e.g., <15)alphabetical values: the normal value may be reported in this location
Examples of reference ranges:•|3.5-4.5|

•

|>50|

•

|<0.001|•|Non Reactive|

OBX-8 Abnormal Flags (IS), required if available.

1260

This field is required when applicable. This field is not repeatable in the IHE Laboratory
Technical Framework. Among the possible values listed for this field in HL7 table 0078, theactor POCDM should support the following subset:
Table Z.6.1.5-4 : HL7 table 0078
Value
L

Description

Comment

Below low normal__________________________________________________________________________
68
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 for Public Comment (June 15 to July 15)______________________________________________________________________________
Value

Description

H

Above high normal

LL

Below lower panic limits

HH

Above upper panic limits

N

Normal (applies to non-numeric results)A

Abnormal (applies to non-numeric results)

AA

Very abnormal (applies to non-numeric units, analogous to panic limits for numeric units)

Null

No range defined, or normal ranges don't apply

Comment

OBX-11 Observation Result Status (ID), required.
This field should be filled according to HL7 Table 0085 described in Chapter 7 of HL7. Given
that the POCDM sends reviewed observations, the status shall be valued “F”.
OBX-14 Date/Time of the Observation (TS), required if available.
This field should be valued when the OBX-5 field (Value field) is also valued. The observation
date-time is the physiologically relevant date-time or the closest approximation to that date-time.
In the case of tests performed on specimens, the relevant date-time is the specimen’s collection
date-time.
1270

OBX-15 Producer's ID (CE), is not used in transaction LAB-32. The information is given
within field OBR-34 “Technician”.
OBX-16 Responsible Observer (XCN), is not used in transaction LAB-32. The information(common to all the observations of this set) is carried within field OBR-34 “Technician”.
OBX-17 Observation Method (CE), conditional.
Condition predicate: This field is required when the value of the result may be dependant of the
Observation Method and the Observation Identifier does not permit to identify the Method. With
some Observation Identifiers such as LOINC(r) Codes, the identifier also identifies the Method,in which case this field does not need to be valued.

1280

OBX-18 Equipment Instance Identifier (EI), required if available for transaction LAB-32:
Every point of care device (POCRG actor) should be identified by a universally unique identifierin the format specified by IEEE for the EUI-64 identifier. If this EUI-64 identifier is available, it
should be recorded in the ‘universal ID’ component of this field. If it is not available, themanufacturer’s Device identifier (e.g., serial number) should be recorded in ‘universal ID’
component, with the Device or manufacturer name in ‘universal ID type’ component.
OBX-19 Date/Time of the Analysis (TS), is not used in transaction LAB-32. The information(common to all the observations of this set) is given within field OBR-34 “Technician”.

__________________________________________________________________________
69
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 for Public Comment (June 15 to July 15)______________________________________________________________________________

32.6.2 Static definition for ACK^R33: Acknowledgement message
This message sent by the Order Filler to the POCDM is the acknowledgement message for both
ORU^R30 and ORU^R31 messages.
1290

Table 32.6.1-1 : static definition for ACK^R33
Segment

Meaning

Usage

Card.

HL7 chapter

MSH

Message Header

R[1..1]

2

MSA

Message AcknowledgementR[1..1]

2[{ERR}]

Error

C[0..1]

2

32.6.2.1 Usage of MSH segment
The MSH segment has a common definition for all HL7 messages of IHE Laboratory Technical
Framework. This common definition is presented in section 3.1 of L-TF Volume 2. Below are
additional recommendations for the usage of this segment within this acknowledgement:
MSH-9 – Message Type, shall have its three components valued “ACK^R33^ACK”
MSH-15 – Accept Achnowledgement Type, and MSH-16 – Application Acknowledgement
Type are not used, and would be valued “NE” (Never) if they were used: This ACK message
itself, does not wait for any acknowledgement.
32.6.2.2 Usage of MSA segment
1300

Table 0-5: MSA - Message Acknowledgement
SEQ

LEN

DT

Usage

Card.

TBL#
0008

ITEM#

Element name

1

2

ID

R

[1..1]

00018

Acknowledgement code

2

20

ST

R

[1..1]

00010

Message Control Id

3

80

ST

R

[0..0]

00020

Text Message

X[0..0]

00022

Delayed Acknowledgment TypeX

[0..0]

00023

Error Condition

5
6

250

CE

0357

The general specification of use of this segment by the IHE Laboratory Technical Framework is
given in section 3.2 of Volume 2 of this framework. As a reminder, given that the original mode
acknowledgement is in use throughout all IHE domains, field MSA-1 – Acknowledgement code(ID), required, is used as follows:
Table 0-6: HL7 table 0008 - Acknowledgement code
Value

Description

CommentAA

Original mode:
Application Accept

Message accepted and integrated by the receiving application

AE

Original mode:
Application Error

Message contains errors. It SHALL not be sent again without priorcorrection of these errors.

AR

Original mode:
Application Reject

Message rejected by the receiving application. If the rejection is not related
to an invalid value in the MSH segment, the sender may try again later.

__________________________________________________________________________
70
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 for Public Comment (June 15 to July 15)______________________________________________________________________________The particularity of use in the context of the Order Filler acknowledging a POCT observation set
to the POCDM is as follows:
MSA-3 – Text Message (ST), is usage R (required). This field contains the filler order number
sent by the Order Filler to the POCDM.
1310

32.6.2.3 Usage of ERR segment
The usage of this segment is fully described in section 3.3 of Volume 2 of the Laboratory
Technical Framework. The segment is only used in case of error.

32.7 Expected Actions
When receiving an ORU^R30, the Order Filler performs the following sequence of actions:
1. It generates a new order to store this set of point of care observations within.
2. It sends back to the POCDM the acknowledgement message ACK^R33, including thefiller order number.
1320

3. Using Transaction LAB-2 of LSWF profile, the Order Filler propagates this new order to
the Order Placer, and requires a placer order number for it. The placer order number issent back by the Order Placer to the Order Filler.
4. The Order Filler stores the placer order number within the order in its database.
When receiving an ORU^R32, the Order Filler performs the following sequence of actions:
1. It tries to match an existing order in its data base, corresponding to this set ofobservations. The criteria used may depend upon site-defined policies. They should
include the patient, the ordering provider, the facility where the point of care tests was
performed, the date-time of the observations and the ordering provider.
2. If no order can be matched, the Order Filler proceeds as if it had received an ORU^R30(see the sequence of actions above).

1330

3. If an order is matched, the Order Filler stores the results in this order, and acknowledges
the order to the POCDM, sending back the filler order number in the acknowledgement.
4. Using Transaction LAB-1 of LSWF profile, the Order Filler notifies the arrival of the
POCT results to the Order Placer.

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