Master Files
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) doctor 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
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 doctor 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.6,
"STAFF AND PRACTITIONER MASTER FILES," through 8.10, "Clinical Trials MASTER
FILES," of this chapter.
A given master files message concerns only a single master file. However, the
location 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 - test/observation master file; M04 - charge description
master file; M05 - location master file; M06 - clinical study master file; M12
- M99 - reserved for future HL7-defined master files. Site-specific master
files should use a code of the form Znn. (See also Section 8.4.1.1, "Master
file identifier (CE) 00658," HL7 table 0175 - Master file identifier
codes.)
An 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 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 (varies)
Z-segments carrying the data
for the entry identified in the MFE segment
MFK 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). |
Note: 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 Master File Delayed Acknowledgment Chapter
MSH Message Header 2
MFI Master File Identification 8
{ [MFA] } Master file ACK segment 8
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 Query for Master File Record Chapter
MSH Message Header 2
QRD Query Definition 2
[QRF] Query Filter 2
[DSC] Continuation 2
MFR Master Files Response Chapter
MSH Message Header 2
MSA Acknowledgment 2
[ ERR ] Error 2
QRD Query Definition 2
[QRF] Query Filter 2
MFI Master File Name 8
{MFE Master File Entry 8
[Z..] } One or more HL7 and/or (varies)
Z-segments carrying the data for the entry
identified in the MFE segment.
[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
fields in the MFI segment are defined in Figure 8-1 - MFI attributes.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
| 1 | 60 | 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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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). 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 |
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 and MSH-16-application acknowledgment type operate as
defined in Chapter 2.
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 |
8.4.2.0 MFE field definitions
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 MFA 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).
This field may be either a CE or PL data type. The PL data type is used only
on Location master transactions. 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.
The
MFA segment contains the following fields as defined in Figure 8-3 - MFA
attributes.
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 | 60 | CE | R | 0181 | 00669 | Error Return Code And/Or Text | |
| 5 | 60 | CE | R | Y | 01308 | Primary Key Value - MFA |
8.4.3.0 MFA field definitions
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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 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.
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 2 |
60 3 |
CE NM |
R R |
xxxx xxxx |
xxxxx xxxxx |
HL7
table entry for table xxxx Display-sort-key |
8.5.1.0 ZL7 field definitions
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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.2
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
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.2
MSA|AA|MSGID002
MFI|0006^RELIGION^HL7|UPD
MFA|MAD|199109051000|19910918060545|S|U^Buddhist^HL7
MFA|MAD|199109051015|19910918060545|S|Z^Zen Buddhist^HL7
MSH|^~\&|HL7REG|UH|HL7LAB|CH|19910918060544||MFN^M01|MSGID002|P|2.2||AL|AL
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||MSA|MSGID99002|P|2.2
MSA|CA|MSGID002
MSH|^~\&|HL7LAB|CH|HL7ADT|UH|19911001080504||MFK|MSGID99502|P|2.2||AL|
MSA|AA|MSGID002
MFI|0006^RELIGION^HL7|UPD
MFA|MAD|199109051000|19910918010040|S|U^Buddhist^HL7
MFA|MAD|199109051015|19910918010040|S|Z^Zen Buddhist^HL7
MSH|^~\&|HL7ADT|UH|HL7LAB|CH|19911001080507||ACK|MSGID444|P|2.2
MSA|CA|MSGID5002
MSH|^~\&|HL7REG|UH|HL7LAB|CH|19910918060544||MFN^M01|MSGID002|P|2.2||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||MSA|MSGID99002|P|2.2
MSA|CA|MSGID002
MSH|^~\&|HL7LAB|CH|HL7ADT|UH|19910919060545||MFD|MSGID99002|P|2.2|||AL
MFI|0006^RELIGION^HL7|UPD
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.2
MSA|CA|MSGID500
The
staff (STF) and practitioner (PRA) segments can be used to transmit master
files information between systems. The STF segment provides general information
about personnel; the PRA segment 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 segment is the first such segment.
When the STF and PRA segments are used in an MFN message, the abstract
definition is as follows:
MFN Master File Notification for Staff/Practitioner
Chapter
MSH Message Header 2
MFI Master File Identification 8
{MFE Master File Entry 8
STF Staff Identification 8
[PRA] Practitioner Detail 8
}
MFK 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]
}
The
STF segment can identify any personnel referenced by information systems.
These can be providers, staff, system users, and referring agents. In a
network environment, this segment can be used to define personnel to other
applications; for example, order entry clerks, insurance verification clerks,
admission clerks, as well as provider demographics. MFE-4-primary key
value is used to link all the segments pertaining to the same master file
entry. Therefore, in the MFE segment, MFE-4-primary key value must be
filled in. Other segments may follow the STF segment to provide data for a
particular type of staff member. The PRA segment (practitioner) is one such.
It may optionally follow the STF segment in order to add practitioner-specific
data. Other segments may be defined as needed.
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
| 1 | 60 |
CE |
R | 00671 | Primary Key Value - STF | ||
| 2 | 60 |
CX |
O | Y | 00672 | Staff ID Code | |
| 3 | 48 |
XPN |
O | 00673 | Staff Name | ||
| 4 | 2 |
IS |
O | Y | 0182 | 00674 | Staff Type |
| 5 | 1 |
IS |
O | 0001 | 00111 | Sex | |
| 6 | 26 |
TS |
O | 00110 | Date/Time Of Birth | ||
| 7 | 1 |
ID |
O | 0183 | 00675 | Active/Inactive | |
| 8 | 200 |
CE |
O | Y | 0184 | 00676 | Department |
| 9 | 200 |
CE |
O | Y | 0069 | 00677 | Service |
| 10 | 40 |
XTN |
O | Y | 00678 | Phone | |
| 11 | 106 |
XAD |
O | Y | 00679 | Office/Home Address | |
| 12 | 26 |
CM |
O | Y | 00680 | Activation Date | |
| 13 | 26 |
CM |
O | Y | 00681 | Inactivation Date - STF | |
| 14 | 60 |
CE |
O | Y | 00682 | Backup Person ID | |
| 15 | 40 |
ST |
O | Y | 00683 | E-Mail Address | |
| 16 | 1 |
ID |
O | 0185 | 00684 | Preferred Method Of Contact | |
| 17 | 1 |
IS |
O | 0002 | 00119 | Marital Status | |
| 18 | 20 |
ST |
O | 00785 | Job Title | ||
| 19 | 20 |
JCC |
O | 00786 | Job Code/Class | ||
| 20 | 2 |
IS |
O | 0066 | 01276 | Employment Status | |
| 21 | 1 |
ID |
O | 0136 | 01275 | Additional Insured on Auto | |
| 22 | 25 |
DLN |
O | 01302 | Driver's License Number - Staff | ||
| 23 | 1 |
ID |
O | 0136 | 01229 | Copy Auto Ins | |
| 24 | 8 |
DT |
O | 01232 | Auto Ins. Expires | ||
| 25 | 8 |
DT |
O | 01298 | Date Last DMV Review | ||
| 26 | 8 |
DT |
O | 01234 | Date Next DMV Review |
8.6.2.0 STF field definitions
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field must match MFE-4-primary key value to identify
which entry is being referenced.
Components:
<ID (ST)> ^ <check digit (ST)> ^ <code identifying the check
digit scheme employed (ID)> ^ <assigning authority (HD)> ^
<identifier type code (IS)> ^ <assigning facility (HD)>
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 a personnel identification code or institution
user number, used by the institution to identify this person. Repeating field
allows multiple ID codes per person, with the type of ID code indicated in the
third component of the coded entry data type.
Components:
<family name (ST)> ^ <given name (ST)> ^ <middle initial or
name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^ <prefix (e.g., DR)
(ST)> ^ <degree (e.g., MD) (ST)> ^ <name type code (ID)
>
Definition: This field contains the staff person's name.
Definition: This field contains a code identifying what type of staff. Refer to user-defined table 0182 - Staff type for suggested values. Values may include codes for staff, practitioner (physician, nurse, therapist, etc.), referral agent or agency, etc.
Definition: This field contains the staff person's sex. Refer to user-defined table 0001 - Sex for suggested values.
Definition: This field contains a staff member's date and time of birth.
Definition: This field indicates whether person is currently a valid staff member. Refer to HL7 table 0183 - Active/inactive for valid values.
| Value | Description |
| A | Active Staff |
| I | Inactive Staff |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the institution department to which this
person reports or belongs. Refer to user-defined table 0184 -
Department for suggested values.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the hospital or ancillary service with which
this staff person is associated. Refer to user-defined table 0069 -
Hospital service for suggested values.
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 staff person's phone number. This is a
repeating field with a component for indicating which phone number is which. It
is recommended that the last part of the XTN, [C any text], start with a code
from the table associated below with STF-16-preferred method of contact,
in order to indicate the type of each phone number in this repeating field.
Components:
<street address (ST)> ^ <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)>
Definition: This field contains the office address and home address of the
staff person. This is a repeating field.
Components:
<date (TS)> ^ <institution name (CE)>
Subcomponents for institution name: <identifier (ST)> & <text
(ST) & <name of coding system (ST)> & <alternate identifier
(ST)> & <alternate text (ST)> & <name of alternate coding
system (ST)>
Definition: This field contains the date when staff became active for an
institution. Repeats.
Components:
<date (TS)> ^ <institution name (CE)>
Subcomponents for institution name: <identifier (ST)> & <text
(ST) & <name of coding system (ST)> & <alternate identifier
(ST)> & <alternate text (ST)> & <name of alternate coding
system (ST)>
Definition: This field contains the date when staff became active for an
institution. Repeats.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the MFE-4-primary key value of the
master file entry which corresponds to the designated backup person for this
staff person.
Definition: This field has been retained for backward compatibility. (It is now present in the fourth component of STF-10-phone).
Definition: This field contains a one-letter code that indicates which of multiple phone numbers is the preferred method of contact for this person. Note that all values of this code refer to this segment's phone field, except for the value "E," which refers to the E-mail address field. If more than one phone number of the preferred type exists in STF-10-phone, this field refers to the first such instance. Refer to HL7 table 0185 - Preferred method of contact for valid values.
| Value | Description |
| H | Home Phone Number |
| O | Office Phone Number |
| F | FAX Number |
| C | Cellular Phone Number |
| B | Beeper Number |
| E | E-Mail Address (for backward compatibility) |
Definition: This field contains the staff member's marital status. Refer to user-defined table 0002 - Marital status for suggested values. Same values as those for PID-16-marital status.
Definition: This field contains a descriptive name of the staff member's occupation (e.g., Sr. Systems Analyst, Sr. Accountant).
Components:
<job code (IS)> ^ <job class (IS)>
Definition: This field contains the staff member's job code and employee
classification. Refer to user-defined table 0327 - Job code and
user-defined table 0329 - Job class.
Definition: This field contains the code that indicates the staff member's employment status, e.g., full-time, part-time, self-employed, etc. Refer to user-defined table 0066 - Employment status for suggested values.
Definition:
This field contains an indicator for whether the present institution is named
as an additional insured on the staff member's auto insurance, especially for
use when staff is a driver for the institution. Refer to HL7 table 0136 -
Yes/no indicator for valid values.
Y indicates that the institution is named as an additional insured
N indicates that the institution is not named as an additional insured
Components:
<license number (ST)> ^ <issuing state, province, country (IS)> ^
<expiration date (DT)
Definition: This field contains the driver's license information of staff,
especially for use when staff is a driver for the institution. For state or
province refer to official postal codes for that country; for country refer to
ISO 3166 for codes.
Definition:
This field contains an indicator for whether the institution has on file a
copy of the staff member's auto insurance, especially for use when staff is a
driver for the institution. Refer to HL7 table 0136 - Yes/no indicator
for valid values.
Y indicates that the institution has a copy on file
N indicates that the institution does not have a copy on file
Definition: This field contains the date on which the staff member's driver's license expires, especially for use when staff is a driver for the institution.
Definition: This field contains the date of the staff member's most recent Department of Motor Vehicles review, especially for use when staff is a driver for the institution.
Definition: This field contains the date of the staff member's next Department of Motor Vehicles review, especially for use when staff is a driver for the institution.
The PRA segment adds detailed medical practitioner information to the personnel identified by the STF segment. A PRA segment may optionally follow an STF segment. A PRA segment must always have been preceded by a corresponding STF segment. The PRA segment may also be used for staff who work in healthcare who are not practitioners, but need to be certified, e.g., "medical records staff."
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
|---|---|---|---|---|---|---|---|
| 1 | 20 |
ST |
R | 00685 | Primary Key Value - PRA | ||
| 2 | 60 |
CE |
O | Y | 00686 | Practitioner Group | |
| 3 | 3 |
IS |
O | Y | 0186 | 00687 | Practitioner Category |
| 4 | 1 |
ID |
O | 0187 | 00688 | Provider Billing | |
| 5 | 100 |
CM |
O | Y | 0337 | 00689 | Specialty |
| 6 | 100 |
CM |
O | Y | 0338 | 00690 | Practitioner ID Numbers |
| 7 | 200 |
CM |
O | Y | 00691 | Privileges | |
| 8 | 8 |
DT |
O | 01296 | Date Entered Practice |
8.6.3.0 PRA field definitions
Definition: This field must match MFE-4-primary key value, to identify which entry is being referenced.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the name and/or code of a group of
practitioners to which this practitioner belongs.
Definition: This field contains the category of practitioner. Refer to user-defined table 0186 - Practitioner category whose values may include codes for staff physician, courtesy physician, resident, physician assistant, physical therapist, psychiatrist, psychologist, pharmacist, registered nurse, licensed practical nurse, licensed vocational nurse, nurse practitioner, etc.
Definition: This field indicates how provider services are billed. Refer to HL7 table 0187 - Provider billing for valid values.
| Value | Description |
| P | Provider does own billing |
| I | Institution bills for provider |
Components:
<specialty name (ST)> ^ <governing board (ST)> ^ <eligible or
certified (IS)> ^ <date of certification (DT)>
Definition: This repeating field is made up of multiple components to record
the practitioner's specialties. The multiple components of each specialty are:
(1) specialty name or abbreviation, identifies provider's specialty, (2) name
of specialty governing board, (3) Certification Status, (4) certified date
contains the date of certification, if certified.
| Value | Description |
| E | Eligible |
| C | Certified |
Components:
<ID number (ST)> ^ <type of ID number (IS)> ^ <state/other
qualifying info (ST)> ^ <expiration date>
Definition: This repeating field contains this practitioner's license numbers
and other ID numbers. This is a field made up of the following components: (1)
the ID number, and (2) the type of number, and optionally (3) the state or
province in which it is valid, if relevant, or other qualifying information.
It is recommended that state qualifications use the abbreviations from the
postal service of the country. The practitioner ID number type (component 2)
is a user-defined table (table 0338).
| Value | Description |
| UPIN | Unique Physician ID. No. |
| SL | State License Number |
| MCD | Medicaid Number |
| GL | General Ledger Number |
| CY | County Number |
| TAX | Tax ID Number |
| DEA | Drug Enforcement Agency No. |
| MCR | Medicare Number |
| L&I | Labor and Industries Number |
| QA | QA Number |
| TRL | Training License Number |
Components:
<privilege (CE)> ^ <privilege class (CE)> ^ <expiration date
(DT)> ^ <activation date (DT)>
Subcomponents for privilege: < identifier (ID)> & <text
(ST)> & <name of coding system (ST)> & <alternate
identifier (ID)> & <text (ST)> & <name of alternate coding
system(ST)>
Subcomponents for privilege class: < identifier (ID)> & <text
(ST)> & <name of coding system (ST)> & <alternate
identifier (ID)> & <text (ST)> & <name of alternate coding
system(ST)>
Definition: This field contains the institutional privileges which this
provider may exercise. Depends upon institutional needs. For example, admit,
transfer, discharge, place orders, verify orders, review results, etc. Can
also be used for privileges other than patient services. This is a repeating
field, with each privilege made up of the following components: (1) privilege;
(2) privilege class; (3) privilege expiration date, if any; and (4) privilege
activation date, if any. Note that the privilege and privilege class
components are CE data types, and thus they are encoded with the subcomponent
delimiter (&) rather than the component delimiter (^).
Definition: This field contains the date the practitioner began practicing at the present institution (e.g., at hospital, at physician organization, at managed care network).
MSH|^~\&|HL7REG|UH|HL7LAB|CH|19910918060544||MFN^M02|MSGID002|P|2.3|||AL|NE
MFI|0004^DOCTOR^HL7|UPD|||AL
MFE|MAD|U2246|199110011230|PMF98123789182^^PLW
STF|PMF98123789182^^PLW|U2246^^PLW~111223333^^SSN|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 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
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.3.1, "MFN/MFK - master files notification," and 8.3.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:
MFN Master File Notification Chapter
MSH Message Header 2
MFI Master File Identification 8
{MFE Master File Entry 8
OM1 General Segment (Fields That Apply 8
to Most Observations)
[other segments(s)]
}
where other segments can be any of the following combinations:
MFI-1-master file identifier code = OMA, for numeric observations
(second component of MSH-9-event type = M08).
[
[OM2] Numeric Observation Segment
[OM3] Categorical Test/Observation Segment
[OM4] Observations that Require Specimens
]
or
MFI-1-master file identifier code = OMB, for categorical observations
(second component of MSH-9-event type - M09).
[OM3 Categorical Test/Observation Segment
[{OM4}] Observations that Require Specimens
]
or
MFI-1-master file identifier code = OMC, for observation batteries
(second component of MSH-9-event type - M10).
[OM5 Observation Batteries
[{OM4}] Observations that Require Specimens
]
or
MFI-1-master file identifier code = OMD, calculated observations (second
component of MSH-9-event type - M11).
[OM6 Observations Calculated from Other Observations
OM2] Numeric Observation Segment
Note: A 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
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 | ||
| 2 | 200 |
CE |
R | 00587 | Producer's Test/Observation ID | ||
| 3 | 12 |
ID |
O | Y | 0125 | 00588 | Permitted Data Types |
| 4 | 1 |
ID |
R | 0136 | 00589 | Specimen Required | |
| 5 | 200 |
CE |
R | 00590 | Producer ID | ||
| 6 | 200 |
TX |
O | 00591 | Observation Description | ||
| 7 | 200 |
CE |
O | 00592 | Other 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 | ||
| 1 1 | 200 |
ST |
O | 00596 | Preferred Long Name for the Observation | ||
| 12 | 1 |
ID |
O | 0136 | 00597 | Orderability | |
| 13 | 60 |
CE |
O | Y | 00598 | Identity of Instrument Used to Perform this Study | |
| 14 | 200 |
CE |
O | Y | 00599 | Coded Representation of Method | |
| 15 | 1 |
ID |
O | 0136 | 00600 | Portable | |
| 16 | 1 |
CE |
O | Y | 00601 | Observation Producing Department/Section | |
| 17 | 40 |
XTN |
O | 00602 | Telephone Number of Section | ||
| 18 | 1 |
IS |
R | 0174 | 00603 | Nature of Test/Observation | |
| 19 | 200 |
CE |
O | 00604 | Report Subheader | ||
| 20 | 20 |
ST |
O | 00605 | Report Display Order | ||
| 21 | 26 |
TS |
O | 00606 | Date/Time Stamp for any change in Def Attri for Obs | ||
| 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 | 200 |
CE |
O | Y | 00612 | Outside Site(s) Where Observation may be Performed | |
| 28 | 1000 |
XAD |
O | 00613 | Address of Outside Site(s) | ||
| 29 | 400 |
XTN |
O | 00614 | Phone Number of Outside Site | ||
| 30 | 1 |
IS |
O | 0177 | 00615 | Confidentiality Code | |
| 31 | 200 |
CE |
O | 00616 | Observations Required to Interpret the Obs | ||
| 32 | 64K |
TX |
O | 00617 | Interpretation of Observations | ||
| 33 | 64K |
CE |
O | 00618 | Contraindications to Observations | ||
| 34 | 200 |
CE |
O | Y | 00619 | Reflex Tests/Observations | |
| 35 | 80 |
TX |
O | 00620 | Rules that Trigger Reflex Testing | ||
| 36 | 64K |
CE |
O | 00621 | Fixed Canned Message | ||
| 37 | 200 |
TX |
O | 00622 | Patient Preparation | ||
| 38 | 200 |
CE |
O | 00623 | Procedure Medication | ||
| 39 | 200 |
TX |
O | 00624 | Factors that may Effect the Observation | ||
| 40 | 60 |
ST |
O | Y | 00625 | Test/Observation Performance Schedule | |
| 41 | 64K |
TX |
O | 00626 | Description of Test Methods | ||
| 42 | 60 |
CE |
O | 0254 | 00937 | Kind of Quantity Observed | |
| 43 | 60 |
CE |
O | 0255 | 00938 | Point Versus Interval | |
| 44 | 200 |
TX |
O | 00939 | Challenge Information | ||
| 45 | 200 |
CE |
O | 0258 | 00940
|
Relationship Modifier | |
| 46 | 200 |
CE |
O | 00941 | Target Anatomic Site Of Test | ||
| 47 | 200 |
CE |
O | 0259 | 00942 | Modality Of Imaging Measurement |
8.7.3.0 OM1 field definitions
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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 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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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) 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 test/observation is an orderable code.
Refer to HL7 table 0136 - Yes/no indicator for valid values.
Y the test/observation is an orderable code
N the 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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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.
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
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, creatine clearance), usually done at different times and/or on different specimens |
| A | Atomic 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) This set indicates that the code being described is used to order multiple test/observation batteries. For example, a client who routinely orders a CBC, a differential, and a thyroxine as an outpatient profile might use a single, special code to order all three test batteries, instead of having to submit three separate order codes. |
| 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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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-28-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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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-6-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:
<street address (ST)> ^ <other designation (ST)> ^ <city
(ST)> ^ <state or province (ST)> ^ <zip or postal code (ST)> ^
<country (ID)> ^ <address type> (ID)> ^ <other geographic
designation (ST)> ^ <country/parish code (IS)> ^ <census tract
(S)>
Definition: This field contains the address of the outside services listed in
OM1-28-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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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 tests/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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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.4.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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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.[1]
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.
Enzymatic Activity |
Other Properties |
||
CACT |
*Catalytic Activity |
ABS |
Absorbance |
CNC |
*Catalytic Concentration |
ACT |
*Activity |
CCRTO |
Catalytic Concentration Ratio |
APER |
Appearance |
CCNT |
*Catalytic Content |
ARB |
*Arbitrary |
CFR |
*Catalytic Fraction |
AREA |
Area |
CRAT |
*Catalytic Rate |
ASPECT |
Aspect |
CRTO |
Catalytic Ratio |
CLAS |
Class |
| Entitic | CNST | *Constant | |
ENT |
*Entitic |
COEF |
*Coefficient |
ENTSUB |
*Entitic Substance of Amount |
COLOR |
Color |
ENTCAT |
*Entitic Catalytic Activity |
CONS |
Consistency |
ENTNUM |
*Entitic Number |
DEN |
Density |
ENTVOL |
*Entitic Volume |
DEV |
Device |
| Mass | DIFF | *Difference | |
MASS |
*Mass |
ELAS |
Elasticity |
MCNC |
*Mass Concentration |
ELPOT |
Electrical Potential (Voltage) |
MCRTO |
*Mass Concentration Ratio |
ELRAT |
Electrical current (amperage) |
MCNT |
Mass Content |
ELRES |
Electrical Resistance |
MFR |
*Mass Fraction |
ENGR |
Energy |
MINC |
*Mass Increment |
EQL |
Equilibrium |
MRAT |
*Mass Rate |
FORCE |
Mechanical force |
MRTO |
*Mass Ratio |
FREQ |
Frequency |
| Counts | IMP | Impression/ interpretation of study | |
NUM |
*Number |
KINV |
*Kinematic Viscosity |
NCNC |
*Number Concentration |
LEN |
Length |
NCNT |
*Number Content |
LINC |
*Length Increment |
NFR |
*Number Fraction |
LIQ |
*Liquifaction |
NRTO |
*Number Ratio |
MGFLUX |
Magnetic flux |
| Substance Amount (Moles/Millequivalents) | MORPH | Morphology | |
SUB |
*Substance Amount |
MOTIL |
Motility |
SCNC |
*Substance Concentration |
OD |
Optical density |
SCRTO |
*Substance Concentration Ratio |
OSMOL |
*Osmolality |
SCNT |
*Substance Content |
PRID |
Presence/Identity/Existence |
SCNTR |
*Substance Content Rate |
PRES |
*Pressure (Partial) |
SFR |
*Substance Fraction |
PWR |
Power (wattage) |
SCNCIN |
*Substance Concentration Increment |
RANGE |
*Ranges |
SRAT |
*Substance Rate |
RATIO |
*Ratios |
SRTO |
*Substance Ratio |
RDEN |
*Relative Density |
| Volumes | REL | *Relative | |
VOL |
*Volume |
SATFR |
*Saturation Fraction |
VCNT |
*Volume Content |
SHAPE |
Shape |
VFR |
*Volume Fraction |
SMELL |
Smell |
VRAT |
*Volume Rate |
SUSC |
*Susceptibility |
VRTO |
*Volume Ratio |
TASTE |
Taste |
| Miscellaneous Unit Measures | TEMP | *Temperature | |
ACNC |
Concentration, Arbitrary Substance |
TEMPDF |
*Temperature Difference |
RLMCNC |
*Relative Mass Concentration |
TEMPIN |
*Temperature Increment |
RLSCNC |
*Relative Substance Concentration |
TITR |
*Dilution Factor (Titer) |
THRMCNC |
*Threshold Mass Concentration |
TYPE |
*Type |
THRSCNC |
*Threshold Substance Concentration |
VEL |
*Velocity |
Time |
VELRT |
*Velocity Ratio | |
TIME |
*Time (e.g. seconds) |
VISC |
*Viscosity |
TMDF |
*Time Difference |
||
TMSTP |
*Time Stamp -- Date and Time |
||
TRTO |
*Time Ratio |
||
RCRLTM |
*Reciprocal Relative Time |
||
RLTM |
*Relative Time |
||
*Starred items are adopted from the IUPAC Silver Book,2 non-starred items are extensions. |
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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.
PT |
To identify measures at a point in time. This is a synonym for "spot" or "random" as applied to urine measurements. |
||||
* (star) |
Life of the "unit." Used for blood products. |
||||
30M |
30 minutes |
7H |
7 hours |
6D |
6 days |
1H |
1 hour |
8H |
8 hours |
1W |
1 week |
2H |
2 hours |
12H |
12 hours |
2W |
2 weeks |
2.5H |
2½ hours |
24H |
24 hours |
3W |
3 weeks |
3H |
3 hours |
2D |
2 days |
4W |
4 weeks |
4H |
4 hours |
3D |
3 days |
1L |
1 months (30 days) |
5H |
5 hours |
4D |
4 days |
2L |
2 months |
6H |
6 hours |
5D |
5 days |
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.8.3.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.
BS
Baseline (time just before the challenge) |
|
n minutes/hours/days/weeks/months/etc. after challenge begun: |
|
1M
1 minute post challenge |
6H
6 hours 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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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; it is
adopted from DICOM C.7.3.1.1.1 Modality. If these are used, the code source ID
would be DCM.
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-19-nature of
test/observation).
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
| 1 | 4 |
NM |
O | 00586 | Sequence Number | ||
| 2 | 60 |
CE |
O | 00627 | Units of Measure | ||
| 3 | 10 |
NM |
O | Y | 00628 | Range of Decimal Precision | |
| 4 | 60 |
CE |
O | 00629 | Corresponding SI Units of Measure | ||
| 5 | 60 |
TX |
O | 00630 | SI Conversion Factor | ||
| 6 | 200 |
CM |
O | 00631 | Reference (Normal) Range - Ordinal & Continuous Obs | ||
| 7 | 200 |
CM |
O | 00632 | Critical Range for Ordinal & Continuous Obs | ||
| 8 | 200 |
CM |
O | 00633 | Absolute Range for Ordinal & Continuous Obs | ||
| 9 | 200 |
CM |
O | Y | 00634 | Delta Check Criteria | |
| 10 | 20 |
NM |
O | 00635 | Minimum Meaningful Increments |
8.7.4.0 OM2 field definitions
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the single tests/observations (those with a
nature code of A or C, as described in OM1-18-nature of
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 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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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 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
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 & high value>
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-3-units of measure).
Definition: This subcomponent contains the sex of the patient. Refer to user-defined table 0001 - Sex for suggested values.
Subcomponents:
<low value & high value>
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 & high value>
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 ^ high value>
Definition: This field applies only to single tests/observations (i.e., a
nature code of A or C, as described in OM1-19-nature of
test/observations) 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-7-reference (normal) range-ordinal and continuous
obs).
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-19-nature of 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 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-3-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-19-nature of 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).
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 | ||
| 2 | 60 |
CE |
O | 00636 | Preferred Coding System | ||
| 3 | 60 |
CE |
O | 00637 | Valid Coded "Answers" | ||
| 4 | 200 |
CE |
O | Y | 00638 | Normal Text/Codes for Categorical Observations | |
| 5 | 200 |
CE |
O | 00639 | Abnormal Text/Codes for Categorical Observations | ||
| 6 | 200 |
CE |
O | 00640 | Critical Text Codes for Categorical Observations | ||
| 7 | 3 |
ID |
O | 0125 | 00570 | Value Type |
8.7.5.0 OM3 field definitions
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: Certain observations/tests with a nature code of A or C (see
OM1-18-nature of 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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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.
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 | ||
| 2 | 1 |
ID |
O | 0170 | 00642 | Derived Specimen | |
| 3 | 60 |
TX |
O | 00643 | Container Description | ||
| 4 | 20 |
NM |
O | 00644 | Container Volume | ||
| 5 | 60 |
CE |
O | 00645 | Container Units | ||
| 6 | 60 |
CE |
O | 00646 | Specimen | ||
| 7 | 60 |
CE |
O | 00647 | Additive | ||
| 8 | 10K |
TX |
O | 00648 | Preparation | ||
| 9 | 10K |
TX |
O | 00649 | Special Handling Requirements | ||
| 10 | 20 |
CQ |
O | 00650 | Normal Collection Volume | ||
| 11 | 20 |
CQ |
O | 00651 | Minimum Collection Volume | ||
| 12 | 10K |
TX |
O | 00652 | Specimen Requirements | ||
| 13 | 1 |
ID |
O | Y | 0027 | 00653 | Specimen Priorities |
| 14 | 20 |
CQ |
O | 00654 | Specimen Retention Time |
8.7.6.0 OM4 field definitions
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. The
codes are the following:
| 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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the codes that should be those provided by
NCCLS[2]. The following list is not exhaustive;
it includes only examples.
NAME |
NCCLS |
DESCRIPTION |
(1) Lithium Heparin -- anticoagulant |
LIH Green |
Dry powder. 10 to 30 USP units per mL of blood |
(2) Sodium Heparin -- anticoagulant |
NAH Green |
Dried solution. 10 to 30 U.S.P. units per mL of blood |
(3) Ethylenediaminetetraacetic acid; dipotassium salt [EDTA(K2)] |
K2E Lavender |
Dry powder. 1.5 to 2.2 mg per mL of blood |
(4) Ethylenediaminetetraacetic acid; tripotassium salt [EDTA (K3)] |
K3E Lavender |
Clear solution. 1.5 to 2.2 mg per mL of blood |
(5) Ethylenediaminetetraacetic acid; disodium salt [EDTA (Na2)] |
N2E Lavender |
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> ^ <units>
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> ^ <units>
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> ^ <units>
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.
This
segment contains the information about batteries and supersets (a nature code
of F, P or S, as described in OM1-18-nature of test/observation).
SEQ |
LEN |
DT |
OPT |
RP/# |
TBL# |
ITEM# |
ELEMENT NAME |
| 1 | 4 |
NM |
O | 00586 | Sequence Number | ||
| 2 | 200 |
CE |
O | Y | 00655 | Test/Observations Included w/an Ordered Test Battery | |
| 3 | 200 |
ST |
O | 00656 | Observation ID Suffixes |
8.7.7.0 OM5 field definitions
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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 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 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 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.
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 | ||
| 2 | 10K |
TX |
O | 00657 | Derivation Rule |
8.7.8..0 OM6 field definitions
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 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-3-producer's 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.
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.8.2, "LOC - location identification
segment," through 8.8.68.3." In the following message, the MFI-1-master
file identifier field should equal "LOC"
MFN 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 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:
{MFE Master File Entry
LOC Patient Location Master
[{LCH}] Location Characteristic
[{LRL}] Location Relationship
{LDP Location Department
[{LCH}] Location Characteristic
[{LCC}] }}Location Charge Code
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 |
| 4 | 90 | XON | O | 00947 | Organization Name | ||
| 5 | 106 | XAD | O | 00948 | Location Address | ||
| 6 | 40 | XTN | O | Y | 00949 | Location Phone | |
| 7 | 60 | CE | O | Y | 00951 | License Number | |
| 8 | 3 | IS | O | Y | 0261 | 00953 | Location Equipment |
8.8.2.0 LOC field definitions
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 (ID)> ^
<ID number (ID)> ^ <check digit (NM)> ^ < check digit scheme
(ID)> ^ <assigning authority (HD)> ^ <identifier type code (ID)>
^ <assigning facility ID (HD)>
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 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:
<street address (ST)> ^ <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)>
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This field contains the multiple license numbers for the facility.
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 |
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 |
1 |
ID |
O |
0206 |
00763 |
Segment Action Code | |
3 |
80 |
EI |
O |
00764 |
Segment Unique Key | ||
4 |
80 |
CE |
R |
0324 |
01295 |
Location Characteristic ID | |
5 |
80 |
CE |
R |
01237 |
Location Characteristic Value |
8.8.3.0 LCH field definitions
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), its preceding LOC (LOC-1-LOC primary key
value), and its preceding LDP (LDP-1-LDP primary key value).
Definition: This field indicates whether this repetition of the segment is being added, changed or deleted. This repetition of the repeating segment must be identified using FT1-25-segment unique key. 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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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-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-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-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.
| 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-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-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-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-Location
relationship value.
Y this location is licensed
N this location is not licensed
The
LRL segment is used 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 |
80 |
CE |
R |
0325 |
01230 |
Location Relationship ID | |
5 |
80 |
XON |
C |
01301 |
Organizational Location Relationship Value | ||
6 |
80 |
PL |
C |
01292 |
Patient Location Relationship Value |
8.8.4.0 LRL field definitions
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), its preceding LOC (LOC-1-LOC primary key
value), and its preceding LDP (LDP-1-LDP primary key value).
Definition: This field indicates whether this repetition of the segment is being added, changed or deleted. This repetition of the repeating segment must be identified using FT1-25-segment unique key. 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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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 Pharmacy |
| LAB | Nearest Lab |
| LB2 | Second Lab |
| DTY | Nearest Dietary |
| 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)>
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 relation
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:
<nursing unit or department or clinic (ID)> ^ <room (ST)> ^
<bed (ST)> ^ <facility (HD)> ^ <status (ID)> ^ <person
location type (ID)> ^ <building (ID)> ^ <floor (ST)> ^
<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-IPL primary key value 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. Aliases should be
put in LOC-20-location aliases.
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 | 10 | IS | R | 0264 | 00964 | Location Department | |
| 3 | 3 | IS | O | Y | 0069 | 00965 | Location Service |
| 4 | 60 | 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 | ||
| 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 | 40 | XTN | O | 00978 | Contact Phone |
8.8.5.0 LDP field definitions
Components:
<point of care (ID)> ^ <room (ST)> ^ <bed (ST)> ^
<facility (HD)> ^ <status (ID)> ^ <person location type
(IS)> ^ <building (ID)> ^ <floor (ST)> ^ <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) and its preceding LOC (LOC-1-LOC primary
key value).
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.
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.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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'
(LOC-20-accommodation type) is a financial accommodation type. Refer to
user-defined table 0265 - Specialty type for suggested values. See also
LOC-33-privacy level and LOC-34-level of care.
| 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.
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 | 10 | IS | R | 0264 | 00964 | Location Department | |
| 3 | 60 | CE | O | Y | 00980 | Accommodation Type | |
| 4 | 60 | CE | R | Y | 0132 | 00981 | Charge Code |
8.8.6.0 LCC field definitions
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), its preceding LOC (LOC-1-LOC primary key
value), and its preceding LDP (LDP-1-LDP primary key value).
Definition: This field contains the institution's department to which this location belongs, or its cost center. It must match the value in its preceding LDP (LDP-2-location department). Refer to user-defined table 0264 -Location department for suggested values.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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. Site-defined codes.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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. Values are site
negotiated. Refer to user-defined table 0132 - Transaction code for
suggested values.
MSH|^~\&|HL7REG|UH|HL7LAB|CH|19910918060544||MFN^M05|MSGID002|P|2.2||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.4, "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 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 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
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 |
200 |
CE |
R | 0132 | 01306 | Primary Key Value - CDM | |
2 |
200 |
CE |
O | Y | 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 |
60 |
CE |
O | Y | 00987 | Exploding Charges | |
7 |
200 |
CE |
O | Y | 00988 | Procedure Code | |
8 |
1 |
ID |
O | 0183 | 00675 | Active/Inactive Indicator | |
9 |
60 |
CE |
O | Y | 00990 | Inventory Number | |
10 |
12 |
NM |
O | 00991 | Resource Load | ||
11 |
200 |
CK |
O | Y | 00992 | Contract Number | |
12 |
200 |
XON |
O | 00993 | Contract Organization | ||
13 |
1 |
ID |
O | 0136 | 00994 | Room Fee Indicator |
8.9.2.0 CDM field definitions
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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. Refer to user-defined table 0132 -
Transaction code. See Chapter 7 for discussion of the universal service
ID.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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.
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
Definition: This optional field contains an identifying stock number, if any,
which might be used, for example, as a cross reference for materials management.
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)> ^ <check digit scheme
(ID)> ^ <assigning authority (HD)>
Subcomponents of assigning authority: <namespace ID (IS)> &
<universal ID (ST) & <universal ID Type (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 (ID)> ^
<ID number (ID)> ^ <check digit (NM)> ^ < check digit scheme
(ID)> ^ <assigning authority (HD)> ^ <identifier type code (ID)>
^ <assigning facility ID (HD)>
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
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 | 200 |
CE |
R | 0132 | 00982 | Primary Key Value - PRC | |
| 2 | 60 |
CE |
O | Y | 00995 | Facility ID | |
| 3 | 30 |
CE |
O | Y | 00996 | Department | |
| 4 | 1 |
IS |
O | Y | 0004 | 00997 | 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 | 60 |
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 |
8.9.3.0 PRC fields definitions
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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-MFE primary key and CDM-1-CDM primary key. Refer to
user-defined table 0132 - Transaction code. See Chapter 7 for
discussion of the universal service ID.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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-PRC
primary key) 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.
Components:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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-PRC
primary key) 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.
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 (ST)> & <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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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.
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.2||AL|NE<cr>
MFI|CDM|UPD|||AL<cr>
MFE|MAD|CDM98123789182|199110011230|U2246^^PLW<cr>
CDM|P2246^^PLW |2445||APPENDECTOMY|N||244.34|A|2321||||A<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.
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 |
CE |
O | Y/3 | 01012 | Alternate Study ID's | |
| 4 | 300 |
ST |
R | 01013 | Title of Study | ||
| 5 | 60 |
XCN |
O | 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 | 60 |
XCN |
O | 01018 | Contact for Study | ||
| 10 | 40 |
XTN |
O | 01019 | Contact's Tel. Number | ||
| 11 | 100 |
XAD |
O | 01020 | Contact's Address |
8.10.2.0 CM0 field definitions
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:
<identifier (ST)> ^ <text (ST)> ^ <name of coding system
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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 (ST)> ^ <given name (ST)> ^
<middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^
<prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source
table (IS)> ^ <assigning authority (HD)> ^ <name type (ID)> ^
<identifier check digit (ST)> ^ <code identifying the check digit
scheme employed (ID) ^ <identifier type code (IS)> ^ <assigning
facility ID (HD)>
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 (ST)> ^ <given name (ST)> ^
<middle initial or name (ST)> ^ <suffix (e.g., JR or III) (ST)> ^
<prefix (e.g., DR) (ST)> ^ <degree (e.g., MD) (ST)> ^ <source
table (IS)> ^ <assigning authority (HD)> ^ <name type (ID)> ^
<identifier check digit (ST)> ^ <code identifying the check digit
scheme employed (ID) ^ <identifier type code (IS)> ^ <assigning
facility ID (HD)>
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 test (ST)>
Definition: This field contains the phone number of the study contact
identified in CM0-9-contact for study
Components:
<street address (ST)> ^ <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)>
Definition: This field contains the address of the study contact identified in
CM0-9contact for study.
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 | 60 |
CE |
R | 01022 | Study Phase Identifier | ||
| 3 | 300 |
ST |
R | 01023 | Description of Study Phase |
8.10.3.0 CM1 field definitions
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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 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 | 60 |
CE |
R | 01025 | Scheduled Time Point | ||
| 3 | 300 |
ST |
O | 01026 | Description of Time Point | ||
| 4 | 60 |
CE |
R | Y/200 | 01027 | Events Scheduled This Time Point |
8.10.3.0 CM2 field definitions
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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
(ST)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^
<name of alternate coding system (ST)>
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.
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.
[2] NCCLS Document H1-A3: Evacuated tubes for
blood specimen collection -- Third Edition, Volume 11, Number 9, Approved
standard. July 1991.