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

Integrating the Healthcare Enterprise

IHE Laboratory Technical Framework
Supplement 2004-2005

10

Laboratory Code Set Distribution(LCSD)

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 Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________

Foreword
20

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.
The approach employed in the IHE initiative is not to define new integration standards, but rather

30

40

50

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.
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-15Copyright © 2005 GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________
through the identification and correction of errata. The current version for these Technical
Frameworks may be found at www.rsna.org/IHE or http://www.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.

Document production
80

Date:

June 15, 2005

Authors:

Jean-Christophe Cauvin, René Spronk

Introduction
This is a new integration profile which will be added to Volume I of the IHE Laboratory
Technical Framework. Associated with this profile is one new transaction that will be added toVolume II of the IHE Laboratory Technical Framework.

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

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________

Open Issues and Questions
Profile Abstract

90

A set of common codes is generally used by multiple application systems in a laboratory
workflow environment. These common codes need to be synchronized across the various
applications at a given site. In many implementations, one application system will be the author(the "owner") of the code set. The responsibility for managing a code set may also be distributed
among different systems.
This profile provides a way for the owner of a code set (battery, test and observation codes) to
distribute the code set amongst other applications within the enterprise. This profile involves all
dedicated actors currently defined in the Laboratory Scheduled Workflow Integration Profile:
Order Placer, Order Filler, Automation Manager and Order Result Tracker.

GLOSSARY

100

Battery – A set of one or more observations identified as by a single name and code, treated as ashorthand unit for ordering or retrieving results of the constituent observations. A battery can bea single observation, but also a superset of batteries.
Code set - a code set is any set of codes used for encoding data elements, such as tables of terms,
medical concepts, medical diagnosis codes, or medical procedure codes. An example ofinternational code set is LOINCTM (Logical Observation Identifier Names and Codes).
Master File – a common reference file used by one or more application systems. A code set canbe considered as a master file.
Observation – a measurement of a single variable or a single value derived logically and/or
algebraically from other measured or derived values. A test result is an observation.
Test - a medical procedure that involves testing a sample of blood, urine, or other substance fromthe body.

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

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________

Volume I – Integration Profiles

110

Changes to Sections 1 – 1.X
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 or the beginning of the bullet list in section 1.6•

Added the Laboratory Code Set Distribution Profile which provides a way for the owner of acode set (battery, test and observation codes) to distribute it to other applications in theenterprise.

120
Remove section 2.3 Integration Profiles overview
Renumber 2.4 to 2.3

2.4 Actors in Laboratory Technical Framework
Add the following actors at the end of the list defined in section 2.4
Code Set Master: A system which owns (is responsible for the maintenance of) one or several
code sets. This system may also be an Order Filler or an Enterprise Common Repository. Codesets can be sent on a routine basis (e.g. every week) or every time the code set changes. A code
set may contain battery, test and observation codes.
130

Code Set Consumer: A system which receives code sets from Code Set Master(s) and updates
its internal tables to reflect the code set as maintained by the Code Set Master. This system may
also be an Order Placer, an Order Result Tracker, an Automation Manager, or an Order Filler.

X Laboratory Code Set Distribution Integration Profile
A set of common codes is generally used by multiple application systems in a laboratory
workflow environment. These common codes need to be synchronized across the various
applications at a given site. In many implementations, one application system will be the author(the "owner") of the code set. The responsibility for managing a code set may also be distributed
among different systems.
__________________________________________________________________________
4
Rev. 0.1 - 2005-06-15Copyright © 2005 GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________

140

This profile provides a way for the owner of a code set (battery, test and observation codes) tosend the code set to other applications. This profile involves all dedicated actors currently
defined in the Laboratory Scheduled Workflow Integration Profile: Order Placer, Order Filler,
Automation Manager and Order Result Tracker.

X.1 Actors/ Transactions
Figure X.1-1 shows the actors directly involved in the Laboratory Code Set Distribution
Integration Profile and the transaction between them. Other actors that may be indirectly
involved due to their participation in other profiles are not shown.

Code Set Master

Laboratory Code Set Management [LAB-X] ↓Code Set Consumer

150

Figure X.1-1. Laboratory Code Set Distribution Actor Diagram

Table X.1-1 lists the transactions for each actor directly involved in the Laboratory Code Set
Distribution Profile. In order to claim support of this Integration Profile, an implementation must
perform the required transaction (labeled “R”).
Table X.1-1. Laboratory Code Set Distribution Integration Profile - Actors andTransactions
ActorsTransactions

Optionality

Section in
Vol. 2

Code Set Master

Laboratory Code Set Management

R

X.Y

Code Set Consumer

Laboratory Code Set Management

R

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

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________

X.2 Laboratory Code Set Distribution Integration Profile Options
The LCSD profile does not define any optional transactions.
160

X.3 Laboratory Code Set Distribution Process Flow
The Code Set Master manages a set of laboratory codes (battery, test and observation). Three use
cases are identified:Use case 1: the entire code set is sent to subscribing systems. These systems must replace thecurrent code set by the new one. Codes which have been removed from the code set are not to be
used by the receiving system any more. Codes which have been removed should not be deleted
but be flagged as disabled/invalid for backward compatibility reasons. New added codes may be
used from the effective date/time given in the transaction.
170

Use case 2: a single battery, a single test or a single observation is added, removed or changed by
the Code Set Master. The full code set is not sent to the subscribers but only those parts which
describe the changes.
Use case 3: upon receipt of an unknown code, the receiver queries the Code Set Master for thefull details associated with the code.
Use case 1 will be described in this version of the IHE Laboratory Technical Framework. The
other use cases may be added to later versions of this profile.
Code Set Master

Code Set
ConsumerLaboratory Code Set Mgmt [LAB-51]

Figure X.3-1. Basic Process Flow in the Laboratory Code Set Distribution Profile__________________________________________________________________________
6
Rev. 0.1 - 2005-06-15Copyright © 2005 GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________<Appendix A> Actor Summary Definitions
180

Code Set Master: A system which owns (is responsible for the maintenance of) one or several
code sets. This system may also be an Order Filler or an Enterprise Common Repository. Codesets can be distributed on a routine basis (e.g. every week) or every time the code set changes. A
code set may contain battery, test and observation codes.
Code Set Consumer: A system which receives code sets from Code Set Master(s) and updates
its internal tables to reflect the code set as maintained by the Code Set Master. This system may
also be an Order Placer, an Order Result Tracker, an Automation Manager, or an Order Filler.

<Appendix B> Transaction Summary Definitions
LAB-51. Laboratory Code Set Management: Code set distribution (battery, test, observation).

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

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________

Volume 2 - Transactions
190

IHE Transactions
X.Y Laboratory Code Set Management
This section corresponds to Transaction LAB-51 of the IHE Laboratory Technical Framework.
Transaction LAB-51 is used by the Code Set Master and Code Set Consumer actors.
X.Y.1 Scope
This transaction is used by the Code Set Master actor to distribute entire code sets to Code Set
Consumer actors. A code set may contain battery, test and observation codes. This transaction is
initiated on a scheduled based (e.g. weekly) or whenever the organization of the laboratorychanges (e.g. because of the addition/removing of an instrument, specialties).
X.Y.2 Use Case Roles
Code Set
Consumer

Code Set
MasterLaboratory Code
Set Management

200
Figure X.Y.2-1. Use Case Roles for the Laboratory Code Set Management transaction
Actor: Code Set Master
Role: Sends a full code set.
Actor: Code Set Consumer
Role: Receives a code set, and notifies the Code Set Master of its acceptance or refusal.
X.Y.3 Referenced Standard
HL7 2.5 Chapter 8 (Master Files)
X.Y.4 Interaction Diagram
210

The interaction diagram shows the flow of message between a Code Set Master and a Code Set
Consumer. Four messages are defined for this transaction:__________________________________________________________________________
8
Rev. 0.1 - 2005-06-15Copyright © 2005 GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________•

MFN^M08 – Master File Notification – Test/Observation (Numeric). This message isused for codes related to individual tests with numeric results. This message should not
be used for battery or profile definitions. If the result of the test is a formulaic expression(a calculation) of other tests, MFN^M11 should be used instead of this message.

•

MFN^M09 – Master File Notification – Test/Observation (Categorical). This message isused for codes related to individual tests with results that are NOT numeric. This message
should not be used for battery or profile definitions. If the result of the test is a formulaic
expression of other tests, MFN^M11 should be used instead of this message•

MFN^M10 – Master File Notification – Test/Observation Batteries. This message is used
for codes that identify batteries or profiles. This message should not be used to forindividual tests.

•

MFN^M11 – Master File Notification – Test/Calculated Observations. This message isused for codes related to individual tests with calculated results. This message should not
be used for battery or profile definitions.

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

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________
Code Set
Consumer

Code Set
Master

MFN^M08 – Master File Notification –Test/Observation (Numeric)Replace current version of the code set
by the set contained in the message

MFK^M08 – acknowledgment

MFN^M09 – Master File Notification –Test/Observation (Categorical)
MFK^M09 – acknowledgment

MFN^M10 – Master File Notification –Test/Observation Batteries
MFK^M10 – acknowledgment

MFN^M11 – Master File Notification –Test/Calculated Observations
MFK^M11 – acknowledgment

In order to simplify the management of observation codes (OBX-3) and battery codes (OBR-4),
the MFN^M08, MFN^M09 and MFN^M11 messages will be used to distribute observation
codes only (OBX-3), and MFN^M10 will be used to distribute battery codes (OBR-4).
230

In order to fully synchronize the code sets between the Code Set Master and the Code Set
Consumer 4 messages will have to be sent, each of which conveys the definition of part of theoverall laboratory code set. The definitions of atomic tests shall be sent (M08, M09) before thedefinitions of calculated tests or batteries (M10, M11).
X.Y.4.1 Master File Notification – Test/Observation (Numeric)This message is used to transmit observation codes, i.e. codes sent in the OBX-3 field(Observation Identifier). Observations must have continuous values (data of type numeric, date,or time stamp).
__________________________________________________________________________
10
Rev. 0.1 - 2005-06-15Copyright © 2005 GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________
X.Y.4.1.1 Trigger Events
MFN^M08 – the Code Set Master sends a full set of observation codes.
240

X.Y.4.1.2 Message Semantics
HL7 2.5 Chapter 8 MFN^M08 message. Refer to HL7 Standard for general message semantics.
The OM2 segment can be used to transport the Units of Measure if necessary.
Table X.Y.4.1-1. MFN^M08 static definition
Segment

Meaning

MSH
MFI
{
MFE
OM1
[OM2]
[OM4]
}

Message Header
Master File Identification--- MASTER FILE ENTRY begin
Master File Entry
General Segment
Numeric Observation Segment
Observations that Require Specimens--- MASTER FILE ENTRY end

Usage

Card.

HL7

R
R
R
R
R
O
O

[1..1][1..1][1..*][1..1][1..1][0..1][0..1]

2
8
8
8
8
8
8

A description of the usage of the MSH is contained in section 3.1 of the IHE Laboratory
Technical Framework, Volume II.
X.Y.4.1.2.1 MFI – Master File Identification
250

Table X.Y.4.1-2. MFI – Master File Identification
SEQ

LEN

DT

Usage

Card.

TBL#

ITEM#

Element name

1
2
3
4
5
6

250
180
3
26
26
2

CE
HD
ID
TS
TS
ID

R
R
R
O
R
R

[1..1][1..1][1..1][0..1][1..1][1..1]

0175

00658
00659
00660
00661
00662
00663

Master File Identifier
Master File Application IdentifierFile-Level Event CodeEntered Date/Time
Effective Date/Time
Response Level Code

0178

0179

MFI-1 Master File Identifier (CE), required, shall contain the value OMA (Numerical
Observation Master File).
MFI-2 Master File Application Identifier (HD), required, contains a code of up to 180
characters which uniquely identifies the application responsible for maintaining this file at aparticular site.

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

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________The value of this field shall be formatted by concatenating the values below using the “_”(underscore) character as a separator:•

the name of the application that owns the code set. This shall be equal to the value of the
field MSH-3 Sending Application.

•

the type of master file. This shall be equal to the value of the field MFI-1 Master File
Identifier.

•the language of the (textual descriptions of the) code set. This shall be equal to the value
contained in the field MSH-19 Principal Language of the Message.

•(optional, if applicable) the version/revision of the code set. The character string used to
identify a new version or revision should sort to be alphabetically “later” when compared
to any previous versions or revisions.

260

270

The resulting identifier will have the form “SENDINGAPP_MFTYPE_LANGUAGE” or“SENDINGAPP_MFTYPE_LANGUAGE_VERSION”. The receiver should not attempt todeconstruct this string into its constituent elements; it should use the identifying string in its
entirety. With the exception of version/revision all elements are available elsewhere in themessage.
Examples include “Lab1_OMA_EN_1.2” or “X-PAS_OMB_FR”.
MFI-3 File-Level Event Code (ID), required, shall contain the value REP (replace current
version of this master file with the version contained in this message).

280

MFI-5 Effective Date/Time (TS), required, contains the date/time the Code Set Master expects
that the event is to have been completed on the receiving system. The sending system should use
the current date/time as a default. The Code Set Consumer shall process the event as soon as
possible if the value of this field is in the past. If the value of this field is at some point in the
future, then the Code Set Consumer shall process the event before that time.
MFI-6 Response Level Code (ID), required, shall contain the value ER. The acceptance statusof the individual master file entries is only to be reported in case of an error. Since the IHE
Laboratory Technical Framework uses the HL7 original acknowledgment mode, all MFA
segments must be returned via the application-level acknowledgment message.
X.Y.4.1.2.2 MFE – Master File Entry Segment
Table X.Y.4.1-3. MFE – Master File Entry Segment
SEQ

LEN

DT

Usage

Card.

TBL#

ITEM#

Element name

1
2
3
4
5

3
20
26
200
3

ID
ST
TS
Varies
ID

R
R
O
R
R

[1..1][1..1][0..1][1..1][1..1]

0180

00664
00665
00662
00667
01319

Record-Level Event Code
MFN Control ID
Effective Date/Time
Primary Key Value – MFE
Primary Key Value Type0355__________________________________________________________________________
12
Rev. 0.1 - 2005-06-15Copyright © 2005 GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________

290

MFE-1 Record-Level Event Code (ID), required, shall contain the value MAD (add record tomaster file). Given that the file-level event code is REP, each MFE segment must have a recordlevel event code of MAD.
MFE-2 MFN Control ID (ST) is required since the response level code is ER. It contains an
identifier that uniquely identifies the change to the record.
MFE-4 Primary Key Value – MFE, required, uniquely identifies a record of the code set. The
data type of this field is CE (coded element). One unique identifier shall be provided; the last 3
components of the CE data type shall not be valued.
MFE-5 Primary Key Value Type (ID), required, contains the value CE (coded element).
X.Y.4.1.2.3 OM1 – General Segment

300

Table X.Y.4.1-4. OM1 – General Segment
SEQ

LEN

DT

Usage

Card.

1

4

NM

R

[1..1]

TBL#

00586

Sequence Number Test/Observation Master File

2

250

CE

R

[1..1]

00587

Producer'sService/Test/Observation ID

3
4
5

12
1
250

ID
ID
CE

Permitted Data Types

250

CE

[0..*][1..1][1..1][0..*]

00588

7

O
R
R
O

8
18

200
1

ST
IS

R
R

[1..*][1..1]

19
20

250
20

CE
ST

RE
RE

[0..1][0..1]

0125
0136

ITEM#

Element name00589

Specimen Required

00590

Producer ID

00592

Other Service/Test/Observation
IDs for the Observation

00593

Other Names

0174

00603

Nature ofService/Test/Observation

99999

00604

Report Subheader

00605

Report Display order

OM1-1 Sequence Number – Test/Observation Master File (NM), required, shall contain asequence number from 1 to n (number of records).
OM1-2 MFN Producer’s Service/Test/Observation ID (CE) is required. Only the first threesub-fields (Identifier, Text and Name of Coding System) are required. The last 3 components of
the CE data type shall not be valued.
OM1-3 Permitted Data Types (ID), optional, should contain numerical, date or time stamp datatypes.
310

OM1-4 Specimen Required (ID), required, contain the value Y if one or more specimen are
required to obtain this observation, and N if a specimen is not required.
__________________________________________________________________________
13
Rev. 0.1 - 2005-06-15Copyright © 2005 GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________
OM1-5 Producer ID (CE), required, uniquely identifies the service producing the observation.
Only the first three sub-fields (Identifier, Text and Name of Coding System) are required.
OM1-7 Other Service/Test/Observation IDs for the Observation (CE) is optional andrepeating. It can be used to send mapped/translated codes to the destination system. This field
can be used to convey the mapping of local codes to reference code sets such as LOINC or
SNOMED CT.
OM1-8 Other Names (CE), required, contains aliases or synonyms for the name in the context
of the Order Placer. By default, this field can contain the same value as OM1-2 (2nd sub-field).
320

OM1-18 Nature of Service/Test/Observation (IS), required, contains the value A (atomic
observation).
OM1-19 Report Subheader (CE), required if known, contains an optional string that defines
the preferred header under which this observation should be listed on a standard display.
OM1-20 Report Display Order (ST), required if known, contains an optional string that defines
the absolute sort order in which this observation is presented in a standard report or display that
contains the many observations.
X.Y.4.1.2.4 OM2 – Numeric Observation Segment
Table X.Y.4.1-5. OM2 – Numeric Observation Segment

330

SEQ

LEN

DT

Usage

Card.

2
3

250

CE

10

NM

250

RFR

R
RE
O

[1..1][0..*][0..*]

6

TBL#

ITEM#

Element name00627

Units of Measure

00628

Range of Decimal Precision

00631

Reference (Normal) Range For
Ordinal And Continuous
Observations

OM2-2 Units of Measure (CE), required. Used only if the test contained in OM1 has numeric
results. Contains the customary units of measure for the test.
OM2-3 Range of Decimal Precision (NM), required if known. Used only if the test contained in
OM1 has numeric results. Specifies the total length in characters of the field needed to display
the observation, and the number of digits displayed to the right of the decimal point. This iscoded as a single number in the format <length>.<decimal-digits>. For example, a value of 6.2
implies 6 characters total (including the sign and decimal point) with 2 digits after the decimal
point. For integer values, the period and <decimal-digits> portion may be omitted (that is, 5.0
and 5 are equivalent). More than one such mask may be transmitted (separated by repeat
delimiters) when it is necessary to define possible multiple display formats.

340

OM2-6 Reference (Normal) Range for Ordinal and Continuous Observations, Optional.
This field contains the reference (normal) ranges for "numeric" observations/tests with a naturecode of A or C (see OM1-18 - Nature of Service/Test/Observation). The use of this field is
discouraged (but not forbidden) by IHE. This field can identify different reference (normal)__________________________________________________________________________
14
Rev. 0.1 - 2005-06-15Copyright © 2005 GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________
ranges for different categories of patients according to age, sex, race, and other patient
conditions. Reference (normal) ranges however also depend on the Analyzer being used, a factor
which isn’t included in this field. Without having knowledge of the Analyzer generic statements
about reference ranges may be clinically misleading and dangerous.
X.Y.4.1.2.5 OM4 – Observations that Require Specimens

350

The OM4 segment is used to convey information related to the (collection of) specimen required
for the test/battery. This information can be used by Order Placers (e.g. at the ward) to collect the
specimen.
Table X.Y.4.1-6. OM4 – Observations that Require Specimens
SEQ

LEN

DT

Usage

Card.

R
O

[1..1]

00643

Container Description[0..1]

00646

Specimen

3

60

TX

6

250

CE

TBL#

ITEM#

Element name

OM4-3 Container Description (TX), required. Used only if OM1-4 contains “Y”; contains atextual description of the type of container used for collection of the sample, e.g. “Red capped
tube #2”.
OM4-6 Specimen (CE), optional. See SPM-4 for additional information. The actor shall use one
and the same vocabulary table for OM4-6 and SPM-4 if the Code Set Master is also an Order
Filler actor.
X.Y.4.1.3 Expected Actions
360

The Code Set Consumer must replace its corresponding code set by the received code set.
Codes which have been removed from the code set are not to be used by the receiving system
any more, from the effective date/time given in the message. Codes which have been removed
should not be deleted but be flagged as disabled/invalid for backward compatibility reasons. New
added codes are usable from the effective date/time given in the message.
X.Y.4.2 Master File Notification – Test/Observation (Categorical)
This message is used to transmit the code of observations where the value is free text and othernon-numeric data types.
X.Y.4.2.1 Trigger Events
MFN^M09 – the Code Set Master sends a full set of non-numeric observation codes.

370

X.Y.4.2.2 Message Semantics
HL7 2.5 Chapter 8 MFN^M09 message. Refer to HL7 Standard for general message semantics.
The construction of the message is roughly the same as MFN^M08. The OM3 segment can be__________________________________________________________________________
15
Rev. 0.1 - 2005-06-15Copyright © 2005 GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________
used to transmit categorical results for a test (such a “high”/“low”, or “reactive”/”unreactive”/”transactive”) or to indicate a vocabulary for the results (e.g. SNOMED).
Table X.Y.4.2-1. MFN^M09 static definition
Segment
MSH
MFI
{
MFE
OM1
[
OM3
[{OM4}]]}

Meaning
Message Header
Master File Identification--- MASTER FILE ENTRY begin
Master File Entry
General Segment--- MF_TEST_CAT_DETAIL begin
Categorical Service/Test/Observation Segment
Observations that Require Specimens--- MF_TEST_CAT_DETAIL end--- MASTER FILE ENTRY end

Usage

Card.

HL7

R
R
R
R
R
O
R
O

[1..1][1..1][1..*][1..1][1..1][0..1][1..1][0..*]

2
8
8
8
8
8
8
8

X.Y.4.2.2.1 MFI – Master File Identification
380

Refer to X.Y.4.1.2.1 for the construction of this segment. The difference with the MFI segmentof a MFN^M08 message is:
MFI-1 Master File Identifier (CE), required, shall contain the value OMB (Categorical
Observation Master File).
X.Y.4.2.2.2 MFE – Master File Entry Segment
Refer to X.Y.4.1.2.2 for the construction of this segment. There is no difference with the MFE
segment of a MFN^M08 message.
X.Y.4.2.2.3 OM1 – General Segment
Refer to X.Y.4.1.2.3 for the construction of this segment. The difference with the OM1 segmentof a MFN^M08 message is:390

OM1-3 Permitted Data Types (ID), optional, should contain data types other than numerical,
date or time stamp.
X.Y.4.2.2.4 OM4 – Observations that Require Specimens
Refer to X.Y.4.1.2.5 for the construction of this segment. There is no difference with the OM4
segment of a MFN^M08 message.

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

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________
X.Y.4.2.3 Expected Actions

400

The Code Set Consumer must replace its corresponding code set by the received code set. .
Codes which have been removed from the code set are not to be used by the receiving system
any more from the effective date/time given in the message. Codes which have been removed
should not be deleted but be flagged as disabled/invalid for backward compatibility reasons. New
added codes are usable from the effective date/time given in the message.
X.Y.4.3 Master File Notification – Test/Observation BatteriesThis message is used to transmit battery codes, i.e. codes sent in the OBR-4 field (Universal
Service Identifier).
X.Y.4.3.1 Trigger Events
MFN^M10 – the Code Set Master sends a full set of battery codes.
X.Y.4.3.2 Message Semantics
HL7 2.5 Chapter 8 MFN^M10 message. Refer to HL7 Standard for general message semantics.
The construction of the message is roughly the same as MFN^M08.

410

Table X.Y.4.3-1. MFN^M10 static definition
Segment
MSH
MFI
{
MFE
OM1
[
OM5
[{OM4}]]}

Meaning
Message Header
Master File Identification--- MASTER FILE ENTRY begin
Master File Entry
General Segment--- MF_TEST_BATT_DETAIL begin
Observation Batteries
Observations that Require Specimens--- MF_TEST_BATT_DETAIL end--- MASTER FILE ENTRY end

Usage

Card.

HL7

R
R
R
R
R
RE
R
O

[1..1][1..1][1..*][1..1][1..1][0..1][1..1][0..*]

2
8
8
8
8
8
8
8

X.Y.4.3.2.1 MFI – Master File Identification
Refer to X.Y.4.1.2.1 for the construction of this segment. The difference with the MFI segmentof a MFN^M08 message is:
MFI-1 Master File Identifier (CE), required, shall contain the value OMC (Observation
Batteries Master File).

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

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________
X.Y.4.3.2.2 MFE – Master File Entry Segment
Refer to X.Y.4.1.2.2 for the construction of this segment. There is no difference with the MFE
segment of a MFN^M08 message.
420

X.Y.4.3.2.3 OM1 – General Segment
Refer to X.Y.4.1.2.3 for the construction of this segment. The difference with the OM1 segmentof a MFN^M08 message is:
OM1-18 Nature of Service/Test/Observation (IS), required, contains the value P (battery
consisting of one or many independent atomic observations), F (functional procedure) and S(superset of batteries or procedure ordered under a single code unit).
X.Y.4.3.2.4 OM5 – Observation Batteries
Table X.Y.4.3.2-1. OM5 – Observation Batteries
SEQ

LEN

DT

Usage

Card.

2

250

CE

R

[1..*]

TBL#

ITEM#

Element name00655

Test/Observations Included
within an Ordered Test Battery

OM5-2 Test/Observations Included within an Ordered Test Battery, required, contains thecodes and names of all tests/observations included within a single battery.
430

If the OM1 segment defined serum electrolytes, this field might look like the following:
84132^potassium^AS4~84295^sodium^AS4~82435^chloride^AS4~82374^HCO3^^AS4
X.Y.4.3.2.5 OM4 – Observations that Require Specimens
Refer to X.Y.4.1.2.5 for the construction of this segment. There is no difference with the OM4
segment of a MFN^M08 message.

X.Y.4.3.3 Expected Actions

440

The Code Set Consumer must replace its corresponding code set by the received code set. .
Codes which have been removed from the code set are not to be used by the receiving system
any more from the effective date/time given in the message. Codes which have been removed
should not be deleted but be flagged as disabled/invalid for backward compatibility reasons. New
added codes are usable from the effective date/time given in the message.
X.Y.4.4 Master File Notification – Test/Calculated Observation
This message is used to transmit the code of observations where the value is derived from one ormore quantities or direct observations.

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

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________
X.Y.4.4.1 Trigger Events
MFN^M11 – the Code Set Master sends a full set of calculated observation codes.
X.Y.4.4.2 Message Semantics

450

HL7 2.5 Chapter 8 MFN^M11 message. Refer to HL7 Standard for general message semantics.
The construction of the message is roughly the same as MFN^M08. The OM6 segment can beused to detail the rule or formula used to determine the value of the test. The OM2 segment canbe used to specify the units of measure if the formula results in a numeric value.
Table X.Y.4.4-1. MFN^M11 static definition
Segment
MSH
MFI
{
MFE
OM1
[
OM6
OM2
]
}

Meaning

Usage

Card.

HL7

Message Header
Master File Identification--- MASTER FILE ENTRY begin
Master File Entry
General Segment

R
R
R
R
R

[1..1][1..1][1..*][1..1][1..1]

288
88Observation calculated from other observations
Numeric Observation Segment

OO[0..1][0..1]

8
8--- MASTER FILE ENTRY end

X.Y.4.4.2.1 MFI – Master File Identification
Refer to X.Y.4.1.2.1 for the construction of this segment. The difference with the MFI segmentof a MFN^M08 message is:
MFI-1 Master File Identifier (CE), required, shall contain the value OMD (CalculatedObservations Master File).
460

X.Y.4.4.2.2 MFE – Master File Entry Segment
Refer to X.Y.4.1.2.2 for the construction of this segment. There is no difference with the MFE
segment of a MFN^M08 message.
X.Y.4.4.2.3 OM1 – General Segment
Refer to X.Y.4.1.2.3 for the construction of this segment. The difference with the OM1 segmentof a MFN^M08 message is:
OM1-18 Nature of Service/Test/Observation (IS), required, contains the value C (single
observation calculated via a rule or formula from other independent observations).
__________________________________________________________________________
19
Rev. 0.1 - 2005-06-15Copyright © 2005 GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________
X.Y.4.4.3 Expected Actions
470

The Code Set Consumer must replace its corresponding code set by the received code set. .
Codes which have been removed from the code set are not to be used by the receiving system
any more from the effective date/time given in the message. Codes which have been removed
should not be deleted but be flagged as disabled/invalid for backward compatibility reasons. New
added codes are usable from the effective date/time given in the message.
X.Y.4.5 Acknowledge Mode
Applications that receive HL7 messages defined in the IHE Laboratory Technical Framework
shall send acknowledgements using the HL7 original acknowledgement mode. The Master File
Application Acknowledgment message is defined in HL7 2.5 Chapter 8. The structure of theacknowledgement messages is the same for all acknowledgements:

480

Table X.Y.4-5. MFK^M08, MFK^M09, MFK^M10, MFK^M11 static definition
Segment

MeaningMSH
MSA[{ERR}]
MFI
{
MFA
}

Message Header
Acknowledgment
Error
Master File Identification--- MASTER FILE ENTRY begin
Master File ACK Segment--- MASTER FILE ENTRY end

Usage

Card.

HL7

R
R
C
R
C
R

[1..1][1..1][1..1][1..1][0..*][1..1]

2
2
2
8
8
8

The construction of MSH, MSA and ERR segments is defined in section 3.1 of the IHE
Laboratory Technical Framework, Volume II. The ERR segment shall be used in case ofnegative acknowledgement, i.e. when the receiving application sends an error on one Master Fileentry.
The MASTER FILE ENTRY segment group is conditional upon the presence of errors (see thedescription of field MFI-6). The segment group shall only be populated with MFA Segment for
those master file entries that could NOT be accepted. If the entire batch can be accepted by thereceiver then the acknowledgement message shall not contain any MFA segments.
490

X.Y.4.5.1 MFA - Master File Acknowledgement Segment
The MFA – Master File Acknowledgment segment is defined in the following table.
Table X.Y.4.5-1. MFA – Master File Acknowledgment Segment
SEQ

LEN

DT

Usage

Card.

TBL#

ITEM#

Element name

1

3

ID

R

[1..1]

0180

00664

Record-Level Event Code__________________________________________________________________________
20
Rev. 0.1 - 2005-06-15Copyright © 2005 GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________
SEQ

LEN

DT

Usage

Card.

2
3
4
5
6

20
26
250
250
3

ST
TS
CE
CE
ID

R
O
R
R
R

[1..1][0..1][1..1][1..1][1..1]

TBL#

ITEM#

Element name

0181

00665
00668
00669
01308
01320

MFN Control ID
Event Completion Date/Time
MFN Record Level Error ReturnPrimary Key Value - MFA
Primary Key Value Type - MFA

0355

MFA-1 Record-Level Event Code (ID), required, shall contain the value MAD (add record tomaster file).
MFA-2 MFN Control ID (ST) is required and contains an identifier that uniquely identifies thechange to the record.
500

MFA-4 MFN Record Level Error Return (CE), required, contains the status of the requested
update. The actors of IHE Laboratory Technical Framework should support the following values:
Table X.Y.4-3. MFN record-level error return
Value

Description

S

Successful posting of the record defined by the MFE segment

U

Unsuccessful posting of the record defined by the MFE segment

MFA-5 Primary Key Value – MFA, required, uniquely identifies a record of the code set. It
contains the same value as MFE-4.
MFA-6 Primary Key Value Type - MFA (ID), required, contains the value CE (coded
element).

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

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________

X.Y.5 Examples
This section contains a number of examples for the messages defined in the LCSD profile.
510
X.Y.5.1 Example 1: Numeric Observations
The message below is a Dutch (NLD) language example containing a master file definition for
numeric tests. The master file has the version ID “1.2”. The (optional) OM4 segment defines thetype of container (e.g. “stolbuis rode dop4” = red capped blood tube #4) and specimen type(e.g. “BLDV^volbloed” = venous blood) which is associated with a test. This information isused by the OP in those cases where the OP is responsible for collecting the sample.
MSH|^~\&|OF|LabSystem|OP||20050205094510||MFN^M08^MFN_M08|2106|2.5|||NLD|8859/1|NL|
MFI|OMA|OF_OMA_NL_1.2|REP|||ER|

520

MFE|MAD|1846||1846^CREABL/Creatinine^L|CE|
OM1|1|1846^CREABL/Creatinine^L|NM|Y|K231^Klinisch Chemisch
Laboratorium^L|||Creatinine||||||||||A|
OM2|1|umol/l|6.0||
OM4|1||stolbuis rode dop4||ml|BLDV^volbloed^HL70487|
MFE|MAD|1848||1848^CREAUV/Creatinine^L|CE|
OM1|2|1848^CREAUV/Creatinine^L|NM|Y|K231^Klinisch Chemisch
Laboratorium^L|||Creatinine||||||||||A|
OM2|2|mmol/l|6.0||
OM4|2||24-uurs bokaal|||UR^urine^HL70487|

530

MFE|…. (other master file entries not shown)

Response message:
Note that those additions that are successful are not explicitly acknowledged. Each OM1
segments that is problematic to the receiver causes a MFA segment to be present in theacknowledgement message. In this example, all updates are accepted except for 1848.
MSH|^~\&|OP||OF|LabSystem|20050205094520||MFK^M08^MFK_M01|234443|2.5|||NLD|8859/1|NL|
MSA|AA|2106|
MFI|OMA|OF_OMA_NL_1.2|REP|||ER|

540

MFA|MAD|1848||U^Duplicate ID|1848^CREAUV/Creatinine^L|CE__________________________________________________________________________
22
Rev. 0.1 - 2005-06-15Copyright © 2005 GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy

IHE Laboratory Technical Framework Supplement - Profile Draft______________________________________________________________________________
X.Y.5.2 Example 2: Calculated Observation
The message below is a Dutch (NLD) language example containing a master file definition for
calculated numeric tests. The calculation algorithm is shown (in textual form) in the OM6segment.
MSH|^~\&|OF|LabSystem|OP||20050205094520||MFN^M11^MFN_M11|2107|2.5|||NLD|8859/1|NL|
MFI|OMD|OF_OMD_NL_1.1|REP|||ER|
MFE|MAD|1849||1849^CLEA/Creatinine clearance^L|CE

550

OM1|1|1849^CLEA/Creatinine clearance^L|NM|Y|K231^Klinisch Chemisch
Laboratorium^L|||Creatinine clearance||||||||||C|
OM6|1|(CREAUV * HOEV) / (CREASE * 1440)
OM2|1|ml/min|4.0||
MFE|…. (other master file entries not shown)

Response message:
The entire contents of the message are accepted.
MSH|^~\&|OP||OF|LabSystem|20050205094530||MFK^M11^MFK_M01|234450|2.5|||NLD|8859/1|NL|

560

MSA|AA|2107|
MFI|OMD|OF_OMD_NL_1.1|REP|||ER|__________________________________________________________________________
23
Rev. 0.1 - 2005-06-15Copyright © 2005 GMSIH/HL7 France H’/HL7 Germany/IHE-J/JAHIS/SFIL/IHE Italy