Chapter Chair: |
Mark
Shafarman |
Editor: |
Klaus
D. Veil |
Additional Editor: |
Jim
Kingsland |
The
content of this chapter is "owned" by various Technical Committees as listed
below:
Steward Committee |
Message |
Segment |
Control/Query |
M01 |
MFI, MFE, MFA |
PAFM |
M04, M05 |
LOC, LCH, LRL, LDP, LCH, LCC, CDM, PRC |
Personnel Management |
M02 |
STF, PRA, ORG |
Orders/Observations |
M03, M08, M09, M10, M11, M12 |
OM1, OM2, OM3 , OM4, OM5, OM6, OM7 |
Orders/Observations (Clinical Trials) |
M06, M07 |
CM0, CM1, CM2 |
In
an open-architecture healthcare environment there often exists a set of common
reference files used by one or more application systems. Such files are called
master files. Some common examples of master files in the healthcare
environment include:
a) staff and health practitioner master file
b) system user (and password) master file
c) location (census and clinic) master file
d) device type and location (e.g., workstations, terminals, printers, etc.)
e) lab test definition file
f) exam code (radiology) definition file
g) charge master file
h) patient status master
i) patient type master
j) service item master file
These common reference files need to be synchronized across the various
applications at a given site. The Master Files Notification message provides a
way of maintaining this synchronization by specifying a standard for the
transmission of this data between applications.
In many implementations, one application system will "own" a particular master
file such as the staff and practitioner master file. The changes (e.g., adds,
deletes, updates) to this file are made available to various other applications
on a routine basis. The Master Files Notification message supports this common
case, but also supports the situation where an application not "owning" a
particular master file, transmits update information to other systems (usually
to the "owning" system), for review and possible inclusion.
The Master Files Notification message supports the distribution of changes to
various master files between systems in either online or batch modes, and
allows the use of either original or enhanced acknowledgment modes, as well as
providing for a delayed application acknowledgment mode. These messages use
the MSH segment to pass the basic event code (master files notification or
acknowledgment). The MFI (master file identification) segment identifies the
master file being updated as well as the initial and requested dates for
"file-level" events (such as "replace file"). For each record being changed,
the MFE (Master File Entry) segment carries the record-level event code (such
as add, update, etc.), the initial and requested dates for the event, and the
record-level key identifying the entry in the master file. The MFA (master
file acknowledgment) segment returns record-specific acknowledgment
information.
Note: The MFE segment is not the master file record, but only
specifies its identifier, event, and event dates. The master file record so
identified is contained in either Z-segments or HL7-defined segments
immediately following the MFE segment. This record may be either a flat record
contained in a single segment, or a complex record needing more than a single
segment to carry its data and (usually hierarchical) structure.
The master file segments commonly needed across HL7 applications as well as
those specific to the various application chapters, are defined in Sections
8.7, "STAFF AND PRACTITIONER MASTER FILES," through 8.11, "SERVICE ITEM MASTER
FILES," of this chapter.
A given master files message concerns only a single master file. However, the
provision of a record-level event code (and requested activation date) on the
MFE and the MFA segments allows a single message to contain several types of
changes (events) to that file.
The Master Files Notification events do not specify whether the receiving
system must support an automated change of the master file in question, nor do
they specify whether the receiving system must create a file in the same form
as that maintained on the sending system.
In general, the way in which the receiving system processes the change
notification message will depend on both the design of the receiving system and
the requirements negotiated at the site. Some systems and/or sites may specify
a manual review of all changes to a particular master file. Some may specify a
totally automated process. Not every system at every site will need all the
fields contained in the master file segment(s) following the MFE segment for a
particular master file entry.
This also means that an application acknowledgment (or a deferred application
acknowledgment) from a receiving system that it changed a particular record in
its version of the master file does not imply that the receiving system now has
an exact copy of the information and state that is on the sending system: it
means only that whatever subset of that master file's data (and state) that has
been negotiated at the site is kept on the receiving system in such a manner
that a new Master Files Notification transaction with the same primary key can
be applied unambiguously (in the manner negotiated at the site) to that subset
of information.
The
Master Files Change Notification message can be used for the following
message-level trigger events:
Mnn: A message containing notifications of changes to a single master file.
nn defines a particular HL7 master file. Currently-defined values are (see
HL7 table 0003 - Event type): M01 - master file not otherwise
specified (for backward compatibility only); M02 -
staff/practitioner master file; M03 - service/test/observation master file
(for backward compatibility only); M04 - charge description
master file; M05 - location master file; M06 - clinical study master file; M08
- M12 - service/text/observation master file; M13 - M99 - reserved for future
HL7-defined master files. Site-specific master files should use a code of the
form Znn. (See also Section 8.5.1.0, MFI field definitions.)
A MFN message may contain the following "file-level" events, as specified in
the MFI segment:
REP: Replace current version of this master file with the version contained in
this message.
UPD: Change file records as defined in the record-level event codes for each
record that follows.
These are the only file-level events currently defined. REP means that every
MFE segment that follows will use the MAD event code.
The replace option allows the sending system to replace a file without sending
delete record-level events for each record in that file. UPD means that the
events are defined according to the record-level event code contained in each
MFE segment in that message.
An MFN message may contain the following "record-level" events, as specified in
the MFE segments.
MAD: Add record to master file.
MDL: Delete record from master file.
MUP: Update record for master file.
MDC: Deactivate: discontinue using record in master file, but do not delete
from database.
MAC: Reactivate deactivated record.
The MFD transaction is used for the following trigger event:
MFA: Master Files Delayed Application Acknowledgment.
The following messages are defined for master files transactions: MFN, master files notification; MFK, master files application acknowledgment; MFD, master files delayed application acknowledgment; and MFQ, master files query.
The
MFN transaction is defined as follows:
MFN^M01-M06^MFN_M01 |
Master File Notification |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MFI |
Master File Identification |
8 |
{MFE |
Master File Entry |
8 |
[Z..] } |
One or more HL7 and/or Z-segments carrying the data for the entry identified in the MFE segment |
(varies) |
MFK^M01-M06^MFK_M01 |
Master File Application Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
MFI |
Master File Identification |
8 |
{ [MFA] } |
Master file ACK segment |
8 |
The
master file record identified by the MFE segment is contained in either
Z-segments and/or HL7-defined segments immediately following the MFE segment,
and is denoted by "Z..." in the MFN abstract message definition given above.
This record may be either a flat record contained in a single segment, or a
complex record needing more than a single segment to carry its data and
(usually hierarchical) structure.
The master file record "[Z..]" identified by the MFE segment is optional
(indicated by square brackets) in the single case where the master file is a
simple one which contains only a key and the text value of that key. For this
case only, both values may be carried in MFE-4 - primary key
value.
Note: If the file-level event code is "REP" (replace file), then each
MFA segment must have a record-level event code of "MAD" (add record to master
file).
The MFK message is used for an application acknowledgment in either the
original or enhanced acknowledgment modes.
The MFA segment carries acknowledgment information for the corresponding MFE
segment (identified by MFA-5-primary key value).
The
MFD transaction is the delayed application acknowledgment. It can be used to
return "deferred" application-level acknowledgment statuses at the MFE level,
without reference to the original MFN message. It is defined as follows:
MFD^MFA^MFD_MFA |
Master File Delayed Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MFI |
Master File Identification |
8 |
{ [MFA] } |
Master file ACK segment |
8 |
ACK^MFA^ACK |
General Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
The
MFQ transaction allows a system to query for a particular record or group
records (defined by the primary key) in a particular master file.
The Master files query is defined as follows:
MFQ^M01-M06^MFQ_M01 |
Query for Master File Record |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
QRD |
Query Definition |
5 |
[QRF] |
Query Filter |
5 |
[DSC] |
Continuation |
2 |
MFR^M01-M06^MFR_M01 |
Master Files Response |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Acknowledgment |
2 |
[ ERR ] |
Error |
2 |
[QAK] |
Query Acknowledgment |
5 |
QRD |
Query Definition |
5 |
[QRF] |
Query Filter |
5 |
MFI |
Master File Name |
8 |
{MFE |
Master File Entry |
8 |
[Z..] } |
One or more HL7 and/or Z-segments carrying the data for the entry identified in the MFE segment. |
(varies) |
[DSC] |
Continuation |
2 |
The value "MFQ" of the QRD-what subject filter of the QRD segment identifies a master files query. The QRD-what department data code of the QRD segment identifies the name of the master file in question. The QRD-what data code value qual of the QRD segment identifies the primary key (or keys, or range of keys) defining the master file MFE segments (and associated master file records, denoted by "Z") to be returned with the response. The QRF segment may be used to define time ranges, particular MFN record-level event codes etc. Unless otherwise specified, the response returns only active current record(s).
The following segments are defined for the master files messages.
The
Technical Steward for the MFI segment is CQ.
The fields in the MFI segment are defined in HL7 Attribute Table - MFI.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
250 |
CE |
R |
0175 |
00658 |
Master File Identifier |
|
2 |
180 |
HD |
O |
00659 |
Master File Application Identifier |
||
3 |
3 |
ID |
R |
0178 |
00660 |
File-Level Event Code |
|
4 |
26 |
TS |
O |
00661 |
Entered Date/Time |
||
5 |
26 |
TS |
O |
00662 |
Effective Date/Time |
||
6 |
2 |
ID |
R |
0179 |
00663 |
Response Level Code |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field is a CE data type that identifies a standard HL7 master
file. This table may be extended by local agreement during implementation to
cover site-specific master files (z-master files). HL7 recommends use of the
HL7 assigned table number as the master file identifier code if one is not
specified in Table 0175. For example, a master file of Marital Status codes
would be identified by HL70002 as the MFI-1 - Master file
identifier. Refer to HL7 table 0175 - Master file identifier
code for valid values.
Value |
Description |
|---|---|
CDM |
Charge description master file |
CMA |
Clinical study with phases and scheduled master file |
CMB |
Clinical study without phases but with scheduled master file |
LOC |
Location master file |
OMA |
Numerical observation master file |
OMB |
Categorical observation master file |
OMC |
Observation batteries master file |
OMD |
Calculated observations master file |
PRA |
Practitioner master file |
STF |
Staff master file |
CLN |
Clinic master file |
OME |
Other basic observation/service attributes |
Components:
<namespace ID (IS) ^ <universal ID (ST) ^ <universal ID type
(ID)
Definition: This field contains an optional code of up to 180 characters which
(if applicable) uniquely identifies the application responsible for maintaining
this file at a particular site. A group of intercommunicating applications may
use more than a single instance of a master file of certain type (e.g., charge
master or physician master). The particular instance of the file is identified
by this field.
Definition:
This field defines the file-level event code. Refer to HL7
table 0178 - File level event code for valid values.
Value |
Description |
|---|---|
REP |
Replace current version of this master file with the version contained in this message |
UPD |
Change file records as defined in the record-level event codes for each record that follows |
Definition: This field contains the time stamp for file-level event on originating system.
Definition: This optional field contains the effective date/time, which can be included for file-level action specified. It is the date/time the originating system expects that the event is to have been completed on the receiving system. If this field is not present, the action date/time should default to the current date/time (when the message is received).
Definition:
These codes specify the application response level defined for a given Master
File Message at the MFE segment level as defined in HL7 table 0179 -
Response level. Required for MFN-Master File Notification message.
Specifies additional detail (beyond MSH-15 - Accept acknowledgment
type and MSH-16 - Application acknowledgment type) for
application-level acknowledgment paradigms for Master Files transactions.
MSH-15 - accept acknowledgment type and MSH-16 -
Application acknowledgment type operate as defined in Chapter 2.
The
Technical Steward for the MFE segment is CQ.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
3 |
ID |
R |
0180 |
00664 |
Record-Level Event Code |
|
2 |
20 |
ST |
C |
00665 |
MFN Control ID |
||
3 |
26 |
TS |
O |
00662 |
Effective Date/Time |
||
4 |
200 |
Varies |
R |
Y |
00667 |
Primary Key Value - MFE |
|
5 |
3 |
ID |
R |
Y |
0355 |
01319 |
Primary Key Value Type |
Definition:
This field defines the record-level event for the master file record
identified by the MFI segment and the primary key field in this segment.
Refer to HL7 table 0180 - Record level event code for valid
values.
Value |
Description |
|---|---|
MAD |
Add record to master file |
MDL |
Delete record from master file |
MUP |
Update record for master file |
MDC |
Deactivate: discontinue using record in master file, but do not delete from database |
MAC |
Reactivate deactivated record |
Note: If the file-level event code is "REP" (replace file), then each MFE segment must have a record-level event code of "MAD" (add record to master file).
Definition:
A number or other identifier that uniquely identifies this change to this
record from the point of view of the originating system. When returned to the
originating system via the MFA segment, this field allows the target system to
precisely identify which change to this record is being acknowledged. It is
only required if the MFI response level code requires responses at the record
level (any value other than NE).
Note: Note that this segment does not contain a Set ID field. The
MFE-2 - MFN control ID implements a more general concept than the
Set ID. It takes the place of the SET ID in the MFE segment.
Definition: An optional effective date/time can be included for the record-level action specified. It is the date/time the originating system expects that the event is to have been completed on the receiving system. If this field is not present, the effective date/time should default to the current date/time (when the message is received).
Definition:
This field uniquely identifies the record of the master file (identified in
the MFI segment) to be changed (as defined by the record-level event code).
The data type of field is defined by the value of MFE-5 - Value
type, and may take on the format of any of the HL7 data types defined in
HL7 table 0355 - Primary key value type. The PL data type is used
only on Location master transactions.
The following exception to the use of the CE data type is deprecated in v
2.3.1, and left only to satisfy backwards compatibility. When the CE data
type is used, the first component of this CE data field carries an optional
subcomponent, the application ID, that uniquely identifies the application
responsible for creating the primary key value. The application ID
subcomponent can be used to guarantee uniqueness of the primary key across
multiple applications.
The repetition of the primary key permits the identification of an individual
component of a complex record as the object of the record-level event code.
This feature allows the Master Files protocol to be used for modifications of
single components of complex records. If this field repeats, the field
MFE-5 - Value type must also repeat (with the same number of
repetitions), and the data type of each repetition of MFE-4 - Primary key
value is specified by the corresponding repetition of MFE-5
- Value type.
Definition:
This field contains the HL7 data type of MFE-4 - Primary key
value. The valid values for the data type of a primary key are listed
in HL7 table 0355 - Primary key value type.
Value |
Description |
|---|---|
PL |
Person location |
CE |
Coded element |
Note: This table contains data types for MFE-4 values present in HL7 defined master files. As HL7 adopts a new master file that contains a data type for MFE-4 not defined in Table 0355, the data type will be added to Table 0355. For locally defined master files, this table can be locally extended with other HL7 data types as defined in section 2.6.6.
The
Technical Steward for the MFA segment is CQ.
The MFA segment contains the following fields as defined in HL7 Attribute Table
- MFA - Master File Acknowledgment
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
3 |
ID |
R |
0180 |
00664 |
Record-Level Event Code |
|
2 |
20 |
ST |
C |
00665 |
MFN Control ID |
||
3 |
26 |
TS |
O |
00668 |
Event Completion Date/Time |
||
4 |
250 |
CE |
R |
0181 |
00669 |
MFN Record Level Error Return |
|
5 |
250 |
CE |
R |
Y |
9999 |
01308 |
Primary Key Value - MFA |
6 |
3 |
ID |
R |
Y |
0355 |
01320 |
Primary Key Value Type - MFA |
Definition: This field defines record-level event for the master file record identified by the MFI segment and the primary key in this segment. Refer to HL7 table 0180 - Record level event code for valid values.
Definition: This field contains a number or other identifier that uniquely identifies this change to this record from the point of view of the originating system. This field uniquely identifies the particular record (identified by the MFE segment) being acknowledged by this MFA segment. When returned to the originating system via the MFA segment, this field allows the target system to precisely identify which change to this record is being acknowledged. It is only required if MFI-6 - Response level code requires responses at the record level (any value other than NE).
Definition: This field may be required or optional depending on the site specifications for the given master file, master file event, and receiving facility.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the status of the requested update.
Site-defined table, specific to each master file being updated via this
transaction.
Refer to User-defined Table 0181 - MFN record-level error return
for suggested values. All such tables will have at least the following two
return code values:
Value |
Description |
|---|---|
S |
Successful posting of the record defined by the MFE segment |
U |
Unsuccessful posting of the record defined by the MFE segment |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field uniquely identifies the record of the master file
(identified in the MFI segment) to be change status is being acknowledged (as
defined by the field MFN-4 - Record level error return). The data
type of this field is defined by the value of MFA-6 - Value type -
MFA, and may take on the format of any of the HL7 data types defined in
HL7 table 0355 - Primary key value type. The PL data type is used
only on location master transactions.
The following exception to the use of the CE data type is deprecated in
V2.3.1, and left in for backward compatibility. When the CE data type is
used, the first component of this CE data field carries an optional
subcomponent, the application ID, that uniquely defines the application
responsible for creating the primary key value. The application ID
subcomponents can be used to guarantee uniqueness of the primary key across
multiple applications.
The repetition of the primary key permits the identification of an individual
component of a complex record as the object of the record-level event code.
This feature allows the Master Files protocol to be used for modifications of
single components of complex records. If this field repeats, the field
MFA-6 - Primary key value type - MFA must also repeat (with the
same number of repetitions), and the data type of each repetition of
MFA-5 - Primary key value - MFA is specified by the corresponding
repetition of MFA-6 - Value type - MFA.
Definition: This field contains the HL7 data type of MFA-5 - Primary key value - MFA. The valid HL7 data types are listed in HL7 table 0355 - Primary key value type.
This
is an example of a proposed generic method of updating a standard HL7 table.
This particular example shows two records being added to HL7 table 0006 -
Religion.
Note: A standard HL7 table segment can be constructed by defining two
fields: a table entry field (as a CE field) and a display-sort-key field (a
numeric field) as follows.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
250 |
CE |
R |
xxxx |
xxxxx |
HL7 table entry for table xxxx |
|
2 |
3 |
NM |
R |
xxxx |
xxxxx |
Display-sort-key |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains HL7 table values for identifier and text
encoded as a CE data type.
Definition: This field is used to specify a non-alphabetic ordering for display or print versions of a standard HL7 table.
MSH|^~\&|HL7REG|UH|HL7LAB|CH|19910918060544||MFN^M01|MSGID002|P|2.4
MFI|0006^RELIGION^HL7||UPD|||AL
MFE|MAD|199109051000|199110010000|U^Buddhist^HL7|CE
ZL7|U^Buddhist^HL7|3^^Sortkey
MFE|MAD|199109051015|199110010000|Z^Zen Buddhist^HL7|CE
ZL7|Z^Zen Buddhist^HL7|12^^Sortkey
In this case, the primary key contains all the data needed for this simple
table, so that the HL7 segment could be constructed with ONLY the single field,
"sort-key," rather than repeating the primary key value as we have done in this
example.
MFK, master file application acknowledgment, as original mode acknowledgment of
the HL7 message according to MFI Response Level Code of "AL."
MSH|^~\&|HL7LAB|CH|HL7ADT|UH|19910918060546||MFK|MSGID99002|P|2.4
MSA|AA|MSGID002
MFI|0006^RELIGION^HL7||UPD||AL
MFA|MAD|199109051000|19910918060545|S|U^Buddhist^HL7|CE
MFA|MAD|199109051015|19910918060545|S|Z^Zen Buddhist^HL7|CE
MSH|^~\&|HL7REG|UH|HL7LAB|CH|19910918060544||MFN^M01|MSGID002|P|2.4||AL|AL
MFI|0006^RELIGION^HL7||UPD|||AL
MFE|MAD|199109051000|199110010000|U^Buddhist^HL7|CE
ZL7|U^Buddhist^HL7|3^^Sortkey
MFE|MAD|199109051015|199110010000|Z^Zen Buddhist^HL7|CE
ZL7|Z^Zen Buddhist^HL7|12^^Sortkey
MSH|^~\&|HL7LAB|CH|HL7ADT|UH|19910918060545||MSA|MSGID99002|P|2.4
MSA|CA|MSGID002
MSH|^~\&|HL7LAB|CH|HL7ADT|UH|19911001080504||MFK|MSGID99502|P|2.4||AL|
MSA|AA|MSGID002
MFI|0006^RELIGION^HL7||UPD||AL
MFA|MAD|199109051000|19910918010040|S|U^Buddhist^HL7|CE
MFA|MAD|199109051015|19910918010040|S|Z^Zen Buddhist^HL7|CE
MSH|^~\&|HL7ADT|UH|HL7LAB|CH|19911001080507||ACK|MSGID444|P|2.4
MSA|CA|MSGID5002
MSH|^~\&|HL7REG|UH|HL7LAB|CH|19910918060544||MFN^M01|MSGID002|P|2.4||AL|NE
MFI|0006^RELIGION^HL7||UPD|||AL
MFE|MAD|199109051000|199110010000|U^Buddhist^HL7
ZL7|U^Buddhist^HL7|3^^Sortkey
MFE|MAD|199109051015|199110010000|Z^Zen Buddhist^HL7
ZL7|Z^Zen Buddhist^HL7|12^^Sortkey
MSH|^~\&|HL7LAB|CH|HL7ADT|UH|19910918060545||ACK|MSGID99002|P|2.4
MSA|CA|MSGID002
MSH|^~\&|HL7LAB|CH|HL7ADT|UH|19910919060545||MFD|MSGID99002|P|2.4|||AL
MFI|0006^RELIGION^HL7||UPD|||AL
MFA|MAD|199109051000|19910919020040|S|U^Buddhist^HL7
MFA|MAD|199109051015|19910919020040|S|Z^Zen Buddhist^HL7
MSH|^~\&|HL7ADT|UH|HL7LAB|CH|19910919060546||ACK|MSGID444|P|2.4
MSA|CA|MSGID500
The
staff identification (STF), practitioner detail (PRA), and practitioner
organization unit segment (ORG) segments can be used to transmit master files
information between systems. The STF segment provides general information about
personnel; the PRA and ORG segments provides detailed information for a staff
member who is also a health practitioner. Other segments may be defined to
follow the STF segment to provide additional detail information for a
particular type of staff member: the PRA and ORG segments are the first such
segments. When the STF, PRA, and ORG segments are used in an MFN message, the
abstract definition is as follows:
MFN^M02^MFN_M02 |
Master File Notification for Staff/Practitioner |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MFI |
Master File Identification |
8 |
{MFE |
Master File Entry |
8 |
STF |
Staff Identification |
15 |
[PRA] |
Practitioner Detail |
15 |
[ORG] |
Practitioner Organization Unit Segment |
15 |
} |
MFK^M02^MFK_M01 |
Master File Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Acknowledgment |
2 |
MFI |
Master File Identification |
8 |
[{MFA}] |
Master File ACK segment |
8 |
When
the STF and PRA segments are used in the MFR message, the part of the message
represented by:
{MFE
[Z..]}
is replaced by:
{MFE
STF
[PRA]
[ORG]
}
Note that the STF and PRA segments have been moved to Chapter 15 - Personnel
Management. The ORG segment is defined in Chapter 15 - Personnel Management.
MSH|^~\&|HL7REG|UH|HL7LAB|CH|19910918060544||MFN^M02|MSGID002|P|2.4|||AL|NE
MFI|PRA^Practitioner Master File^HL70175||UPD|||AL
MFE|MAD|U2246|199110011230|PMF98123789182^^PLW
STF|PMF98123789182^^PLW|U2246^^^PLW~111223333^^^USSSA^SS|KILDARE^RICHARD^J^JR^DR^M.D.|P|M|19511004|A|^ICU|^MED|(206)689-1999X345CO~(206)283-3334CH(206)689-1345X789CB|214
JOHNSON ST^SUITE 200^SEATTLE^WA^98199^H~3029 24TH AVE W^^SEATTLE, WA^98198^O
|19890125^UMC&University Medical
Center&L01||PMF88123453334|74160.2326@COMPUSERV.COM|B
PRA|PMF98123789182^^PLW|^KILDARE FAMILY PRACTICE|ST|I|OB/GYN^STATE BOARD OF
OBSTETRICS AND
GYNECOLOGY^C^19790123|1234887609^UPIN~1234987^CTY^MECOSTA~223987654^TAX~1234987757^DEA~12394433879^MDD^CA|ADMIT&&ADT^MED&&L2^19941231~DISCH&&ADT^MED&&L2^19941231|
These
segments define the format for the general information about the observations
that a clinical or diagnostic service produces and sends to its "clients."
This format can be used to send the producer's entire service/test/observation
definition or a few of the producer's observations, such as those with
procedure, technique, or interpretation changes.
In anticipation of an object-oriented organization of segments in future
releases of this Standard, the attributes of observations/batteries have been
grouped into six different segments:
OM1 contains the attributes that apply to all observations
OM2 applies to numerically-valued observations
OM3 applies to text or code-valued observations
OM4 applies to observations or batteries that require specimens
OM5 contains the attributes of batteries, or sets of observations or other
batteries
OM6 contains the quantities (observations in a most general sense) that are
calculated from one or more other observations
OM7 contains additional basic attributes that apply to the definition of most
observations/services.
Thus, the full definition of a numerically-valued laboratory observation would
require the transmission of OM1, OM2, and OM4.
In the following discussion, we use OMx to refer to any of the six
observation-defining segments. Each instance of an OMx segment contains the
information about one observation or observation battery. These OMx segments
are designed to be "inclusive" and accommodate the attributes of many kinds of
observations. Thus, the fact that a field is listed in a particular segment
should not be construed as meaning that a producer must include information
about that item in its definition transmission. Many fields will apply to some
terms; others will not. One observation producer may choose to populate one
set of fields; another may choose to populate a different set of fields,
according to the requirements of that producer's "client."
Most of the fields of data type TX in those segments are intended to include
information typically contained in a diagnostic service's user manual. Such
fields should describe how the data is to be interpreted or used, and are not
intended for computer interpretation.
Remember that the magnitude of a treatment can also be regarded as an
observation and, as such, can be represented as an observation within these
segments. Many examples exist. When a blood gas is transmitted, the
requesting service usually transmits the amount of inspired O2 (a treatment) on
requisition. (In an electronic transmission, the service would send this as an
OBX segment, along with the electronic order for the test.) When blood levels
are drawn, the amount and time of the last dose are routinely included as
observations on the request for service. A pharmacy system could routinely
send to a medical record system the average daily dose of each outpatient
medication it dispenses. In such cases, the treatment amounts would be
observations to the receiving system and would be transmitted as OBX segments.
When received, they would be treated like any other observation. A medical
record system could then create, for example, a flowchart of lab results, or
lab results mixed with relevant treatments.
The
usage of the OMx segments in the Master Files MFN and MFR messages is described
in Sections 8.4.1, "MFN/MFK - master files notification," and 8.4.3, "MFQ/MFR -
master files query," above. Basically the segment groupings described below
follow the MFI and MFE segments in those messages (replacing the [Z...] section
as follows:
Note: MFN^M03 is retained for backward compatibility only.
MFN^M03^MFN_M03 |
Master File Notification |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MFI |
Master File Identification |
8 |
{MFE |
Master File Entry |
8 |
OM1 |
General Segment (Fields That Apply to Most Observations) |
8 |
??? |
[other segments(s)] |
|
} |
where
other segments can be any of the following combinations:
MFI-1 - Master file identifier = OMA, for numeric
observations (second component of MSH-9 - Message type =
M08).
[
[
OM2]
Numeric Observation Segment
[OM3] Categorical Service/Test/Observation Segment
[OM4] Observations that Require Specimens
]
MFN^M08^MFN_M08 |
Master File Notification |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MFI |
Master File Identification |
8 |
{MFE |
Master File Entry |
8 |
OM1 |
General Segment (Fields That Apply to Most Observations) |
8 |
[OM2] |
Numeric Observation Segment |
8 |
[OM3] |
Categorical Service/Test/Observation Segment |
8 |
[OM4] |
Observations that Require Specimens |
8 |
} |
or
MFI-1 - Master file identifier = OMB, for categorical
observations (second component of MSH-9 - Message type =
M09).
[OM3 Categorical Service/Test/Observation Segment
[{OM4}] Observations that Require Specimens
]
MFN^M09^MFN_M09 |
Master File Notification |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MFI |
Master File Identification |
8 |
{MFE |
Master File Entry |
8 |
OM1 |
General Segment (Fields That Apply to Most Observations) |
8 |
[OM3 |
Categorical Service/Test/Observation Segment |
8 |
[{OM4}] |
Observations that Require Specimens |
8 |
] |
||
} |
or
MFI-1 - Master file identifier = OMC, for observation
batteries (second component of MSH-9 - Message type =
M10).
[OM5 Observation Batteries
[{OM4}] Observations that Require Specimens
]
MFN^M10^MFN_M10 |
Master File Notification |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MFI |
Master File Identification |
8 |
{MFE |
Master File Entry |
8 |
OM1 |
General Segment (Fields That Apply to Most Observations) |
8 |
[OM5 |
Observation Batteries |
8 |
[{OM4}] |
Observations that Require Specimens |
8 |
] |
||
} |
or
MFI-1 - Master file identifier = OMD, calculated
observations (second component of MSH-9 - Message type =
M11).
[OM6 Observations Calculated from Other Observations
OM2] Numeric Observation Segment
MFN^M11^MFN_M11 |
Master File Notification |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MFI |
Master File Identification |
8 |
{MFE |
Master File Entry |
8 |
OM1 |
General Segment (Fields That Apply to Most Observations) |
8 |
[OM6 |
Observations Calculated from Other Observations |
8 |
OM2] |
Numeric Observation Segment |
8 |
} |
or
MFI-1 - Master file identifier = OME, Additional basic
observation/service attributes (second component of MSH-9 -
Message type = M12).
[OM7] Other basic observation/service attributes
MFN^M12^MFN_M12 |
Master File Notification |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MFI |
Master File Identification |
8 |
{MFE |
Master File Entry |
8 |
OM1 |
General Segment (Fields That Apply to Most Observations) |
8 |
[OM7] |
Other Basic Observation/Service Attributes |
8 |
} |
Note: A service/test/observation definition may have both an OM2 (numeric) and OM3 (categorical) segment included in case the value may be either numeric and/or categorical.
The
Technical Steward for the OM1 segment is ORDERS.
The OM1 segment contains the attributes that apply to the definition of most
observations. This segment also contains the field attributes that specify
what additional segments might also be defined for this observation.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
NM |
R |
00586 |
Sequence Number - Test/Observation Master File |
||
2 |
250 |
CE |
R |
9999 |
00587 |
Producer's Service/Test/Observation ID |
|
3 |
12 |
ID |
O |
Y |
0125 |
00588 |
Permitted Data Types |
4 |
1 |
ID |
R |
0136 |
00589 |
Specimen Required |
|
5 |
250 |
CE |
R |
9999 |
00590 |
Producer ID |
|
6 |
200 |
TX |
O |
00591 |
Observation Description |
||
7 |
250 |
CE |
O |
9999 |
00592 |
Other Service/Test/Observation IDs for the Observation |
|
8 |
200 |
ST |
R |
Y |
00593 |
Other Names |
|
9 |
30 |
ST |
O |
00594 |
Preferred Report Name for the Observation |
||
10 |
8 |
ST |
O |
00595 |
Preferred Short Name or Mnemonic for Observation |
||
11 |
200 |
ST |
O |
00596 |
Preferred Long Name for the Observation |
||
12 |
1 |
ID |
O |
0136 |
00597 |
Orderability |
|
13 |
250 |
CE |
O |
Y |
9999 |
00598 |
Identity of Instrument Used to Perform this Study |
14 |
250 |
CE |
O |
Y |
9999 |
00599 |
Coded Representation of Method |
15 |
1 |
ID |
O |
0136 |
00600 |
Portable Device Indicator |
|
16 |
250 |
CE |
O |
Y |
9999 |
00601 |
Observation Producing Department/Section |
17 |
250 |
XTN |
O |
00602 |
Telephone Number of Section |
||
18 |
1 |
IS |
R |
0174 |
00603 |
Nature of Service/Test/Observation |
|
19 |
250 |
CE |
O |
9999 |
00604 |
Report Subheader |
|
20 |
20 |
ST |
O |
00605 |
Report Display Order |
||
21 |
26 |
TS |
O |
00606 |
Date/Time Stamp for any change in Definition for the Observation |
||
22 |
26 |
TS |
O |
00607 |
Effective Date/Time of Change |
||
23 |
20 |
NM |
O |
00608 |
Typical Turn-Around Time |
||
24 |
20 |
NM |
O |
00609 |
Processing Time |
||
25 |
40 |
ID |
O |
Y |
0168 |
00610 |
Processing Priority |
26 |
5 |
ID |
O |
0169 |
00611 |
Reporting Priority |
|
27 |
250 |
CE |
O |
Y |
9999 |
00612 |
Outside Site(s) Where Observation may be Performed |
28 |
250 |
XAD |
O |
Y |
00613 |
Address of Outside Site(s) |
|
29 |
250 |
XTN |
O |
00614 |
Phone Number of Outside Site |
||
30 |
1 |
IS |
O |
0177 |
00615 |
Confidentiality Code |
|
31 |
250 |
CE |
O |
9999 |
00616 |
Observations Required to Interpret the Observation |
|
32 |
65536 |
TX |
O |
00617 |
Interpretation of Observations |
||
33 |
250 |
CE |
O |
9999 |
00618 |
Contraindications to Observations |
|
34 |
250 |
CE |
O |
Y |
9999 |
00619 |
Reflex Tests/Observations |
35 |
80 |
TX |
O |
00620 |
Rules that Trigger Reflex Testing |
||
36 |
250 |
CE |
O |
9999 |
00621 |
Fixed Canned Message |
|
37 |
200 |
TX |
O |
00622 |
Patient Preparation |
||
38 |
250 |
CE |
O |
9999 |
00623 |
Procedure Medication |
|
39 |
200 |
TX |
O |
00624 |
Factors that may Affect Affect the Observation |
||
40 |
60 |
ST |
O |
Y |
00625 |
Service/Test/Observation Performance Schedule |
|
41 |
65536 |
TX |
O |
00626 |
Description of Test Methods |
||
42 |
250 |
CE |
O |
0254 |
00937 |
Kind of Quantity Observed |
|
43 |
250 |
CE |
O |
0255 |
00938 |
Point Versus Interval |
|
44 |
200 |
TX |
O |
0256/0257 |
00939 |
Challenge Information |
|
45 |
250 |
CE |
O |
0258 |
00940 |
Relationship Modifier |
|
46 |
250 |
CE |
O |
9999 |
00941 |
Target Anatomic Site Of Test |
|
47 |
250 |
CE |
O |
0259 |
00942 |
Modality Of Imaging Measurement |
Definition: This field contains the first OM1 segment in a message and is described as 1, the second as 2, and so on.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the producer's usual or preferred
identification of the test or observation. Only three components should be
included: <ID code>^<service text name/description>^<source
list of code>. All components should be non-null. The source list may
be any of those included in ASTM Tables 3 and 5, or a local code.
Definition: This field contains the allowed data type(s) for this observation. The codes are the same as those listed for OBX (a given observation may, under different circumstances, take on different data types). Indeed, under limited circumstances, an observation can consist of one or more fragments of different data types. When an observation may have more than one data type, e.g., coded (CE) and numeric (NM) the allowable data types should be separated by repeat delimiters. Refer to HL7 table 0125 - Value type for valid values.
Definition:
This field contains a flag indicating whether or not at least one specimen is
required for the service/test/observation. Refer to HL7 table 0136 -
Yes/no indicator as defined in Chapter 2.
Y one or more specimens are required to obtain this observation
N a specimen is not required
When a specimen is required, segment OM4 will usually be included (one per
specimen is required).
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field uniquely identifies the service producing the
observation described in this segment. Three components should be included: an
identifying code, the name of the producer, and the identity of the coding
system (e.g., 323-5678^Acme Special Lab^MC). The identity of the coding system
will usually be MC (Medicare provider number or HIBCC site codes) in the United
States. Each country may want to specify its preferred coding system and
define a coding system ID to identify it.
Remember that the magnitude of a treatment or the setting on a machine, such as
a ventilator, can be regarded as an observation. Thus, pharmacy, respiratory
care, and nursing may be producers of such observations.
Definition: This field contains a text description of this observation.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains all alias codes/identifiers for this
observation. If more than one alias code needs to be specified, multiple
three-component, CE-format entries (<code 1>^<name 1>^<code
system 1>) may be given, separated by repeat delimiters. An observation may
have as many names/codes as are applicable (e.g., ICD9, ACR-NEMA, SNOMED, and
READ). We encourage the inclusion of as many different codes as may apply to
assist cross-system mapping of terminology. All components of each triplet
should be non-null (that is, names and coding system IDs within the CE data
type are required in addition to codes). The source list may be any of those
included in ASTM Tables 3 and 5.
Because the size (dose) of a treatment can also be an observation, codes that
identify treatments (e.g., NDC, ICCS) may also be included in this field.
Note: In this field, the names within the CE data type are required.
Definition: This field contains any test aliases or synonyms for the name in the context of the ordering service. These are alternative names, not associated with a particular coding system, by which the battery, test, or observation (e.g., measurement, test, diagnostic study, treatment, etc.) is known to users of the system. Multiple names in this list are separated by repeat delimiters.
Definition: This field contains the preferred name for reporting the observation or battery. The name can contain up to 30 characters (including blanks). It is the preferred name for columnar reports that require a maximum name size.
Definition: This field contains the name that can be used in space-limited reports (e.g., specimen labels) to identify the observation for the convenience of human readers. The name can contain up to eight characters.
Definition: This field contains the fully-specified name for the observation or battery. It may include the full (unabbreviated) multiple-word names and contain up to 200 characters. It should be as scientifically precise as possible.
Definition:
This field indicates whether or not a service/test/observation is an orderable
code. Refer to HL7 table 0136 - Yes/no indicator for valid
values.
Y the service/test/observation is an orderable code
N the service/test/observation is not orderable
For example, blood differential count is usually an orderable "test," MCV,
contained within the differential count, is usually not independently orderable.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: When applicable, this field identifies the instrument or device
that is used to generate this observation or battery. Examples are the
automated instrument in the laboratory, the imaging device and model number in
radiology, and the automatic blood pressure machine on the ward. The
instrument is specified as a coded entry in anticipation that these identifiers
could be specified as codes. Initially, we expect that most of the information
about devices will be transmitted as text in the second component of the CE
identifier. If more than one kind of instrument is used, all of them can be
listed, separated by repeat delimiters.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the method(s) used to produce the observation
and should be recorded in a computer-understandable (coded) form here. This
field should report the same method(s) reported in narrative in the following
field. More than one method may be listed, but only if they produce results
that are clinically indistinguishable. Multiple methods must be separated by
repeat delimiters.
Definition:
This field indicates whether or not a portable device may be used for the
service/test/observation. Refer to HL7 table 0136 - Yes/no
indicator for valid values.
Y the observation can be obtained with a portable device brought to the
patient
N the patient or specimen must be transported to the device
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field permits the sorting of observation orders and values by
the providing service's department/section. It provides "source oriented"
reporting when required. The codes for this field should be taken from ASTM
Table 15 (Diagnostic Service Codes). Free text may be used instead of these
codes, but in that case, they should be recorded as the second "component" of
the field to distinguish them from the standard codes. Multiple codes in this
field are separated by repeat delimiters.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^
<telecommunication use code (ID)> ^ <telecommunication equipment type
(ID)> ^ <email address (ST)> ^ <country code (NM)> ^
<area/city code (NM)> ^ <phone number (NM)> ^ <extension
(NM)> ^ <any text (ST)>
Definition: This field contains the telephone number for calling responsible
parties in this section to ask results or advice about the use of this test.
Definition:
This field indicates whether the definition entry identifies a test battery,
an entire functional procedure or study, a single test value (observation),
multiple test batteries or functional procedures as an orderable unit
(profile), or a single test value (observation) calculated from other
independent observations. Refer to User-defined Table 0174 - Nature of
service/test/observation for suggested values.
Value |
Description |
|---|---|
P |
Profile or battery consisting of many independent atomic observations (e.g., SMA12, electrolytes), usually done at one instrument on one specimen |
F |
Functional procedure that may consist of one or more interrelated measures (e.g., glucose tolerance test, creatinine clearance), usually done at different times and/or on different specimens |
A |
Atomic service/test/observation (test code or treatment code) |
S |
Superset--a
set of batteries or procedures ordered under a single code unit but processed
as separate batteries (e.g., routines = CBC, UA, electrolytes) |
C |
Single observation calculated via a rule or formula from other independent observations (e.g., Alveolar--arterial ratio, cardiac output) |
Codes
P, F, and S identify sets (batteries) and should be associated with an OM5
segment that defines the list of elements. The definitions for the contained
elements would have to be sent in other independent OMx segments, one for each
contained element. In the ASTM context, most text reports - such as discharge
summaries, admission H&Ps, and chest X-ray reports - are considered as
sets, in which each section of the report (e.g., description, impression, and
recommendation of an X-ray report) is considered a separate observation.
Code A identifies a single direct observation and would usually be associated
with an OM2 and/or OM3 segments.
Code C identifies a derived quantity and would usually be associated with an
OM6 segment.
All of these codes can be associated with one or more OM4 (specimen) segments.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains an optional string that defines the preferred
header under which this observation should be listed on a standard display.
For example, if the test is hemoglobin, this string might be "Complete blood
count." It is represented as a coded data type so that a battery can be a
header. Only the description part of the string may be included in case the
subheader does not have an associated code. When a series of observations is
displayed according to the sort order given below, the subheader that groups
those observations is presented whenever the subheader changes.
Definition: This field contains an optional string that defines the sort order in which this observation is presented in a standard report or display that contains the many observations.
Definition: This field contains the date and time that the last of any field change was made and in the host's record corresponding to the OM1 segment.
Definition:
This field contains the date and time of the last change in the test procedure
that would make previous results incompatible with new results, e.g., the last
time that normal reference range or units changed for a numeric
test/observation.
We strongly suggest that observation producers never use the same observation
ID when the measurement procedures change in such a way that results produced
under the new procedure are clinically different from those produced with the
old procedure. Rather, the producer should try to adjust the new procedure so
that its values are clinically indistinguishable from the old. Failing that,
one should create a new observation ID for the observation produced under the
new procedure.
In the rare circumstances when a procedure change occurs and neither of the
above two options is viable, this field shall be used to transmit the effective
date/time of the new procedure. The receiving system shall assume that any
values that come across under this observation ID are under the new procedure
after this date and take appropriate steps to distinguish the old from the new
observations.
This number is included to provide a means of communicating with the
observation producing service when they have questions about particular
observations or results.
Definition: This field contains the typical processing time for single test/observation. This field indicates the time from the delivery of a specimen or transport of a patient to a diagnostic service and the completion of the study. It includes the usual waiting time. The units are measured in minutes.
Definition: This field contains the usual length of time (in minutes) between the start of a test process and its completion.
Definition:
This field contains one or more available priorities for performing the
observation or test. This is the priority that can be placed in OBR-27 -
Quantity/timing. For tests that require a specimen, this field may
contain two components in the format <specimen priority>^<processing
priority>. The first component in this case indicates the priority with
which the specimen will be collected and is the priority that is specified in
an OBR segment when ordering the observation. The second component indicates
the corresponding priority with which the producer service will process the
specimen, produce the observation, and return results, when this differs from
collection priority. Refer to HL7 table 0168 - Processing
priority for valid values.
Value |
Description |
|---|---|
S |
Stat (do immediately) |
A |
As soon as possible (a priority lower than stat) |
R |
Routine |
P |
Preoperative (to be done prior to surgery) |
T |
Timing critical (do as near as possible to requested time) |
C |
Measure continuously (e.g., arterial line blood pressure) |
B |
Do at bedside or portable (may be used with other codes) |
The priority for obtaining the specimen is included in OM4. Multiple priorities may be given, separated by repeat delimiters. For example, S~A~R~P~T indicates that the test may be ordered using codes S, A, R, P, or T.
Definition:
This field contains the available priorities reporting the test results when
the user is asked to specify the reporting priority independent of the
processing priority. Refer to HL7 Table 0169 - Reporting
priority for valid values.
Value |
Description |
|---|---|
C |
Call back results |
R |
Rush reporting |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the identification(s) of the outside
service(s) that produce(s) the observation. The format of this CE field uses
the producer ID (as defined in OM1-5 - Producer ID) and the
name of the service separated by component delimiters. An example is
...|39221^ACME lab^MC|... If multiple services are used, they should be
separated by repeat delimiter(s).
Components:
In Version 2.3 and later, replaces the AD data type. <street address
(SAD)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or
province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^
< address type (ID)> ^ <other geographic designation (ST)>
^ <county/parish code (IS)> ^ <census tract (IS)> ^
<address representation code (ID)> ^ <address validity range
(DR)>
Definition: This field contains the address of the outside services listed in
OM1-28 - Address of outside site(s) where observation may be
performed. If multiple services are recorded in that field, their addresses
should be separated by repeat delimiters, and the addresses should appear in
the same order in which the services appear in the preceding field.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^
<telecommunication use code (ID)> ^ <telecommunication equipment type
(ID)> ^ <email address (ST)> ^ <county code (NM)> ^
<area/city code (NM)> ^ <phone number (NM) ^ <extension (NM)> ^
<any text (ST)>
Definition: This field contains the telephone number of the outside site.
Definition:
This field contains the degree to which special confidentiality protection
should be applied to the observation. For example, a tighter control may be
applied to an HIV test than to a CBC. Refer to User-defined Table 0177 -
Confidentiality code for suggested values.
Value |
Description |
|---|---|
V |
Very restricted |
R |
Restricted |
U |
Usual control |
EMP |
Employee |
UWM |
Unwed mother |
VIP |
Very important person or celebrity |
PSY |
Psychiatric patient |
AID |
AIDS patient |
HIV |
HIV(+) patient |
ETH |
Alcohol/drug treatment patient |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the list of variables that the diagnostic
service needs to interpret the results of an ordered study. The observations
specified here should be sent to the diagnostic service as OBX segments along
with the order (OBR) segment.
Example for cervical pap smear:
...|2000.32^date last menstrual period^AS4~2000.33^menstrual state^AS4|...
Example for arterial blood gas:
...|94700^inspired 02^AS4|...
These examples use AS4 codes in code/text format to identify the variables.
Separate multiple items by repeat delimiters.
Definition: This field contains the clinical information about interpreting test results. Examples are the conditions (drugs) that may cause false abnormals, and the information about the sensitivity and specificity of the test for diagnoses.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the diagnosis or problem for which the test is
a contraindication or of possible danger (e.g., pacemaker, pregnancy,
diabetes). For example, if the test identified in OM1 was an intravenous
pyelogram, this field would include warnings about the use of contrast media in
diabetes. The contraindication diagnoses should be separated by repeat
delimiters.
Most contraindication rules will be transmitted as free text. In such cases,
the contents serve only as information for human reading. However, an
alternative for machine readable contraindication rules also exists. The rule
may be defined formally in the Arden Syntax (ASTM 1460-1992) which has syntax
for defining algebraic and transcendental equations, as well as temporal and
logical selection criteria based on patient information stored in the computer
record. Reflex rules that are written in Arden Syntax should begin and end with
a double semi-colon (;;), the Arden slot delimiter.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the test names as type CE (i.e.,
<code>^<text name>^<coding system>) that may be ordered
automatically by the diagnostic service, depending on the results obtained from
the ordered battery. A screening CBC might trigger a reticulocyte count if the
Hgb is less than 12. Multiple reflex tests are separated by repeat delimiters.
Definition:
This field contains the rules that trigger the reflex tests listed above. If
multiple reflex tests are listed in OM1-34 - Reflex text/observations
separated by repeat delimiters, a set of corresponding rules will be
included in this section. The first rule will apply to the first test, the
second to the second test, and so on.
Most reflex rules will usually be transmitted as free text. In such cases, the
contents serve only as information for human reading. However, an alternative
for machine readable rules also exists. The rule may be defined formally in the
Arden Syntax (ASTM 1460-1992) which has syntax for defining algebraic and
transcendental equations, as well as temporal and logical selection criteria
based on patient information stored in the computer record. Reflex rules that
are written in Arden Syntax should begin and end with a double semi-colon (;;),
the Arden slot delimiter.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the codes and a fixed text message that is
always associated with an abbreviation. The field may include multiple
messages separated by repeat delimiters.
Most rules about patient testing will be transmitted as free text. In such
cases, the contents serves only as information for human reading. However, an
alternative for machine readable rules also exists. The rule may be defined
formally in the Arden Syntax (ASTM 1460-1992) which has syntax for defining
algebraic and transcendental equations, as well as temporal and logical
selection criteria based on patient information stored in the computer record.
Rules about patient preparation are written in Arden Syntax should begin and
end with a double semi-colon (;;), the Arden slot delimiter.
Definition:
This field contains the tests or observations that require special patient
preparation, diet, or medications. For GI contrast studies, this field would
contain the pretest diet, e.g., low residue for two days, NPO before study, and
the preferred purgatives. Each separate med, diet, or preparation should be
delimited by a repeat delimiter. Separate each requirement by a repeat
delimiter. Example for a sigmoidectomy:
...|clear liquid diet full day before procedure~take 8 oz mag citrate 6pm day
before procedure~take 2 ducat tabs (5m) at 4pm day before procedure~NPO past
midnight.|...
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the treatments that may be needed as part of
the procedure. Examples are radioactive iodine for a thyroid screen, and
methacholine for a methacholine spirometry challenge. This field should be
identified as a CE data type.
Definition:
This field contains the text description of the foods, diagnoses, drugs, or
other conditions that may influence the interpretation of the observation.
Information about the direction of the effect, and any recommendation about
altering the diet, conditions, or drug before initiating the test
observation.
Most rules about factors that effect the test interpretation will be
transmitted as free text. In such cases, the contents serves only as
information for human reading. However, an alternative for machine readable
rules also exists. The rule may be defined formally in the Arden Syntax (ASTM
1460-1992) which has syntax for defining algebraic and transcendental
equations, as well as temporal and logical selection criteria based on patient
information stored in the computer record. Rules about patient preparation are
written in Arden Syntax and should begin and end with a double semi-colon (;;),
the Arden slot delimiter.
Definition: This field contains the diagnostic studies/tests that are performed only at certain times during the course of a work day or work week. This field indicates the maximum interval between successive test performances (the test may actually be performed more frequently). The format given in Chapter 4, Section 4.3.2.1, "Repeat Pattern," should be used. If necessary, multiple codes may be given, separated by repeat delimiters. The use of multiple codes indicates that the test is performed at multiple concurrent intervals. For example, Q6H indicates that the test is performed at least once every 6 hours around the clock. QJ1 indicates that the test is performed at least every week on Mondays. QAM~QPM indicates that the test is performed at least once every morning and every evening. QJ1~QJ3~QJ5 indicates that the test is performed at least every week on Mondays, Wednesdays, and Fridays. C indicates that the test is performed continuously, 7 days per week.
Definition: This field contains the text description of the methods used to perform the text and generate the observations. Bibliographic citations may be included.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definitions: This optional attribute describes the underlying kind of property
represented by this observation. This attribute distinguishes concentrations
from total amounts, molar concentrations from mass concentrations, partial
pressures from colors, and so forth. These are discussed more fully in the
LOINC Users' Manual.[1] They are derived from
the approach described in 1995 edition of the IUPAC Silver Book.[2] These distinctions are used in IUPAC and LOINC
standard codes. Defined categories are listed in HL7 table 0254 - Kind
of quantity.
The distinctions of true quantities in this table are based primarily on
dimensional analyses. The table contains a number of "families," those related
to simple counts (number, number concentration, etc.), to mass (mass, mass
concentration, etc.), to enzyme activity (catalytic content, catalytic
concentration, etc.), and molar or equivalents (substance content, substance
concentration).
By this classification, a glucose (in the US) would be classed as a mass
concentration. A sodium would be classed as a substance concentration. Within
the family, a total amount should be described as the unadorned variant; e.g.,
the property of measure for a patient's weight would be mass, not mass content.
Most chemical measures produce concentrations, as exemplified by sodium and
glucose. However, a 24-hour urine protein is not a mass concentration, but a
mass rate (mass per unit time). The content variants (e.g., mass content,
substance content) are used to reflect an amount per mass (usually) of
tissue.
This attribute would be valued in a master file only if the service sending the
master file classified observations by their principle of measurement.
Value |
Description |
|---|---|
CACT |
*Catalytic Activity |
CNC |
*Catalytic Concentration |
CCRTO |
Catalytic Concentration Ratio |
CCNT |
*Catalytic Content |
CFR |
*Catalytic Fraction |
CRAT |
*Catalytic Rate |
CRTO |
Catalytic Ratio |
ENT |
*Entitic |
ENTSUB |
*Entitic Substance of Amount |
ENTCAT |
*Entitic Catalytic Activity |
ENTNUM |
*Entitic Number |
ENTVOL |
*Entitic Volume |
MASS |
*Mass |
MCNC |
*Mass Concentration |
MCRTO |
*Mass Concentration Ratio |
MCNT |
Mass Content |
MFR |
*Mass Fraction |
MINC |
*Mass Increment |
MRAT |
*Mass Rate |
MRTO |
*Mass Ratio |
NUM |
*Number |
NCNC |
*Number Concentration |
NCNT |
*Number Content |
NFR |
*Number Fraction |
NRTO |
*Number Ratio |
SUB |
*Substance Amount |
SCNC |
*Substance Concentration |
SCRTO |
*Substance Concentration Ratio |
SCNT |
*Substance Content |
SCNTR |
*Substance Content Rate |
SFR |
*Substance Fraction |
SCNCIN |
*Substance Concentration Increment |
SRAT |
*Substance Rate |
SRTO |
*Substance Ratio |
VOL |
*Volume |
VCNT |
*Volume Content |
VFR |
*Volume Fraction |
VRAT |
*Volume Rate |
VRTO |
*Volume Ratio |
ACNC |
Concentration, Arbitrary Substance |
RLMCNC |
*Relative Mass Concentration |
RLSCNC |
*Relative Substance Concentration |
THRMCNC |
*Threshold Mass Concentration |
THRSCNC |
*Threshold Substance Concentration |
TIME |
*Time (e.g. seconds) |
TMDF |
*Time Difference |
TMSTP |
*Time Stamp -- Date and Time |
TRTO |
*Time Ratio |
RCRLTM |
*Reciprocal Relative Time |
RLTM |
*Relative Time |
ABS |
Absorbance |
ACT |
*Activity |
APER |
Appearance |
ARB |
*Arbitrary |
AREA |
Area |
ASPECT |
Aspect |
CLAS |
Class |
CNST |
*Constant |
COEF |
*Coefficient |
COLOR |
Color |
CONS |
Consistency |
DEN |
Density |
DEV |
Device |
DIFF |
*Difference |
ELAS |
Elasticity |
ELPOT |
Electrical Potential (Voltage) |
ELRAT |
Electrical current (amperage) |
ELRES |
Electrical Resistance |
ENGR |
Energy |
EQL |
Equilibrium |
FORCE |
Mechanical force |
FREQ |
Frequency |
IMP |
Impression/ interpretation of study |
KINV |
*Kinematic Viscosity |
LEN |
Length |
LINC |
*Length Increment |
LIQ |
*Liquefaction |
MGFLUX |
Magnetic flux |
MORPH |
Morphology |
MOTIL |
Motility |
OD |
Optical density |
OSMOL |
*Osmolality |
PRID |
Presence/Identity/Existence |
PRES |
*Pressure (Partial) |
PWR |
Power (wattage) |
RANGE |
*Ranges |
RATIO |
*Ratios |
RDEN |
*Relative Density |
REL |
*Relative |
SATFR |
*Saturation Fraction |
SHAPE |
Shape |
SMELL |
Smell |
SUSC |
*Susceptibility |
TASTE |
Taste |
TEMP |
*Temperature |
TEMPDF |
*Temperature Difference |
TEMPIN |
*Temperature Increment |
TITR |
*Dilution Factor (Titer) |
TYPE |
*Type |
VEL |
*Velocity |
VELRT |
*Velocity Ratio |
VISC |
*Viscosity |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This optional attribute allows master files to classify
observations as measuring the patient's state at a point in time (e.g., spot
urines, random urines, serum potassium), or averaged over a interval of time
(e.g., concentration, total amount, or clearance over a 24-hour collection).
Interval measures most often apply to urine and stool specimens (e.g., 24-hour
urines, 3-day stool fats). They also apply to clinical measurements such as
urine outputs, which are reported as shift totals and 24-hour totals, and event
counts on physiologic monitors such as the number of PVCs on a 24-hour Holter
monitor.
This field would only be valued in a transaction if the service sending this
master file message classified its observation by point versus time interval.
This field is not used to record the time collection interval for a
particular sample. It is used to specify a characteristic of an observation
which has a defined normal range and to distinguish observations of the same
kind but observed over varying periods of time. A spot urine sodium would have
PT stored in this field. A 24-hour urine sodium and a 24-hour Holter monitor
would have 24H stored here. This attribute would only be valued if the filling
service classified its observations by timing. Refer to User-defined
Table 0255 - Duration categories for suggested values.
Value |
Description |
|---|---|
PT |
To identify measures at a point in time. This is a synonym for "spot" or "random" as applied to urine measurements. |
* |
(asterisk) Life of the "unit." Used for blood products. |
30M |
30 minutes |
1H |
1 hour |
2H |
2 hours |
2.5H |
2½ hours |
3H |
3 hours |
4H |
4 hours |
5H |
5 hours |
6H |
6 hours |
7H |
7 hours |
8H |
8 hours |
12H |
12 hours |
24H |
24 hours |
2D |
2 days |
3D |
3 days |
4D |
4 days |
5D |
5 days |
6D |
6 days |
1W |
1 week |
2W |
2 weeks |
3W |
3 weeks |
4W |
4 weeks |
1L |
1 months (30 days) |
2L |
2 months |
3L |
3 months |
Definition:
This optional attribute provides information for classifying observations by
the challenge component of the test, if a challenge does speciate the
observation. For example, distinguishing tests that have a challenge component
in database. There co-ascribes the physiologic or drug challenge that is
intrinsic to the measurement. To identify, for example, tests that include a
glucose challenge.
To construct this text string, use the following template. (Note: This field
is not constructed of formally defined components; it is a free text field.
Component delimiters are not used and it is not necessary to supply
placeholders if some "components" are not used.)
The time delay follows the syntax: n<S|M|H|D|W> where n is a number
(possibly a decimal); S denotes seconds; M denotes minutes; H denotes hours; D
denotes days; and W denotes weeks. The time delay can be preceded by a
`greater than' (>) sign, e.g. >4H.
HL7 Table 0256 - Time delay post challenge lists possible values
for time delay.
Examples
PRE 100 GM GLUCOSE PO
PRE 100 GM GLUCOSE PO
30M POST 100 GM GLUCOSE PO
2H POST 100 GM GLUCOSE PO
TROUGH
For drug peak and trough measures the nature of the substance challenged is the
same as the analyte name, and need not be included.
We denote the route of the challenge via abbreviations for medication routes
(see Chapter 4, Section 4.14.2.1, "Route," HL7 table 0162 - Route of
administration). An oral route of administration would be denoted by
"PO," an intravenous route by "IV."
Details of the drug dose, time the dose was given, route of administration,
etc., would be noted in separate OBX, and would have corresponding master
observation definitions stored in the observation master file map to different
records stored in the master file segments contained in the drug level
message.
Value |
Description |
|---|---|
BS |
Baseline (time just before the challenge) |
PEAK |
The time post drug dose at which the highest drug level is reached (differs by drug) |
TROUGH |
The time post drug dose at which the lowest drug level is reached (varies with drug) |
RANDOM |
Time from the challenge, or dose not specified. (random) |
1M |
1 minute post challenge |
2M |
2 minutes post challenge |
3M |
3 minutes post challenge |
4M |
4 minutes post challenge |
5M |
5 minutes post challenge |
6M |
6 minutes post challenge |
7M |
7 minutes post challenge |
8M |
8 minutes post challenge |
9M |
9 minutes post challenge |
10M |
10 minutes post challenge |
15M |
15 minutes post challenge |
20M |
20 minutes post challenge |
25M |
25 minutes post challenge |
30M |
30 minutes post challenge |
1H |
1 hour post challenge |
2H |
2 hours post challenge |
2.5H |
2 1/2 hours post challenge |
3H |
3 hours post challenge |
4H |
4 hours post challenge |
5H |
5 hours post challenge |
6H |
6 hours post challenge |
7H |
7 hours post challenge |
8H |
8 hours post challenge |
8H SHIFT |
8 hours aligned on nursing shifts |
12H |
12 hours post challenge |
24H |
24 hours post challenge |
2D |
2 days |
3D |
3 days |
4D |
4 days |
5D |
5 days |
6D |
6 days |
7D |
7 days |
1W |
1 week |
10D |
10 days |
2W |
2 weeks |
3W |
3 weeks |
4W |
4 weeks |
1L |
1 month (30 days) post challenge |
2L |
2 months (60 days) post challenge |
3L |
3 months (90 days) post challenge |
The
nature of a physiologic (non-drug) challenge may also be specified, using the
terms in HL7 Table 0257 - Nature of
challenge.
Value |
Description |
|---|---|
CFST |
Fasting (no calorie intake) for the period specified in the time component of the term, e.g., 1H POST CFST |
EXCZ |
Exercise undertaken as challenge (can be quantified) |
FFST |
No fluid intake for the period specified in the time component of the term |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This optional attribute provides a mechanism for classifying
observations according to the subject, in relation to the patient whose results
might be stored with as "patient" data. It is standard practice, for example,
to report values for controls, donors, and blood product units as well as the
patient's own values, and store them in the patient's record. (This may not be
the best way to model such information, but it is the way it is usually
reported.) This should be valued when two values (e.g., one for patient and one
for a blood product unit) could otherwise be confused.
The default value is "Patient," and if not specified, this value is assumed.
The persons sub-component can refer to HL7 Table 0258 - Relationship
modifier for valid values.
Value |
Description |
|---|---|
CONTROL |
Control |
PATIENT |
Patient |
DONOR |
Donor |
BPU |
Blood product unit |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This optional attribute formally indicates the site of the
observation (to make it easy for a system to find all tests related to one
anatomic site). It can be used to classify the observation by target site of
the examination. For example, "heart" might be recorded as the target of the
electrocardiogram, cardiac echo, and thallium exercise test. This attribute
would be applicable to most imaging and electro-physiologic examinations. The
SNOMED topology axis is an example of a coding system for anatomic sites.
User-defined tables may also apply here.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This optional attribute describes the modality used to classify
the observations, e.g., radiograph, ultrasound, CT scan, NMR, etc. This
attribute is especially important for imaging studies. Refer to
User-defined Table 0259 - Modality for suggested values;
they are adopted from DICOM C.7.3.1.1.1 Modality. If these are used, the code
source ID would be DCM.
The
Technical Steward for the OM2 segment is ORDERS.
This segment contains the attributes of observations with continuous values
(including those with data types of numeric, date, or time stamp). It can be
applied to observation batteries of type A and C (see OM1-18 - Nature of
service/test/observation).
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
NM |
O |
00586 |
Sequence Number- Test/Observation Master File |
||
2 |
250 |
CE |
O |
9999 |
00627 |
Units of Measure |
|
3 |
10 |
NM |
O |
Y |
00628 |
Range of Decimal Precision |
|
4 |
250 |
CE |
O |
9999 |
00629 |
Corresponding SI Units of Measure |
|
5 |
60 |
TX |
O |
00630 |
SI Conversion Factor |
||
6 |
250 |
CM |
O |
00631 |
Reference (Normal) Range - Ordinal and Continuous Observations |
||
7 |
205 |
CM |
O |
00632 |
Critical Range for Ordinal and Continuous Observations |
||
8 |
250 |
CM |
O |
00633 |
Absolute Range for Ordinal and Continuous Observations |
||
9 |
250 |
CM |
O |
Y |
00634 |
Delta Check Criteria |
|
10 |
20 |
NM |
O |
00635 |
Minimum Meaningful Increments |
Definition: This field contains the same value as the sequence number of the associated OM1 segment.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the single tests/observations (those with a
nature code of A or C, as described in OM1-18 - Nature of
service/test/observation) that have numeric values. This field contains
their customary units of measure.
Definition: This field contains the numerically valued single observations (code A or C as described in OM1-18 - Nature of service/test/observation), 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 is coded 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 multiple display formats that are possible.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the single tests/observations - the
corresponding SI units of measure in the format, when these differ from the
customary units of measure given in the previous field.
Definition:
This field contains the continuous, numerically valued tests/observations,
with a nature code of A or C (see OM1-18 - Nature of
service/test/observation). This is a factor for converting the
customary units to SI units.
In the case that the observation units are not SI units, this field provides
the formula needed to convert from the reported units to SI units, this shall
include the equation needed to convert from the reporting to the SI units.
In the case that the relation is simply multiplicative, this field shall
include only the conversion factor. For example., if (results SI units) = c *
(results reporting units),then only c would be stored in this field. In the
case of any other functional relationship, the entire equation would be stored
as a test.
Definition:
This field contains the reference (normal) ranges for "numeric"
observations/tests with a nature code of A or C (see OM1-18 - Nature of
service/test/observation). It can identify different reference (normal)
ranges for different categories of patients according to age, sex, race, and
other conditions.
The general format is:
<ref. (normal) range1>^<sex1>^<age
range1>^<age
gestation1>^<species1>^<race/subspecies1>^<text
condition1>~
<ref. (normal) range2>^<sex2>^<age
range2>^<age
gestation2>^<species2>^<race/subspecies2>^<text
condition2>~
·
·
·
<ref. (normal) rangen>^<sexn>^<age
rangen>^<age
gestationn>^<speciesn>^<race/subspeciesn>^<text
conditionn>
The components are defined in the following sections.
Components:
<low value (NM)> & <high value (NM)>
Definition: This subcomponent contains the reference (normal) range. The
format of this field is where the range is taken to be inclusive (i.e., the
range includes the end points). In this specification, the units are assumed
to be identical to the reporting units given in OM2-2 - Units of
measure).
Definition: This subcomponent contains the sex of the patient. Refer to User-defined Table 0001 - Administrative Sex for suggested values.
Subcomponents:
<low value (NM)> & <high value (NM)>
Definition: This component contains the age range (in years or fractions
thereof) specified as two values separated by a subcomponent delimiter (in
order to allow a simple and consistent machine interpretation of this
component). Ages of less than one year should be specified as a fraction
(e.g., 1 month = 0.0830, 1 week = 0.01920, 1 day = 0.0027300). However, for
most purposes involving infants, the gestational age (measured in weeks) is
preferred. The lower end of the range is not indicated; the upper end is,
assuring that series of ranges do not overlap.
Subcomponents:
<low value (NM)> & <high value (NM)>
Definition: This component contains the gestational age and is relevant only
when the reference range is influenced by the stage of pregnancy. A range of
values is required. The gestational age is measured in weeks from conception.
For example, <1&10> implies that the normals apply to gestational
ages from 1 week to 4 weeks inclusive (1&4). The lower end of the range is
not included; the upper end is, assuring that series of age ranges do not
overlap.
Definition: This component is assumed to be human unless otherwise stated. The species should be represented as text (e.g., rabbit, mouse, rat).
Definition: In the case of humans (the default), the race is specified when race influences the reference range. When normal ranges for animals are being described, this component can be used to describe subspecies or special breeds of animals.
Definition: This component contains the condition as simply free text. This component allows for definition of normal ranges based on any arbitrary condition, e.g., phase of menstrual cycle or dose of a particular drug. It is provided as a way to communicate the normal ranges for special conditions. It does not allow automatic checking of these text conditions.
A
range that applies unconditionally, such as albumin, is transmitted as:
3.0 & 5.5
A normal range that depends on sex, such as Hgb, is transmitted as:
13.5 & 18^M~
12.0 & 16^F
A normal range that depends on age, sex, and race (a concocted example) is:
10 & 13 ^M^0 & 2 ^^^B
11 & 13.5 ^M^2 & 20 ^^^B~
12 & 14.5 ^M^20 & 70 ^^^B~
13 & 16.0 ^M^70 & ^^^B
When no value is specified for a particular component, the range given applies
to all categories of that component. For example, when nothing is specified
for race/species, the range should be taken as the human range without regard
to race. If no age range is specified, the normal range given is assumed to
apply to all ages. If the upper or lower end of a range is left out, it is
assumed to be +infinity or -infinity, respectively.
When two different methods result in two different reference ranges, two
different observations and corresponding OMx segments should be defined.
Components:
<low value (NM)> ^ <high value (NM)>
Definition: This field applies only to single tests/observations (i.e., a
nature code of A or C, as described in OM1-18 - Nature of
service/test/observation) with numeric results. When a critical range
is defined for such observations, it should be recorded here in the same format
as the normal range (see OM2-6 - Reference (normal) range - ordinal and
continuous observations).
Components:
<range> ^ <numeric change> ^ <%/a change> ^
<days>
Definition: This field applies only to single tests/observations with a nature
code of A or C (see OM1-18 - Nature of service/test/observation).
It defines the range of possible results. Results outside this range are not
possible. The field should be recorded in the same format as the normal and
critical ranges.
Components:
<low & high (CM)> ^ <numeric threshold (NM)> ^ <change
(ST)> ^ <length of time-days (NM)>
Definition: This field applies to numeric tests/observations with a nature
code of A or C (see OM1-18 - Nature of service/test/observation).
The field describes the information that controls delta check warnings and
includes four components.
1) The range to which the following applies: <low & high>.
All the
ranges are defined in terms of the customary reporting units given in
OM2-2-units of measure. If no value range is given, the check applies to all
values.
2) The numeric threshold of the change that is detected, e.g., 10.
3) Whether the change is computed as a percent change or an absolute change.
This component can have two possible values:
% Indicates a percent
change
a Absolute change
4) The length of time that the service retains a value for computing delta
checks. This is recorded in number of days.
More than one delta check rule can apply.
13&16^10^%^100~16.1&20^2^a^100 implies that the delta check will
trigger on a 10% change when the value of the observation is between 13 and 16.
The check will trigger on an absolute change of 2 when the value is between
16.1 and 20. In both cases, the system will keep the last result for 100 days.
In this example, beyond 100 days, the computer will not compute a delta check
because it will not have a comparison value.
Definition: This field contains the numerically valued single observations (a nature code of A or C, as described in OM1-18 - Nature of service/test/observation) and specifies the smallest meaningful difference between reported values (the effective resolution of the measuring instrument or technique for continuous data, or the smallest discrete interval that can occur for discrete data).
The
Technical Steward for the OM3 segment is ORDERS.
This segment applies to free text and other non-numeric data types.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
NM |
O |
00586 |
Sequence Number- Test/Observation Master File |
||
2 |
250 |
CE |
O |
9999 |
00636 |
Preferred Coding System |
|
3 |
250 |
CE |
O |
9999 |
00637 |
Valid Coded "Answers" |
|
4 |
250 |
CE |
O |
Y |
9999 |
00638 |
Normal Text/Codes for Categorical Observations |
5 |
250 |
CE |
O |
9999 |
00639 |
Abnormal Text/Codes for Categorical Observations |
|
6 |
250 |
CE |
O |
9999 |
00640 |
Critical Text/Codes for Categorical Observations |
|
7 |
2 |
ID |
O |
0125 |
00570 |
Value Type |
Definition: This field contains the same value as the sequence number of the associated OM1 segment.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the observations whose categorical responses
are taken from a specified table of codes (e.g., CE data types). Record the
preferred coding system for this observation (e.g., ICD9, SNOMED III). Take
the codes from ASTM Table 3 or 5, or specify a local code.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains a list of valid coded answers. In the case
that the list of coded answers is easily enumerated, list the valid coded
answers for this observation here using the preferred coding system given in
OM3-2 - Preferred coding system. If, for example, the given
observation was VDRL, the valid answers might be non-reactive, 86^
intermediate, and 87^ reactive.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: Certain observations/tests with a nature code of A or C (see
OM1-18 - Nature of service/test/observation) have text (alpha)
results (e.g., reactive, nonreactive). Alpha normals for those tests should be
entered in this field (e.g., "nonreactive").
The format of this field is:
The first component is a code taken from a standard code source list. The
second component is the text associated with the code. The third component is
the identification of the code table source. When only a text description of a
possible answer is available, it is recorded as ^<text>.
Care should be taken to transmit only those results that are considered normal
for that test. A drug screen may have possible results of "negative" and
"positive." However, only a result of "negative" is considered to be normal.
When an observation has more than one "normal" result, multiple values in this
field should be separated with a repeat delimiter.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the list of the text answers that are abnormal
for the test.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the list of coded results that are critically
abnormal for this observation.
Definition: This field contains the allowed data type for a single categorical observation (code A or C in OM1-18 - Nature of observation). Refer to HL7 table 0125 - Value type for valid values.
The
Technical Steward for the OM4 segment is ORDERS.
This segment applies to observations/batteries that require a specimen for
their performance. When an observation or battery requires multiple specimens
for their performance (e.g., creatinine clearance requires a 24-hour urine
specimen and a serum specimen), multiple segments may be included, one for each
specimen type.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM # |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
NM |
O |
00586 |
Sequence Number- Test/Observation Master File |
||
2 |
1 |
ID |
O |
0170 |
00642 |
Derived Specimen |
|
3 |
60 |
TX |
O |
00643 |
Container Description |
||
4 |
20 |
NM |
O |
00644 |
Container Volume |
||
5 |
250 |
CE |
O |
9999 |
00645 |
Container Units |
|
6 |
250 |
CE |
O |
9999 |
00646 |
Specimen |
|
7 |
250 |
CE |
O |
0371 |
00647 |
Additive |
|
8 |
10240 |
TX |
O |
00648 |
Preparation |
||
9 |
10240 |
TX |
O |
00649 |
Special Handling Requirements |
||
10 |
20 |
CQ |
O |
00650 |
Normal Collection Volume |
||
11 |
20 |
CQ |
O |
00651 |
Minimum Collection Volume |
||
12 |
10240 |
TX |
O |
00652 |
Specimen Requirements |
||
13 |
1 |
ID |
O |
Y |
0027 |
00653 |
Specimen Priorities |
14 |
20 |
CQ |
O |
00654 |
Specimen Retention Time |
Definition: This field contains the same value as the sequence number of the associated OM1 segment.
Definition:
This field contains the codes that identify the parents and children for
diagnostic studies -- especially in microbiology -- where the initial specimen
(e.g., blood) is processed to produce results (e.g., the identity of the
bacteria grown out of the culture). The process also produces new "specimens"
(e.g., pure culture of staphylococcus, and E. Coli), and these are studied by a
second order process (bacterial sensitivities). The parents (e.g., blood
culture) and children (e.g., penicillin MIC) are identified in such cases.
Refer to HL7 Table 0170 - Derived specimen for valid values:
Value |
Description |
|---|---|
P |
Parent Observation |
C |
Child Observation |
N |
Not Applicable |
Definition: This field contains the physical appearance, including color of tube tops, shape, and material composition (e.g., red-top glass tube). Note that the color is not necessarily a unique identifier of the additive and/or use of the tube. This is especially true for black and some blue tube tops, as can be seen above. Color is included here for user convenience.
Definition: This field indicates the capacity of the container.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the units of measure of the container volume.
If the units are ISO+ units, they should be recorded as single case
abbreviations. If the units are ANS+ or L (local), the units and the source
code table must be recorded, except that in this case, component delimiters
should be replaced by subcomponent delimiters. For example, 1 indicates
liters, whereas pt&&ANS+ indicates pints (ANSI units). The default
unit is milliliters (ml), which should be assumed if no units are reported.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field reports the specimen as one of the specimen codes
described in ASTM Table 14 of 1238-91. If multiple kinds of specimen are
associated with this observation (as in the case for a creatinine clearance),
separate them with repeat delimiters.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the codes that should be those provided by
NCCLS[3]. Refer to HL7 table 0371 -
Additive for valid values. The table's values are taken from NCCLS
AUTO4. The value set can be extended with user specific values.
Value |
Description |
|---|---|
EDTK |
Potassium/K EDTA |
EDTN |
Sodium/Na EDTA |
HEPL |
Lithium/Li Heparin |
HEPN |
Sodium/Na Heparin |
C32 |
3.2% Citrate |
C38 |
3.8% Citrate |
BOR |
Borate |
HCL6 |
6N HCL |
This table was not specified in previous versions and thus sites may choose to use other site-specific tables.
Definition: This field contains the special processing that should be applied to the container, e.g., add acidifying tablets before sending.
Definition: This field contains the special handling requirements here (e.g., ice specimen, deliver within two hours of obtaining).
Components:
<quantity (NM)> ^ <units (CE)>
Definition: This field contains the normal specimen volume required by the
lab. This is the amount used by the normal methods and provides enough
specimens to repeat the procedure at least once if needed. The default unit is
milliliters (ml).
Components:
<quantity (NM)> ^ <units (CE)>
Definition: This field contains the amount of specimen needed by the most
specimen sparing method (e.g., using micro techniques). The minimum amount
allows for only one determination. The default unit is milliliters (ml).
Definition: This field contains the other requirements for specimen delivery and special handling (e.g., delivery within one hour, iced).
Definition:
This field contains the allowed priorities for obtaining the specimen. Note
that they may be different from the processing priorities given in OM1-25
- Processing priority. When a test is requested, the specimen priority
given in OBR-27 - Quantity/timing should be one of the priorities
listed here. Multiple priorities are separated by repeat delimiters. Refer to
HL7 Table 0027 - Priority for valid values.
Value |
Description |
|---|---|
S |
Stat (do immediately) |
A |
As soon as possible (a priority lower than stat) |
R |
Routine |
P |
Preoperative (to be done prior to surgery) |
T |
Timing critical (do as near as possible to requested time) |
Components:
<quantity (NM)> ^ <units (CE)>
Definition: This field contains the usual time that a specimen for this
observation is retained after the observation is completed, for the purpose of
additional testing. The first component is the duration, and the second
component is an ISO time unit.
The
Technical Steward for the OM5 segment is ORDERS.
This segment contains the information about batteries and supersets (a nature
code of F, P or S, as described in OM1-18 - Nature of
service/test/observation).
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
NM |
O |
00586 |
Sequence Number- Test/Observation Master File |
||
2 |
250 |
CE |
O |
Y |
9999 |
00655 |
Test/Observations Included within an Ordered Test Battery |
3 |
250 |
ST |
O |
00656 |
Observation ID Suffixes |
Definition: This field contains the same value as the sequence number of the associated OM1 segment.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the codes and names of all tests/observations
included within a single battery (nature code P, as described in OM1-18 -
Nature of service/test/observation), a single functional procedure
(nature code F), or a given superset (nature code S). When a segment includes
a list of component elements, the sending system should be sure that the
segments defining all of the components are sent before the segment that
references them. An entry in this list can itself be a battery.
The individual service/test/observation IDs should be recorded as type CE,
i.e., in the standard format for coded observation identifiers. Multiple
observations should be separated by repeat delimiters.
If the definition segment defined serum electrolytes, this field might look
like the following:
84132^potassium^AS4~
84295^sodium^AS4~
82435^chloride^AS4~
82374^HCO3^^AS4~
For S (superset) parameters, this field contains the batteries that are
included within the "super" battery. For example, ROUTINES might be defined
as:
402^Electrolytes~352^Urinalysis~432^CBC~520^SMA12
Definition: This field contains the tests or procedures that produce a type which uses observation ID suffixes following the service/test/observation ID code. This field lists the possible options. The applicable three-character mnemonics given in ASTM Table 20 (or others appropriate to the application) are listed, separated by repeat delimiters. For example, a chest X-ray may use the suffixes IMP, REC, DEV, or others. Each of the expected suffixes should be listed here.
The
Technical Steward for the OM6 segment is ORDERS.
This segment contains the information about quantities that are derived from
one or more other quantities or direct observations by mathematical or logical
means.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
NM |
O |
00586 |
Sequence Number- Test/Observation Master File |
||
2 |
10240 |
TX |
O |
00657 |
Derivation Rule |
Definition: This field contains the same value as the sequence number of the associated OM1 segment.
Definition:
This field is used when there are patient variables that are derived from one
or more other patient variables (e.g., creatinine clearance, ideal weight,
maximum daily temperature, average glucose, framingham risk). This field
contains the rules for deriving the value of this variable (i.e., nature code
C, as given in OM1-18 - Nature of service/test/observation).
These can be described in terms of humanly understandable formulas or
descriptions.
When possible, however, they should be defined in terms of the Arden Syntax for
specifying selection and transcendative functions and algebraic operations,
ASTM E1460-92. Derivation rules that are represented in Arden Syntax should
begin and end with an Arden slot delimiter (;;). Within this syntax, variables
should be identified by OM1-2 - Producer's service/test/observation
ID. We recommend the use of the Arden Syntax because it permits the
unambiguous specification of most such derived values and is a published
standard for medical logic modules.
The
OM7 segment contains additional basic attributes that apply to the definition
of most observations/services.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
NM |
R |
00586 |
Sequence Number - Test/Observation Master File |
||
2 |
250 |
CE |
R |
00238 |
Universal Service Identifier |
||
3 |
250 |
CE |
O |
Y |
0412 |
01481 |
Category Identifier |
4 |
200 |
TX |
O |
01482 |
Category Description |
||
5 |
200 |
ST |
O |
Y |
01483 |
Category Synonym |
|
6 |
26 |
TS |
O |
01484 |
Effective Test/Service Start Date/Time |
||
7 |
26 |
TS |
O |
01485 |
Effective Test/Service End Date/Time |
||
8 |
5 |
NM |
O |
01486 |
Test/Service Default Duration Quantity |
||
9 |
250 |
CE |
O |
9999 |
01487 |
Test/Service Default Duration Units |
|
10 |
60 |
IS |
O |
0335 |
01488 |
Test/Service Default Frequency |
|
11 |
1 |
ID |
O |
0136 |
01489 |
Consent Indicator |
|
12 |
250 |
CE |
O |
0413 |
01490 |
Consent Identifier |
|
13 |
26 |
TS |
O |
01491 |
Consent Effective Start Date/Time |
||
14 |
26 |
TS |
O |
01492 |
Consent Effective End Date/Time |
||
15 |
5 |
NM |
O |
01493 |
Consent Interval Quantity |
||
16 |
250 |
CE |
C |
0414 |
01494 |
Consent Interval Units |
|
17 |
5 |
NM |
O |
01495 |
Consent Waiting Period Quantity |
||
18 |
250 |
CE |
C |
0414 |
01496 |
Consent Waiting Period Units |
|
19 |
26 |
TS |
O |
00607 |
Effective Date/Time of Change |
||
20 |
250 |
XCN |
O |
00224 |
Entered By |
||
21 |
200 |
PL |
O |
Y |
01497 |
Orderable-at Location |
|
22 |
1 |
IS |
O |
0473 |
01498 |
Formulary Status |
|
23 |
1 |
ID |
O |
0136 |
01499 |
Special Order Indicator |
|
24 |
250 |
CE |
O |
Y |
0132 |
01306 |
Primary Key Value - CDM |
Definition: This field contains the value as the sequence number.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the producer's usual or preferred
identification of the test or service. The test/service ID may be any of those
included in ASTM tables 3 and 5, or a local code.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the category name (term given to a group of
service items for the purpose of classification). Examples: Laboratory,
Pharmacy, Diagnostic Imaging, etc. Refer to User-defined Table 0412 -
Category identifier for suggested values.
Value |
Description |
|---|---|
No suggested values defined |
Definition:
This field contains a text description for the category of the test/service
item.
Example: The category "Pathology" may be described as a specialty practice
concerned with all aspects of disease, with special reference to the essential
natural cause and development of abnormal conditions, as well as the structural
and functional changes that result from the disease process.
Definition: This field contains an alternate name(s) for the category of the test/service. Example: The category "Radiology" is a synonym name for the category " Diagnostic Imaging".
Definition: This field contains the date and time that the service item is available to be ordered, performed, etc.
Definition: This field contains the date and time that the service item is no longer authorized to be ordered, performed, etc.
Definition: This field indicates the default duration quantity for the service.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field indicates the default duration units for the service.
Definition: This field indicates the default frequency (how often) the service would be ordered for or performed on.
Definition:
This field indicates if a consent is needed for the service item. Refer to
HL7 Table 0136 - Yes/no indicator.
Y A consent is required for service item to be ordered/performed.
N No consent is needed for service item to be ordered/performed
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the identifier for the consent specified for
the service item. Refer to User-defined Table 0413 - Consent
identifier for suggested values.
Value |
Description |
|---|---|
No suggested values defined |
Definition: This field contains the date and time the consent is valid for the service item.
Definition: This field contains the date and time the consent is no longer valid for the test/service.
Definition: This field specifies the period of time for which a consent is valid for a specific service item.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field specifies the unit of time for OM7-15 - Consent
interval quantity. Refer to
User-defined
Table 0414 - Units of time for suggested values.
Value |
Description |
|---|---|
No suggested values defined |
Note: If Consent Interval Quantity is specified, then Consent Interval Unit is required.
Definition: This field contains the time period between the time the consent is signed and the procedure can be performed.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field specifies the unit of time for OM7-17 - Consent
waiting period quantity. Refer to User-defined Table 0414 - Units
of time for suggested values.
Note: If Consent Waiting Period Quantity is specified, then
Consent Waiting Period Unit is required.
Definition: This field contains the date and time of the last change in the test procedure that would make previous results incompatible with new results.
Components:
<ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^
<second or further given names or initials thereof (ST)> ^ <suffix
(e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g.,
MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^
<name type code (ID)> ^ <identifier check digit (ST)> ^ <code
identifying the check digit scheme employed (ID)> ^ <identifier type code
(IS)> ^ <assigning facility (HD)> ^ <name representation code
(ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ <
name assembly order (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)
Definition: This field contains the identity of the person who actually keyed
the service item into the application. It provides an audit trail in case the
request is entered incorrectly and the ancillary department needs to clarify
the request.
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ < location status (IS)> ^ <person location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location
description (ST)>
Subcomponents of facility: <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains the location(s) where the test/service can be
ordered.
Definition:
This field indicates whether or not the service (pharmaceutical) is in the
formulary. Refer to User-defined Table 0473 - Formulary status for
valid values.
Value |
Description |
|---|---|
G |
This observation/service is on the formulary, and has guidelines |
N |
This observation/service is not on the formulary |
R |
This observation/service is on the formulary, but is restricted |
Y |
This observation/service is on the formulary |
Definition:
This field indicates whether or not the service (pharmaceutical) is a special
order. Refer to HL7 Table 0136 - Yes/no indicator for valid
values.
Y This is a special order.
N This is not a special order
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: Allows the ability to associate a Service/Test/Observation item
with a CIM (charge item master). It is possible to allow multiple charge
items to a single SIM item.
This
section is specifically concerned with describing a master file message that
should be used to transmit information which identifies the inventory of
healthcare patient locations, such as nursing units, rooms, beds, clinics, exam
rooms, etc. In a network environment, this segment can be used to define
patient locations to other applications. The segment also includes the
readiness states and support locations for the patient locations.
The LOC, LCH, LRL, LDP, and LCC segments must be preceded by the MFI and MFE
segments, as described in Sections 8.9.2, "LOC - location identification
segment," through 8.9.68.4." In the following message, the MFI-1 -
Master file identifier field should equal "LOC"
MFN^M05^MFN_M05 |
Master File Notification |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MFI |
Master File Identification |
8 |
{MFE |
Master File Entry |
8 |
LOC |
Patient Location Master |
8 |
[{LCH}] |
Location Characteristic |
8 |
[{LRL}] |
Location Relationship |
8 |
{ LDP |
Location Department |
8 |
[{LCH}] |
Location Characteristic |
8 |
[{LCC}] |
Location Charge Code |
8 |
} |
||
} |
When
the LCH segment appears immediately following the LOC segment, it communicates
characteristics which are the same across multiple departments that may use the
same room. When the LCH segment appears immediately following the LDP segment,
it communicates characteristics which differ for different departments that may
use the same room.
MFK^M05^MFK_M01 |
Master File Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Acknowledgment |
2 |
MFI |
Master File Identification |
8 |
[{MFA}] |
Master File ACK |
8 |
Master
Files Query Response: When the LOC segment is used in the MFR message, the part
of the message represented by:
{MFE |
||
[Z..]} |
is
replaced by:
The
Technical Steward for the LOC segment is PAFM.
The LOC segment can identify any patient location referenced by information
systems. This segment gives physical set up information about the location.
This is not intended to include any current occupant or current use
information. There should be one LOC segment for each patient location. If
desired, there can also be one LOC segment for each nursing unit and room.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
200 |
PL |
R |
01307 |
Primary Key Value - LOC |
||
2 |
48 |
ST |
O |
00944 |
Location Description |
||
3 |
2 |
IS |
R |
Y |
0260 |
00945 |
Location Type - LOC |
4 |
250 |
XON |
O |
Y |
00947 |
Organization Name - LOC |
|
5 |
250 |
XAD |
O |
Y |
00948 |
Location Address |
|
6 |
250 |
XTN |
O |
Y |
00949 |
Location Phone |
|
7 |
250 |
CE |
O |
Y |
0461 |
00951 |
License Number |
8 |
3 |
IS |
O |
Y |
0261 |
00953 |
Location Equipment |
9 |
1 |
IS |
O |
0442 |
01583 |
Location Service Code |
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <person location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location
description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field contains the institution's identification code for the
location. The identifying key value. Must match MFE-4 -Primary key
value. This field has the same components as the patient location
fields in the PV1 segment (except that bed status is not included here).
At least the first component of this field is required. The first component
can be an identifying code for the nursing station for inpatient locations, or
clinic, department or home for patient locations other than inpatient ones.
Definition: This field contains the optional free text description of the location, to elaborate upon LOC primary key value.
Definition:
This field contains the code identifying what type of location this is. Refer
to User-defined Table 0260 - Patient location type for
suggested values.
Value |
Description |
|---|---|
N |
Nursing Unit |
R |
Room |
B |
Bed |
E |
Exam Room |
O |
Operating Room |
C |
Clinic |
D |
Department |
L |
Other Location |
Components:
<organization name (ST)> ^ <organization name type code (IS)> ^
<ID number (NM)> ^ <check digit (NM)> ^ <code identifying the
check digit scheme employed (ID)> ^ <assigning authority (HD)> ^
<identifier type code (IS)> ^ <assigning facility ID (HD)> ^
<name representation code (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the organization(s) of which this location is
a part. For inpatient locations, this can be the hospital or institution name.
For outpatient locations, this can be the clinic or office name.
Components:
In Version 2.3 and later, replaces the AD data type. <street address
(SAD)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or
province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^
< address type (ID)> ^ <other geographic designation (ST)>
^ <county/parish code (IS)> ^ <census tract (IS)> ^
<address representation code (ID)> ^ <address validity range
(DR)>
Definition: This field contains the address of the patient location,
especially for use for outpatient clinic or office locations.
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^ <telecommunication
use code (ID)> ^ <telecommunication equipment type (ID)> ^ <email
address (ST)> ^ <county code (NM)> ^ <area/city code (NM)> ^
<phone number (NM) ^ <extension (NM)> ^ <any text (ST)>
Definition: This field contains the phone number within the patient location,
if any. For example, the room or bed phone for use by the patient.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the multiple license numbers for the facility.
Refer to User-defined Table 0461 - License number for
suggested values.
Value |
Description |
|---|---|
No suggested values |
Definition:
This repeating field indicates what types of equipment are built in. Applies
only to room or bed locations. If LOC-3 - Location type indicates
that this is a room, this will be the equipment in the room which can be used
by more than one bed. If LOC-3 - Location type indicates this is
a bed, this will be the bedside devices available to this bed. Refer to
User-defined Table 0261 - Location equipment for suggested
values.
Value |
Description |
|---|---|
OXY |
Oxygen |
SUC |
Suction |
VIT |
Vital signs monitor |
INF |
Infusion pump |
IVP |
IV pump |
EEG |
Electro-Encephalogram |
EKG |
Electro-Cardiogram |
VEN |
Ventilator |
Definition:
This field categorizes the types of services provided by the location. Refer
to User-defined Table 0442 - Location service code for suggested
values.
Value |
Description |
|---|---|
D |
Diagnostic |
T |
Therapeutic |
P |
Primary Care |
E |
Emergency Room Casualty |
The
Technical Steward for the LCH segment is PAFM.
The LCH segment is used to identify location characteristics which determine
which patients will be assigned to the room or bed. It contains the location
characteristics of the room or bed identified in the preceding LOC segment.
There should be one LCH segment for each attribute.
When the LCH segment appears immediately following the LOC segment, it
communicates characteristics which are the same across multiple departments
that may use the same room. When the LCH segment appears immediately following
the LDP segment, it communicates characteristics which differ for different
departments that may use the same room. For example, the following
characteristics are more likely to vary by which department is using the room:
teaching, gender, staffed, set up, overflow, whereas the other characteristics
are likely to remain the same.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
200 |
PL |
R |
01305 |
Primary Key Value - LCH |
||
2 |
3 |
ID |
O |
0206 |
00763 |
Segment Action Code |
|
3 |
80 |
EI |
O |
00764 |
Segment Unique Key |
||
4 |
250 |
CE |
R |
0324 |
01295 |
Location Characteristic ID |
|
5 |
250 |
CE |
R |
0136/ 0262/ 0263 |
01294 |
Location Characteristic Value-LCH |
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <person location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location
description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field contains the institution's identification code for the
location. The identifying key value. This field has the same components as
the patient location fields in the PV1 segment (except that bed status is not
included here). At least the first component of this field is required. The
contents of this field must exactly match the content of its preceding MFE
(MFE-4 - Primary key value - MFE), its preceding LOC (LOC-1
- Primary key value - LOC), and its preceding LDP (LDP-1 - Primary
key value - LDP).
Definition: This field indicates whether this repetition of the segment is being added, changed or deleted. -- The action code adds a validation check to indicate, from the point of view of the sending system, whether this repetition of a segment is being added, changed or deleted. This and the following field are used to implement the "unique key" mode of updating repeating segments. (See Chapter 2, Section 2.23.4.2, "Action code/unique identifier mode update definition.") Refer to HL7 Table 0206 - Segment action code for valid values.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains a unique identifier for one of the multiple
repetitions of this segment, to be used in conjunction with the preceding
field. Each of the repetitions of the segment will be uniquely identified by
this unique key field for the purposes of updates.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains an identifier code to show WHICH
characteristic is being communicated with this segment. Refer to
User-defined Table 0324 - Location characteristic ID for suggested
values.
Value |
Description |
|---|---|
SMK |
Smoking |
LIC |
Licensed |
IMP |
Implant: can be used for radiation implant patients |
SHA |
Shadow: a temporary holding location that does not physically exist |
INF |
Infectious disease: this location can be used for isolation |
PRL |
Privacy level: indicating the level of private versus non-private room |
LCR |
Level of care |
OVR |
Overflow |
STF |
Bed is staffed |
SET |
Bed is set up |
GEN |
Gender of patient(s) |
TEA |
Teaching location |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the value of the above field's characteristic.
The expected coded values for this field will depend upon the previous field.
For example, if the previous field is SMK, IMP, INF, the values would be "Y" or
"N".
When LCH-4-location characteristic ID contains "SHA"- Shadow, refer to
HL7 Table 0136 - Yes/no indicator for valid values for LRL-5
- Organizational location relationship value.
Y not a real bed, but a temporary holding location that does not physically
exist in the census
N this is a real bed
When LCH-4 - Location characteristic ID contains "PRL"- Privacy
level (CE), then LRL-5 - Organizational location relationship
value indicates how the room is set up and intended to be used,
disregarding different uses under special circumstances. Refer to
User-defined Table 0262 - Privacy level for suggested values.
Value |
Description |
|---|---|
F |
Isolation |
P |
Private room |
J |
Private room - medically justified |
Q |
Private room - due to overflow |
S |
Semi-private room |
W |
Ward |
When
LCH-4 - Location characteristic ID contains "LCR"- Level of care,
then LRL-5 - Organizational location relationship value contains
the code which indicates what severity of the patient's medical condition which
this location is designed to handle. This indicates how the room is set up and
intended to be used, disregarding different uses under special circumstances.
Refer to User-defined Table 0263 - Level of care for
suggested values.
Value |
Description |
|---|---|
A |
Ambulatory |
E |
Emergency |
F |
Isolation |
N |
Intensive care |
C |
Critical care |
R |
Routine |
S |
Surgery |
When
LCH-4 - Location characteristic ID contains "IFD"- Infectious
disease, refer to HL7 Table 0136 - Yes/no indicator for valid
values for LRL-5 - Organizational location relationship value.
Y patients with infectious diseases can be admitted to this location, that is,
this location can be used for isolation
N this location cannot be used for isolation
When LCH-4 - Location characteristic ID contains "SMO"- Smoking,
refer to HL7 Table 0136 - Yes/no indicator for valid values for
LRL-5 - Organizational location relationship value.
Y this is a smoking location
N this is a non-smoking location
When LCH-4 - Location characteristic ID contains "IMP"- Implant,
refer to HL7 Table 0136 - Yes/no indicator for valid values for
LRL-5 - Organizational location relationship value.
Y this location can be used by radiation implant patients
N this location can not be used by radiation implant patients
When LCH-4 - Location characteristic ID contains "LIC"- Licensed,
refer to HL7 Table 0136 - Yes/no indicator for valid values for
LRL-5 - Organizational location relationship value.
Y this location is licensed
N this location is not licensed
The
Technical Steward for the LRL segment is PAFM.
The LRL segment is used to identify one location's relationship to another
location, the nearest lab, pharmacy, etc.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
200 |
PL |
R |
00943 |
Primary Key Value - LRL |
||
2 |
3 |
ID |
O |
0206 |
00763 |
Segment Action Code |
|
3 |
80 |
EI |
O |
00764 |
Segment Unique Key |
||
4 |
250 |
CE |
R |
0325 |
01277 |
Location Relationship ID |
|
5 |
250 |
XON |
C |
Y |
01301 |
Organizational Location Relationship Value |
|
6 |
80 |
PL |
C |
01292 |
Patient Location Relationship Value |
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <person location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location
description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field contains the institution's identification code for the
location. The identifying key value. This field has the same components as
the patient location fields in the PV1 segment (except that bed status is not
included here). At least the first component of this field is required. The
contents of this field must exactly match the content of its preceding MFE
(MFE-4 - Primary key value - MFE), its preceding LOC (LOC-1
- Primary key value - LOC), and its preceding LDP (LDP-1 - Primary
key value - LDP).
Definition: This field indicates whether this repetition of the segment is being added, changed or deleted. The action code adds a validation check to indicate, from the point of view of the sending system, whether this repetition of a segment is being added, changed or deleted. This and the following field are used to implement the "unique key" mode of updating repeating segments. (See Chapter 2, Section 2.23.4.2, "Action code/unique identifier mode update definition.") Refer to HL7 Table 0206 - Segment action code for valid values.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains a unique identifier for one of the multiple
repetitions of this segment, to be used in conjunction with the preceding
field. Each of the repetitions of the segment will be uniquely identified by
this unique key field for the purposes of updates.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains an identifier code to show WHICH relationship
is being communicated with this segment. Refer to User-defined Table
0325 - Location relationship ID for suggested values.
Value |
Description |
|---|---|
RX |
Nearest pharmacy |
RX2 |
Second nearest pharmacy |
LAB |
Nearest lab |
LB2 |
Second nearest lab |
DTY |
Nearest dietary location |
ALI |
Location Alias(es) |
PAR |
Parent location |
Components:
<organization name (ST)> ^ <organization name type code (IS)> ^
<ID number (NM)> ^ <check digit (NM)> ^ <code identifying the
check digit scheme employed (ID)> ^ <assigning authority (HD)> ^
<identifier type code (IS)> ^ <assigning facility ID (HD)> ^
<name representation code(ID)
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field is conditional on the value of LRL-4 -
Location relationship ID. When LRL-4 -Location
relationship ID contains "RX"- Nearest Pharmacy, "RX2"- Other Pharmacy,
"LAB"- Nearest Lab, "LB2"- Other Lab, or "DTY"- Dietary, this field holds that
organization's extended name i.e., the value of this field is conditional on
the value of LRL-4 - Location relationship ID. For
example, for an inpatient location, this could be an in-house department ID
code using only the third component of this data type. For an outpatient
location, this could be the nearest external pharmacy.
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <person location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location
description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field is conditional on the value of LRL-4 -
Location relationship ID. When LRL-4 -Location relationship
ID contains "ALI"- Location aliases or "PAR"- Parent location this field
holds the value of the associated patient location.
When LRL-4 - Location relationship ID contains "PAR"- Parent, this
field holds the value of the parent location to allow for nested entries. For
example, a bed entry can point to its containing room or nurse unit. The value
for the parent location should match the LOC-1 - Primary key value
- LOC of the parent entry. Not intended to be used for multiple
designations of the same physical location, but for identifying the larger
physical locations (supersets) which include this physical location as a subset.
The
Technical Steward for the LDP segment is PAFM.
The LDP segment identifies how a patient location room is being used by a
certain department. Multiple departments can use the same patient location, so
there can be multiple LDP segments following an LOC segment. There must be at
least one LDP segment for each LOC segment. This is not intended to include
any current occupant information.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
200 |
PL |
R |
00963 |
Primary Key Value - LDP |
||
2 |
250 |
CE |
R |
0264 |
00964 |
Location Department |
|
3 |
3 |
IS |
O |
Y |
0069 |
00965 |
Location Service |
4 |
250 |
CE |
O |
Y |
0265 |
00966 |
Specialty Type |
5 |
1 |
IS |
O |
Y |
0004 |
00967 |
Valid Patient Classes |
6 |
1 |
ID |
O |
0183 |
00675 |
Active/Inactive Flag |
|
7 |
26 |
TS |
O |
00969 |
Activation Date LDP |
||
8 |
26 |
TS |
O |
00970 |
Inactivation Date - LDP |
||
9 |
80 |
ST |
O |
00971 |
Inactivated Reason |
||
10 |
80 |
VH |
O |
Y |
0267 |
00976 |
Visiting Hours |
11 |
250 |
XTN |
O |
00978 |
Contact Phone |
||
12 |
250 |
CE |
O |
0462 |
01584 |
Location Cost Center |
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ < location status (IS)> ^ <person location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location
description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST)> & <universal ID type (ID)>
Definition: This field contains the institution's identification code for the
location. The identifying key value. This field has the same components as
the patient location fields in the PV1 segment (except that bed status is not
included here). At least the first component of this field is required. The
contents of this field must exactly match the content of its preceding MFE
(MFE-4 - Primary key value - MFE) and its preceding LOC
(LOC-1 - primary key value - LOC).
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the institution's department to which this
location belongs, or its cost center. Refer to User-defined Table 0264 -
Location department for suggested values.
Value |
Description |
|---|---|
No suggested values defined |
Definition:
This field contains the hospital or ancillary service with which this location
is associated. Depends on institution use. Repeats for rooms that can be
used, for example, by different services on different days. These values
should match the values used for PV1-10 - Hospital service, which
is site defined. Refer to User-defined Table 0069 - Hospital
service for suggested values.
Value |
Description |
|---|---|
No suggested values defined |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the specialty type (if any) of the department
or clinic. This may also be considered a bed type. Specialty type is a
physical accommodation type, whereas `accommodation type' (LCC-3 -
Accommodation type) is a financial accommodation type. Refer to
User-defined Table 0265 - Specialty type for suggested values.
See also LCH-4 - Location characteristic ID and LHC-5 -
Location characteristic value.
Value |
Description |
|---|---|
AMB |
Ambulatory |
PSY |
Psychiatric |
PPS |
Pediatric psychiatric |
REH |
Rehabilitation |
PRE |
Pediatric rehabilitation |
ISO |
Isolation |
OBG |
Obstetrics, gynecology |
PIN |
Pediatric/neonatal intensive care |
INT |
Intensive care |
SUR |
Surgery |
PSI |
Psychiatric intensive care |
EDI |
Education |
CAR |
Coronary/cardiac care |
NBI |
Newborn, nursery, infants |
CCR |
Critical care |
PED |
Pediatrics |
EMR |
Emergency |
OBS |
Observation |
WIC |
Walk-in clinic |
PHY |
General/family practice |
ALC |
Allergy |
FPC |
Family planning |
CHI |
Chiropractic |
CAN |
Cancer |
NAT |
Naturopathic |
OTH |
Other specialty |
Definition: This field contains the patient types that are allowed to be assigned to this bed. For example, Inpatient, Outpatient, Series, Clinic, ER, Ambulatory, Observation, etc. These values should be the same set of values as those used for PV1-2 - Patient class. Refer to User-defined Table 0004 - Patient class for suggested values.
Definition: This field indicates whether the entry for this location is currently an active, that is, valid, usable entry (disregarding whether it's waiting to be maintained by housekeeping). Refer to HL7 Table 0183 - Active/inactive for valid values.
Definition: This field contains the date and time when the location became active or "in service" for a department (disregarding whether it is waiting to be maintained by housekeeping).
Definition: This field contains the date when the location became inactive or "out of service" for this department (disregarding whether it is waiting to be maintained by housekeeping).
Definition: This field contains the reason the location was put out of service. It is used when LDP-8 - Inactivation date-LDP is sent.
Components:
<start day range (ID)> ^ <end day range (ID)> ^ <start hour
range (TM)> ^ <end hour range (TM)>
Definition: This field contains the hours when this location is open for
visiting. Refer to HL7 Table 0267 - Days of the week for
valid values for the first two components.
Value |
Description |
|---|---|
SAT |
Saturday |
SUN |
Sunday |
MON |
Monday |
TUE |
Tuesday |
WED |
Wednesday |
THU |
Thursday |
FRI |
Friday |
Components:
[NNN] [(999)]999-9999 [X99999] [B99999] [C any text] ^
<telecommunication use code (ID)> ^ <telecommunication equipment type
(ID)> ^ <email address (ST)> ^ <county code (NM)> ^
<area/city code (NM)> ^ <phone number (NM) ^ <extension (NM)> ^
<any text (ST)>
Definition: This field contains the phone number to use to contact facility
personnel about the patient location, in case of inquiries about the location.
This phone is not necessarily within the named patient location.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the cost center to which this location
belongs. Refer to User-defined Table 0462 - Location cost
center for suggested values.
Value |
Description |
|---|---|
No suggested values defined |
The
Technical Steward for the LCC segment is PAFM.
The optional LCC segment identifies how a patient location room can be billed
by a certain department. A department can use different charge codes for the
same room or bed, so there can be multiple LCC segments following an LDP
segment.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
200 |
PL |
R |
00979 |
Primary Key Value - LCC |
||
2 |
250 |
CE |
R |
0264 |
00964 |
Location Department |
|
3 |
250 |
CE |
O |
Y |
0129 |
00980 |
Accommodation Type |
4 |
250 |
CE |
R |
Y |
0132 |
00981 |
Charge Code |
Components:
<point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^
<facility (HD)> ^ <location status (IS)> ^ <person location
type (IS)> ^ <building (IS)> ^ <floor (IS)> ^ <location
description (ST)>
Subcomponents of facility: <namespace ID (IS)> & <universal
ID (ST) & <universal ID Type (ID)
Definition: This field contains the institution's identification code for the
location. The identifying key value. This field has the same components as
the patient location fields in the PV1 segment (except that bed status is not
included here). At least the first component of this field is required. The
content of this field must exactly match the content of its preceding MFE
(MFE-4 - Primary key value - MFE), its preceding LOC (LOC-1
- LOC primary key value), and its preceding LDP (LDP-1 - Primary
key value - LDP).
Definition: This field contains the institution's department to which this location belongs, or its cost center. It may match the value in its preceding LDP (LDP-2 - Location department or LDP-12 - Location cost center. Refer to User-defined Table 0264 - Location department for suggested values.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the financial accommodation type of the bed or
room which implies the rate to be used when occupied by a patient under
specific medical conditions, which determines how it is billed. Not the same
as specialty type. Used for general ledger categories. Specialty type is a
physical accommodation type, whereas this field is a financial accommodation
type. Repeating coded value. Refer to User-defined Table 0129 -
Accommodation code for suggested values.
Value |
Description |
|---|---|
No suggested values defined |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the repeating coded entry for codes
identifying how the use of this location is to be charged. For
cross-referencing beds master files with the charge master files, or for
generating charges when a patient is assigned to a bed. These should be the
same set of values used in FT1-7 -Transaction code.
Refer to User-defined Table 0132 - Transaction code for suggested
values.
MSH|^~\&|HL7REG|UH|HL7LAB|CH|19910918060544||MFN^M05|MSGID002|P|2.4||AL|NE<cr>
MFI|LOC||UPD|||AL<cr>
MFE|MAD|PMF98123789182|199110011230|3A^RM17^17-2^FAC1<cr>
LOC|3A^RM17^17-2^FAC1|BEST BED IN UNIT|B|UNIVERSITY HOSPITAL|54326 SAND P0INT
WAY^^SEATTLE^WA^98199|(206)689-1329|92837465998|OXY<cr>
LCH|3A^RM17^17-2^FAC1|||IMP|Y<cr>
LRL|3A^RM17^17-2^FAC1|||LAB|3WEST PATH LAB<cr>
LDP|3A^RM17^17-2^FAC1|PED|MED|PIN|I|A|19941004||||(206)689-1363<cr>
LCC|3A^RM17^17-2^FAC1|PED|PIC|R38746<cr>
The
charge description (CDM) master file segment should be used in conjunction with
the general master file segments in Section 8.5, "GENERAL MASTER FILE
SEGMENTS." Interfacing systems often need not only to communicate data about a
patient's detailed charges, but also to communicate the charge identification
entries by which an application knows how to handle a particular charge code.
The charge description master is a master file. The CDM segment below is a
specially designed master file segment for interfacing charge description
masters. In the following message, the MFI-master file identifier should equal
"CDM." When the CDM segment is used in an MFN message, the abstract definition
is as follows:
MFN^M04^MFN_M04 |
Master File Notification |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MFI |
Master File Identification |
8 |
{MFE |
Master File Entry |
8 |
CDM |
Charge Description Master |
8 |
{ [PRC] } |
Price Segment |
8 |
} |
MFK^M04^MFK_M01 |
Master File Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Acknowledgment |
2 |
MFI |
Master File Identification |
8 |
{ [MFA] } |
Master File ACK segment |
8 |
Master
File Response Message: When the CDM segment is used in the MFR message, the
part of the message represented by:
{MFE |
||
[Z..] } |
is
replaced by:
{MFE |
||
CDM |
|
|
{ [PRC] } |
|
|
} |
The
Technical Steward for the CDM segment is PAFM.
The CDM segment contains the fields for identifying anything which is charged
to patient accounts, including procedures, services, supplies. It is intended
to be used to maintain a list of valid chargeable utilization items. Its
purpose is to keep billing codes synchronized between HIS, Patient Accounting,
and other departmental systems. It is not intended to completely support
materials management, inventory, or complex pricing structures for which
additional complex fields would be required. Given an identifying charge code,
the associated fields in the charge description master file will provide basic
pricing and billing data. All the additional information necessary for patient
accounting systems to do billing and claims is not intended to be included in
this segment; those should be part of insurance or billing profile tables.
The CDM segment contains the fields which, for one chargeable item, remain the
same across facilities, departments, and patient types. The following PRC
segment contains the fields which, for the same chargeable item, vary depending
upon facility or department or patient type.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
250 |
CE |
R |
0132 |
01306 |
Primary Key Value - CDM |
|
2 |
250 |
CE |
O |
Y |
9999 |
00983 |
Charge Code Alias |
3 |
20 |
ST |
R |
00984 |
Charge Description Short |
||
4 |
250 |
ST |
O |
00985 |
Charge Description Long |
||
5 |
1 |
IS |
O |
0268 |
00986 |
Description Override Indicator |
|
6 |
250 |
CE |
O |
Y |
9999 |
00987 |
Exploding Charges |
7 |
250 |
CE |
O |
Y |
0088 |
00393 |
Procedure Code |
8 |
1 |
ID |
O |
0183 |
00675 |
Active/Inactive Flag |
|
9 |
250 |
CE |
O |
Y |
0463 |
00990 |
Inventory Number |
10 |
12 |
NM |
O |
00991 |
Resource Load |
||
11 |
250 |
CK |
O |
Y |
00992 |
Contract Number |
|
12 |
250 |
XON |
O |
Y |
00993 |
Contract Organization |
|
13 |
1 |
ID |
O |
0136 |
00994 |
Room Fee Indicator |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the code assigned by the institution for the
purpose of uniquely identifying the thing that can be charged. The key field
of the entry. For example, this field would be used to uniquely identify a
procedure, item, or test for charging purposes. Probably the same set of
values as used in FT1-7- Transaction code in financial messages.
Must match MFE-4 - Primary key value - MFE. Refer to
User-defined Table 0132 - Transaction for suggested values. See Chapter
7 for discussion of the universal service ID.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains an alternative charge code. For example,
points to another charge description master entry in cases where one code
supersedes or overrides another code. Repeating field allows for different
codes used by different systems which should be handled as if they were the
same; for example, the general ledger code may differ from the billing code.
Or, in a multi-facility environment which does facility-specific pricing, there
may be more than one of these master file entries for one charge description,
each with a different facility.
Definition: This field contains the text abbreviations or code that is associated with this CDM entry.
Definition: This field contains the full text description of this CDM entry.
Definition:
This field indicates whether this CDM entry's description can be overridden.
Refer to User-defined Table 0268 - Override for suggested
values.
Value |
Description |
|---|---|
X |
Override not allowed |
A |
Override allowed |
R |
Override required |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the repeating occurrences for a list of other
CDM entry charge codes identifying the other charges which should be generated
from this CDM entry. If non-null, posting a charge to this CDM entry should
result in posting the charges identified here. These are sometimes called
"linked items."
In the case of "chained" charges where the "lead" charge must be included in
the exploded charges, the "lead" charge should be included in the list of
exploding charges. If the price of this parent charge is included in the
message, then it overrides the sum of the exploded charges prices.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the procedure code for procedure, if any,
associated with this charge description. Repeating field allows for different
procedure coding systems such as CPT4, ASTM, ICD9. Coded entry made up of code
plus coding schema. Refer to User defined Table 0088 - Procedure code
for suggested values.
Definition: This field indicates whether this is a usable CDM entry. Refer to HL7 table 0183 - Active/inactive for valid values.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This optional field contains an identifying stock number, if any,
which might be used, for example, as a cross reference for materials
management. Refer to User-defined Tabl
e
0463 - Inventory number for suggested values.
Value |
Description |
|---|---|
No suggested values |
Definition: This field contains the Relative Value Unit (RVU) minutes and ATS, a factor related to CPT4 coding and to pricing structure for physical billing.
Components:
<ID number (NM)> ^ <check digit (NM)> ^ <code identifying the
check digit scheme employed (ID)> ^ <assigning authority
(HD)>
Type Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST) & <universal ID (ID)
Definition: This field contains any contract number pertaining to this
chargeable item. For example, supplier contract or service contract.
Components:
<organization name (ST)> ^ <organization name type code (IS)> ^
<ID number (NM)> ^ <check digit (NM)> ^ <code identifying the
check digit scheme employed (ID)> ^ <assigning authority (HD)> ^
<identifier type code (IS)> ^ <assigning facility ID (HD)> ^
<name representation code (ID)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the organization with whom there is a
contractual arrangement for providing the service or material used for this
chargeable item.
Definition:
This field contains a room fee indicator. Refer to HL7 Table 0136 -
Yes/no indicator for valid values.
Y this is a component of the room fees
N this is any other chargeable item other than room fees
The
Technical Steward for the PRC segment is PAFM.
The PRC segment contains the pricing information for the preceding CDM
segment's chargeable item. It contains the fields which, for the same
chargeable item, might vary depending upon facility or department or patient
type. The preceding CDM segment contains the fields which, for one chargeable
item, remain the same across facilities, departments, and patient types.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
250 |
CE |
R |
0132 |
00982 |
Primary Key Value - PRC |
|
2 |
250 |
CE |
O |
Y |
0464 |
00995 |
Facility ID - PRC |
3 |
250 |
CE |
O |
Y |
0184 |
00676 |
Department |
4 |
1 |
IS |
O |
Y |
0004 |
00967 |
Valid Patient Classes |
5 |
12 |
CP |
C |
Y |
00998 |
Price |
|
6 |
200 |
ST |
O |
Y |
00999 |
Formula |
|
7 |
4 |
NM |
O |
01000 |
Minimum Quantity |
||
8 |
4 |
NM |
O |
01001 |
Maximum Quantity |
||
9 |
12 |
MO |
O |
01002 |
Minimum Price |
||
10 |
12 |
MO |
O |
01003 |
Maximum Price |
||
11 |
26 |
TS |
O |
01004 |
Effective Start Date |
||
12 |
26 |
TS |
O |
01005 |
Effective End Date |
||
13 |
1 |
IS |
O |
0268 |
01006 |
Price Override Flag |
|
14 |
250 |
CE |
O |
Y |
0293 |
01007 |
Billing Category |
15 |
1 |
ID |
O |
0136 |
01008 |
Chargeable Flag |
|
16 |
1 |
ID |
O |
0183 |
00675 |
Active/Inactive Flag |
|
17 |
12 |
MO |
O |
00989 |
Cost |
||
18 |
1 |
IS |
O |
0269 |
01009 |
Charge On Indicator |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the code assigned by the institution for the
purpose of uniquely identifying the thing that can be charged. The key field
of the entry. For example, this field would be used to uniquely identify a
procedure, item, or test for charging purposes. Probably the same set of
values as used in FT1-7 - Transaction code in financial messages.
Must match MFE-4 - Primary key - MFE and CDM-1 -
Primary key - CDM. Refer to User-defined Table 0132 - Transaction
code for suggested values. See Chapter 7 for discussion of the universal
service ID.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the facility of the institution for which this
price (for the preceding CDM entry) is valid. For use when needing
multi-facility pricing. If null, assume all facilities. In a multi-facility
environment, the facility associated with this chargeable item may not be the
same as the sending or receiving facility identified in the MSH segment. Use
only when the price is not the same for all facilities, that is, a null value
indicates that this pricing is valid for all facilities.
When two PRC segments are sent with the same key values but different facility
identifiers, the second is sent in addition to the first, not to replace the
first. The effective unique identifier is the charge code (PRC-1
- Primary key value - PRC) plus the facility ID
(PRC-2 - Facility ID). Multiple facility
identifiers can be sent in the same segment to indicate that those facilities
use the same pricing. Refer to User-defined Table 0464 - Facility
ID for suggested values.
Value |
Description |
|---|---|
No suggested values defined |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the department of the facility which accrues
revenue/cost for this type of charge. When pricing is different for different
departments within the same facility, this will indicate for which department
the following pricing information is valid. Use only when the price is not the
same for all departments, that is, a null value indicates that this pricing is
valid for all departments.
When two PRC segments are sent the same key values but with different
departments, the second is sent in addition to the first, not to replace the
first. The effective unique identifier is the charge code (PRC-1
- Primary key - PRC) plus the facility ID (PRC-2 -
Facility ID) plus the department (PRC-3 -
Department). Multiple departments can be sent in the same
segment to indicate that those departments use the same pricing. Refer
to User-defined Table 0184 - Department for suggested values.
Definition:
This field contains the patient types for which this charge description is
valid. For example, Inpatient, Outpatient, Series, Clinic, ER, Ambulatory,
Observation, etc. These values should be the same set of values as those used
for PV1-3 - Patient class, which is site defined. Use only when
the price is not valid for all patient types, that is, a null value indicates
that this pricing is valid for all patient classes. Refer to User-defined
Table 0004 - Patient class for suggested values.
When two PRC segments are sent the same key values but with different valid
patient classes, the second is sent in addition to the first, not to replace
the first. The effective unique identifier is the charge code
(PRC-1 - PRC primary key) plus the facility ID
(PRC-2 - Facility ID) plus the department
(PRC-3 - Department) plus the patient class
(PRC-4 - Valid patient classes). Multiple patient
classes can be sent in the same segment to indicate that those patient classes
use the same pricing.
Components:
<price (MO)> ^ <price type (ID)> ^ <from value (NM)> ^
<to value (NM)> ^ <range units (CE)> ^ <range type
(ID)>
Subcomponents of price: <quantity (NM)> & <denomination
(ID)>
Subcomponents of range nits: <identifier (ST)> & <text (ST)
& <name of coding system (IS)> & <alternate identifier
(ST)> & <alternate text (ST)> & <name of alternate coding
system (ST)>
Definition: This field contains the price to be charged for service, item, or
procedure. If CDM price will always be overridden when charges are posted,
then this field is optional. Otherwise, price would be a required field. The
formula or calculation that is to be used to get total price from these price
components is left to implementation negotiations agreed upon by the
participating institutions. See Chapter 2, Section 2.8.8, "CP - composite
price," for a description of the use of the composite price (CP) data type.
Definition: This field contains the mathematical formula to apply to PRC-5 - Price in order to compute total price. The syntax of this formula must conform to Arden Syntax rules.
Definition: This field contains the minimum number of identical charges allowed on one patient account for this CDM entry.
Definition: This field contains the maximum number of identical charges allowed on one patient account for this CDM entry.
Components:
<quantity (NM)> ^ <denomination (ID)>
Definition: This field contains the minimum total price (after computation of
components of price) that can be charged for this item.
Components:
<quantity (NM)> ^ <denomination (ID)>
Definition: This field contains the maximum total price (after computation of
components of price) that can be charged for this item.
Definition: This field contains the date/time when this CDM entry becomes effective.
Definition: This field contains the date/time when this CDM entry is no longer effective.
Definition: This field indicates whether this CDM entry's price can be overridden. Refer to User-defined Table 0268 - Override for suggested values.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains the billing category codes for any
classification systems needed, for example, general ledger codes and UB92
categories. Repeating field with coded entry made up of category code plus
category system. Refer to User-defined Table 0293 - Billing
category for suggested values.
Value |
Description |
|---|---|
No suggested values defined |
Definition:
This field contains a chargeable indicator. Refer to HL7 Table
0136 - Yes/no indicator for valid values.
N charge is not billable, that is, do not create charges for this CDM entry;
this is zero price item
Y item is billable (this is also the default when NULL)
Definition: This indicates whether this is a usable CDM entry. Refer to HL7 Table 0183 - Active/inactive for valid values.
Components:
<quantity (NM)> ^ <denomination (ID)>
Definition: This field contains the institution's calculation of how much it
costs to provide this item, that is, what the institution had to pay for the
material plus any specified payment expenditure, effort or loss due to
performing or providing the chargeable item.
Definition:
This field contains the user-defined table of values which indicates when a
charge for services or procedures should be accrued. Refer to
User-defined Table 0269 - Charge on indicator for suggested
values.
Value |
Description |
|---|---|
O |
Charge on Order |
R |
Charge on Result |
MSH|^~\&|HL7REG|UH|HL7LAB|CH|19910918060544||MFN^M04|MSGID002|P|2.4||AL|NE<cr>
MFI|CDM||UPD|||AL<cr>
MFE|MAD|CDM98123789182|199110011230|P2246^^PLW<cr>
CDM|P2246^^PLW |2445||APPENDECTOMY|X||244.34|A|2321||||N<cr>
PRC|P2246^^PLW |FAC3|SURG|O~A|100.00^UP |formula |1|1
|100.00^USD|1000.00^USD|19941031||Y|GL545|Y|A|<cr>
The
CM0 (Clinical Study Master), CM1 (Clinical Study Phase), and CM2 (Clinical
Study Schedule) segments can be used to transmit master files information
between systems. The CM0 segment contains the information about the study
itself; the CM1 contains the information about one phase of the study
identified in the preceding CM0; and the CM2 contains the information about the
scheduled time points for the preceding study or phase-related treatment or
evaluation events. When these segments are used in an MFN message, the
abstract definition is described below.
Case 1: MFN message for Clinical Study with phases and schedules
MFI-1 - master file identifier code = CMA
MFN^M06^MFN_M06 |
Master File Notification |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MFI |
Master File Identification |
8 |
{ MFE |
Master File Entry |
8 |
CM0 |
Clinical Study Master |
8 |
[{ CM1 |
Clinical Study Phase |
8 |
[{CM2}] }] |
Clinical Study Schedule |
8 |
} |
MFK^M06^MFK_M01 |
Master File Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Acknowledgment |
2 |
MFI |
Master File Identification |
8 |
{ [MFA] } |
Master file ACK |
8 |
Case 2: MFN message for Clinical Study without phases but with
schedules
MFI-1 - master file identifier code = CMB
MFN^M07^MFN_M07 |
Master File Notification |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MFI |
Master File Identification |
8 |
{ MFE |
Master File Entry |
8 |
CM0 |
Clinical Study Master |
8 |
[ {CM2}] |
Clinical Study Schedule |
8 |
} |
MFK^M07^MFK_M01 |
Master File Acknowledgment |
Chapter |
|---|---|---|
MSH |
Message Header |
2 |
MSA |
Acknowledgment |
2 |
MFI |
Master File Identification |
8 |
{ [MFA] } |
Master file ACK |
8 |
When
the Clinical Trials master segments are used in the MFR message, the part of
the message represented by:
MFE
[Z..] }
is replaced by, in case 1 above:
{ MFE
CM0
[{ CM1
[ {CM2}]
}
In case 2 above, the corresponding segments in the MFR message represented
by:
{MFE
[Z..] }
are replaced by
{ MFE
CM0
[ {CM2}] }]
}
The
Technical Steward for the CM0 segment is ORDERS.
The Clinical Study Master (CM0) segment contains the information about the
study itself. The sending application study number for each patient is sent in
the CSR segment. The optional CM0 enables information about the study at the
sending application that may be useful to the receiving systems. All of the
fields in the segment describe the study status at the sending facility unless
otherwise agreed upon.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
SI |
O |
01010 |
Set ID - CM0 |
||
2 |
60 |
EI |
R |
01011 |
Sponsor Study ID |
||
3 |
60 |
EI |
O |
Y/3 |
01036 |
Alternate Study ID |
|
4 |
300 |
ST |
R |
01013 |
Title of Study |
||
5 |
250 |
XCN |
O |
Y |
01014 |
Chairman of Study |
|
6 |
8 |
DT |
O |
01015 |
Last IRB Approval Date |
||
7 |
8 |
NM |
O |
01016 |
Total Accrual to Date |
||
8 |
8 |
DT |
O |
01017 |
Last Accrual Date |
||
9 |
250 |
XCN |
O |
Y |
01018 |
Contact for Study |
|
10 |
250 |
XTN |
O |
01019 |
Contact's Telephone Number |
||
11 |
250 |
XAD |
O |
Y |
01020 |
Contact's Address |
Definition: This field contains a number that uniquely identifies this transaction for the purpose of adding, changing, or deleting the transaction. For those messages that permit segments to repeat, the Set ID field is used to identify the repetitions.
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains the study number established by the study
sponsor. Please see discussion in Section 7.7.1.1, "Sponsor study ID."
Components:
<entity identifier (ST)> ^ <namespace ID (IS)> ^ <universal ID
(ST)> ^ <universal ID type (ID)>
Definition: This field contains the local or collaborators' cross-referenced
study numbers.
Definition: This field contains the sending institution's title for the clinical trial. It gives recipients further identification of the study.
Components:
<ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^
<second or further given names or initials thereof (ST)> ^ <suffix
(e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g.,
MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^
<name type code (ID)> ^ <identifier check digit (ST)> ^ <code
identifying the check digit scheme employed (ID)> ^ <identifier type code
(IS)> ^ <assigning facility (HD)> ^ <name representation code
(ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ <
name assembly order (ID)>
Subcomponents of family name: <family name (ST)> & <own
family name prefix (ST)> & <own family name (ST)> & <family
name prefix from partner/spouse (ST)> & <family name from
partner/spouse (ST)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the sending institution's chairman. It
further identifies the study. The chairman's name may be needed for
communication purposes.
Definition: This field contains an institution's Internal Review Board approval dates which are required annually to continue participation in a clinical trial.
Definition: This field is a quality control field to enable checks that patient data have been transmitted on all registered patients.
Definition: This field contains the status information on the patient registration activity for quality control and operations purposes.
Components:
<ID number (ST)> ^ <family name (FN)> ^ <given name (ST)> ^
<second or further given names or initials thereof (ST)> ^ <suffix
(e.g., JR or III) (ST)> ^ <prefix (e.g., DR) (ST)> ^ <degree (e.g.,
MD) (IS)> ^ <source table (IS)> ^ <assigning authority (HD)> ^
<name type code (ID)> ^ <identifier check digit (ST)> ^ <code
identifying the check digit scheme employed (ID)> ^ <identifier type code
(IS)> ^ <assigning facility (HD)> ^ <name representation code
(ID)> ^ <name context (CE)> ^ <name validity range (DR)> ^ <
name assembly order (ID)>
Subcomponents of family name: <family name (ST)> & <own
family name prefix (ST)> & <own family name (ST)> & <family
name prefix from partner/spouse (ST)> & <family name from
partner/spouse (ST)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Subcomponents of assigning facility ID: <namespace ID (IS)> &
<universal ID (ST)> & <universal ID type (ID)>
Definition: This field contains the name of the individual who should be
contacted for inquiries about data transmitted for this study.
Components:
[NNN] [(999)]999-9999 [X9999] [C any text] ^ <telecommunication use code
(ID)> ^ <telecommunication equipment type (ID)> ^ <email address
(ST)> ^ <county code (NM)> ^ <area/city code (NM)> ^ <phone
number (NM)> ^ <extension (NM)> ^ <any text (ST)>
Definition: This field contains the phone number of the study contact
identified in CM0-9 - Contact for study.
Components:
In Version 2.3 and later, replaces the AD data type. <street address
(SAD)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or
province (ST)> ^ <zip or postal code (ST)> ^ <country (ID)> ^
< address type (ID)> ^ <other geographic designation (ST)>
^ <county/parish code (IS)> ^ <census tract (IS)> ^
<address representation code (ID)> ^ <address validity range
(DR)>
Subcomponents of street address: <street address (ST)> &
<street name (ST)> & <dwelling number (ST)>
Definition: This field contains the address of the study contact identified in
CM0-9 - Contact for study.
The
Technical Steward for the CM1 segment is ORDERS.
Each Clinical Study Phase Master (CM1) segment contains the information about
one phase of a study identified in the preceding CM0. This is an optional
structure to be used if the study has more than one treatment or evaluation
phase within it. The identification of study phases that the patient enters
are sent in the CSP segment: sequence 2. The CM1 segment describes the phase
in general for the receiving system.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
SI |
R |
01021 |
Set ID - CM1 |
||
2 |
250 |
CE |
R |
01022 |
Study Phase Identifier |
||
3 |
300 |
ST |
R |
01023 |
Description of Study Phase |
Definition: This field contains a number that uniquely identifies this transaction for the purpose of adding, changing, or deleting the transaction. For those messages that permit segments to repeat, the Set IF field is used to identify the repetitions.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field should correspond to the study phase ID coding system
in Section 7.7.2.1, "Study phase ID."
Definition: This field contains a brief explanation for recipients to understand what the phase represents.
The
Technical Steward for the CM2 segment is ORDERS.
The Clinical Study Schedule Master (CM2) contains the information about the
scheduled time points for study or phase-related treatment or evaluation
events. The fact that a patient has data satisfying a scheduled time point is
sent in the CSS segment, sequence 2. The CM2 segment describes the scheduled
time points in general.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
1 |
4 |
SI |
O |
01024 |
Set ID- CM2 |
||
2 |
250 |
CE |
R |
9999 |
01025 |
Scheduled Time Point |
|
3 |
300 |
ST |
O |
01026 |
Description of Time Point |
||
4 |
250 |
CE |
R |
Y/200 |
9999 |
01027 |
Events Scheduled This Time Point |
Definition: This field contains a number that uniquely identifies this transaction for the purpose of adding, changing, or deleting the transaction. For those messages that permit segments to repeat, the Set ID field is used to identify the repetitions.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field should correspond to the scheduled time point coding
system in Section 7.7.3.1, "Study scheduled time point."
Definition: This field contains a brief explanation so recipients will understand what the time point represents.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (IS)>
Definition: This field contains a study-specific event. Coding systems may be
developed for this field or applications may use facility-wide or standardized
orders and procedures coding systems. This enables integration of procedures
or events ordered for clinical trials with medical order entry systems.
This
example shows the lab system using the Master Files specification to send two
update test dictionary entries to an ICU system. The OM1 (observation
dictionary) segment, currently under development by HL7 and ASTM, carries the
dictionary information. Several varieties of acknowledgement are shown. The
choice of acknowledgment mode is site-specific.
Original mode example:
MSH|^~\&|LABxxx|ClinLAB|ICU||19910918060544||MFN^M03|MSGID002|P|2.2
MFI|LABxxx^Lab Test Dictionary^L|UPD|||AL
MFE|MUP|199109051000|199110010000|12345^WBC^L
OM1|...
MFE|MUP|199109051015|199110010000|6789^RBC^L
OM1|...
Original mode acknowledgment of the HL7 message according to MFI Response
Level Code of AL.
MSH|^~\&|ICU||LABxxx|ClinLAB|19910918060545||MFK|MSGID99002|P|2.2
MSA|AA|MSGID002
MFI|LABxxx^Lab Test Dictionary^L|UPD|||MFAA
MFA|MUP|199110010000|199110010040|S|12345^WBC^L
MFA|MUP|199110010000|199110010041|S|6789^RBC^L
Enhanced mode example
Initial message with accept acknowledgment
MSH|^~\&|LABxxx|ClinLAB|ICU||19910918060544||MFN^M03|MSGID002|P|2.2|||AL|AL
MFI|LABxxx^Lab Test Dictionary^L|UPD|||AL
MFE|MUP|199109051000|199110010000|12345^WBC^L
OM1|...
MFE|MUP|199109051015|199110010000|6789^RBC^L
OM1|...
MSH|^~\&|ICU||LABxxx|ClinLAB|19910918060545||MSA|MSGID99002|P|2.2
MSA|CA|MSGID002
Application acknowledgment message
MSH|^~\&|ICU||LABxxx|ClinLAB|19911001080504||MFK|MSGID5002|P|2.2|||AL|
MSA|AA|MSGID002
MFI|LABxxx^Lab Test Dictionary^L|UPD|||MFAA
MFA|MUP|199109051000|199110010040|S|12345^WBC^L
MFA|MUP|199109051015|199110010041|S|6789^RBC^L
MSH|^~\&|LABxxx|ClinLAB|ICU||19911001080507||ACK|MSGID444|P|2.2
MSA|CA|MSGID5002
Delayed application acknowledgment
Note: If the MFN message in Section 8.12, "Original mode example:," had
not required an application acknowledgment at the message level (i.e., the
application acknowledgment code of the MSH segment = NE), the (Master Files
Chapter defined) MFD message could be used to provide a delayed application
level acknowledgment not tied to the original MFN message.
The following example includes an acknowledgment for an MFE segment not in the
original message. This additional MFE was sent via another MFN message.
Initial message with accept acknowledgment
MSH|^~\&|LABxxx|ClinLAB|ICU||19910918060544||MFN^M03|MSGID002|P|2.2|||AL|NE
MFI|LABxxx^Lab Test Dictionary^L|UPD|||AL
MFE|MUP|199109051000|199110010000|12345^WBC^L
OM1|...
MFE|MUP|199109051015|199110010000|6789^RBC^L
OM1|...
MSH|^~\&|ICU||LABxxx|ClinLAB|19910918060545||MSA|MSGID99002|P|2.2
MSA|CA|MSGID002
Delayed application acknowledgment
MSH|^~\&|ICU||LABxxx|ClinLAB|19911001080504||MFD|MSGID65002|P|2.4|||AL|
MFI|LABxxx^Lab Test Dictionary^L|UPD|||MFAA
MFA|MUP|199109051000|199110010040|S|12345^WBC^L
MFA|MUP|199109051015|199110010041|S|6789^RBC^L
MFA|MUP|199109051025|199110010041|S|4339^HGB^L
MSH|^~\&|LABxxx|ClinLAB|ICU||19911001080507||ACK|MSGID444|P|2.4
MSA|CA|MSGID65002
We invite proposals for the specification of other HL7-wide master files segments.
LOINC Committee. Logical Observation
identifier Names and Codes. Indianapolis: Regenstrief Institute and LOINC
Committee, 1995.
[2] International Union of Pure and Applied
Chemistry/International Federation of Clinical Chemistry. The Silver Book:
Compendium of terminology and nomenclature of properties in clinical laboratory
sciences. Oxford: Blackwell Scientific Publishers, 1995.
[3] NCCLS Document H1-A3: Evacuated tubes for
blood specimen collection -- Third Edition, Volume 11, Number 9, Approved
standard. July 1991.