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

Draft Website - For Review Purposes Only

MFE - Master File Entry Segment

The Technical Steward for the MFE segment is Infrastructure and Messaging.

HL7 Attribute Table - MFE - Master File Entry Segment
Seq# DataElement Description Must Implement Flags Cardinality Length C.LEN Vocabulary DataType
MFE
1 00664 Record-Level Event Code SHALL [1..1] [3..3]
0180 Masterfile Action Code
ID
2

00665 MFN Control ID MAY
True:
False: 		C=
[1..1]
[0..1] 		20
ST
3 00662 Effective Date/Time [0..1]
DTM
4 00667 Primary Key Value - MFE SHALL [1..*]
0608
Varies
5 01319 Primary Key Value Type SHALL [1..*] [2..3]
0355 Primary Key Value Type
ID
6 00661 Entered Date/Time [0..1]
DTM
7 00224 Entered By [0..1]
XCN

MFE-1: Record-Level Event Code (ID) 00664

(Definition from MFE.1 in Ch. 8)

Definition: This field defines the record-level event for the master file record identified by the MFI segment and the primary key field in this segment. Refer to HL7 Table 0180 - Record Level Event Code in Chapter 2C, Code Tables, for valid values.

Note: If the MFI-3 - File-level event code is "REP" (replace file), then each MFE segment must have an MFE-1 - Record-level event code of "MAD" (add record to master file).


(Definition from MFA.1 in Ch. 8)

Definition: This field defines record-level event for the master file record identified by the MFI segment and the primary key in this segment. Refer to HL7 Table 0180 - Record-level Event Code in Chapter 2C, Code Tables, for valid values.

Note: If the MFI-3 - File-level event code is "REP" (replace file), then each MFA segment must have an MFA-1 - Record-level event code of "MAD" (add record to master file).


MFE-2: MFN Control ID (ST) 00665

(Definition from MFE.2 in Ch. 8)

Definition: A number or other identifier that uniquely identifies this change to this record from the point of view of the originating system. When returned to the originating system via the MFA segment, this field allows the target system to precisely identify which change to this record is being acknowledged. It is only required if the MFI response level code requires responses at the record level (any value other than NE).

Note: Note that this segment does not contain a Set ID field. The MFE-2 - MFN Control ID implements a more general concept than the Set ID. It takes the place of the SET ID in the MFE segment.


(Definition from MFA.2 in Ch. 8)

Definition: This field contains a number or other identifier that uniquely identifies this change to this record from the point of view of the originating system. This field uniquely identifies the particular record (identified by the MFE segment) being acknowledged by this MFA segment. When returned to the originating system via the MFA segment, this field allows the target system to precisely identify which change to this record is being acknowledged. It is only required if MFI-6 - Response Level Code requires responses at the record level (any value other than NE).

MFE-3: Effective Date/Time (DTM) 00662

(Definition from MFI.5 in Ch. 8)

Definition: This optional field contains the effective date/time, which can be included for file-level action specified. It is the date/time the originating system expects that the event is to have been completed on the receiving system. If this field is not present, the action date/time should default to the current date/time (when the message is received).

(Definition from MFE.3 in Ch. 8)

Definition: An optional effective date/time can be included for the record-level action specified. It is the date/time the originating system expects that the event is to have been completed on the receiving system. If this field is not present, the effective date/time should default to the current date/time (when the message is received).

(Definition from DPS.3 in Ch. 8)

Definition: An optional effective date/time can be included for the record-level action specified. It is the date/time the originating system expects that the event is to have been completed on the receiving system. If this field is not present, the effective date/time should default to the current date/time (when the message is received).

MFE-4: Primary Key Value - MFE (Varies) 00667

Definition: This field uniquely identifies the record of the master file (identified in the MFI segment) to be changed (as defined by the record-level event code). The data type of field is defined by the value of MFE-5 - Value Type, and may take on the format of any of the HL7 data types defined in HL7 Table 0355 - Primary Key Value Type in Chapter 2C, Code Tables. The PL data type is used only on Location master transactions. Refer to Table 0608 - Primary Key Value - MFE in Chapter 2C for valid values.

The repetition of the primary key permits the identification of an individual component of a complex record as the object of the record-level event code. This feature allows the Master Files protocol to be used for modifications of single components of complex records. If this field repeats, the field MFE-5 - Value Type must also repeat (with the same number of repetitions), and the data type of each repetition of MFE-4 - Primary Key Value - MFE is specified by the corresponding repetition of MFE-5 - Value Type.

MFE-5: Primary Key Value Type (ID) 01319

Definition: This field contains the HL7 data type of MFE-4 - Primary Key Value - MFE. The valid values for the data type of a primary key are listed in HL7 Table 0355 - Primary Key Value Type in Chapter 2C, Code Tables.

MFE-6: Entered Date/Time (DTM) 00661

(Definition from NTE.6 in Ch. 2)

Definition: This field contains the actual date the comment was keyed into the application.

(Definition from MFI.4 in Ch. 8)

Definition: This field contains the date/time for the file-level event on originating system.

(Definition from MFE.6 in Ch. 8)

Definition: This field contains the date and time of the last change of the record.

MFE-7: Entered By (XCN) 00224

(Definition from NTE.5 in Ch. 2)

Definition: This field contains the identity of the person who actually keyed the comment into the application. It provides an audit trail in case the comment is entered incorrectly and the ancillary department needs to clarify the comment. By local agreement, either the ID number or name component MAY be omitted.

(Definition from ORC.10 in Ch. 4)

Definition: This field was retained for backward compatibility only as of v 2.7 and the detail was withdrawn and removed from the standard as of v 2.9. The reader is referred to the PRT segment described in Chapter 7.

(Definition from ACC.7 in Ch. 6)

Definition: This field identifies the person entering the accident information.

(Definition from MFE.7 in Ch. 8)

Definition: This field contains the identity of the person who actually keyed the master file entry into the application. It provides an audit trail in case the request is entered incorrectly and the ancillary department needs to clarify the request.

(Definition from OM7.20 in Ch. 8)

Note: This field is deprecated and retained for backward compatibility as of v 2.8.

Definition: This field contains the identity of the person who actually keyed the service item into the application. It provides an audit trail in case the request is entered incorrectly and the ancillary department needs to clarify the request.