visit the hl7 website The Demo site for our new HL7 Version 2+ (plus) Standard

19.12.2 Master Files (99.1.7)

20 . Master Files (8)

Chapter Chair

Anthony Julian Mayo Clinic/Foundation

Chapter Chair

Dave Shaver Corepoint Health

Chapter Chair

Sandra Stuart Kaiser Permanente

Contributor

Jim Kingsland McKesson Provider Technologies

Chapter Editor

Scott Robertson Kaiser Permanente

List Server:

inm@lists.hl7.org

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

OM1, OM2, OM3 , OM4, OM5, OM6, OM7, OMC, PM1, MCP, DPS

Orders/Observations (Clinical Trials)

M06, M07

CM0, CM1, CM2

20.1 CHAPTER 8 CONTENTS (8.1)

20.2 PURPOSE (8.2)

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:

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 8.7, "STAFF AND PRACTITIONER MASTER FILES," through 8.11, "CLINICAL TRIALS MASTER FILES" of this chapter.

A given master files message concerns only a single master file. However, the provision of a record-level event code (and requested activation date) on the MFE and the MFA segments allows a single message to contain several types of changes (events) to that file.

The Master Files Notification events do not specify whether the receiving system must support an automated change of the master file in question, nor do they specify whether the receiving system must create a file in the same form as that maintained on the sending system.

In general, the way in which the receiving system processes the change notification message will depend on both the design of the receiving system and the requirements negotiated at the site. Some systems and/or sites may specify a manual review of all changes to a particular master file. Some may specify a totally automated process. Not every system at every site will need all the fields contained in the master file segment(s) following the MFE segment for a particular master file entry.

This also means that an application acknowledgment (or a deferred application acknowledgment) from a receiving system that it changed a particular record in its version of the master file does not imply that the receiving system now has an exact copy of the information and state that is on the sending system: it means only that whatever subset of that master file's data (and state) that has been negotiated at the site is kept on the receiving system in such a manner that a new Master Files Notification transaction with the same primary key can be applied unambiguously (in the manner negotiated at the site) to that subset of information.

20.3 TRIGGER EVENTS (8.3)

The Master Files Change Notification message can be used for the following message-level trigger events:

TBD: HEADER

TBD: HEADER

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

20.4 MESSAGES (8.4)

The following messages are defined for master files transactions: MFN, master files notification; MFK, master files application acknowledgment; and MFQ, master files query.

20.4.1 MFN/MFK - Master File Notification [WITHDRAWN] (Event M01) (8.4.1)

Withdrawn in version 2.7 and later; refer to master file messages which follow.

20.4.2 MFN/MFK - Master File Notification - General (Event M13) (8.4.2)

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:

Segment Cardinality Must Implement Status
MFN^M13^MFN_M13
MSH 1..1 Yes
SFT  
MFI 1..1 Yes
MFE 1..* Yes

 

We need some ER7 examples...
We need some XML examples...
Segment Cardinality Must Implement Status
MFK^M13^MFK_M01
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  
MFI 1..1 Yes
MFA  

 

We need some ER7 examples...
We need some XML examples...
Note: The MFK message is used for an application acknowledgment in either the original or enhanced acknowledgment modes.

20.4.2.1 MFK use notes (8.4.2.1)

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.

20.4.3 MFN/MFK - Master File Notification - Site Defined (Event M14) (8.4.3)

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:

Segment Cardinality Must Implement Status
MFN^M14^MFN_Znn
MSH 1..1 Yes
SFT  
MFI 1..1 Yes
MF_SITE_DEFINED 1..* Yes
MFE 1..1 Yes
Hxx 1..1 Yes

 

We need some ER7 examples...
We need some XML examples...
Segment Cardinality Must Implement Status
MFK^M14^MFK_M01
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  
MFI 1..1 Yes
MFA  

 

We need some ER7 examples...
We need some XML examples...
Note: The MFK message is used for an application acknowledgment in either the original or enhanced acknowledgment modes.

20.4.3.1 MFN use notes (8.4.3.1)

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.

20.4.3.2 MFK use notes (8.4.3.2)

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.

20.4.4 MFQ/MFR - Master Files Query [WITHDRAWN] (Event M01-M17) (8.4.4)

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.

20.5 GENERIC MASTER FILE EXAMPLES (8.6)

The following are examples of a generic method of updating a standard HL7 table, covering the following two cases:

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.

20.5.1 ZL7 Segment (Proposed Example Only) (8.6.1)

HL7 Attribute Table - ZL7 - (proposed example only)

20.5.1.1 ZL7 Field Definitions (8.6.1.0)

20.5.1.2 ZL7-1 Primary Key Value - ZL7 (CWE) (8.6.1.1)

Definition: This field contains HL7 table values for identifier and text encoded as a CWE data type.

20.5.1.3 ZL7-2 Display-Sort-Key (NM) (8.6.1.2)

Definition: This field is used to specify a non-alphabetic ordering for display or print versions of a standard HL7 table.

20.5.2 MFN Message with Original Acknowledgment Mode (8.6.2)

20.5.2.1 Example message (8.6.2.1)

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|^~\&|HL7REG|UH|HL7LAB|CH|200106290544||MFN^M14^MFN_Z99|MSGID001|P|2.8

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|^~\&|HL7LAB|CH|HL7REG|UH|200106290545||MFK^M14^MFK_M01|MSGID99001|P|2.8

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.

20.5.3 MFN message with enhanced Mode Application-Level Acknowledgment (8.6.3)

20.5.3.1 Example message (8.6.3.1)

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|^~\&|HL7REG|UH|HL7LAB|CH|200106290544||MFN^M13^MFN_M13|MSGID004|P|2.8||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|^~\&|HL7LAB|CH|HL7REG|UH|200106290545||ACK^M13^ACK|MSGID99004|P|2.8

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|^~\&|HL7LAB|CH|HL7REG|UH|200106290550||MFK^M13^MFK_M13|MSGID99501|P|2.8||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|^~\&|HL7REG|UH|HL7LAB|CH|200106290551||ACK^M13^ACK|MSGID445|P|2.8

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.

20.6 STAFF AND PRACTITIONER MASTER FILES (8.7)

20.6.1 MFN/MFK - Staff/Practitioner Master File Message (Event M02) (8.7.1)

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:

Segment Cardinality Must Implement Status
MFN^M02^MFN_M02
MSH 1..1 Yes
SFT  
MFI 1..1 Yes
MF_STAFF 1..* Yes
MFE 1..1 Yes
STF 1..1 Yes
PRA  
ORG  
AFF  
LAN  
EDU  
CER  
NTE  

 

We need some ER7 examples...
We need some XML examples...
Segment Cardinality Must Implement Status
MFK^M02^MFK_M01
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  
MFI 1..1 Yes
MFA  

 

We need some ER7 examples...
We need some XML examples...
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.

20.6.2 Example: Staff and Health Practitioner Master File MFN Message (8.7.2)

MSH|^~\&|HL7REG|UH|HL7LAB|CH|200102280700||MFN^M02^MFN_M02|MSGID002|P|2.8|||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|

20.7 SERVICE/TEST/OBSERVATIONS MASTER FILES (8.8)

20.7.1 General Approach of Service/Test/Observation Master Files (8.8.1)

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:

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.

20.7.2 MFN/MFK - Master File Notification - Test/Observation [WITHDRAWN] (Event M03) (8.8.2)

Withdrawn in version 2.7 and later; refer to master file messages which follow (Events M08, M09, M10, M11 and M12).

20.7.3 MFN/MFK - Master File Notification - Test/Observation (Numeric) (Event M08) (8.8.3)

Segment Cardinality Must Implement Status
MFN^M08^MFN_M08
MSH 1..1 Yes
SFT  
MFI 1..1 Yes
MF_TEST_NUMERIC 1..* Yes
MFE 1..1 Yes
OM1 1..1 Yes
OMC  
PRT  
OM2 0..1  
OM3 0..1  
OM4  

 

We need some ER7 examples...
We need some XML examples...
Segment Cardinality Must Implement Status
MFK^M08^MFK_M01
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  
MFI 1..1 Yes
MFA  

 

We need some ER7 examples...
We need some XML examples...
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.

20.7.4 MFN/MFK - Master File Notification - Test/Observation (Categorical) (Event M09) (8.8.4)

Segment Cardinality Must Implement Status
MFN^M09^MFN_M09
MSH 1..1 Yes
SFT  
MFI 1..1 Yes
MF_TEST_CATEGORICAL 1..* Yes
MFE 1..1 Yes
OM1 1..1 Yes
OMC  
PRT  
MF_TEST_CAT_DETAIL 0..1  
OM3 1..1 Yes
OM4  

 

We need some ER7 examples...
We need some XML examples...
Segment Cardinality Must Implement Status
MFK^M09^MFK_M01
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  
MFI 1..1 Yes
MFA  

 

We need some ER7 examples...
We need some XML examples...
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.

20.7.5 MFN/MFK - Master File Notification - Test/Observation Batteries (Event M10) (8.8.5)

MFN^M10^MFN_M10: Master File Notification - Test/Observation Batteries

Segment Cardinality Must Implement Status
MFK^M10^MFK_M01
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  
MFI 1..1 Yes
MFA  

 

We need some ER7 examples...
We need some XML examples...
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.

20.7.6 MFN/MFK - Master File Notification - Test/Calculated Observations (Event M11) (8.8.6)

Segment Cardinality Must Implement Status
MFN^M11^MFN_M11
MSH 1..1 Yes
SFT  
MFI 1..1 Yes
MF_TEST_CALCULATED 1..* Yes
MFE 1..1 Yes
OM1 1..1 Yes
OMC  
PRT  
MF_TEST_CALC_DETAIL 0..1  
OM6 1..1 Yes
OM2 1..1 Yes

 

We need some ER7 examples...
We need some XML examples...
Segment Cardinality Must Implement Status
MFK^M11^MFK_M01
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  
MFI 1..1 Yes
MFA  

 

We need some ER7 examples...
We need some XML examples...
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.

20.7.7 MFN/MFK - Master File Notification - Additional Basic Observation/Service Attributes (Event M12) (8.8.7)

Segment Cardinality Must Implement Status
MFN^M12^MFN_M12
MSH 1..1 Yes
SFT  
MFI 1..1 Yes
MF_OBS_ATTRIBUTES 1..* Yes
MFE 1..1 Yes
OM1 1..1 Yes
PRT  
MF_OBS_OTHER_ATTRIBUTES 0..1  
OM7 1..1 Yes
PRT  

 

We need some ER7 examples...
We need some XML examples...
Segment Cardinality Must Implement Status
MFK^M12^MFK_M01
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  
MFI 1..1 Yes
MFA  

 

We need some ER7 examples...
We need some XML examples...
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.

20.7.8 MFN/MFK - Master File Notification - Test/Observation (Payer) (Event M18) (8.8.8)

MFN^M18^MFN_M18: Master File Notification - Test/Observation (Payer)

Segment Cardinality Must Implement Status
MFK^M18^MFK_M01
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  
MFI 1..1 Yes
MFA  

 

We need some ER7 examples...
We need some XML examples...

20.8 LOCATION MASTER FILES (8.9)

20.8.1 MFN/MFK - Patient Location Master File Message (event M05) (8.9.1)

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"

Segment Cardinality Must Implement Status
MFN^M05^MFN_M05
MSH 1..1 Yes
SFT  
MFI 1..1 Yes
MF_LOCATION 1..* Yes
MFE 1..1 Yes
LOC 1..1 Yes
LCH  
LRL  
MF_LOC_DEPT 1..* Yes
LDP 1..1 Yes
LCH  
LCC  

 

We need some ER7 examples...
We need some XML examples...

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.

Segment Cardinality Must Implement Status
MFK^M05^MFK_M01
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  
MFI 1..1 Yes
MFA  

 

We need some ER7 examples...
We need some XML examples...

20.8.2 Example: MFN Location Master File Message (8.9.7)

MSH|^~\&|HL7REG|UH|HL7LAB|CH|19910918060544||MFN^M05^MFN_M05|MSGID002|P|2.8||AL|NE

MFI|LOC||UPD|||AL

MFE|MAD|PMF98123789182|199110011230|3A^RM17^17-2^FAC1|PL

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

LCH|3A^RM17^17-2^FAC1|||IMP|Y

LRL|3A^RM17^17-2^FAC1|||LAB|3WEST PATH LAB

LDP|3A^RM17^17-2^FAC1|PED|MED|PIN|I|A|19941004||||(206)689-1363

LCC|3A^RM17^17-2^FAC1|PED|PIC|R38746

20.9 CHARGE DESCRIPTION MASTER FILES (8.10)

20.9.1 MFN/MFK - Charge Description Master File Message (Event M04) (8.10.1)

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:

Segment Cardinality Must Implement Status
MFN^M04^MFN_M04
MSH 1..1 Yes
SFT  
MFI 1..1 Yes
NTE  
MF_CDM 1..* Yes
MFE 1..1 Yes
NTE  
CDM 1..1 Yes
NTE  
PRC  

 

We need some ER7 examples...
We need some XML examples...
Segment Cardinality Must Implement Status
MFK^M04^MFK_M01
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  
MFI 1..1 Yes
MFA  

 

We need some ER7 examples...
We need some XML examples...

20.9.2 Example: MFN Message Charge Description Master File (8.10.4)

MSH|^~\&|HL7REG|UH|HL7LAB|CH|19910918060544||MFN^M04^MFN_M04|MSGID002|P|2.8||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|

20.10 CLINICAL TRIALS MASTER FILES (8.11)

20.10.1 MFN/MFK - Clinical Trials Master File Message (Event M06-M07) (8.11.1)

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

Segment Cardinality Must Implement Status
MFN^M06^MFN_M06
MSH 1..1 Yes
SFT  
MFI 1..1 Yes
MF_CLIN_STUDY 1..* Yes
MFE 1..1 Yes
CM0 1..1 Yes
MF_PHASE_SCHED_DETAIL  
CM1 1..1 Yes
CM2  

 

We need some ER7 examples...
We need some XML examples...
Segment Cardinality Must Implement Status
MFK^M06^MFK_M01
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  
MFI 1..1 Yes
MFA  

 

We need some ER7 examples...
We need some XML examples...

Case 2: MFN message for Clinical Study without phases but with schedules

MFI-1 - Master File Identifier Code = CMB

Segment Cardinality Must Implement Status
MFN^M07^MFN_M07
MSH 1..1 Yes
SFT  
MFI 1..1 Yes
MF_CLIN_STUDY_SCHED 1..* Yes
MFE 1..1 Yes
CM0 1..1 Yes
CM2  

 

We need some ER7 examples...
We need some XML examples...
Segment Cardinality Must Implement Status
MFK^M07^MFK_M01
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  
MFI 1..1 Yes
MFA  

 

We need some ER7 examples...
We need some XML examples...

20.11 INVENTORY ITEM MASTER FILES (8.12)

20.11.1 MFN/MFK - Inventory Item Master File Message (Event M15) (8.12.1)

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.
Segment Cardinality Must Implement Status
MFN^M15^MFN_M15
MSH 1..1 Yes
SFT  
MFI 1..1 Yes
MF_INV_ITEM 1..* Yes
MFE 1..1 Yes
IIM 1..1 Yes

 

We need some ER7 examples...
We need some XML examples...
Segment Cardinality Must Implement Status
MFK^M15^MFK_M01
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  
MFI 1..1 Yes
MFA  

 

We need some ER7 examples...
We need some XML examples...

Master Files Query Response: See conformance based queries as defined in Chapter 5. Refer to Section Error! Reference source not found., "Error! Reference source not found.," for an example of a master file conformance based query.

20.11.2 MFN/MFK - Inventory Item Master File Message - Enhanced (Event M16) (8.12.2)

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.

Segment Cardinality Must Implement Status
MFN^M16^MFN_M16
MSH 1..1 Yes
SFT  
MFI 1..1 Yes
MATERIAL_ITEM_RECORD 1..* Yes
MFE 1..1 Yes
ITM 1..1 Yes
NTE  
STERILIZATION  
STZ 1..1 Yes
NTE  
PURCHASING_VENDOR  
VND 1..1 Yes
PACKAGING  
PKG 1..1 Yes
PCE  
MATERIAL_LOCATION  
IVT 1..1 Yes
ILT  
NTE  

 

We need some ER7 examples...
We need some XML examples...
Segment Cardinality Must Implement Status
MFK^M16^MFK_M01
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  
MFI 1..1 Yes
MFA  

 

We need some ER7 examples...
We need some XML examples...

Master Files Query Response: See conformance based queries as defined in Chapter 5. Refer to Section Error! Reference source not found., "Error! Reference source not found.," for an example of a master file conformance based query.

20.12 DRG MASTER FILES (8.13)

20.12.1 MFN/MFK - DRG Master File Message (Event M17) (8.13.1)

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".

Segment Cardinality Must Implement Status
MFN^M17^MFN_M17
MSH 1..1 Yes
SFT  
MFI 1..1 Yes
MF_DRG 1..* Yes
MFE 1..1 Yes
DMI 1..1 Yes

 

We need some ER7 examples...
We need some XML examples...
Segment Cardinality Must Implement Status
MFK^M17^MFK_M01
MSH 1..1 Yes
SFT  
MSA 1..1 Yes
ERR  
MFI 1..1 Yes
MFA  

 

We need some ER7 examples...
We need some XML examples...

Master Files Query Response: See conformance based queries as defined in Chapter 5. Refer to Section Error! Reference source not found., "Error! Reference source not found.," for an example of a master file conformance based query.