Chapter Chair |
Anthony Julian |
Chapter Chair |
Dave Shaver |
Chapter Chair |
Sandra Stuart |
Chapter Editor |
Scott Robertson |
List Server: |
The content of this chapter is "owned" by various Work Groups as listed below:
Steward Work Group |
Message |
Segment |
Infrastructure and Messaging |
M01, M13, M14 |
MFI, MFE, MFA |
Patient Administration |
M02, M05, M15, M16 |
LOC, LCH, LRL, LDP, LCH, LCC |
Financial Management |
M04, M17 |
CDM, PRC, DMI |
Orders/Observations |
M03, M08, M09, M10, M11, M12, M18, M19 |
OM1, OM2, OM3 , OM4, OM5, OM6, OM7, OMC, PM1, MCP, DPS, CTR |
Orders/Observations (Clinical Trials) |
M06, M07 |
CM0, CM1, CM2 |
In an open-architecture healthcare environment there often exists a set of common reference files used by one or more application systems. Such files are called master files. Some common examples of master files in the healthcare environment include:
staff and health practitioner master file
system user (and password) master file
location (census and clinic) master file
device type and location (e.g., workstations, terminals, printers, etc.)
lab test definition file
exam code (radiology) definition file
charge master file
patient status master
patient type master
service item master file
These common reference files need to be synchronized across the various applications at a given site. The Master Files Notification message provides a way of maintaining this synchronization by specifying a standard for the transmission of this data between applications.
In many implementations, one application system will "own" a particular master file such as the staff and practitioner master file. The changes (e.g., adds, deletes, updates) to this file are made available to various other applications on a routine basis. The Master Files Notification message supports this common case, but also supports the situation where an application not "owning" a particular master file transmits update information to other systems (usually to the "owning" system) for review and possible inclusion.
The Master Files Notification message supports the distribution of changes to various master files between systems in either online or batch modes, and allows the use of either original or enhanced acknowledgment modes. 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 0 through 4 of this chapter.
A given master files message concerns only a single master file. However, the provision of a record-level event code (and requested activation date) on the MFE and the MFA segments allows a single message to contain several types of changes (events) to that file.
The Master Files Notification events do not specify whether the receiving system must support an automated change of the master file in question, nor do they specify whether the receiving system must create a file in the same form as that maintained on the sending system.
In general, the way in which the receiving system processes the change notification message will depend on both the design of the receiving system and the requirements negotiated at the site. Some systems and/or sites may specify a manual review of all changes to a particular master file. Some may specify a totally automated process. Not every system at every site will need all the fields contained in the master file segment(s) following the MFE segment for a particular master file entry.
This also means that an application acknowledgment (or a deferred application acknowledgment) from a receiving system that it changed a particular record in its version of the master file does not imply that the receiving system now has an exact copy of the information and state that is on the sending system: it means only that whatever subset of that master file's data (and state) that has been negotiated at the site is kept on the receiving system in such a manner that a new Master Files Notification transaction with the same primary key can be applied unambiguously (in the manner negotiated at the site) to that subset of information.
The Master Files Change Notification message can be used for the following message-level trigger events:
Trigger Event |
Name |
M01 |
Master File Notification - not otherwise specified [WITHDRAWN] |
M02 |
Master File Notification – Staff/Practitioner |
M03 |
Master File Notification – Test/Observation [WITHDRAWN] |
M04 |
Master File Notification – Charge Description |
M05 |
Master File Notification – Patient Location |
M06 |
Master File Notification – Clinical Study with Phases and Schedules |
M07 |
Master File Notification – Clinical Study without phases but with schedules |
M08 |
Master File Notification – Test/Observation (Numeric) |
M09 |
Master File Notification – Test/Observation (Categorical) |
M10 |
Master File Notification – Test/Observation Batteries |
M11 |
Master File Notification – Test/Calculated Observations |
M12 |
Master File Notification – Test/Observation – Additional Basic |
M13 |
Master File Notification – General |
M14 |
Master File Notification – Site Defined |
M15 |
Master File Notification – Inventory Item |
M16 |
Master File Notification – Inventory Item - Enhanced |
M17 |
Master File Notification – DRG |
M18 |
Master File Notification – Test/Observation (Payer) |
M19 |
Contract Master File |
It is recommended that site-specific master files use event M13 or M14; alternately a code of the form Znn can be used (see also section 8.5.1, "MFI - Master File Identification Segment.")
The MFN message specifies whether the master file, as a whole, has been replaced or if a record within the file has been updated. See section 8.5.13, "MFI-3 File Event Code," for further details.
The MFN message transmits the specific action taken on a record. See section 8.5.2.1, "MFE-1 Record Event Code," for further details.
The following messages are defined for master files transactions: MFN, master files notification; MFK, master files application acknowledgment; and MFQ, master files query.
Withdrawn in version 2.7 and later; refer to master file messages which follow.
The MFN General master file notification transaction is used where the master file is a simple one that contains only a key and the text value of that key. Both values are carried in MFE-4 - Primary Key Value - MFE. The specific master file being updated is identified by MFI-1 - Master File Identifier and MFI-2 - Master Files Application Identifier.
The General master file notification is defined as follows:
Note: The MFK message is used for an application acknowledgment in either the original or enhanced acknowledgment modes.
Send Application Ack: MFK^M13^MFK_M01
When the MSH-15 value of a MFN^M13^MFN_M13 message is AL or ER or SU, an ACK^M13^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFN^M13^MFN_M13 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFN^M13^MFN_M13 message is AL or ER or SU, a MFK^M13^MFK_M01 message SHALL be sent as an application ack.
When the MSH-16 value of a MFN^M13^MFN_M13 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M13^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: MFK^M13^MFK_M01 |
NE, AL, ER, SU | (none) |
Send An Acknowlegment is never sent in original mode.
When the MSH-15 value of a MFK^M13^MFK_M01 message is AL or ER or SU, an ACK^M13^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFK^M13^MFK_M01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFK^M13^MFK_M01 message is AL or ER or SU, a message SHALL be sent as an application ack.
When the MSH-16 value of a MFK^M13^MFK_M01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M13^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: |
NE, AL, ER, SU | (none) |
The MFA segment carries acknowledgment information for the corresponding MFE segment (identified by MFA-5 - Primary Key Value - MFA). Fields MFE-4 - Primary Key Value - MFE and MFA-5 - Primary Key Value - MFA provide the link between the corresponding segments.
The MFN Site defined master file notification transaction is used where the master file is not a simple one (as defined for MFN^M13) and is not a transaction type currently defined by HL7, but rather requires one or more HL7 and/or 'Z' segments to carry the master file information.
The Site defined master file notification is defined as follows:
Note: The MFK message is used for an application acknowledgment in either the original or enhanced acknowledgment modes.
Send Application Ack: MFK^M14^MFK_M01
When the MSH-15 value of a MFN^M14^MFN_Z message is AL or ER or SU, an ACK^M14^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFN^M14^MFN_Z message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFN^M14^MFN_Z message is AL or ER or SU, a MFK^M14^MFK_M01 message SHALL be sent as an application ack.
When the MSH-16 value of a MFN^M14^MFN_Z message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M14^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: MFK^M14^MFK_M01 |
NE, AL, ER, SU | (none) |
Send An Acknowlegment is never sent in original mode.
When the MSH-15 value of a MFK^M14^MFK_M01 message is AL or ER or SU, an ACK^M14^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFK^M14^MFK_M01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFK^M14^MFK_M01 message is AL or ER or SU, a message SHALL be sent as an application ack.
When the MSH-16 value of a MFK^M14^MFK_M01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M14^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: |
NE, AL, ER, SU | (none) |
The master file record identified by the MFE segment is contained in Z-segments immediately following the MFE segment, and is denoted by "..." 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 definition of this transaction and the associated abstract message structure code (as defined in MSH-9 - Message Type, denoted by MFN_Znn above) are subject to site negotiation. Refer to Chapter 2, section 2.17, "Local Extension" for additional information on 'Z' abstract message structure code definition.
The MFA segment carries acknowledgment information for the corresponding MFE segment (identified by MFA-5 - Primary Key Value - MFA). Fields MFE-4 - Primary Key Value - MFE and MFA-5 - Primary Key Value - MFA provide the link between the corresponding segments.
Withdrawn in version 2.7 and later; refer to Chapter 5 section 5.4 instead. Also, refer to Section 8.4.5 for an example of a master file conformance based query.
The following segments are defined for the master files messages.
The Technical Steward for the MFI segment is Infrastructure and Messaging.
The fields in the MFI segment are defined in HL7 Attribute Table - MFI.
Seq# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
MFI | |||||||||
1 | Master File Identifier | CWE | R | [1..1] | 00658 | ||||
2 | Master File Application Identifier | HD | O | [0..*] | 00659 | ||||
3 | File-Level Event Code | ID | R | [1..1] | 00660 | [3..3] | |||
4 | Entered Date/Time | DTM | O | [0..1] | 00661 | ||||
5 | Effective Date/Time | DTM | O | [0..1] | 00662 | ||||
6 | Response Level Code | ID | R | [1..1] | 00663 | [2..2] |
The Technical Steward for the MFE segment is Infrastructure and Messaging.
Seq# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
MFE | |||||||||
1 | Record-Level Event Code | ID | R | [1..1] | 00664 | [3..3] | |||
2 | MFN Control ID | ST | C | [0..1] | 00665 | 20 | # | ||
3 | Effective Date/Time | DTM | O | [0..1] | 00662 | ||||
4 | Primary Key Value - MFE | Varies | R | [1..*] | 00667 | ||||
5 | Primary Key Value Type | ID | R | [1..*] | 01319 | [2..3] | |||
6 | Entered Date/Time | DTM | O | [0..1] | 00661 | ||||
7 | Entered By | XCN | O | [0..1] | 00224 |
The Technical Steward for the MFA segment is Infrastructure and Messaging.
The MFA segment contains the following fields as defined in HL7 Attribute Table - MFA - Master File Acknowledgment
Seq# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
MFA | |||||||||
1 | Record-Level Event Code | ID | R | [1..1] | 00664 | [3..3] | |||
2 | MFN Control ID | ST | C | [0..1] | 00665 | 20 | # | ||
3 | Event Completion Date/Time | DTM | O | [0..1] | 00668 | ||||
4 | MFN Record Level Error Return | CWE | R | [1..1] | 00669 | ||||
5 | Primary Key Value - MFA | Varies | R | [1..*] | 01308 | ||||
6 | Primary Key Value Type - MFA | ID | R | [1..*] | 01320 | [2..3] |
The following are examples of a generic method of updating a standard HL7 table, covering the following two cases:
The case with a site-defined "Z" segment. This message type is used when standard HL7 segments are not available to carry all of the required information on the master file. This message type can also be used in the case where standard HL7 segments are available, but the transaction type is not currently defined by HL7. Refer to Section 8.4.3, "MFN/MFK - Master File Notification - Site Defined (Event M14)," for more information on this message type.
The case without a site-defined "Z" segment. This message type is used when standard HL7 segments are available to carry all of the required information on the master file (in the case of a 'simple' master file that contains only a key and the text value of that key). Refer to Section 8.4.2, "MFN/MFK - Master File Notification - General (Event M13)," for more information on this message type.
The following examples show two records being added to User-defined Table 0006 - Religion (in Chapter 2C, Code Tables).
Note: A site-defined "Z" table segment ("ZL7" in this example) can be constructed by defining two fields: a table entry field (as a CWE field) and a display-sort-key field (a numeric field) as follows.
Seq# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
ZL7 | |||||||||
1 | Primary key value - ZL7 | CWE | R | [1..1] | 00000 | ||||
2 | Primary key value - ZL7 | CWE | R | [1..1] | 00000 |
The initiating system constructs an MFN^M14 message. In this example, the message contains site-defined "Z" segments. The following message is sent to the responding system:
MSH|^~VALUEamp;|HL7REG|UH|HL7LAB|CH|200106290544||MFN^M14^MFN_Z99|MSGID001|P|2.9
MFI|HL70006^RELIGION^HL70175||UPD|||AL
MFE|MAD|6772331|200106290500|BUD^Buddhist^HL70006|CWE
ZL7|BUD^Buddhist^HL70006|3
MFE|MAD|6772332|200106290500|BOT^Buddhist: Other^HL70006|CWE
ZL7|BOT^Buddhist: Other^HL70006|4
The responder receives the message and performs necessary validation on the message. In this example, it determines the message just received is acceptable for processing. The following MFK^M14 message is constructed by the responder and sent to the initiating system to indicate acknowledgment of the MFN^M14 message:
MSH|^~VALUEamp;|HL7LAB|CH|HL7REG|UH|200106290545||MFK^M14^MFK_M01|MSGID99001|P|2.9
MSA|AA|MSGID001
MFI|HL70006^RELIGION^HL70175||UPD|||AL
MFA|MAD|6772331|200106290545|S|BUD^Buddhist^HL70006|CWE
MFA|MAD|6772332|200106290545|S|BOT^Buddhist: Other^HL70006|CWE
Note that MSA-1 - Acknowledgment Code contains 'AA' to indicate the message was received and processed successfully. This value could also have been 'AE' or 'AR' to indicate the message was received but not processed successfully. MSA-2 - Message Control ID contains the value from MSH-10 - Message Control ID in the initiating MFN^M14 message (MSGID001) to link the acknowledgment response to the initiating message.
The initiating system constructs an MFN^M13 message. In this example, the message does not contain site-defined "Z" segments. The following message is sent to the responding system:
MSH|^~VALUEamp;|HL7REG|UH|HL7LAB|CH|200106290544||MFN^M13^MFN_M13|MSGID004|P|2.9||AL|AL
MFI|HL70006^RELIGION^HL70175||UPD|||AL
MFE|MAD|6772333|200106290500|BUD^Buddhist^HL70006|CWE
MFE|MAD|6772334|200106290500|BOT^Buddhist: Other^HL70006|CWE
The responder receives the message and performs necessary validation on the message. In this example, it determines the message just received is acceptable for processing. Since MSH-15 - Accept Acknowledgment of the initiating message indicates an accept acknowledgment is required ('AL'), the following ACK message is constructed by the responder and sent to the initiating system to indicate acknowledgment of the MFN^M13 message:
MSH|^~VALUEamp;|HL7LAB|CH|HL7REG|UH|200106290545||ACK^M13^ACK|MSGID99004|P|2.9
MSA|CA|MSGID004
Note that MSA-1 - Acknowledgment Code contains 'CA' to indicate the message was received and committed to safe storage. This value could also have been 'CE' or 'CR' to indicate the message was received but not processed successfully. MSA-2 - Message Control ID contains the value from MSH-10 - Message Control ID in the initiating MFN^M13 message (MSGID004) to link the acknowledgment response to the initiating message.
The initiating system indicated in this example via MSH-16 - Application Acknowledgment Type that it requires an application level acknowledgment ('AL'). The responder, at some point following the sending of the above ACK message to the initiating system, will process the MFN^M13 message. Once message processing is complete, the application acknowledgment is sent from the responder to the initiating system to indicate the message was processed. The responder constructs an MFK^M13 acknowledgment message, and sends it to the initiating system:
MSH|^~VALUEamp;|HL7LAB|CH|HL7REG|UH|200106290550||MFK^M13^MFK_M13|MSGID99501|P|2.9||AL|
MSA|AA|MSGID004
MFI|HL70006^RELIGION^HL70175||UPD|||AL
MFA|MAD|6772333|200106290550|S|BUD^Buddhist^HL70006|CWE
MFA|MAD|6772334|200106290550|S|BOT^Buddhist: Other^HL70006|CWE
Note that MSA-1 - Acknowledgment Code contains 'AA' to indicate the message was received and processed successfully. This value could also have been 'AE' or 'AR' to indicate the message was received but not processed successfully. This value applies to all MFA segments which follow. MSA-2 - Message Control ID contains the value from MSH-10 - Message Control ID in the initiating MFN^M13 message (MSGID004) to link the application acknowledgment response to the initiating message.
The initiating system receives the application acknowledgment message from the responder, and forms an ACK message to acknowledge it. The following message is sent to the responder system:
MSH|^~VALUEamp;|HL7REG|UH|HL7LAB|CH|200106290551||ACK^M13^ACK|MSGID445|P|2.9
MSA|CA|MSGID99501
Note that MSA-2 - Message Control ID contains the value from MSH-10 - Message Control ID in the MFK^M13 message just received (MSGID99501), and NOT from the initiating MFN^M13 message.
The staff identification (STF), practitioner detail (PRA), practitioner organization unit segment (ORG), professional affiliation (AFF), language detail (LAN), educational detail (EDU), and certificate detail (CER) segments can be used to transmit master files information between systems. The STF segment provides general information about personnel; the PRA, ORG, AFF, LAN, EDU, CER and NTE segments provide detailed information for a staff member.
When the STF, PRA, ORG, AFF, LAN, EDU, CER and NTE segments are used in an MFN message, the abstract definition is as follows:
Note: As of v2.5, the PRA and ORG segments in the MFN^M02 are repeatable. HL7 does not give semantic meaning to the first instance of either. Refer to section 2.8.2.d in Chapter 2.
Send Application Ack: MFK^M02^MFK_M01
When the MSH-15 value of a MFN^M02^MFN_M02 message is AL or ER or SU, an ACK^M02^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFN^M02^MFN_M02 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFN^M02^MFN_M02 message is AL or ER or SU, a MFK^M02^MFK_M01 message SHALL be sent as an application ack.
When the MSH-16 value of a MFN^M02^MFN_M02 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M02^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: MFK^M02^MFK_M01 |
NE, AL, ER, SU | (none) |
Send An Acknowlegment is never sent in original mode.
When the MSH-15 value of a MFK^M02^MFK_M01 message is AL or ER or SU, an ACK^M02^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFK^M02^MFK_M01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFK^M02^MFK_M01 message is AL or ER or SU, a message SHALL be sent as an application ack.
When the MSH-16 value of a MFK^M02^MFK_M01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M02^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: |
NE, AL, ER, SU | (none) |
MSH|^~VALUEamp;|HL7REG|UH|HL7LAB|CH|200102280700||MFN^M02^MFN_M02|MSGID002|P|2.9|||AL|NE
MFI|PRA^Practitioner Master File^HL70175||UPD|||AL
MFE|MAD|U2246|200102280700|PMF98123789182^^PLW|CWE
STF|PMF98123789182^^PLW|U2246^^^PLW~444444444^^^USSSA^SS|Hippocrates^Harold^H^JR^DR^M.D.|P|M|19511004|A|^ICU|^MED|^WPN^PH^^^555^5551003~^PRN^PH^^^955^5551003|1003 Healthcare Drive ^^Ann Arbor^MI^^^H~4444 Healthcare Dr^^Ann Arbor^MI^^^O|19890125^&Level Seven Healthcare, Inc.&L01||PMF88123453334|74160.2326@COMPUSERV.COM|B
PRA|PMF98123789182^^PLW|^Level Seven Healthcare|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|
AFF|1|AMERICAN MEDICAL ASSOCIATION|123 MAIN STREET^^OUR TOWN^CA^98765^USA^M |19900101|
LAN|1|ESL^SPANISH^ISO639|1^READ^HL70403|1^EXCELLENT^HL70404|
LAN|2|ESL^SPANISH^ISO639|2^WRITE^HL70403|2^GOOD^HL70404|
LAN|3|FRE^FRENCH^ISO639|3^SPEAK^HL70403|3^FAIR^HL70404|
EDU|1|BA|19810901^19850601||19850604|YALE UNIVERSITY^L|U^HL70402|456 CONNECTICUT AVENUE^^NEW HAVEN^CO^87654^USA^M|
EDU|2|MD|19850901^19890601||19890604|HARVARD MEDICAL SCHOOL^L |M^HL70402|123 MASSACHUSETTS AVENUE^^CAMBRIDGE^MA^76543^USA^M|
These segments define the format for the general information about the observations that a clinical or diagnostic service produces and sends to its "clients." This format can be used to send the producer's entire service/test/observation definition or a few of the producer's observations, such as those with procedure, technique, or interpretation changes.
In anticipation of an object-oriented organization of segments in future releases of this Standard, the attributes of observations/batteries have been grouped into seven different segments:
OM1 contains the attributes that apply to all observations
OM2 applies to numerically-valued observations
OM3 applies to text or code-valued observations
OM4 applies to observations or batteries that require specimens
OM5 contains the attributes of batteries, or sets of observations or other batteries
OM6 contains the quantities (observations in a most general sense) that are calculated from one or more other observations
OM7 contains additional basic attributes that apply to the definition of most observations/services.
Thus, the full definition of a numerically-valued laboratory observation would require the transmission of OM1, OM2, and OM4.
In the following discussion, we use OMx to refer to any of the seven 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.
Withdrawn in version 2.7 and later; refer to master file messages which follow (Events M08, M09, M10, M11 and M12).
Note: The MFK message is used for an application acknowledgment in either the original or enhanced acknowledgment modes.
Note:MFI-1 - Master File Identifier = OMA for numeric observations.
Note: A service/test/observation definition may have both an OM2 (numeric) and OM3 (categorical) segment included in case the value may be either numeric and/or categorical.
Send Application Ack: MFK^M08^MFK_M01
When the MSH-15 value of a MFN^M08^MFN_M08 message is AL or ER or SU, an ACK^M08^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFN^M08^MFN_M08 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFN^M08^MFN_M08 message is AL or ER or SU, a MFK^M08^MFK_M01 message SHALL be sent as an application ack.
When the MSH-16 value of a MFN^M08^MFN_M08 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M08^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: MFK^M08^MFK_M01 |
NE, AL, ER, SU | (none) |
Send An Acknowlegment is never sent in original mode.
When the MSH-15 value of a MFK^M08^MFK_M01 message is AL or ER or SU, an ACK^M08^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFK^M08^MFK_M01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFK^M08^MFK_M01 message is AL or ER or SU, a message SHALL be sent as an application ack.
When the MSH-16 value of a MFK^M08^MFK_M01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M08^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: |
NE, AL, ER, SU | (none) |
Note: The MFK message is used for an application acknowledgment in either the original or enhanced acknowledgment modes.
Note:MFI-1 - Master File Identifier = OMB for categorical observations.
Send Application Ack: MFK^M09^MFK_M01
When the MSH-15 value of a MFN^M09^MFN_M09 message is AL or ER or SU, an ACK^M09^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFN^M09^MFN_M09 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFN^M09^MFN_M09 message is AL or ER or SU, a MFK^M09^MFK_M01 message SHALL be sent as an application ack.
When the MSH-16 value of a MFN^M09^MFN_M09 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M09^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: MFK^M09^MFK_M01 |
NE, AL, ER, SU | (none) |
Send An Acknowlegment is never sent in original mode.
When the MSH-15 value of a MFK^M09^MFK_M01 message is AL or ER or SU, an ACK^M09^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFK^M09^MFK_M01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFK^M09^MFK_M01 message is AL or ER or SU, a message SHALL be sent as an application ack.
When the MSH-16 value of a MFK^M09^MFK_M01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M09^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: |
NE, AL, ER, SU | (none) |
Note: The MFK message is used for an application acknowledgment in either the original or enhanced acknowledgment modes.
Note:MFI-1 - Master File Identifier = OMC for observation batteries.
Send Application Ack: MFK^M10^MFK_M01
When the MSH-15 value of a MFN^M10^MFN_M10 message is AL or ER or SU, an ACK^M10^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFN^M10^MFN_M10 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFN^M10^MFN_M10 message is AL or ER or SU, a MFK^M10^MFK_M01 message SHALL be sent as an application ack.
When the MSH-16 value of a MFN^M10^MFN_M10 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M10^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: MFK^M10^MFK_M01 |
NE, AL, ER, SU | (none) |
Send An Acknowlegment is never sent in original mode.
When the MSH-15 value of a MFK^M10^MFK_M01 message is AL or ER or SU, an ACK^M10^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFK^M10^MFK_M01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFK^M10^MFK_M01 message is AL or ER or SU, a message SHALL be sent as an application ack.
When the MSH-16 value of a MFK^M10^MFK_M01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M10^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: |
NE, AL, ER, SU | (none) |
Note: The MFK message is used for an application acknowledgment in either the original or enhanced acknowledgment modes.
Note:MFI-1 - Master File Identifier = OMD for calculated observations.
Send Application Ack: MFK^M11^MFK_M01
When the MSH-15 value of a MFN^M11^MFN_M11 message is AL or ER or SU, an ACK^M11^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFN^M11^MFN_M11 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFN^M11^MFN_M11 message is AL or ER or SU, a MFK^M11^MFK_M01 message SHALL be sent as an application ack.
When the MSH-16 value of a MFN^M11^MFN_M11 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M11^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: MFK^M11^MFK_M01 |
NE, AL, ER, SU | (none) |
Send An Acknowlegment is never sent in original mode.
When the MSH-15 value of a MFK^M11^MFK_M01 message is AL or ER or SU, an ACK^M11^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFK^M11^MFK_M01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFK^M11^MFK_M01 message is AL or ER or SU, a message SHALL be sent as an application ack.
When the MSH-16 value of a MFK^M11^MFK_M01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M11^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: |
NE, AL, ER, SU | (none) |
Note: The MFK message is used for an application acknowledgment in either the original or enhanced acknowledgment modes.
Note:MFI-1 - Master File Identifier = OME for additional basic observation/service attributes.
Send Application Ack: MFK^M12^MFK_M01
When the MSH-15 value of a MFN^M12^MFN_M12 message is AL or ER or SU, an ACK^M12^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFN^M12^MFN_M12 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFN^M12^MFN_M12 message is AL or ER or SU, a MFK^M12^MFK_M01 message SHALL be sent as an application ack.
When the MSH-16 value of a MFN^M12^MFN_M12 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M12^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: MFK^M12^MFK_M01 |
NE, AL, ER, SU | (none) |
Send An Acknowlegment is never sent in original mode.
When the MSH-15 value of a MFK^M12^MFK_M01 message is AL or ER or SU, an ACK^M12^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFK^M12^MFK_M01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFK^M12^MFK_M01 message is AL or ER or SU, a message SHALL be sent as an application ack.
When the MSH-16 value of a MFK^M12^MFK_M01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M12^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: |
NE, AL, ER, SU | (none) |
Send Application Ack: MFK^M18^MFK_M01
When the MSH-15 value of a MFN^M18^MFN_M18 message is AL or ER or SU, an ACK^M18^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFN^M18^MFN_M18 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFN^M18^MFN_M18 message is AL or ER or SU, a MFK^M18^MFK_M01 message SHALL be sent as an application ack.
When the MSH-16 value of a MFN^M18^MFN_M18 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M18^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: MFK^M18^MFK_M01 |
NE, AL, ER, SU | (none) |
Send An Acknowlegment is never sent in original mode.
When the MSH-15 value of a MFK^M18^MFK_M01 message is AL or ER or SU, an ACK^M18^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFK^M18^MFK_M01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFK^M18^MFK_M01 message is AL or ER or SU, a message SHALL be sent as an application ack.
When the MSH-16 value of a MFK^M18^MFK_M01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M18^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: |
NE, AL, ER, SU | (none) |
The Technical Steward for the OM1 segment is Orders and Observations.
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# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
OM1 | |||||||||
1 | Sequence Number - Test/Observation Master File | NM | R | [1..1] | 00586 | 4 | # | ||
2 | Producer's Service/Test/Observation ID | CWE | R | [1..1] | 00587 | ||||
3 | Permitted Data Types | ID | O | [0..*] | 00588 | [2..3] | |||
4 | Specimen Required | ID | R | [1..1] | 00589 | [1..1] | |||
5 | Producer ID | CWE | R | [1..1] | 00590 | ||||
6 | Observation Description | TX | O | [0..1] | 00591 | 200 | # | ||
7 | Other Service/Test/Observation IDs for the Observation | CWE | O | [0..*] | 00592 | ||||
8 | Other Names | ST | B | [0..*] | 00593 | 200 | # | ||
9 | Preferred Report Name for the Observation | ST | O | [0..1] | 00594 | 30 | # | ||
10 | Preferred Short Name or Mnemonic for the Observation | ST | O | [0..1] | 00595 | [1..8] | |||
11 | Preferred Long Name for the Observation | ST | O | [0..1] | 00596 | 200 | # | ||
12 | Orderability | ID | O | [0..1] | 00597 | [1..1] | |||
13 | Identity of Instrument Used to Perform this Study | CWE | O | [0..*] | 00598 | ||||
14 | Coded Representation of Method | CWE | O | [0..*] | 00599 | ||||
15 | Portable Device Indicator | ID | O | [0..1] | 00600 | [1..1] | |||
16 | Observation Producing Department/Section | CWE | B | [0..*] | 00601 | ||||
17 | Telephone Number of Section | XTN | B | [0..1] | 00602 | ||||
18 | Nature of Service/Test/Observation | CWE | R | [1..1] | 00603 | [1..1] | |||
19 | Report Subheader | CWE | O | [0..1] | 00604 | ||||
20 | Report Display Order | ST | O | [0..1] | 00605 | 20 | # | ||
21 | Date/Time Stamp for Any Change in Definition for the Observation | DTM | O | [0..1] | 00606 | ||||
22 | Effective Date/Time of Change | DTM | O | [0..1] | 00607 | ||||
23 | Typical Turn-Around Time | NM | B | [0..1] | 00608 | ||||
24 | Processing Time | NM | O | [0..1] | 00609 | ||||
25 | Processing Priority | ID | O | [0..*] | 00610 | [1..1] | |||
26 | Reporting Priority | ID | O | [0..1] | 00611 | [1..1] | |||
27 | Outside Site(s) Where Observation May Be Performed | CWE | B | [0..*] | 00612 | ||||
28 | Address of Outside Site(s) | XAD | B | [0..*] | 00613 | ||||
29 | Phone Number of Outside Site | XTN | B | [0..1] | 00614 | ||||
30 | Confidentiality Code | CWE | O | [0..1] | 00615 | ||||
31 | Observations Required to Interpret this Observation | CWE | B | [0..*] | 00616 | ||||
32 | Interpretation of Observations | TX | O | [0..1] | 00617 | ||||
33 | Contraindications to Observations | CWE | O | [0..*] | 00618 | ||||
34 | Reflex Tests/Observations | CWE | O | [0..*] | 00619 | ||||
35 | Rules that Trigger Reflex Testing | TX | O | [0..*] | 00620 | ||||
36 | Fixed Canned Message | CWE | O | [0..*] | 00621 | ||||
37 | Patient Preparation | TX | O | [0..*] | 00622 | 200 | # | ||
38 | Procedure Medication | CWE | O | [0..1] | 00623 | ||||
39 | Factors that may Affect the Observation | TX | O | [0..1] | 00624 | 200 | # | ||
40 | Service/Test/Observation Performance Schedule | ST | O | [0..*] | 00625 | 60 | # | ||
41 | Description of Test Methods | TX | O | [0..1] | 00626 | ||||
42 | Kind of Quantity Observed | CWE | O | [0..1] | 00937 | ||||
43 | Point Versus Interval | CWE | O | [0..1] | 00938 | ||||
44 | Challenge Information | TX | O | [0..1] | 00939 | 200 | # | ||
45 | Relationship Modifier | CWE | O | [0..1] | 00940 | ||||
46 | Target Anatomic Site Of Test | CWE | O | [0..1] | 00941 | ||||
47 | Modality of Imaging Measurement | CWE | O | [0..1] | 00942 | ||||
48 | Exclusive Test | ID | O | [0..1] | 03310 | [1..1] | |||
49 | Diagnostic Serv Sect ID | ID | O | [0..1] | 00257 | [2..3] | |||
50 | Taxonomic Classification Code | CWE | O | [0..1] | 01539 | ||||
51 | Other Names | ST | O | [0..*] | 03399 | [200..*] | |||
52 | Replacement Producer's Service/Test/Observation ID | CWE | O | [0..*] | 03433 | ||||
53 | Prior Resuts Instructions | TX | O | [0..*] | 03434 | ||||
54 | Special Instructions | TX | O | [0..1] | 03435 | ||||
55 | Test Category | CWE | O | [0..*] | 03436 | ||||
56 | Observation/Identifier associated with Producer’s Service/Test/Observation ID | CWE | O | [0..1] | 03437 | ||||
57 | Typical Turn-Around Time | CQ | O | [0..1] | 03438 | ||||
58 | Gender Restriction | CWE | O | [0..*] | 03439 | ||||
59 | Age Restriction | NR | O | [0..*] | 03440 |
The Technical Steward for the OM2 segment is Orders and Observations.
This segment contains the attributes of observations with continuous values (including those with data types of numeric, date, or time stamp). It can be applied to observation batteries of type A and C (see OM1-18 - Nature of Service/Test/Observation).
Seq# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
OM2 | |||||||||
1 | Sequence Number - Test/Observation Master File | NM | O | [0..1] | 00586 | 4 | # | ||
2 | Units of Measure | CWE | O | [0..1] | 00627 | ||||
3 | Range of Decimal Precision | NM | O | [0..*] | 00628 | 10 | # | ||
4 | Corresponding SI Units of Measure | CWE | O | [0..1] | 00629 | ||||
5 | SI Conversion Factor | TX | O | [0..1] | 00630 | 60 | # | ||
6 | Reference | RFR | O | [0..*] | 00631 | ||||
7 | Critical Range for Ordinal and Continuous Observations | RFR | O | [0..*] | 00632 | ||||
8 | Absolute Range for Ordinal and Continuous Observations | RFR | O | [0..1] | 00633 | ||||
9 | Delta Check Criteria | DLT | O | [0..*] | 00634 | ||||
10 | Minimum Meaningful Increments | NM | O | [0..1] | 00635 |
The Technical Steward for the OM3 segment is Orders and Observations.
This segment applies to free text and other non-numeric data types.
Seq# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
OM3 | |||||||||
1 | Sequence Number - Test/Observation Master File | NM | O | [0..1] | 00586 | 4 | # | ||
2 | Preferred Coding System | CWE | O | [0..1] | 00636 | ||||
3 | Valid Coded "Answers" | CWE | O | [0..*] | 00637 | ||||
4 | Normal Text/Codes for Categorical Observations | CWE | O | [0..*] | 00638 | ||||
5 | Abnormal Text/Codes for Categorical Observations | CWE | O | [0..*] | 00639 | ||||
6 | Critical Text/Codes for Categorical Observations | CWE | O | [0..*] | 00640 | ||||
7 | Value Type | ID | O | [0..1] | 00570 | [2..3] |
The Technical Steward for the OM4 segment is Orders and Observations.
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.
OM4 is a repeating segment. It allows multiple specimens per Order Code and accommodates for multiple alternate specimen for each preferred specimen. In some cases an Order Code can require multiple specimens. In many cases there are preferred specimens and for each preferred it is possible to have one or more alternative specimens. The alternative specimen will carry in OM4-17 the Sequence Number – Test/Observation Master File (OM4-1) of the preferred specimen.
If multiple kinds of specimen are associated with this observation (as in the case for a creatinine clearance), multiple segments may be included, one for each specimen type.
This segment will also allow for reporting Preferred and Alternate specimens, when applicable.
Seq# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
OM4 | |||||||||
1 | Sequence Number - Test/Observation Master File | NM | O | [0..1] | 00586 | 4 | # | ||
2 | Derived Specimen | ID | O | [0..1] | 00642 | [1..1] | |||
3 | Container Description | TX | O | [0..*] | 00643 | [1..60] | 60 | # | |
4 | Container Volume | NM | O | [0..*] | 00644 | ||||
5 | Container Units | CWE | O | [0..*] | 00645 | ||||
6 | Specimen | CWE | O | [0..1] | 00646 | ||||
7 | Additive | CWE | O | [0..1] | 00647 | ||||
8 | Preparation | TX | O | [0..1] | 00648 | ||||
9 | Special Handling Requirements | TX | O | [0..1] | 00649 | ||||
10 | Normal Collection Volume | CQ | O | [0..1] | 00650 | ||||
11 | Minimum Collection Volume | CQ | O | [0..1] | 00651 | ||||
12 | Specimen Requirements | TX | O | [0..1] | 00652 | ||||
13 | Specimen Priorities | ID | O | [0..*] | 00653 | [1..1] | |||
14 | Specimen Retention Time | CQ | O | [0..1] | 00654 | ||||
15 | Specimen Handling Code | CWE | O | [0..*] | 01908 | ||||
16 | Specimen Preference | ID | O | [0..1] | 03311 | ||||
17 | Preferred Specimen/Attribture Sequence ID | NM | O | [0..1] | 03312 | ||||
18 | Taxonomic Classification Code | CWE | O | [0..*] | 01539 |
The Technical Steward for the OM5 segment is Orders and Observations.
This segment contains the information about batteries and supersets (a nature code of F, P or S, as described in OM1-18 - Nature of Service/Test/Observation).
Seq# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
OM5 | |||||||||
1 | Sequence Number - Test/Observation Master File | NM | O | [0..1] | 00586 | 4 | # | ||
2 | Test/Observations Included Within an Ordered Test Battery | CWE | O | [0..*] | 00655 | ||||
3 | Observation ID Suffixes | ST | O | [0..1] | 00656 |
The Technical Steward for the OM6 segment is Orders and Observations.
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# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
OM6 | |||||||||
1 | Sequence Number - Test/Observation Master File | NM | O | [0..1] | 00586 | 4 | # | ||
2 | Derivation Rule | TX | O | [0..1] | 00657 |
The Technical Steward for the OM7 segment is Orders and Observations.
The OM7 segment contains additional basic attributes that apply to the definition of most observations/services.
Seq# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
OM7 | |||||||||
1 | Sequence Number - Test/Observation Master File | NM | R | [1..1] | 00586 | 4 | # | ||
2 | Universal Service Identifier | CWE | R | [1..1] | 00238 | ||||
3 | Category Identifier | CWE | O | [0..*] | 01481 | ||||
4 | Category Description | TX | O | [0..1] | 01482 | 200 | # | ||
5 | Category Synonym | ST | O | [0..*] | 01483 | 200 | # | ||
6 | Effective Test/Service Start Date/Time | DTM | O | [0..1] | 01484 | ||||
7 | Effective Test/Service End Date/Time | DTM | O | [0..1] | 01485 | ||||
8 | Test/Service Default Duration Quantity | NM | O | [0..1] | 01486 | 5 | # | ||
9 | Test/Service Default Duration Units | CWE | O | [0..1] | 01487 | ||||
10 | Test/Service Default Frequency | CWE | O | [0..1] | 01488 | 60 | # | ||
11 | Consent Indicator | ID | O | [0..1] | 01489 | [1..1] | |||
12 | Consent Identifier | CWE | O | [0..1] | 01490 | ||||
13 | Consent Effective Start Date/Time | DTM | O | [0..1] | 01491 | ||||
14 | Consent Effective End Date/Time | DTM | O | [0..1] | 01492 | ||||
15 | Consent Interval Quantity | NM | O | [0..1] | 01493 | 5 | # | ||
16 | Consent Interval Units | CWE | C | [0..1] | 01494 | ||||
17 | Consent Waiting Period Quantity | NM | O | [0..1] | 01495 | 5 | # | ||
18 | Consent Waiting Period Units | CWE | C | [0..1] | 01496 | ||||
19 | Effective Date/Time of Change | DTM | O | [0..1] | 00607 | ||||
20 | Entered By | XCN | B | [0..1] | 00224 | ||||
21 | Orderable-at Location | PL | B | [0..*] | 01497 | ||||
22 | Formulary Status | CWE | O | [0..1] | 01498 | 1 | # | ||
23 | Special Order Indicator | ID | O | [0..1] | 01499 | [1..1] | |||
24 | Primary Key Value - CDM | CWE | O | [0..*] | 01306 |
The Technical Steward for the OMC segment is Orders and Observations.
Seq# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
OMC | |||||||||
1 | Sequence Number - Test/Observation Master File | NM | O | [0..1] | 00586 | 4 | # | ||
2 | Segment Action Code | ID | C | 00763 | [1..1] | ||||
3 | Segment Unique Key | EI | C | 00764 | |||||
4 | Clinical Information Request | CWE | R | [1..1] | 03444 | ||||
5 | Collection Event/Process Step | CWE | R | [1..*] | 03445 | ||||
6 | Communication Location | CWE | R | [1..1] | 03446 | ||||
7 | Answer Required | ID | O | [0..1] | 03447 | ||||
8 | Hint/Help Text | ST | O | [0..1] | 03448 | ||||
9 | Type of Answer | ID | O | [0..1] | 03449 | ||||
10 | Multiple Answers Allowed | ID | O | [0..1] | 03450 | ||||
11 | Answer Choices | CWE | O | [0..*] | 03451 | ||||
12 | Character Limit | NM | O | [0..1] | 03452 | ||||
13 | Number of Decimals | NM | O | [0..1] | 03453 |
The Technical Steward for the PM1 segment is Orders and Observations.
The PM1 segment contains per insurance company (payer) the policies specific to their organization. Trailing this segment in the message structure are either the Limited Coverage Policy or the Approved Coverage Policy. If an insurance company is listed they have limited coverage. Note, the first 10 fields come directly from the IN1 segment.
Seq# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
PM1 | |||||||||
1 | Health Plan ID | CWE | R | [1..1] | 00368 | ||||
2 | Insurance Company ID | CX | R | [1..*] | 00428 | ||||
3 | Insurance Company Name | XON | O | [0..*] | 00429 | ||||
4 | Insurance Company Address | XAD | O | [0..*] | 00430 | ||||
5 | Insurance Co Contact Person | XPN | O | [0..*] | 00431 | ||||
6 | Insurance Co Phone Number | XTN | O | [0..*] | 00432 | ||||
7 | Group Number | ST | O | [0..1] | 00433 | 12 | # | ||
8 | Group Name | XON | O | [0..*] | 00434 | ||||
9 | Plan Effective Date | DT | O | [0..1] | 00437 | ||||
10 | Plan Expiration Date | DT | O | [0..1] | 00438 | ||||
11 | Patient DOB Required | ID | O | [0..1] | 03454 | ||||
12 | Patient Gender Required | ID | O | [0..1] | 03455 | ||||
13 | Patient Relationship Required | ID | O | [0..1] | 03456 | ||||
14 | Patient Signature Required | ID | O | [0..1] | 03457 | ||||
15 | Diagnosis Required | ID | O | [0..1] | 03458 | ||||
16 | Service Required | ID | O | [0..1] | 03459 | ||||
17 | Patient Name Required | ID | O | [0..1] | 03460 | ||||
18 | Patient Address Required | ID | O | [0..1] | 03461 | ||||
19 | Subscribers Name Required | ID | O | [0..1] | 03462 | ||||
20 | Workman's Comp Indicator | ID | O | [0..1] | 03463 | ||||
21 | Bill Type Required | ID | O | [0..1] | 03464 | ||||
22 | Commercial Carrier Name and Address Required | ID | O | [0..1] | 03465 | ||||
23 | Policy Number Pattern | ST | O | [0..1] | 03466 | ||||
24 | Group Number Pattern | ST | O | [0..1] | 03467 |
The Technical Steward for the PM1 segment is Orders and Observations.
For the payer defined in PM1-1 and the service provider defined in MFE-4:
When MFI-1 is MLCP (Medical Limited Coverage Process) this segment is identifing what is in limited coverage.
When MFI-1 is MACP (Medical Approved Coverage Process) this segment is identifing what is approved. This segment defines the tests that are approved for a given Diagnosis Code based on the Procedure Code.
Seq# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
MCP | |||||||||
1 | Set ID - MCP | SI | R | [1..1] | 03468 | [1..4] | |||
2 | Producer's Service/Test/Observation ID | CWE | R | [1..1] | 00587 | ||||
3 | Universal Service Price Range – Low Value | MO | O | [0..1] | 03469 | ||||
4 | Universal Service Price Range – High Value | MO | O | [0..1] | 03470 | ||||
5 | Reason for Universal Service Cost Range | ST | C | [0..1] | 03471 |
The Technical Steward for the DPS segment is Orders and Observations.
For the payer defined in PM1-1 and the service provider defined in MFE-4 and the Producer's Service/Test/Observation ID in MCP-2 these are the Diagnosis and Procedure that impact coverage requirements as defined by:
When MFI-1 is MLCP (Medical Limited Coverage Process) this segment is identifing what is in limited coverage.
When MFI-1 is MACP (Medical Approved Coverage Process) this segment is identifing what is approved. This segment defines the test that are approved for a given Diagnosis Code based on the Procedure Code.
Seq# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
DPS | |||||||||
1 | Diagnosis Code - MCP | CWE | R | [1..1] | 03472 | ||||
2 | Procedure Code | CWE | R | [1..*] | 03484 | ||||
3 | Effective Date/Time | DTM | O | [0..1] | 00662 | ||||
4 | Expiration Date/Time | DTM | O | [0..1] | 03473 | ||||
5 | Type of Limitation | CNE | O | [0..1] | 03474 |
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 Section 8.5, "GENERAL MASTER FILE SEGMENTS." In the following message, the MFI-1 - Master File Identifier field should equal "LOC"
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.
Send Application Ack: MFK^M05^MFK_M01
When the MSH-15 value of a MFN^M05^MFN_M05 message is AL or ER or SU, an ACK^M05^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFN^M05^MFN_M05 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFN^M05^MFN_M05 message is AL or ER or SU, a MFK^M05^MFK_M01 message SHALL be sent as an application ack.
When the MSH-16 value of a MFN^M05^MFN_M05 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M05^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: MFK^M05^MFK_M01 |
NE, AL, ER, SU | (none) |
Send Immediate Ack: ACK^M05^ACK
When the MSH-15 value of a MFK^M05^MFK_M01 message is AL or ER or SU, an ACK^M05^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFK^M05^MFK_M01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFK^M05^MFK_M01 message is AL or ER or SU, a message SHALL be sent as an application ack.
When the MSH-16 value of a MFK^M05^MFK_M01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M05^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: |
NE, AL, ER, SU | (none) |
The Technical Steward for the LOC segment is Patient Administration.
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# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
LOC | |||||||||
1 | Primary Key Value - LOC | PL | R | [1..1] | 01307 | ||||
2 | Location Description | ST | O | [0..1] | 00944 | 48 | # | ||
3 | Location Type - LOC | CWE | R | [1..*] | 00945 | 1 | # | ||
4 | Organization Name - LOC | XON | O | [0..*] | 00947 | ||||
5 | Location Address | XAD | O | [0..*] | 00948 | ||||
6 | Location Phone | XTN | O | [0..*] | 00949 | ||||
7 | License Number | CWE | O | [0..*] | 00951 | ||||
8 | Location Equipment | CWE | O | [0..*] | 00953 | 3 | # | ||
9 | Location Service Code | CWE | O | [0..1] | 01583 | 1 | # |
The Technical Steward for the LCH segment is Patient Administration.
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# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
LCH | |||||||||
1 | Primary Key Value - LCH | PL | R | [1..1] | 01305 | ||||
2 | Segment Action Code | ID | O | [0..1] | 00763 | [1..1] | |||
3 | Segment Unique Key | EI | O | [0..1] | 00764 | ||||
4 | Location Characteristic ID | CWE | R | [1..1] | 01295 | ||||
5 | Location Characteristic Value - LCH | CWE | R | [1..1] | 01294 |
The Technical Steward for the LRL segment is Patient Administration.
The LRL segment is used to identify one location's relationship to another location, the nearest lab, pharmacy, etc.
Seq# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
LRL | |||||||||
1 | Primary Key Value - LRL | PL | R | [1..1] | 00943 | ||||
2 | Segment Action Code | ID | O | [0..1] | 00763 | [1..1] | |||
3 | Segment Unique Key | EI | O | [0..1] | 00764 | ||||
4 | Location Relationship ID | CWE | R | [1..1] | 01277 | ||||
5 | Organizational Location Relationship Value | XON | C | [0..*] | 01301 | ||||
6 | Patient Location Relationship Value | PL | C | [0..1] | 01292 |
The Technical Steward for the LDP segment is Patient Administration.
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# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
LDP | |||||||||
1 | Primary Key Value - LDP | PL | R | [1..1] | 00963 | ||||
2 | Location Department | CWE | R | [1..1] | 00964 | ||||
3 | Location Service | CWE | O | [0..*] | 00965 | 3 | # | ||
4 | Specialty Type | CWE | O | [0..*] | 00966 | ||||
5 | Valid Patient Classes | CWE | O | [0..*] | 00967 | 1 | # | ||
6 | Active/Inactive Flag | ID | O | [0..1] | 00675 | [1..1] | |||
7 | Activation Date - LDP | DTM | O | [0..1] | 00969 | ||||
8 | Inactivation Date - LDP | DTM | O | [0..1] | 00970 | ||||
9 | Inactivated Reason | ST | O | [0..1] | 00971 | 80 | # | ||
10 | Visiting Hours | VH | O | [0..*] | 00976 | ||||
11 | Contact Phone | XTN | O | [0..1] | 00978 | ||||
12 | Location Cost Center | CWE | O | [0..1] | 01584 |
The Technical Steward for the LCC segment is PA.
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# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
LCC | |||||||||
1 | Primary Key Value - LCC | PL | R | [1..1] | 00979 | ||||
2 | Location Department | CWE | R | [1..1] | 00964 | ||||
3 | Accommodation Type | CWE | O | [0..*] | 00980 | ||||
4 | Charge Code | CWE | R | [1..*] | 00981 |
The charge description (CDM) master file segment should be used in conjunction with the general master file segments in Section 8.5, "GENERAL MASTER FILE SEGMENTS." Interfacing systems often need not only to communicate data about a patient's detailed charges, but also to communicate the charge identification entries by which an application knows how to handle a particular charge code. The charge description master is a master file.
The NTE segment may also contain other information to the provider to convey other requirements or context. For example:
Convey the status of Federal Drug Administration (FDA) approval of the test. For example, the test may have FDA approval but is not validated yet because of limited gathering of data to confirm the validity of the test.
Convey that a patient’s consent must be obtained before the test is ordered. This requirement can be conveyed in this NTE as well.
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:
Send Application Ack: MFK^M04^MFK_M01
When the MSH-15 value of a MFN^M04^MFN_M04 message is AL or ER or SU, an ACK^M04^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFN^M04^MFN_M04 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFN^M04^MFN_M04 message is AL or ER or SU, a MFK^M04^MFK_M01 message SHALL be sent as an application ack.
When the MSH-16 value of a MFN^M04^MFN_M04 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M04^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: MFK^M04^MFK_M01 |
NE, AL, ER, SU | (none) |
Send Immediate Ack: ACK^M04^ACK
When the MSH-15 value of a MFK^M04^MFK_M01 message is AL or ER or SU, an ACK^M04^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFK^M04^MFK_M01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFK^M04^MFK_M01 message is AL or ER or SU, a message SHALL be sent as an application ack.
When the MSH-16 value of a MFK^M04^MFK_M01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M04^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: |
NE, AL, ER, SU | (none) |
The Technical Steward for the CDM segment is Financial Management.
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# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
CDM | |||||||||
1 | Primary Key Value - CDM | CWE | R | [1..1] | 01306 | ||||
2 | Charge Code Alias | CWE | O | [0..*] | 00983 | ||||
3 | Charge Description Short | ST | R | [1..1] | 00984 | 20 | # | ||
4 | Charge Description Long | ST | O | [0..1] | 00985 | 250 | # | ||
5 | Description Override Indicator | CWE | O | [0..1] | 00986 | 1 | # | ||
6 | Exploding Charges | CWE | O | [0..*] | 00987 | ||||
7 | Procedure Code | CNE | O | [0..*] | 00393 | ||||
8 | Active/Inactive Flag | ID | O | [0..1] | 00675 | [1..1] | |||
9 | Inventory Number | CWE | O | [0..*] | 00990 | ||||
10 | Resource Load | NM | O | [0..1] | 00991 | 12 | # | ||
11 | Contract Number | CX | O | [0..*] | 00992 | ||||
12 | Contract Organization | XON | O | [0..*] | 00993 | ||||
13 | Room Fee Indicator | ID | O | [0..1] | 00994 | [1..1] |
The Technical Steward for the PRC segment is Financial Management.
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# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
PRC | |||||||||
1 | Primary Key Value - PRC | CWE | R | [1..1] | 00982 | ||||
2 | Facility ID - PRC | CWE | O | [0..*] | 00995 | ||||
3 | Department | CWE | O | [0..*] | 00676 | ||||
4 | Valid Patient Classes | CWE | O | [0..*] | 00967 | 1 | # | ||
5 | Price | CP | C | [0..*] | 00998 | ||||
6 | Formula | ST | O | [0..*] | 00999 | 200 | # | ||
7 | Minimum Quantity | NM | O | [0..1] | 01000 | 4 | # | ||
8 | Maximum Quantity | NM | O | [0..1] | 01001 | 4 | # | ||
9 | Minimum Price | MO | O | [0..1] | 01002 | ||||
10 | Maximum Price | MO | O | [0..1] | 01003 | ||||
11 | Effective Start Date | DTM | O | [0..1] | 01004 | ||||
12 | Effective End Date | DTM | O | [0..1] | 01005 | ||||
13 | Price Override Flag | CWE | O | [0..1] | 01006 | 1 | # | ||
14 | Billing Category | CWE | O | [0..*] | 01007 | ||||
15 | Chargeable Flag | ID | O | [0..1] | 01008 | [1..1] | |||
16 | Active/Inactive Flag | ID | O | [0..1] | 00675 | [1..1] | |||
17 | Cost | MO | O | [0..1] | 00989 | ||||
18 | Charge on Indicator | CWE | O | [0..1] | 01009 | 1 | # |
MSH|^~VALUEamp;|HL7REG|UH|HL7LAB|CH|19910918060544||MFN^M04^MFN_M04|MSGID002|P|2.9||AL|NE
MFI|CDM||UPD|||AL
MFE|MAD|CDM98123789182|199110011230|P2246^^PLW|CWE
CDM|P2246^^PLW |2445|APPENDECTOMY|APPENDECTOMY|X||244.34|A|2321||||N
PRC|P2246^^PLW |FAC3|SURG|O~A|100.00^UP |formula |1|1 |100.00^USD|1000.00^USD|19941031||Y|GL545|Y|A|
The CM0 (Clinical Study Master), CM1 (Clinical Study Phase), and CM2 (Clinical Study Schedule) segments can be used to transmit master files information between systems. The CM0 segment contains the information about the study itself; the CM1 contains the information about one phase of the study identified in the preceding CM0; and the CM2 contains the information about the scheduled time points for the preceding study or phase-related treatment or evaluation events. When these segments are used in an MFN message, the abstract definition is described below.
Case 1: MFN message for Clinical Study with phases and schedules
MFI-1 - Master File Identifier Code = CMA
Case 2: MFN message for Clinical Study without phases but with schedules
MFI-1 - Master File Identifier Code = CMB
Send Application Ack: MFK^M06^MFK_M01
When the MSH-15 value of a MFN^M06^MFN_M06 message is AL or ER or SU, an ACK^M06^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFN^M06^MFN_M06 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFN^M06^MFN_M06 message is AL or ER or SU, a MFK^M06^MFK_M01 message SHALL be sent as an application ack.
When the MSH-16 value of a MFN^M06^MFN_M06 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M06^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: MFK^M06^MFK_M01 |
NE, AL, ER, SU | (none) |
Send Immediate Ack: ACK^M06^ACK
When the MSH-15 value of a MFK^M06^MFK_M01 message is AL or ER or SU, an ACK^M06^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFK^M06^MFK_M01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFK^M06^MFK_M01 message is AL or ER or SU, a message SHALL be sent as an application ack.
When the MSH-16 value of a MFK^M06^MFK_M01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M06^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: |
NE, AL, ER, SU | (none) |
Send Application Ack: MFK^M07^MFK_M01
When the MSH-15 value of a MFN^M07^MFN_M07 message is AL or ER or SU, an ACK^M07^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFN^M07^MFN_M07 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFN^M07^MFN_M07 message is AL or ER or SU, a MFK^M07^MFK_M01 message SHALL be sent as an application ack.
When the MSH-16 value of a MFN^M07^MFN_M07 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M07^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: MFK^M07^MFK_M01 |
NE, AL, ER, SU | (none) |
Send Immediate Ack: ACK^M07^ACK
When the MSH-15 value of a MFK^M07^MFK_M01 message is AL or ER or SU, an ACK^M07^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFK^M07^MFK_M01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFK^M07^MFK_M01 message is AL or ER or SU, a message SHALL be sent as an application ack.
When the MSH-16 value of a MFK^M07^MFK_M01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M07^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: |
NE, AL, ER, SU | (none) |
The Technical Steward for the CM0 segment is Orders and Observations.
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# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
CM0 | |||||||||
1 | Set ID - CM0 | SI | O | [0..1] | 01010 | [1..4] | |||
2 | Sponsor Study ID | EI | R | [1..1] | 01011 | ||||
3 | Alternate Study ID | EI | O | [0..3] | 01036 | ||||
4 | Title of Study | ST | R | [1..1] | 01013 | 300 | # | ||
5 | Chairman of Study | XCN | O | [0..*] | 01014 | ||||
6 | Last IRB Approval Date | DT | O | [0..1] | 01015 | ||||
7 | Total Accrual to Date | NM | O | [0..1] | 01016 | 8 | # | ||
8 | Last Accrual Date | DT | O | [0..1] | 01017 | ||||
9 | Contact for Study | XCN | O | [0..*] | 01018 | ||||
10 | Contact's Telephone Number | XTN | O | [0..1] | 01019 | ||||
11 | Contact's Address | XAD | O | [0..*] | 01020 |
The Technical Steward for the CM1 segment is Orders and Observations.
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# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
CM1 | |||||||||
1 | Set ID - CM1 | SI | R | [1..1] | 01021 | [1..4] | |||
2 | Study Phase Identifier | CWE | R | [1..1] | 01022 | ||||
3 | Description of Study Phase | ST | R | [1..1] | 01023 | 300 | # |
The Technical Steward for the CM2 segment is Orders and Observations.
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# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
CM2 | |||||||||
1 | Set ID- CM2 | SI | O | [0..1] | 01024 | [1..4] | |||
2 | Scheduled Time Point | CWE | R | [1..1] | 01025 | ||||
3 | Description of Time Point | ST | O | [0..1] | 01026 | 300 | # | ||
4 | Events Scheduled This Time Point | CWE | R | [1..200] | 01027 |
This section is concerned with describing a master file message that should be used to communicate information that relates to the inventory of items that can be used to perform an ordered service. While an order specifies a service that is represented in an Other Observation/Service Item master file, this message is concerned with communicating attributes of those orderable items (for example lot number and expiration date) that are represented in the Other Observation/Service Item master file. These attributes are more granular than can be represented in the Other Observation/Service Item master file as there may be multiple items in inventory that meet the characteristics of the Service Item but have different specific characteristics, e.g., multiple lots of a vaccine.
Each MFE/IIM structure describes a specific set of lot, expiration date, location, etc. for a Service Item. Multiple instances of MFE/IIM could be used to describe the same Service Item lot at multiple locations, or a location with multiple lots of the same Service Item.
This message is not intended to act as a complete inventory management system. Various inventory management concepts, e.g., PAR levels, invoice and purchase order tracking, are intentionally not supported. The message is intended to synchronize limited orderable item attributes, e.g., quantity on hand, lot number, expiration date, between communicating systems. Such systems may include a Pharmacy Application and a Nurse-based dispensing system. While the Pharmacy application may define the service items (communicated in [MFN^M12^MFN_12] Other Observation/Service Item master file Messages), the dispensing system would communicate the lot numbers, expiration date and quantity on hand for service items in inventory using the Inventory Item Master file message.
Note: The IIM segment has been moved to Chapter 17.
Master Files Query Response: Refer to Section 8.4.4.
Send Application Ack: MFK^M15^MFK_M01
When the MSH-15 value of a MFN^M15^MFN_M15 message is AL or ER or SU, an ACK^M15^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFN^M15^MFN_M15 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFN^M15^MFN_M15 message is AL or ER or SU, a MFK^M15^MFK_M01 message SHALL be sent as an application ack.
When the MSH-16 value of a MFN^M15^MFN_M15 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M15^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: MFK^M15^MFK_M01 |
NE, AL, ER, SU | (none) |
Send Immediate Ack: ACK^M15^ACK
When the MSH-15 value of a MFK^M15^MFK_M01 message is AL or ER or SU, an ACK^M15^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFK^M15^MFK_M01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFK^M15^MFK_M01 message is AL or ER or SU, a message SHALL be sent as an application ack.
When the MSH-16 value of a MFK^M15^MFK_M01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M15^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: |
NE, AL, ER, SU | (none) |
This section describes a master file message designed to communicate information that relates to the sharing of material item master catalog and material item-inventory information between materials management systems and other systems such as surgical and immunization systems. The synchronization of the "item master" between systems and across the enterprise enables the success of the subsequent interfacing of transactions such as: material item requisitions (pre and post case), accounts payable invoices for the payment of material items, journal entries generated from the issue of items to departments or other inventory locations, and patient charges that allow a customer to improve patient care through the better management of materials. To face budget challenges, healthcare organizations need materials management systems that integrate with finance to automate logistics, eliminate paperwork and analyze data to improve efficiency and reduce overall costs. This process is a major contributor to improving the customers' bottom line by helping to eliminate materials waste, streamline ordering, ensure accurate payment of materials purchased, ensure accurate billing for materials used, and an accurate presentation of the financial statements of a healthcare facility.
Material items defined in this message include consumable supplies, devices, surgical sets, and implants.
Each MFE/ITM structure describes a set of attributes, specific to a material item existing in an item master catalog. The PCE and NTE segments are optional and repeating, associated with the item referred to in the ITM segment. An item may be linked to many patient charge exception combinations.
Each VND/PKG segment grouping includes the available vendors and packaging information valid for the item referred to in the ITM segment. An item may be associated with many vendors. A vendor may be linked to many packaging configurations. Therefore the vendor segment can repeat and can include a repeating PKG segment within each repetition of the vendor segment.
Each MFE/ITM/IVT structure describes a set of attributes specific to the inventory locations associated with the item referred to in the associated ITM segment. An inventory item can exist in more than one inventory location with different values for the same attributes, therefore, this segment repeats.
The ILT segment describes lot and quantity information for a material product. In the message structure, this segment is directly associated with the IVT segment, thus the lot/quantity information is always related to a location. Repetition of the ILT segment supports the case where more than one lot of a material product may exist in an inventory location.
Note that the quantities in the ILT segment are not necessarily intended to refer to continuously updated inventory quantities. The expectation is that periodic inventory quantities would be updated with subsequent master file messages. This segment can be used for interfacing, for example, Immunization information.
Additional specialized information segments may be defined as additional use cases are defined, such as medication/drug segments.
Master Files Query Response: Refer to Section 8.4.4.
Send Application Ack: MFK^M16^MFK_M01
When the MSH-15 value of a MFN^M16^MFN_M16 message is AL or ER or SU, an ACK^M16^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFN^M16^MFN_M16 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFN^M16^MFN_M16 message is AL or ER or SU, a MFK^M16^MFK_M01 message SHALL be sent as an application ack.
When the MSH-16 value of a MFN^M16^MFN_M16 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M16^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: MFK^M16^MFK_M01 |
NE, AL, ER, SU | (none) |
Send Immediate Ack: ACK^M16^ACK
When the MSH-15 value of a MFK^M16^MFK_M01 message is AL or ER or SU, an ACK^M16^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFK^M16^MFK_M01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFK^M16^MFK_M01 message is AL or ER or SU, a message SHALL be sent as an application ack.
When the MSH-16 value of a MFK^M16^MFK_M01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M16^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: |
NE, AL, ER, SU | (none) |
This section is specifically concerned with describing a master file message that should be used to transmit information which identifies the DRG basic information, such as relative weight, lower and upper trim points, etc.
The DMI segment must be preceded by the MFI and MFE segments, as described in Section 8.5, GENERAL MASTER FILE SEGMENTS. In the following message, the MFI-1 - Master File Identifier field should equal "DMI".
Master Files Query Response: Refer to Section 8.4.4.
Send Application Ack: MFK^M17^MFK_M01
When the MSH-15 value of a MFN^M17^MFN_M17 message is AL or ER or SU, an ACK^M17^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFN^M17^MFN_M17 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFN^M17^MFN_M17 message is AL or ER or SU, a MFK^M17^MFK_M01 message SHALL be sent as an application ack.
When the MSH-16 value of a MFN^M17^MFN_M17 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M17^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: MFK^M17^MFK_M01 |
NE, AL, ER, SU | (none) |
Send Immediate Ack: ACK^M17^ACK
When the MSH-15 value of a MFK^M17^MFK_M01 message is AL or ER or SU, an ACK^M17^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFK^M17^MFK_M01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFK^M17^MFK_M01 message is AL or ER or SU, a message SHALL be sent as an application ack.
When the MSH-16 value of a MFK^M17^MFK_M01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M17^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: |
NE, AL, ER, SU | (none) |
The Technical Steward for the DMI segment is Financial Management.
The DMI segment contains the DRG related basic information, for example, relative weight, etc. The DMI segment is used to send the fixed information assigned to a specific DRG.
Seq# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
DMI | |||||||||
1 | Diagnostic Related Group | CNE | O | [0..1] | 00382 | ||||
2 | Major Diagnostic Category | CNE | C | [0..1] | 00381 | ||||
3 | Lower and Upper Trim Points | NR | C | [0..1] | 02231 | ||||
4 | Average Length of Stay | NM | C | [0..1] | 02232 | 5 | # | ||
5 | Relative Weight | NM | C | [0..1] | 02233 | 7 | # |
The following segments are required: MSH, MFI, MFE, CTR, ITM, and VND. PKG is optional. Example- there could be a contract created with no items on it yet, and be saved as Active (corporation and vendor are required but it is not required to add items). The message would have an MSH, MFI, MFE, CTR, ITM (blank), VND, and PKG (blank).
Send Application Ack: MFK^M19^MFK_M01
When the MSH-15 value of a MFN^M19^MFN_M19 message is AL or ER or SU, an ACK^M19^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFN^M19^MFN_M19 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFN^M19^MFN_M19 message is AL or ER or SU, a MFK^M19^MFK_M01 message SHALL be sent as an application ack.
When the MSH-16 value of a MFN^M19^MFN_M19 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M19^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: MFK^M19^MFK_M01 |
NE, AL, ER, SU | (none) |
Send An Acknowlegment is never sent in original mode.
When the MSH-15 value of a MFK^M19^MFK_M01 message is AL or ER or SU, an ACK^M19^ACK message SHALL be sent as an immediate ack.
When the MSH-15 value of a MFK^M19^MFK_M01 message is NE or AL or ER or SU, an immediate ack SHALL NOT be sent.
When the MSH-16 value of a MFK^M19^MFK_M01 message is AL or ER or SU, a message SHALL be sent as an application ack.
When the MSH-16 value of a MFK^M19^MFK_M01 message is NE or AL or ER or SU, an application ack SHALL NOT be sent.
Field | Value | Send Response |
---|---|---|
MSH-15 | AL, ER, SU | immediate ack: ACK^M19^ACK |
NE, AL, ER, SU | (none) | |
MSH-16 | AL, ER, SU | application ack: |
NE, AL, ER, SU | (none) |
Definition: The Contract Master File is a message which will send MedSurg supply item contracts from a supplier to a Materials Management Information system (MMIS) or from an MMIS to other systems which place orders for the supply items. The main purpose of this integration point is to assign the contract price to the supply items (in the MMIS Item
Seq# | Data Element Name | DataType | Usage | Vocabulary | Cardinality | Item # | Length | C.LEN | Flags |
---|---|---|---|---|---|---|---|---|---|
CTR | |||||||||
1 | Contract Identifier | EI | R | [1..1] | 02392 | ||||
2 | Contract Description | ST | O | [0..1] | 02393 | 999 | # | ||
3 | Contract Status | CWE | O | [0..1] | 02394 | ||||
4 | Effective Date | DTM | R | [1..1] | 02395 | ||||
5 | Expiration Date | DTM | R | [1..1] | 02396 | ||||
6 | Contract Owner Name | XPN | O | [0..1] | 02397 | ||||
7 | Contract Originator Name | XPN | O | [0..1] | 02398 | ||||
8 | Supplier Type | CWE | R | [1..1] | 02399 | ||||
9 | Contract Type | CWE | O | [0..1] | 02400 | ||||
10 | Free On Board Freight Terms | CNE | O | [0..1] | 02401 | ||||
11 | Price Protection Date | DTM | O | [0..1] | 02402 | ||||
12 | Fixed Price Contract Indicator | CNE | O | [0..1] | 02403 | ||||
13 | Group Purchasing Organization | XON | O | [0..1] | 02404 | ||||
14 | Maximum Markup | MOP | O | [0..1] | 02405 | ||||
15 | Actual Markup | MOP | O | [0..1] | 02406 | ||||
16 | Corporation | XON | C | [0..*] | 02407 | ||||
17 | Parent of Corporation | XON | O | [0..1] | 02408 | ||||
18 | Pricing Tier Level | CWE | O | [0..1] | 02409 | ||||
19 | Contract Priority | ST | O | [0..1] | 02410 | ||||
20 | Class of Trade | CWE | O | [0..1] | 02411 | ||||
21 | Associated Contract ID | EI | O | [0..1] | 02412 |
This example shows the lab system using the Master Files specification to send two update test dictionary entries to an ICU system. The OM1 (observation dictionary) segment, currently under development by HL7 and ASTM, carries the dictionary information. Several varieties of acknowledgement are shown. The choice of acknowledgment mode is site-specific.
Original mode example:
MSH|^~VALUEamp;|LABxxx|ClinLAB|ICU||19910918060544||MFN^M03^MFN_M03|MSGID002|P|2.9
MFI|OMA|LABxxx^Lab Test Dictionary^L|UPD|||AL
MFE|MUP|199109051000|199110010000|12345^WBC^L|CWE
OM1|...
MFE|MP|199109051015|199110010000|6789^RBC^L|CWE
OM1|...
Original mode acknowledgment of the HL7 message according to MFI Response Level Code of AL.
MSH|^~VALUEamp;|ICU||LABxxx|ClinLAB|19910918060545||MFK^M03^MFK_M01|MSGID99002|P|2.9
MSA|AA|MSGID002
MFI|OMA|LABxxx^Lab Test Dictionary^L|UPD|||AL
MFA|MUP|199110010000|199110010040|S|12345^WBC^L|CWE
MFA|MUP|199110010000|199110010041|S|6789^RBC^L|CWE
Enhanced mode example
Initial message with accept acknowledgment
MSH|^~VALUEamp;|LABxxx|ClinLAB|ICU||19910918060544||MFN^M03^MFN_M03|MSGID002|P|2.9|||AL|AL
MFI|OMA|LABxxx^Lab Test Dictionary^L|UPD|||AL
MFE|MUP|199109051000|199110010000|12345^WBC^L|CWE
OM1|...
MFE|MUP|199109051015|199110010000|6789^RBC^L|CWE
OM1|...
MSH|^~VALUEamp;|ICU||LABxxx|ClinLAB|19910918060545||ACK^M03^ACK|MSGID99002|P|2.7
MSA|CA|MSGID002
Application acknowledgment message
MSH|^~VALUEamp;|ICU||LABxxx|ClinLAB|19911001080504||MFK^M03^MFK_M01|MSGID5002|P|2.9|||AL|
MSA|AA|MSGID002
MFI|OMA|LABxxx^Lab Test Dictionary^L|UPD|||AL
MFA|MUP|199109051000|199110010040|S|12345^WBC^L|CWE
MFA|MUP|199109051015|199110010041|S|6789^RBC^L|CWE
MSH|^~VALUEamp;|LABxxx|ClinLAB|ICU||19911001080507||ACK^M03^ACK|MSGID444|P|2.7
MSA|CA|MSGID5002
We invite proposals for the specification of other HL7-wide master files segments.