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

The fields in the MFI segment are defined in HL7 Attribute Table - MFI.

HL7 Attribute Table - MFI - Master File Identification Segment

Seq#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
MFI
1	00658	Master File Identifier	SHALL		[1..1]			0175 Master File Identifier Code	CWE
2	00659	Master File Application Identifier			[0..*]			0361	HD
3	00660	File-Level Event Code	SHALL		[1..1]	[3..3]		0178 File Level Event Code	ID
4	00661	Entered Date/Time			[0..1]				DTM
5	00662	Effective Date/Time			[0..1]				DTM
6	00663	Response Level Code	SHALL		[1..1]	[2..2]		0179 Response Level	ID

Definition: This field is a CWE data type that identifies a standard HL7 master file. This table may be extended by local agreement during implementation to cover site-specific master files (z-master files). HL7 recommends use of the HL7 assigned table number as the master file identifier code if one is not specified in Table 0175. For example, a master file of Marital Status codes would be identified by HL70002 as the MFI-1 - Master file identifier. Refer to HL7 Table 0175 – Master File Identifier Code in Chapter 2C, Code Tables, for valid values.

Definition: This field contains an optional code of up to 180 characters which (if applicable) uniquely identifies the application responsible for maintaining this file at a particular site. A group of intercommunicating applications may use more than a single instance of a master file of certain type (e.g., charge master or physician master). The particular instance of the file is identified by this field. Refer to User-defined table 0361 - Applications.

Definition: This field defines the file-level event code. Refer to HL7 Table 0178 – File Level Event Code in Chapter 2C, Code Tables, for valid values.

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

(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).

Definition: These codes specify the application response level defined for a given Master File Message at the MFE segment level as defined in HL7 Table 0179 – Response Level in Chapter 2C, Code Tables. Required for MFN-Master File Notification message. Specifies additional detail (beyond MSH-15 - Accept Acknowledgment Type and MSH-16 - Application Acknowledgment Type) for application-level acknowledgment paradigms for Master Files transactions. MSH-15 - Accept Acknowledgment Type and MSH-16 - Application Acknowledgment Type operate as defined in Chapter 2.

The Technical Steward for the MFE segment is 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

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

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

(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).

(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).

(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).

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.

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.

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

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

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

HL7 Attribute Table - MFA - Master File Acknowledgment Segment

Seq#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
MFA
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	00668	Event Completion Date/Time			[0..1]				DTM
4	00669	MFN Record Level Error Return	SHALL		[1..1]			0181 MFN Record-level Error Return	CWE
5	01308	Primary Key Value - MFA	SHALL		[1..*]			0607	Varies
6	01320	Primary Key Value Type - MFA	SHALL		[1..*]	[2..3]		0355 Primary Key Value Type	ID

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

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

(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).

(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).

Definition: This field may be required or optional depending on the site specifications for the given master file, master file event, and receiving facility.

Definition: This field contains the status of the requested update. Site-defined table, specific to each master file being updated via this transaction.

Refer to User-defined Table 0181 - MFN Record-level Error Return in Chapter 2C, Code Tables, for suggested values. All such tables will have at least the following two return code values: "S" for successful and "U" for unsuccessful.

Definition: This field uniquely identifies the record of the master file (identified in the MFI segment) for which the update status is being acknowledged (as defined by the field MFN-4 - Record Level Error Return). The data type of this field is defined by the value of MFA-6 - Value Type - MFA, and may take on the format of any of the HL7 data types defined in HL7 Table 0355 - Primary Key Value Type in Chapter 2C, Code Tables. The PL data type is used only on location master transactions. Refer to Table 0607 - Primary Key Value - MFA 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 MFA-6 - Primary Key Value Type - MFA must also repeat (with the same number of repetitions), and the data type of each repetition of MFA-5 - Primary Key Value - MFA is specified by the corresponding repetition of MFA-6 - Value Type - MFA.

Definition: This field contains the HL7 data type of MFA-5 - Primary Key Value - MFA. The valid HL7 data types are listed in HL7 Table 0355 - Primary Key Value Type in Chapter 2C, Code Tables.

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.

HL7 Attribute Table - OM1 - General Segment (Fields That Apply to Most Observations)

Seq#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
OM1
1	00586	Sequence Number - Test/Observation Master File	SHALL	=	[1..1]		4		NM
2	00587	Producer's Service/Test/Observation ID	SHALL		[1..1]			0630	CWE
3	00588	Permitted Data Types			[0..*]	[2..3]		0125 Value Type	ID
4	00589	Specimen Required	SHALL		[1..1]	[1..1]		0136 Yes/no Indicator	ID
5	00590	Producer ID	SHALL		[1..1]			0631	CWE
6	00591	Observation Description		#	[0..1]		200		TX
7	00592	Other Service/Test/Observation IDs for the Observation			[0..*]			0632	CWE
8	00593	Other Names		B#	[0..*]		200		ST
9	00594	Preferred Report Name for the Observation		#	[0..1]		30		ST
10	00595	Preferred Short Name or Mnemonic for the Observation			[0..1]	[1..8]			ST
11	00596	Preferred Long Name for the Observation		=	[0..1]		200		ST
12	00597	Orderability			[0..1]	[1..1]		0136 Yes/no Indicator	ID
13	00598	Identity of Instrument Used to Perform this Study			[0..*]			0633	CWE
14	00599	Coded Representation of Method			[0..*]			0635	CWE
15	00600	Portable Device Indicator			[0..1]	[1..1]		0136 Yes/no Indicator	ID
16	00601	Observation Producing Department/Section		B	[0..*]			0636	CWE
17	00602	Telephone Number of Section		B	[0..1]				XTN
18	00603	Nature of Service/Test/Observation	SHALL		[1..1]	[1..1]		0174 Nature of Service/Test/Observation	CWE
19	00604	Report Subheader			[0..1]			0637	CWE
20	00605	Report Display Order		=	[0..1]		20		ST
21	00606	Date/Time Stamp for Any Change in Definition for the Observation			[0..1]				DTM
22	00607	Effective Date/Time of Change			[0..1]				DTM
23	00608	Typical Turn-Around Time		B	[0..1]				NM
24	00609	Processing Time			[0..1]				NM
25	00610	Processing Priority			[0..*]	[1..1]		0168 Processing Priority	ID
26	00611	Reporting Priority			[0..1]	[1..1]		0169 Reporting Priority	ID
27	00612	Outside Site(s) Where Observation May Be Performed		B	[0..*]			0638	CWE
28	00613	Address of Outside Site(s)		B	[0..*]				XAD
29	00614	Phone Number of Outside Site		B	[0..1]				XTN
30	00615	Confidentiality Code			[0..1]			0177 Confidentiality Code	CWE
31	00616	Observations Required to Interpret this Observation		B	[0..*]			0639	CWE
32	00617	Interpretation of Observations			[0..1]				TX
33	00618	Contraindications to Observations			[0..*]			0640	CWE
34	00619	Reflex Tests/Observations			[0..*]			0641	CWE
35	00620	Rules that Trigger Reflex Testing			[0..*]				TX
36	00621	Fixed Canned Message			[0..*]			0643	CWE
37	00622	Patient Preparation		=	[0..*]		200		TX
38	00623	Procedure Medication			[0..1]			0644	CWE
39	00624	Factors that may Affect the Observation		=	[0..1]		200		TX
40	00625	Service/Test/Observation Performance Schedule		=	[0..*]		60		ST
41	00626	Description of Test Methods			[0..1]				TX
42	00937	Kind of Quantity Observed			[0..1]			0254 Kind of Quantity	CWE
43	00938	Point Versus Interval			[0..1]			0255 Duration Categories	CWE
44	00939	Challenge Information		=	[0..1]		200	0256 Time Delay Post Challenge	TX
45	00940	Relationship Modifier			[0..1]			0258 Relationship Modifier	CWE
46	00941	Target Anatomic Site Of Test			[0..1]			0645	CWE
47	00942	Modality of Imaging Measurement			[0..1]			0910	CWE
48	03310	Exclusive Test			[0..1]	[1..1]		0919 Exclusive Test	ID
49	00257	Diagnostic Serv Sect ID			[0..1]	[2..3]		0074 Diagnostic Service Section ID	ID
50	01539	Taxonomic Classification Code			[0..1]			0446	CWE
51	03399	Other Names			[0..*]	[200..*]			ST
52	03433	Replacement Producer's Service/Test/Observation ID			[0..*]				CWE
53	03434	Prior Resuts Instructions			[0..*]				TX
54	03435	Special Instructions			[0..1]				TX
55	03436	Test Category			[0..*]				CWE
56	03437	Observation/Identifier associated with Producer’s Service/Test/Observation ID			[0..1]			0647	CWE
57	03438	Typical Turn-Around Time			[0..1]				CQ
58	03439	Gender Restriction			[0..*]			0001 Administrative Sex	CWE
59	03440	Age Restriction			[0..*]				NR

(Definition from OM1.1 in Ch. 8)

Definition: This field contains the first OM1 segment in a message and is described as 1, the second as 2, and so on.

(Definition from OM2.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment. Refer to Table 0648 - Units of Measure in Chapter 2C for valid values.

(Definition from OM3.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM4.1 in Ch. 8)

Definition: The OM4-1 contains a numeric value that indicates a unique set of OM1, OM2, OM3, and OM4 components; each OMn-1 in a set will have the same value as illustrated in the example below. Because the OM4 segment can repeat, but needs to have a unique number for use with OM4-17, the sequence number must be appended with a sequence number as shown in the second example below.

OM4-1 Sequence Number – Test/Observation Master File Example:

MSH|...<cr>

// start MFE Test Begin group

MFE|A|...<cr>

OM1|1|...<cr>

OM2|1|...<cr>

OM3|1|...<cr>

OM4|1|...<cr>

// end MFE Test Begin group

// start MFE_Test_Begin group

MFE|A|...<cr>

OM1|2|...<cr>

OM2|2|...<cr>

OM3|2|...<cr>

OM4|2.1|...<cr>

OM4|2.2|...<cr>

//end MFE_Test_Begin group

(Definition from OM5.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM6.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM7.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OMC.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM1.2 in Ch. 8)

Definition: This field contains the producer's usual or preferred identification of the test or observation. Only three components should be included: <ID code>^<service text name/description>^<source list of code>. All components should be non-null. Refer to Table 0630 - Producer's Service/Test/Observation ID in Chapter 2C for valid values.

(Definition from MCP.2 in Ch. 8)

Definition: This field contains the producer's usual or preferred identification of the test or observation. Only three components should be included: <ID code>^<service text name/description>^<source list of code>. All components should be non-null.

Definition: This field contains the allowed data type(s) for this observation. The codes are the same as those listed for OBX (a given observation may, under different circumstances, take on different data types). Indeed, under limited circumstances, an observation can consist of one or more fragments of different data types. When an observation may have more than one data type, e.g., coded (CWE) and numeric (NM) the allowable data types should be separated by repeat delimiters. Refer to HL7 Table 0125 – Value Type in Chapter 2C, Code Tables, for valid values.

Definition: This field contains a flag indicating whether or not at least one specimen is required for the service/test/observation. Refer to HL7 Table 0136 - Yes/no Indicator as defined in Chapter 2C, Code Tables.

• Y     one or more specimens are required to obtain this observation

• N     a specimen is not required

When a specimen is required, segment OM4 will usually be included (one per specimen is required).

Definition: This field uniquely identifies the service producing the observation described in this segment. Three components should be included: an identifying code, the name of the producer, and the identity of the coding system (e.g., 323-5678^Acme Special Lab^MC). The identity of the coding system will usually be MC (Medicare provider number or HIBCC site codes) in the United States. Each country may want to specify its preferred coding system and define a coding system ID to identify it. Refer to Table 0631 - Producer ID in Chapter 2C for valid values.

Remember that the magnitude of a treatment or the setting on a machine, such as a ventilator, can be regarded as an observation. Thus, pharmacy, respiratory care, and nursing may be producers of such observations.

Definition: This field contains a text description of this observation.

Definition: This field contains all alias codes/identifiers for this observation. If more than one alias code needs to be specified, multiple three-component, CWE-format entries (<code 1>^<name 1>^<code system 1>) may be given, separated by repeat delimiters. An observation may have as many names/codes as are applicable (e.g., ICD9, ACR-NEMA, SNOMED, and READ). We encourage the inclusion of as many different codes as may apply to assist cross-system mapping of terminology. All components of each triplet should be non-null (that is, names and coding system IDs within the CWE data type are required in addition to codes). Refer to Table 0632 - Other Service/Test/Observation IDs for the Observation in Chapter 2C for valid values.

Because the size (dose) of a treatment can also be an observation, codes that identify treatments (e.g., NDC, ICCS) may also be included in this field.

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

Definition: This field contains any test aliases or synonyms for the name in the context of the ordering service. These are alternative names, not associated with a particular coding system, by which the battery, test, or observation (e.g., measurement, test, diagnostic study, treatment, etc.) is known to users of the system. Multiple names in this list are separated by repeat delimiters.

Definition: This field contains the preferred name for reporting the observation or battery. The name can contain up to 30 characters (including blanks). It is the preferred name for columnar reports that require a maximum name size.

Definition: This field contains the name that can be used in space-limited reports (e.g., specimen labels) to identify the observation for the convenience of human readers. The name can contain up to eight characters.

Definition: This field contains the fully-specified name for the observation or battery. It may include the full (unabbreviated) multiple-word names and contain up to 200 characters. It should be as scientifically precise as possible.

Definition: This field indicates whether or not a service/test/observation is an orderable code. Refer to HL7 Table 0136 - Yes/no Indicator in Chapter 2C, Code Tables, for valid values.

• Y     the service/test/observation is an orderable code

• N     the service/test/observation is not orderable

For example, blood differential count is usually an orderable "test," MCV, contained within the differential count, is usually not independently orderable.

Definition: When applicable, this field identifies the instrument or device that is used to generate this observation or battery. Examples are the automated instrument in the laboratory, the imaging device and model number in radiology, and the automatic blood pressure machine on the ward. The instrument is specified as a coded entry in anticipation that these identifiers could be specified as codes. Initially, we expect that most of the information about devices will be transmitted as text in the second component of the CWE identifier. If more than one kind of instrument is used, all of them can be listed, separated by repeat delimiters. Refer to Table 0633 - Identity of Instrument Used to Perform this Study in Chapter 2C for valid values.

Definition: This field contains the method(s) used to produce the observation and should be recorded in a computer-understandable (coded) form here. This field should report the same method(s) reported in narrative in the following field. More than one method may be listed, but only if they produce results that are clinically indistinguishable. Multiple methods must be separated by repeat delimiters. Refer to Table 0635 - Coded Representation of Method in Chapter 2C for valid values.

Definition: This field indicates whether or not a portable device may be used for the service/test/observation. Refer to HL7 Table 0136 - Yes/no Indicator in Chapter 2C, Code Tables, for valid values.

• Y     the observation can be obtained with a portable device brought to the patient

• N     the patient or specimen must be transported to the device

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

Definition: This field permits the sorting of observation orders and values by the providing service's department/section. It provides "source oriented" reporting when required. Free text may be used instead of these codes, but in that case, they should be recorded as the second "component" of the field to distinguish them from the standard codes. Multiple codes in this field are separated by repeat delimiters. Refer to Table 0636 - Observation Producing Department/Section in Chapter 2C for valid values.

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

Definition: This field contains the telephone number for calling responsible parties in this section to ask results or advice about the use of this test.

Definition: This field indicates whether the definition entry identifies a test battery, an entire functional procedure or study, a single test value (observation), multiple test batteries or functional procedures as an orderable unit (profile), or a single test value (observation) calculated from other independent observations. Refer to User-defined Table 0174 - Nature of Service/Test/Observation in Chapter 2C, Code Tables, for suggested values.

Definition: This field contains an optional string that defines the preferred header under which this observation should be listed on a standard display. For example, if the test is hemoglobin, this string might be "Complete blood count." It is represented as a coded data type so that a battery can be a header. Only the description part of the string may be included in case the subheader does not have an associated code. When a series of observations is displayed according to the sort order given below, the subheader that groups those observations is presented whenever the subheader changes. Refer to Table 0637 - Report Subheader in Chapter 2C for valid values.

Definition: This field contains an optional string that defines the sort order in which this observation is presented in a standard report or display that contains the many observations.

Definition: This field contains the date and time that the last of any field change was made and in the host's record corresponding to the OM1 segment.

(Definition from OM1.22 in Ch. 8)

Definition: This field contains the date and time of the last change in the test procedure that would make previous results incompatible with new results, e.g., the last time that normal reference range or units changed for a numeric test/observation.

We strongly suggest that observation producers never use the same observation ID when the measurement procedures change in such a way that results produced under the new procedure are clinically different from those produced with the old procedure. Rather, the producer should try to adjust the new procedure so that its values are clinically indistinguishable from the old. Failing that, one should create a new observation ID for the observation produced under the new procedure.

In the rare circumstances when a procedure change occurs and neither of the above two options is viable, this field shall be used to transmit the effective date/time of the new procedure. The receiving system shall assume that any values that come across under this observation ID are under the new procedure after this date and take appropriate steps to distinguish the old from the new observations.

This number is included to provide a means of communicating with the observation producing service when they have questions about particular observations or results.

(Definition from OM7.19 in Ch. 8)

Definition: This field contains the date and time of the last change in the test procedure that would make previous results incompatible with new results.

Note: This field is deprecated and retained for backward compatibility as of v 2.8.2. See OM1-57.

Definition: This field contains the typical processing time for single test/observation. This field indicates the time from the delivery of a specimen or transport of a patient to a diagnostic service and the completion of the study. It includes the usual waiting time. The units are measured in minutes.

Definition: This field contains the usual length of time (in minutes) between the start of a test process and its completion.

Definition: This field contains one or more available priorities for performing the observation or test. This is the priority that can be placed in TQ1-9 - Priority. Multiple priorities may be given, separated by repeat delimiters. For example, S~A~R~P~T indicates that the test may be ordered using codes S, A, R, P, or T. Refer to HL7 Table 0168 - Processing Priority in Chapter 2C, Code Tables, for valid values.

For tests requiring a specimen, the priority for obtaining the specimen is included in OM4-13 - Specimen Priorities.

Definition: This field contains the available priorities reporting the test results when the user is asked to specify the reporting priority independent of the processing priority. Refer to HL7 Table 0169 - Reporting Priority in Chapter 2C, Code Tables, for valid values.

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

Definition: This field contains the identification(s) of the outside service(s) that produce(s) the observation. The format of this CWE field uses the producer ID (as defined in OM1-5 - Producer ID) and the name of the service separated by component delimiters. An example is ...|39221^ACME lab^MC|... If multiple services are used, they should be separated by repeat delimiter(s). Refer to Table 0638 - Outside Site(s) Where Observation May Be Performed in Chapter 2C for valid values.

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

Definition: This field contains the address of the outside services listed in OM1-28 - Address of Outside Site(s) where observation may be performed. If multiple services are recorded in that field, their addresses should be separated by repeat delimiters, and the addresses should appear in the same order in which the services appear in the preceding field.

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

Definition: This field contains the telephone number of the outside site.

(Definition from ORC.28 in Ch. 4)

Definition: This field contains information about the level of security and/or sensitivity surrounding the order (e.g., highly sensitive, not sensitive, sensitive, etc.). Refer to HL7 Table 0177 – Confidentiality Code in Chapter 2C, Code Tables, for allowed values. The specific treatment of data with a particular confidentiality level is subject to site-specific negotiation.

(Definition from OM1.30 in Ch. 8)

Definition: This field contains the degree to which special confidentiality protection should be applied to the observation. For example, a tighter control may be applied to an HIV test than to a CBC. Refer to User-defined Table 0177 - Confidentiality Code in Chapter 2C, Code Tables, for suggested values.

Note: This field is deprecated and retained for backward compatibility as of v 2.8.2. See OMC Segment.

Definition: This field contains the list of variables that the diagnostic service needs to interpret the results of an ordered study. The observations specified here should be sent to the diagnostic service as OBX segments along with the order (OBR) segment. Separate multiple items by repeat delimiters. Refer to Table 0639 - Observations Required to Interpret this Observation in Chapter 2C for valid values.

Definition: This field contains the clinical information about interpreting test results. Examples are the conditions (drugs) that may cause false abnormals, and the information about the sensitivity and specificity of the test for diagnoses.

Definition: This field contains the diagnosis or problem for which the test is a contraindication or of possible danger (e.g., pacemaker, pregnancy, diabetes). For example, if the test identified in OM1 was an intravenous pyelogram, this field would include warnings about the use of contrast media in diabetes. The contraindication diagnoses should be separated by repeat delimiters. Refer to Table 0640 - Contraindications to Observations in Chapter 2C for valid values.

Most contraindication rules will be transmitted as free text. In such cases, the contents serve only as information for human reading. However, an alternative for machine readable contraindication rules also exists. The rule may be defined formally in the Arden Syntax (ASTM 1460-1992) which has syntax for defining algebraic and transcendental equations, as well as temporal and logical selection criteria based on patient information stored in the computer record. Reflex rules that are written in Arden Syntax should begin and end with a double semi-colon (;;), the Arden slot delimiter.

Definition: This field contains the test names as type CWE (i.e., <code>^<text name>^<coding system>) that may be ordered automatically by the diagnostic service, depending on the results obtained from the ordered battery. A screening CBC might trigger a reticulocyte count if the Hgb is less than 12. Multiple reflex tests are separated by repeat delimiters. Refer to Table 0641 - Reflex Tests/Observations in Chapter 2C for valid values.

Definition: This field contains the rules that trigger the reflex tests listed above. If multiple reflex tests are listed in OM1-34 - Reflex Text/Observations separated by repeat delimiters, a set of corresponding rules will be included in this section. The first rule will apply to the first test, the second to the second test, and so on.

Most reflex rules will usually be transmitted as free text. In such cases, the contents serve only as information for human reading. However, an alternative for machine readable rules also exists. The rule may be defined formally in the Arden Syntax (ASTM 1460-1992) which has syntax for defining algebraic and transcendental equations, as well as temporal and logical selection criteria based on patient information stored in the computer record. Reflex rules that are written in Arden Syntax should begin and end with a double semi-colon (;;), the Arden slot delimiter.

Definition: This field contains the codes and a fixed text message that is always associated with an abbreviation. The field may include multiple messages separated by repeat delimiters. Refer to Table 0643 - Fixed Canned Message in Chapter 2C for valid values.

Most rules about patient testing will be transmitted as free text. In such cases, the contents serve only as information for human reading. However, an alternative for machine readable rules also exists. The rule may be defined formally in the Arden Syntax (ASTM 1460-1992) which has syntax for defining algebraic and transcendental equations, as well as temporal and logical selection criteria based on patient information stored in the computer record. Rules about patient preparation are written in Arden Syntax should begin and end with a double semi-colon (;;), the Arden slot delimiter.

Definition: This field contains the tests or observations that require special patient preparation, diet, or medications. For GI contrast studies, this field would contain the pretest diet, e.g., low residue for two days, NPO before study, and the preferred purgatives. Each separate med, diet, or preparation should be delimited by a repeat delimiter. Separate each requirement by a repeat delimiter. Example for a sigmoidectomy:

...|clear liquid diet full day before procedure~take 8 oz mag citrate 6pm day before procedure~take 2 ducat tabs (5m) at 4pm day before procedure~NPO past midnight.|...

Definition: This field contains the treatments that may be needed as part of the procedure. Examples are radioactive iodine for a thyroid screen, and methacholine for a methacholine spirometry challenge. This field should be identified as a CWE data type. Refer to Table 0644 - Procedure Medication in Chapter 2C for valid values.

Definition: This field contains the text description of the foods, diagnoses, drugs, or other conditions that may influence the interpretation of the observation. Information about the direction of the effect, and any recommendation about altering the diet, conditions, or drug before initiating the test observation.

Most rules about factors that effect the test interpretation will be transmitted as free text. In such cases, the contents serve only as information for human reading. However, an alternative for machine readable rules also exists. The rule may be defined formally in the Arden Syntax (ASTM 1460-1992) which has syntax for defining algebraic and transcendental equations, as well as temporal and logical selection criteria based on patient information stored in the computer record. Rules about patient preparation are written in Arden Syntax and should begin and end with a double semi-colon (;;), the Arden slot delimiter.

Definition: This field contains the diagnostic studies/tests that are performed only at certain times during the course of a work day or work week. This field indicates the maximum interval between successive test performances (the test may actually be performed more frequently). The format given in Chapter 4, Section 4.3.2.1, "Repeat Pattern," should be used. If necessary, multiple codes may be given, separated by repeat delimiters. The use of multiple codes indicates that the test is performed at multiple concurrent intervals. For example, Q6H indicates that the test is performed at least once every 6 hours around the clock. QJ1 indicates that the test is performed at least every week on Mondays. QAM~QPM indicates that the test is performed at least once every morning and every evening. QJ1~QJ3~QJ5 indicates that the test is performed at least every week on Mondays, Wednesdays, and Fridays. C indicates that the test is performed continuously, 7 days per week.

Definition: This field contains the text description of the methods used to perform the text and generate the observations. Bibliographic citations may be included.

Definitions: This optional attribute describes the underlying kind of property represented by this observation. This attribute distinguishes concentrations from total amounts, molar concentrations from mass concentrations, partial pressures from colors, and so forth. These are discussed more fully in the LOINC Users' Manual.¹ They are derived from the approach described in 1995 edition of the IUPAC Silver Book.² These distinctions are used in IUPAC and LOINC standard codes. Defined categories are listed in HL7 Table 0254 - Kind of Quantity in Chapter 2C, Code Tables.

The distinctions of true quantities in this table are based primarily on dimensional analyses. The table contains a number of "families," those related to simple counts (number, number concentration, etc.), to mass (mass, mass concentration, etc.), to enzyme activity (catalytic content, catalytic concentration, etc.), and molar or equivalents (substance content, substance concentration).

By this classification, a glucose (in the US) would be classed as a mass concentration. A sodium would be classed as a substance concentration. Within the family, a total amount should be described as the unadorned variant; e.g., the property of measure for a patient's weight would be mass, not mass content. Most chemical measures produce concentrations, as exemplified by sodium and glucose. However, a 24-hour urine protein is not a mass concentration, but a mass rate (mass per unit time). The content variants (e.g., mass content, substance content) are used to reflect an amount per mass (usually) of tissue.

This attribute would be valued in a master file only if the service sending the master file classified observations by their principle of measurement.

Definition: This optional attribute allows master files to classify observations as measuring the patient's state at a point in time (e.g., spot urines, random urines, serum potassium), or averaged over an interval of time (e.g., concentration, total amount, or clearance over a 24-hour collection). Interval measures most often apply to urine and stool specimens (e.g., 24-hour urines, 3-day stool fats). They also apply to clinical measurements such as urine outputs, which are reported as shift totals and 24-hour totals, and event counts on physiologic monitors such as the number of PVCs on a 24-hour Holter monitor.

This field would only be valued in a transaction if the service sending this master file message classified its observation by point versus time interval. This field is not used to record the time collection interval for a particular sample. It is used to specify a characteristic of an observation which has a defined normal range and to distinguish observations of the same kind but observed over varying periods of time. A spot urine sodium would have PT stored in this field. A 24-hour urine sodium and a 24-hour Holter monitor would have 24H stored here. This attribute would only be valued if the filling service classified its observations by timing. Refer to User-defined Table 0255 - Duration Categories in Chapter 2C, Code Tables, for suggested values.

Definition: This optional attribute provides information for classifying observations by the challenge component of the test, if a challenge does speciate the observation. For example, distinguishing tests that have a challenge component in database. There co-ascribes the physiologic or drug challenge that is intrinsic to the measurement. To identify, for example, tests that include a glucose challenge.

To construct this text string, use the following template. (Note: This field is not constructed of formally defined components; it is a free text field. Component delimiters are not used and it is not necessary to supply placeholders if some "components" are not used.)

The time delay follows the syntax: n<S|M|H|D|W> where n is a number (possibly a decimal); S denotes seconds; M denotes minutes; H denotes hours; D denotes days; and W denotes weeks. The time delay can be preceded by a 'greater than' (>) sign, e.g. >4H.

HL7 Table 0256 - Time Delay Post Challenge in Chapter 2C, Code Tables, lists possible values for time delay.

Examples:

PRE 100 GM GLUCOSE PO

PRE 100 GM GLUCOSE PO

30M POST 100 GM GLUCOSE PO

2H POST 100 GM GLUCOSE PO

TROUGH

For drug peak and trough measures the nature of the substance challenged is the same as the analyte name, and need not be included.

We denote the route of the challenge via abbreviations for medication routes (see Chapter 4A, section 4A.4.2.1, "Route," which references HL7 Table 0162 - Route of Administration in Chapter 2C, Code Tables). An oral route of administration would be denoted by "PO," an intravenous route by "IV."

Details of the drug dose, time the dose was given, route of administration, etc., would be noted in separate OBX, and would have corresponding master observation definitions stored in the observation master file map to different records stored in the master file segments contained in the drug level message.

The nature of a physiologic (non-drug) challenge may also be specified, using the terms in HL7 Table 0257 - Nature of challenge in Chapter 2C, Code Tables.

Definition: This optional attribute provides a mechanism for classifying observations according to the subject, in relation to the patient whose results might be stored with as "patient" data. It is standard practice, for example, to report values for controls, donors, and blood product units as well as the patient's own values, and store them in the patient's record. (This may not be the best way to model such information, but it is the way it is usually reported.) This should be valued when two values (e.g., one for patient and one for a blood product unit) could otherwise be confused.

The default value is "Patient," and if not specified, this value is assumed. The persons sub-component can refer to HL7 Table 0258 - Relationship Modifier in Chapter 2C, Code Tables, for valid values.

Definition: This optional attribute formally indicates the site of the observation (to make it easy for a system to find all tests related to one anatomic site). It can be used to classify the observation by target site of the examination. For example, "heart" might be recorded as the target of the electrocardiogram, cardiac echo, and thallium exercise test. This attribute would be applicable to most imaging and electro-physiologic examinations. The SNOMED topology axis is an example of a coding system for anatomic sites. User-defined tables may also apply here. Refer to Table 0645 - Target Anatomic Site Of Test in Chapter 2C for valid values.

Definition: This optional attribute describes the modality used to acquire the observation data, e.g., radiograph, ultrasound, CT scan, MR, etc. This attribute is especially important for imaging studies. Refer to External Table 0910 – Acquisition Modality in Chapter 2C, Code Tables, for the defined value set, which may be repalce or extended with local codes. If the DICOM codes are used, the coding system ID is DCM.

Note: The use of User-defined Table 0259 - Modality for this field is deprecated and retained for backward compatibility as of v 2.7.

Definition: This field defines if this test should be a specific event with no other tests to be performed with this test. Refer to HL7 Table 0919 – Exclusive Test in Chapter 2C, Code Tables, for valid values.

If not populated, the default value of "N" is assumed and that this test can be included with any number of other tests.

When D is specified for this field, using field OM1-49 determines how tests must be grouped together. Tests within the same Diagnostic Service Sector may be on the same requisition, and therefore in the same message.

(Definition from OBR.24 in Ch. 4)

Definition: This field is the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here. Refer to HL7 Table 0074 – Diagnostic Service Section ID in Chapter 2C, Code Tables, for valid entries.

(Definition from OBR.24 in Ch. 7)

Definition: This field is the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here. Refer to HL7 Table 0074 – Diagnostic Service Section ID in Chapter 2C, Code Tables, for valid entries.

(Definition from OM1.49 in Ch. 8)

Definition: This field is the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here. Refer to HL7 Table 0074 – Diagnostic Service Section ID in Chapter 2C, Code Tables, for valid entries. Same as OBR-24.

(Definition from PID.35 in Ch. 3)

Definition: A code representing the taxonomic classification (e.g. species and/or breed) of an organism. This may include the common or scientific name in the description component, based on the coding system(s) used. SNOMED-CT is the recommended coding system. If this field is not valued, a human is assumed. If the specificity of the coding system is insufficient to represent the organism to the degree desired, the most detailed coded value available may be used in this field and additional information sent in the text field, PID-37 – Strain.

For example:

...|L-80700^Canine, NOS^SNM3|...

...|L-80100^Bovine^SNM3|...

...|L-80A00^Feline^SNM3|...

(Definition from OM1.50 in Ch. 8)

Definition: The species of living organism. This may include the common or scientific name, based on the coding system(s) used. SNOMED is the recommended coding system. If this field is not valued, a human is assumed. Refer to User-defined Table 0446 - Species Code in Chapter 2C, Code Tables, for suggested values.

For example:

...|L-80700^Canine, NOS^SNM3|...

...|L-80100^Bovine^SNM3|...

...|L-80A00^Feline^SNM3|....

This field is a list of species or other taxonomic classification(s) to which the indicated specimen type may appropriately be applied for the indicated observation or test. If this field is omitted the default meaning is that the test or observation is applicable to humans. In a veterinary context if the test is applicable to any species, an appropriate code such as "Kingdom Animalia (organism)" should be used to avoid confusion with the meaning of human only.

(Definition from OM4.18 in Ch. 8)

Definition: The species of living organism. This may include the common or scientific name, based on the coding system(s) used. SNOMED is the recommended coding system. If this field is not valued, a human is assumed. Refer to User-defined Table 0446 - Species Code for suggested values. Refer to Table 0661 - Taxonomic Classification Code in Chapter 2C for valid values.

For example:

...|L-80700^Canine, NOS^SNM3|...

...|L-80100^Bovine^SNM3|...

...|L-80A00^Feline^SNM3|....

This field is a list of species or other taxonomic classification(s) to which the indicated specimen type may appropriately be applied for the indicated observation or test. If this field is omitted the default meaning is that the test or observation is applicable to humans. In a veterinary context, if the test is applicable to any species, an appropriate code such as "Kingdom Animalia (organism)" should be used to avoid confusion with the meaning of human only.

Definition: This field contains any test aliases or synonyms for the name in the context of the ordering service. These are alternative names, not associated with a particular coding system, by which the battery, test, or observation (e.g., measurement, test, diagnostic study, treatment, etc.) is known to users of the system. Multiple names in this list are separated by repeat delimiters.

Definition: This field is used in conjunction with a MFE-1 Record-Level Event Code 'MDC' defined as: "Deactivate: discontinue using record in master file, but do not delete from database", in conjunction with an OM1 segment providing detail for the deactivate code. When the OM1-2 Producer's Service/Test/Observation ID is being deactivated, use OM1-52 to indicate the producer's replacement test or observation code(s), as it was defined in the OM1-2 Producer's Service/Test/Observation ID when the new/replacement code was added. Refer to Table 0646 - Replacement Producer's Service/Test/Observation ID in Chapter 2C for valid values.

Table below for information in change request proposal process and not intended for inclusion in the base standard:

Definition: This field is used to indicate when the test in OM1-2 Producer's Service/Test/Observation ID is ordered, prior results should accompany the order (OML^O21^OML_O21: Laboratory Order Message). For example, when ordering a Thyroid FNA (Fine Needle Aspiration) Evaluation, send the prior results of Ultrasound Findings. The instructions may also indicate a timeframe; for example, send the prior results of CBC in past 60 days.

Definition: This field is used to convey special instructions for the test, for example: "Chain-of-custody documentation is required for samples submitted for pre-employment, random employee testing, and forensic purposes. For other applications, use the standard request form." (Note: this is for toxicology testing); "If reflex test is performed, additional charges/CPT code(s) may apply."; "Please direct any questions regarding this test to Oncology Customer Service"; "Please include tentative diagnosis/treatment on the request form. This is necessary for proper culturing and result interpretation." (Note: this is for chromosome analysis.)

Definition: This field may be used to organize tests for display or other user defined purpose. For example, tests might be categorized by disease state, such as molecular tests for solid tumors; example categories are: breast, colorectal, lung, and melanoma.

Definition: This field contains the code for resulted tests, which are associated with the Producer’s Service/Test/Observation ID code in OM1-2 and will appear in OBX-3 Observation Identifier in a result message. Refer to Table 0647 - Observation/Identifier associated with Producer’s Service/Test/Observation ID in Chapter 2C for valid values.

Definition: This field contains the typical processing time for single test/observation. This field indicates the time from delivery of a specimen or transport of a patient to a diagnostic service and the completion of the study. It includes the usual waiting time.

Definition: This field is used to convey gender restrictions for ordering the test specified in OM1-2 Producer's Service/Test/Observation ID. If there are no restrictions the field is left empty. If the test is restricted to order for certain gender(s), the restricted genders are listed. For example, a Prostate Specific AG (PSA) test is typically ordered only for male patients, thus for PSA the field would be valued 'M' for Male. Refer to User-defined Table 0001 – Administrative Sex in Chapter 2C, Code Tables, for suggested values.

Definition: This field is used to convey age restrictions for ordering the test specified in OM1-2 Producer's Service/Test/Observation ID. If there are no restrictions the field is left empty. If the test is restricted to order for certain age(s), the age range restriction(s) are listed in years. For example, newborn tests are typically restricted to age 1 year or below, thus for newborn tests the field would be valued 0^1.

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

HL7 Attribute Table - OM2 - Numeric Observation Segment

Seq#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
OM2
1	00586	Sequence Number - Test/Observation Master File		=	[0..1]		4		NM
2	00627	Units of Measure			[0..1]			0648	CWE
3	00628	Range of Decimal Precision		=	[0..*]		10		NM
4	00629	Corresponding SI Units of Measure			[0..1]			0649	CWE
5	00630	SI Conversion Factor		=	[0..1]		60		TX
6	00631	Reference			[0..*]				RFR
7	00632	Critical Range for Ordinal and Continuous Observations			[0..*]				RFR
8	00633	Absolute Range for Ordinal and Continuous Observations			[0..1]				RFR
9	00634	Delta Check Criteria			[0..*]				DLT
10	00635	Minimum Meaningful Increments			[0..1]				NM

(Definition from OM1.1 in Ch. 8)

Definition: This field contains the first OM1 segment in a message and is described as 1, the second as 2, and so on.

(Definition from OM2.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment. Refer to Table 0648 - Units of Measure in Chapter 2C for valid values.

(Definition from OM3.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM4.1 in Ch. 8)

Definition: The OM4-1 contains a numeric value that indicates a unique set of OM1, OM2, OM3, and OM4 components; each OMn-1 in a set will have the same value as illustrated in the example below. Because the OM4 segment can repeat, but needs to have a unique number for use with OM4-17, the sequence number must be appended with a sequence number as shown in the second example below.

OM4-1 Sequence Number – Test/Observation Master File Example:

MSH|...<cr>

// start MFE Test Begin group

MFE|A|...<cr>

OM1|1|...<cr>

OM2|1|...<cr>

OM3|1|...<cr>

OM4|1|...<cr>

// end MFE Test Begin group

// start MFE_Test_Begin group

MFE|A|...<cr>

OM1|2|...<cr>

OM2|2|...<cr>

OM3|2|...<cr>

OM4|2.1|...<cr>

OM4|2.2|...<cr>

//end MFE_Test_Begin group

(Definition from OM5.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM6.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM7.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OMC.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

Definition: This field contains the single tests/observations (those with a nature code of A or C, as described in OM1-18 - Nature of Service/Test/Observation) that have numeric values. This field contains their customary units of measure. Use of UCUM is strongly recommended as one of the specified units (either alone or in addition to the local units).

Definition: This field contains the numerically valued single observations (code A or C as described in OM1-18 - Nature of Service/Test/Observation), specifies the total length in characters of the field needed to display the observation, and the number of digits displayed to the right of the decimal point. This is coded as a single number in the format <length>.<decimal-digits>. For example, a value of 6.2 implies 6 characters total (including the sign and decimal point) with 2 digits after the decimal point. For integer values, the period and <decimal-digits> portion may be omitted (that is, 5.0 and 5 are equivalent). More than one such mask may be transmitted (separated by repeat delimiters) when it is necessary to define multiple display formats that are possible.

Definition: This field contains the single tests/observations - the corresponding SI units of measure in the format, when these differ from the customary units of measure given in the previous field. Refer to Table 0649 - Corresponding SI Units of Measure in Chapter 2C for valid values.

Definition: This field contains the continuous, numerically valued tests/observations, with a nature code of A or C (see OM1-18 - Nature of Service/Test/Observation). This is a factor for converting the customary units to SI units.

In the case that the observation units are not SI units, this field provides the formula needed to convert from the reported units to SI units, this shall include the equation needed to convert from the reporting to the SI units.

In the case that the relation is simply multiplicative, this field shall include only the conversion factor. For example, if (results SI units) = c * (results reporting units), then only c would be stored in this field. In the case of any other functional relationship, the entire equation would be stored as a test.

Definition: This field contains the reference (normal) ranges for "numeric" observations/tests with a nature code of A or C (see OM1-18 - Nature of Service/Test/Observation). It can identify different reference (normal) ranges for different categories of patients according to age, sex, race, and other conditions.

In the first component of this field (Normal Range (NR)), the units are assumed to be identical to the reporting units given in OM2-2 - Units of Measure.

When two different methods result in two different reference ranges, two different observations and corresponding OMx segments should be defined.

Definition: This field applies only to single tests/observations (i.e., a nature code of A or C, as described in OM1-18 - Nature of Service/Test/Observation) with numeric results). When a critical range is defined for such observations, it should be recorded here in the same format as the normal range (see OM2-6 - Reference (Normal) Range - Ordinal and Continuous Observations).

Definition: This field applies only to single tests/observations with a nature code of A or C (see OM1-18 - Nature of Service/Test/Observation). It defines the range of possible results. Results outside this range are not possible. The field should be recorded in the same format as the normal and critical ranges.

Definition: This field applies to numeric tests/observations with a nature code of A or C (see OM1-18 - Nature of Service/Test/Observation). The field describes the information that controls delta check warnings and includes four components.

1. The range to which the following applies: <low & high>.
   All the ranges are defined in terms of the customary reporting units given in OM2-2 - Units of Measure. If no value range is given, the check applies to all values.

2. The numeric threshold of the change that is detected, e.g., 10.

3. Whether the change is computed as a percent change or an absolute change. This component can have two possible values:

4. %    indicates a percent change
   a    absolute change

5. The length of time that the service retains a value for computing delta checks. This is recorded in number of days.

More than one delta check rule can apply. 13&16^10^%^100~16.1&20^2^a^100 implies that the delta check will trigger on a 10% change when the value of the observation is between 13 and 16. The check will trigger on an absolute change of 2 when the value is between 16.1 and 20. In both cases, the system will keep the last result for 100 days. In this example, beyond 100 days, the computer will not compute a delta check because it will not have a comparison value.

Definition: This field contains the numerically valued single observations (a nature code of A or C, as described in OM1-18 - Nature of Service/Test/Observation) and specifies the smallest meaningful difference between reported values (the effective resolution of the measuring instrument or technique for continuous data, or the smallest discrete interval that can occur for discrete data).

The Technical Steward for the OM3 segment is Orders and Observations.

This segment applies to free text and other non-numeric data types.

HL7 Attribute Table - OM3 - Categorical Service/Test/Observation Segment

Seq#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
OM3
1	00586	Sequence Number - Test/Observation Master File		=	[0..1]		4		NM
2	00636	Preferred Coding System			[0..1]			0650	CWE
3	00637	Valid Coded "Answers"			[0..*]			0652	CWE
4	00638	Normal Text/Codes for Categorical Observations			[0..*]			0654	CWE
5	00639	Abnormal Text/Codes for Categorical Observations			[0..*]			0655	CWE
6	00640	Critical Text/Codes for Categorical Observations			[0..*]			0656	CWE
7	00570	Value Type			[0..1]	[2..3]		0125 Value Type	ID

(Definition from OM1.1 in Ch. 8)

Definition: This field contains the first OM1 segment in a message and is described as 1, the second as 2, and so on.

(Definition from OM2.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment. Refer to Table 0648 - Units of Measure in Chapter 2C for valid values.

(Definition from OM3.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM4.1 in Ch. 8)

Definition: The OM4-1 contains a numeric value that indicates a unique set of OM1, OM2, OM3, and OM4 components; each OMn-1 in a set will have the same value as illustrated in the example below. Because the OM4 segment can repeat, but needs to have a unique number for use with OM4-17, the sequence number must be appended with a sequence number as shown in the second example below.

OM4-1 Sequence Number – Test/Observation Master File Example:

MSH|...<cr>

// start MFE Test Begin group

MFE|A|...<cr>

OM1|1|...<cr>

OM2|1|...<cr>

OM3|1|...<cr>

OM4|1|...<cr>

// end MFE Test Begin group

// start MFE_Test_Begin group

MFE|A|...<cr>

OM1|2|...<cr>

OM2|2|...<cr>

OM3|2|...<cr>

OM4|2.1|...<cr>

OM4|2.2|...<cr>

//end MFE_Test_Begin group

(Definition from OM5.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM6.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM7.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OMC.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

Definition: This field contains the observations whose categorical responses are taken from a specified table of codes (e.g., CWE data types). Record the preferred coding system for these responses as observations (e.g., ICD10, HGVS, ISCN, SNOMED CT). Refer to Table 0650 - Preferred Coding System in Chapter 2C for valid values.

Definition: This field contains a list of valid coded answers. In the case that the list of coded answers is easily enumerated, list the valid coded answers for this observation here using the preferred coding system given in OM3-2 - Preferred Coding System. If, for example, the given observation was VDRL, the valid answers might be "non-reactive", "86^ intermediate", and "87^ reactive".Refer to Table 0652 - Valid Coded "Answers" in Chapter 2C for valid values.

Definition: Certain observations/tests with a nature code of A or C (see OM1-18 - Nature of Service/Test/Observation) have text (alpha) results (e.g., reactive, nonreactive). Alpha normals for those tests should be entered in this field (e.g., "nonreactive"). Refer to Table 0654 - Normal Text/Codes for Categorical Observations in Chapter 2C for valid values.

The format of this field is:

The first component is a code taken from a standard code source list. The second component is the text associated with the code. The third component is the identification of the code table source. When only a text description of a possible answer is available, it is recorded as ^<text>.

Care should be taken to transmit only those results that are considered normal for that test. A drug screen may have possible results of "negative" and "positive." However, only a result of "negative" is considered to be normal. When an observation has more than one "normal" result, multiple values in this field should be separated with a repeat delimiter.

Definition: This field contains the list of the text answers that are abnormal for the test. Refer to Table 0655 - Abnormal Text/Codes for Categorical Observations in Chapter 2C for valid values.

Definition: This field contains the list of coded results that are critically abnormal for this observation. Refer to Table 0656 - Critical Text/Codes for Categorical Observations in Chapter 2C for valid values.

(Definition from OBX.2 in Ch. 7)

Definition: This field defines the data type of OBX-5, Observation Value. If OBX-5, Observation Value, is valued then OBX-2, Value Type, SHALL be valued. When OBX-5, Observation Value, is not valued, OBX-2 Value Type MAY be valued to represent a data type used to value the observation expressed in OBX-3, Observation Identifier. See HL7 Table 0125 – Value Types for valid values.

Condition: This field is required if OBX-5, Observation Value, is valued.

For example, if the value is 'CWE' then the result in OBX-5 must be a coded entry or text or both. As of v 2.7, the ST data type may not be used to transmit data that can be more precisely transmitted using other data types, e.g. SN when comparative symbols are needed.

The RP value (reference pointer) must be used if the OBX-5 contains a pointer to the data e.g., a URL of an image. The receiving system can use this reference pointer whenever it needs access to the actual data through other interface standards, e.g., DICOM, or through appropriate data base servers.

The structured numeric (SN) data type provides for reporting ranges (e.g., 3-5 or 10-20), titres (e.g., 1:10), and out-of-range indicators (e.g., >50) in a structured and computer-interpretable way.

We allow the FT data type in the OBX segment, but its use is discouraged. Formatted text usually implies a meaningful structure, e.g., a list of three independent diagnoses reported on different lines. But ideally, the structure in three independent diagnostic statements would be reported as three separate OBX segments.

TX should not be used except to send large amounts of text. In the TX data type, the repeat delimiter can only be used to identify paragraph breaks. Use ST to send short, and possibly encodable, text strings.

CDA documents are to be exchanged in the OBX segment in any message that can exchange documents (such as MDM or ORU). Within the OBX segment, the MIME package is encoded as an encapsulated (ED) data type.

(Definition from OM3.7 in Ch. 8)

Definition: This field contains the allowed data type for a single categorical observation (code A or C in OM1-18 - Nature of Observation). Refer to HL7 Table 0125 – Value Type in Chapter 2C, Code Tables, for valid values.

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.

HL7 Attribute Table - OM4 - Observations That Require Specimens Segment

Seq#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
OM4
1	00586	Sequence Number - Test/Observation Master File		=	[0..1]		4		NM
2	00642	Derived Specimen			[0..1]	[1..1]		0170 Derived Specimen	ID
3	00643	Container Description		=	[0..*]	[1..60]	60		TX
4	00644	Container Volume			[0..*]				NM
5	00645	Container Units			[0..*]			0658	CWE
6	00646	Specimen			[0..1]			0660	CWE
7	00647	Additive			[0..1]			0371 Additive/Preservative	CWE
8	00648	Preparation			[0..1]				TX
9	00649	Special Handling Requirements			[0..1]				TX
10	00650	Normal Collection Volume			[0..1]				CQ
11	00651	Minimum Collection Volume			[0..1]				CQ
12	00652	Specimen Requirements			[0..1]				TX
13	00653	Specimen Priorities			[0..*]	[1..1]		0027 Priority	ID
14	00654	Specimen Retention Time			[0..1]				CQ
15	01908	Specimen Handling Code			[0..*]			0376 Special Handling Code	CWE
16	03311	Specimen Preference			[0..1]			0920 Preferred Specimen/Attribute Status	ID
17	03312	Preferred Specimen/Attribture Sequence ID			[0..1]				NM
18	01539	Taxonomic Classification Code			[0..*]			0446	CWE

(Definition from OM1.1 in Ch. 8)

Definition: This field contains the first OM1 segment in a message and is described as 1, the second as 2, and so on.

(Definition from OM2.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment. Refer to Table 0648 - Units of Measure in Chapter 2C for valid values.

(Definition from OM3.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM4.1 in Ch. 8)

Definition: The OM4-1 contains a numeric value that indicates a unique set of OM1, OM2, OM3, and OM4 components; each OMn-1 in a set will have the same value as illustrated in the example below. Because the OM4 segment can repeat, but needs to have a unique number for use with OM4-17, the sequence number must be appended with a sequence number as shown in the second example below.

OM4-1 Sequence Number – Test/Observation Master File Example:

MSH|...<cr>

// start MFE Test Begin group

MFE|A|...<cr>

OM1|1|...<cr>

OM2|1|...<cr>

OM3|1|...<cr>

OM4|1|...<cr>

// end MFE Test Begin group

// start MFE_Test_Begin group

MFE|A|...<cr>

OM1|2|...<cr>

OM2|2|...<cr>

OM3|2|...<cr>

OM4|2.1|...<cr>

OM4|2.2|...<cr>

//end MFE_Test_Begin group

(Definition from OM5.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM6.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM7.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OMC.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

Definition: This field contains the codes that identify the parents and children for diagnostic studies—especially in microbiology—where the initial specimen (e.g., blood) is processed to produce results (e.g., the identity of the bacteria grown out of the culture). The process also produces new "specimens" (e.g., pure culture of staphylococcus, and E. coli), and these are studied by a second order process (bacterial sensitivities). The parents (e.g., blood culture) and children (e.g., penicillin MIC) are identified in such cases. Refer to HL7 Table 0170 - Derived Specimen in Chapter 2C, Code Tables, for valid values:

Definition: This field contains the physical appearance, including color of tube tops, shape, and material composition (e.g., red-top glass tube). Note that the color is not necessarily a unique identifier of the additive and/or use of the tube. This is especially true for black and some blue tube tops, as can be seen above. Color is included here for user convenience. This field repeats to accommodate all the possible specimen that will be allowed. If a container is preferred, only that container should be messaged here with the alternate containers messaged in a repeat OM4 segment.

(Definition from OM4.4 in Ch. 8)

Definition: This field indicates the capacity of the container. This field repeats to accommodate all the possible specimen that will be allowed. If a container is preferred, only that container should be messaged here with the alternate containers messaged in a repeat OM4 segment

(Definition from SAC.21 in Ch. 13)

Definition: This field indicates the capacity of the container in the units specified below.

Definition: This field contains the units of measure of the container volume. If the units are ISO+ units, they should be recorded as single case abbreviations. If the units are ANS+ or L (local), the units and the source code table must be recorded, except that in this case, component delimiters should be replaced by subcomponent delimiters. For example, 1 indicates liters, whereas pt&&ANS+ indicates pints (ANSI units). The default unit is milliliters (ml), which should be assumed if no units are reported. This field repeats to accommodate all the possible specimen that will be allowed. If a container is preferred, only that container units should be messaged here with the alternate containers messaged in a repeat OM4 segment. Refer to Table 0658 - Container Units in Chapter 2C for valid values.

Definition: Describes the specimen from an appropriate controlled vocabulary. 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. Refer to Table 0660 - Specimen in Chapter 2C for valid values.

(Definition from OM4.7 in Ch. 8)

Definition: This field contains the codes that should be those provided by NCCLS³. Refer to HL7 Table 0371 - Additive/Preservative in Chapter 2C, Code Tables, for valid values. The table's values are taken from NCCLS AUTO4. The value set can be extended with user specific values.

This table was not specified in previous versions and thus sites may choose to use other site-specific tables.

(Definition from SAC.27 in Ch. 13)

Definition: This field identifies any additives introduced to the specimen before or at the time of collection. These additives may be introduced in order to preserve, maintain or enhance the particular nature or component of the specimen. It is a repetitive field. Refer to HL7 Table 0371 – Additive/Preservative for valid values. 'The value set can be extended with user specific values.

When the SPM (Specimen) segment is sent together with the SAC segment the additive attribute value from the SPM segment can be included in this field of the SAC.

Definition: This field contains the special processing that should be applied to the container, e.g., add acidifying tablets before sending.

Definition: This field contains the special handling requirements here (e.g., ice specimen, deliver within two hours of obtaining).

Definition: This field contains the normal specimen volume required by the lab. This is the amount used by the normal methods and provides enough specimens to repeat the procedure at least once if needed. The default unit is milliliters (ml).

Definition: This field contains the amount of specimen needed by the most specimen sparing method (e.g., using micro techniques). The minimum amount allows for only one determination. The default unit is milliliters (ml).

Definition: This field contains the other requirements for specimen delivery and special handling (e.g., delivery within one hour, iced).

Definition: This field contains the allowed priorities for obtaining the specimen. Note that they may be different from the processing priorities given in OM1-25 - Processing Priority. When a test is requested, the specimen priority given in TQ1-9 - Priority should be one of the priorities listed here. Multiple priorities are separated by repeat delimiters. Refer to HL7 Table 0027 - Priority in Chapter 2C, Code Tables, for valid values.

Definition: This field contains the usual time that a specimen for this observation is retained after the observation is completed, for the purpose of additional testing. The first component is the duration, and the second component is an ISO time unit.

(Definition from SPM.15 in Ch. 7)

Definition: This describes how the specimen and/or container need to be handled from the time of collection through the initiation of testing. As this field is not required, no assumptions can be made as to meaning when this field is not populated.

Refer to User-defined Table 0376 – Special Handling Code for suggested values.

(Definition from OM4.15 in Ch. 8)

Definition: This describes how the specimen and/or container need to be handled from the time of collection through the initiation of testing. As this field is not required, no assumptions can be made as to meaning when this field is not populated.

Refer to User-defined Table 0376 – Special Handling Code in Chapter 2C, Code Tables, for suggested values.

Definition: This field indicates whether the Specimen/Attribute is Preferred or alternate for collection of the specimen. There can only be one occurrence of a Preferred or Alternate Specimen/Attribute for the code referenced in OM4-6 Specimen. For example, if two OM4 segments are received for specimen type of Serum, only one can be marked as Preferred. Refer to HL7 Table 0920 – Preferred Specimen/Attribute Status in Chapter 2C, Code Tables, for suggested values.

Definition: This field contains the value of the sequence number of the Preferred Specimen that these specimens are the alternative for. Note: For the preferred specimen (i.e., OM4-16 = "P"), this field is not populated. This field is used by the Alternate Specimen (i.e., OM4-16 = "A") to point to the preferred specimen that it is to replace or be used as an alternative.

Example:

Preferred specimen     

OM4|1||Tiger Top|… to field16|P||

OM4|2||Plastic Screw Top|0.5|mL|Urine|without 6N HCI| … to field16|P||

Alternate specimen

OM4|3||Red Top|… to field16|A|1|

(Definition from PID.35 in Ch. 3)

Definition: A code representing the taxonomic classification (e.g. species and/or breed) of an organism. This may include the common or scientific name in the description component, based on the coding system(s) used. SNOMED-CT is the recommended coding system. If this field is not valued, a human is assumed. If the specificity of the coding system is insufficient to represent the organism to the degree desired, the most detailed coded value available may be used in this field and additional information sent in the text field, PID-37 – Strain.

For example:

...|L-80700^Canine, NOS^SNM3|...

...|L-80100^Bovine^SNM3|...

...|L-80A00^Feline^SNM3|...

(Definition from OM1.50 in Ch. 8)

Definition: The species of living organism. This may include the common or scientific name, based on the coding system(s) used. SNOMED is the recommended coding system. If this field is not valued, a human is assumed. Refer to User-defined Table 0446 - Species Code in Chapter 2C, Code Tables, for suggested values.

For example:

...|L-80700^Canine, NOS^SNM3|...

...|L-80100^Bovine^SNM3|...

...|L-80A00^Feline^SNM3|....

This field is a list of species or other taxonomic classification(s) to which the indicated specimen type may appropriately be applied for the indicated observation or test. If this field is omitted the default meaning is that the test or observation is applicable to humans. In a veterinary context if the test is applicable to any species, an appropriate code such as "Kingdom Animalia (organism)" should be used to avoid confusion with the meaning of human only.

(Definition from OM4.18 in Ch. 8)

Definition: The species of living organism. This may include the common or scientific name, based on the coding system(s) used. SNOMED is the recommended coding system. If this field is not valued, a human is assumed. Refer to User-defined Table 0446 - Species Code for suggested values. Refer to Table 0661 - Taxonomic Classification Code in Chapter 2C for valid values.

For example:

...|L-80700^Canine, NOS^SNM3|...

...|L-80100^Bovine^SNM3|...

...|L-80A00^Feline^SNM3|....

This field is a list of species or other taxonomic classification(s) to which the indicated specimen type may appropriately be applied for the indicated observation or test. If this field is omitted the default meaning is that the test or observation is applicable to humans. In a veterinary context, if the test is applicable to any species, an appropriate code such as "Kingdom Animalia (organism)" should be used to avoid confusion with the meaning of human only.

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

HL7 Attribute Table - OM5 - Observation Batteries (Sets) Segment

Seq#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
OM5
1	00586	Sequence Number - Test/Observation Master File		=	[0..1]		4		NM
2	00655	Test/Observations Included Within an Ordered Test Battery			[0..*]			0662	CWE
3	00656	Observation ID Suffixes			[0..1]				ST

(Definition from OM1.1 in Ch. 8)

Definition: This field contains the first OM1 segment in a message and is described as 1, the second as 2, and so on.

(Definition from OM2.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment. Refer to Table 0648 - Units of Measure in Chapter 2C for valid values.

(Definition from OM3.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM4.1 in Ch. 8)

Definition: The OM4-1 contains a numeric value that indicates a unique set of OM1, OM2, OM3, and OM4 components; each OMn-1 in a set will have the same value as illustrated in the example below. Because the OM4 segment can repeat, but needs to have a unique number for use with OM4-17, the sequence number must be appended with a sequence number as shown in the second example below.

OM4-1 Sequence Number – Test/Observation Master File Example:

MSH|...<cr>

// start MFE Test Begin group

MFE|A|...<cr>

OM1|1|...<cr>

OM2|1|...<cr>

OM3|1|...<cr>

OM4|1|...<cr>

// end MFE Test Begin group

// start MFE_Test_Begin group

MFE|A|...<cr>

OM1|2|...<cr>

OM2|2|...<cr>

OM3|2|...<cr>

OM4|2.1|...<cr>

OM4|2.2|...<cr>

//end MFE_Test_Begin group

(Definition from OM5.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM6.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM7.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OMC.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

Definition: This field contains the codes and names of all tests/observations included within a single battery (nature code P, as described in OM1-18 - Nature of Service/Test/Observation), a single functional procedure (nature code F), or a given superset (nature code S). When a segment includes a list of component elements, the sending system should be sure that the segments defining all of the components are sent before the segment that references them. An entry in this list can itself be a battery. Refer to Table 0662 - Test/Observations Included Within an Ordered Test Battery in Chapter 2C for valid values.

The individual service/test/observation code should be recorded as type CWE, i.e., in the standard format for coded observation identifiers. Multiple observations should be separated by repeat delimiters. In the US, it is recommended that, within a single occurrence of OM5-2 Tests/Observations included within an Orders Test Battery, these child observations be identified with LOINC codes as well as by the producer’s local identifier. Examples of code systems used may be LOINC (emerging as the global standard for observation identifiers), JLAC10, or SNOMED CT.

If the definition segment defined serum electrolytes, this field might look like the following:

2951-2^SODIUM^LN~

2823-3^POTASSIUM^LN~

2075-0^CHLORIDE^LN~

2028-9^CARBON DIOXIDE^LN

For S (superset) parameters, this field contains the batteries that are included within the "super" battery. For example, ROUTINES might be defined as:

402^Electrolytes~352^Urinalysis~432^CBC~520^SMA12

Definition: This field contains the tests or procedures that produce a type which uses observation ID suffixes following the service/test/observation ID code. This field lists the possible options. For example, a chest X-ray may use the suffixes IMP, REC, DEV, or others. Each of the expected suffixes should be listed here.

The Technical Steward for the OM6 segment is Orders 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.

HL7 Attribute Table - OM6 - Observations that are Calculated from Other Observations Segment

Seq#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
OM6
1	00586	Sequence Number - Test/Observation Master File		=	[0..1]		4		NM
2	00657	Derivation Rule			[0..1]				TX

(Definition from OM1.1 in Ch. 8)

Definition: This field contains the first OM1 segment in a message and is described as 1, the second as 2, and so on.

(Definition from OM2.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment. Refer to Table 0648 - Units of Measure in Chapter 2C for valid values.

(Definition from OM3.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM4.1 in Ch. 8)

Definition: The OM4-1 contains a numeric value that indicates a unique set of OM1, OM2, OM3, and OM4 components; each OMn-1 in a set will have the same value as illustrated in the example below. Because the OM4 segment can repeat, but needs to have a unique number for use with OM4-17, the sequence number must be appended with a sequence number as shown in the second example below.

OM4-1 Sequence Number – Test/Observation Master File Example:

MSH|...<cr>

// start MFE Test Begin group

MFE|A|...<cr>

OM1|1|...<cr>

OM2|1|...<cr>

OM3|1|...<cr>

OM4|1|...<cr>

// end MFE Test Begin group

// start MFE_Test_Begin group

MFE|A|...<cr>

OM1|2|...<cr>

OM2|2|...<cr>

OM3|2|...<cr>

OM4|2.1|...<cr>

OM4|2.2|...<cr>

//end MFE_Test_Begin group

(Definition from OM5.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM6.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM7.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OMC.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

Definition: This field is used when there are patient variables that are derived from one or more other patient variables (e.g., creatinine clearance, ideal weight, maximum daily temperature, average glucose, framingham risk). This field contains the rules for deriving the value of this variable (i.e., nature code C, as given in OM1-18 - Nature of Service/Test/Observation). These can be described in terms of humanly understandable formulas or descriptions.

When possible, however, they should be defined in terms of the Arden Syntax for specifying selection and transcendative functions and algebraic operations, ASTM E1460-92. Derivation rules that are represented in Arden Syntax should begin and end with an Arden slot delimiter (;;). Within this syntax, variables should be identified by OM1-2 - Producer's Service/Test/Observation ID. We recommend the use of the Arden Syntax because it permits the unambiguous specification of most such derived values and is a published standard for medical logic modules.

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

HL7 Attribute Table - OM7 - Additional Basic Attributes Segment (Fields That Apply to Most Observations/Services)

Seq#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
OM7
1	00586	Sequence Number - Test/Observation Master File	SHALL	=	[1..1]		4		NM
2	00238	Universal Service Identifier	SHALL		[1..1]			0612	CWE
3	01481	Category Identifier			[0..*]			0412	CWE
4	01482	Category Description		=	[0..1]		200		TX
5	01483	Category Synonym		#	[0..*]		200		ST
6	01484	Effective Test/Service Start Date/Time			[0..1]				DTM
7	01485	Effective Test/Service End Date/Time			[0..1]				DTM
8	01486	Test/Service Default Duration Quantity		#	[0..1]		5		NM
9	01487	Test/Service Default Duration Units			[0..1]			0663	CWE
10	01488	Test/Service Default Frequency		=	[0..1]		60		CWE
11	01489	Consent Indicator			[0..1]	[1..1]		0136 Yes/no Indicator	ID
12	01490	Consent Identifier			[0..1]			0413	CWE
13	01491	Consent Effective Start Date/Time			[0..1]				DTM
14	01492	Consent Effective End Date/Time			[0..1]				DTM
15	01493	Consent Interval Quantity		#	[0..1]		5		NM
16	01494	Consent Interval Units	MAY True: False:	C	[1..1] [0..1]			0414	CWE
17	01495	Consent Waiting Period Quantity		#	[0..1]		5		NM
18	01496	Consent Waiting Period Units	MAY True: False:	C	[1..1] [0..1]			0414	CWE
19	00607	Effective Date/Time of Change			[0..1]				DTM
20	00224	Entered By		B	[0..1]				XCN
21	01497	Orderable-at Location		B	[0..*]				PL
22	01498	Formulary Status		=	[0..1]		1	0473 Formulary Status	CWE
23	01499	Special Order Indicator			[0..1]	[1..1]		0136 Yes/no Indicator	ID
24	01306	Primary Key Value - CDM			[0..*]			0132	CWE

(Definition from OM1.1 in Ch. 8)

Definition: This field contains the first OM1 segment in a message and is described as 1, the second as 2, and so on.

(Definition from OM2.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment. Refer to Table 0648 - Units of Measure in Chapter 2C for valid values.

(Definition from OM3.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM4.1 in Ch. 8)

Definition: The OM4-1 contains a numeric value that indicates a unique set of OM1, OM2, OM3, and OM4 components; each OMn-1 in a set will have the same value as illustrated in the example below. Because the OM4 segment can repeat, but needs to have a unique number for use with OM4-17, the sequence number must be appended with a sequence number as shown in the second example below.

OM4-1 Sequence Number – Test/Observation Master File Example:

MSH|...<cr>

// start MFE Test Begin group

MFE|A|...<cr>

OM1|1|...<cr>

OM2|1|...<cr>

OM3|1|...<cr>

OM4|1|...<cr>

// end MFE Test Begin group

// start MFE_Test_Begin group

MFE|A|...<cr>

OM1|2|...<cr>

OM2|2|...<cr>

OM3|2|...<cr>

OM4|2.1|...<cr>

OM4|2.2|...<cr>

//end MFE_Test_Begin group

(Definition from OM5.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM6.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM7.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OMC.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OBR.4 in Ch. 4)

Definition: This field contains the identifier code for the requested observation/test/battery. The identifier can come from either a local coding system or industry standards. Examples may be LOINC (emerging as the global standard for observation identifiers), JLAC10, or SNOMED CT. Refer to Table 0612 - Universal Service Identifier in Chapter 2C for valid values.

(Definition from OBR.4 in Ch. 7)

Definition: This field contains the identifier code for the requested observation/test/battery. The identifier can come from either a local coding system or industry standards. Examples may be LOINC (emerging as the global standard for observation identifiers), JLAC10, or SNOMED CT. Refer to Table 0612 - Universal Service Identifier in Chapter 2C for valid values.

(Definition from OM7.2 in Ch. 8)

Definition: This field contains the producer's usual or preferred identification of the test or service.

(Definition from AIS.3 in Ch. 10)

Definition: This field contains an identifier code for a service to be scheduled. This field may contain a universal service identifier describing the observation/test/battery/procedure or other activity that is to be performed during the requested appointment, similar to the universal service identifier defined for the OBR segment in the Order Entry chapter (Chapter 4). This code can be based on local and/or universal codes. The use of universal codes is recommended.

(Definition from TCC.1 in Ch. 13)

Definition: This field identifies the test code that information is being transmitted about. The alternate elements represent the test code identifier that has been assigned by the manufacturer to this particular test code. Refer to Table 0787 - Universal Service Identifier in Chapter 2C for valid values.

(Definition from TCD.1 in Ch. 13)

Definition: This field identifies the test code that information is being transmitted about. Refer to Table 0789 - Universal Service Identifier in Chapter 2C for valid values.

Definition: This field contains the category name (term given to a group of service items for the purpose of classification). Examples: Laboratory, Pharmacy, Diagnostic Imaging, etc. Refer to User-defined Table 0412 - Category Identifier in Chapter 2C, Code Tables, for suggested values.

Definition: This field contains a text description for the category of the test/service item.

Example: The category "Pathology" may be described as a specialty practice concerned with all aspects of disease, with special reference to the essential natural cause and development of abnormal conditions, as well as the structural and functional changes that result from the disease process.

Definition: This field contains an alternate name(s) for the category of the test/service. Example: The category "Radiology" is a synonym name for the category "Diagnostic Imaging".

Definition: This field contains the date and time that the service item is available to be ordered, performed, etc.

Definition: This field contains the date and time that the service item is no longer authorized to be ordered, performed, etc.

Definition: This field indicates the default duration quantity for the service.

Definition: This field indicates the default duration units for the service. Refer to Table 0663 - Test/Service Default Duration Units in Chapter 2C for valid values.

Definition: This field indicates the default frequency (how often) the service would be ordered for or performed on.

Definition: This field indicates if a consent is needed for the service item. Refer to HL7 Table 0136 - Yes/no Indicator in Chapter 2C, Code Tables.

• Y    A consent is required for service item to be ordered/performed.

• N    No consent is needed for service item to be ordered/performed

Definition: This field contains the identifier for the consent specified for the service item. Refer to User-defined Table 0413 - Consent Identifier in Chapter 2C, Code Tables, for suggested values.

Definition: This field contains the date and time the consent is valid for the service item.

Definition: This field contains the date and time the consent is no longer valid for the test/service.

Definition: This field specifies the period of time for which a consent is valid for a specific service item.

Definition: This field specifies the unit of time for OM7-15 - Consent Interval Quantity. Refer to User-defined Table 0414 - Units of Time in Chapter 2C, Code Tables, for suggested values.

Definition: This field contains the time period between the time the consent is signed and the procedure can be performed.

Definition: This field specifies the unit of time for OM7-17 - Consent Waiting Period Quantity. Refer to User-defined Table 0414 - Units of time in Chapter 2C, Code Tables, for suggested values.

(Definition from OM1.22 in Ch. 8)

Definition: This field contains the date and time of the last change in the test procedure that would make previous results incompatible with new results, e.g., the last time that normal reference range or units changed for a numeric test/observation.

We strongly suggest that observation producers never use the same observation ID when the measurement procedures change in such a way that results produced under the new procedure are clinically different from those produced with the old procedure. Rather, the producer should try to adjust the new procedure so that its values are clinically indistinguishable from the old. Failing that, one should create a new observation ID for the observation produced under the new procedure.

In the rare circumstances when a procedure change occurs and neither of the above two options is viable, this field shall be used to transmit the effective date/time of the new procedure. The receiving system shall assume that any values that come across under this observation ID are under the new procedure after this date and take appropriate steps to distinguish the old from the new observations.

This number is included to provide a means of communicating with the observation producing service when they have questions about particular observations or results.

(Definition from OM7.19 in Ch. 8)

Definition: This field contains the date and time of the last change in the test procedure that would make previous results incompatible with new results.

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

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

Definition: This field contains the location(s) where the test/service can be ordered.

Definition: This field indicates whether or not the service (pharmaceutical) is in the formulary. Refer to User-defined Table 0473 - Formulary Status in Chapter 2C, Code Tables, for valid values.

Definition: This field indicates whether or not the service (pharmaceutical) is a special order. Refer to HL7 Table 0136 - Yes/no Indicator in Chapter 2C, Code Tables, for valid values.

Y    This is a special order.

N    This is not a special order

(Definition from OM7.24 in Ch. 8)

Definition: Allows the ability to associate a Service/Test/Observation item with a CIM (charge item master). This field contains the corresponding value of CDM-1 for the CIM being linked to. It is possible to allow multiple charge items to a single Service/Test/Observation item.

(Definition from CDM.1 in Ch. 8)

Definition: The key field of the entry. Must match MFE-4 - Primary Key Value - MFE. This field contains the code assigned by the institution for the purpose of uniquely identifying the thing that can be charged. For example, this field would be used to uniquely identify a procedure, item, or test for charging purposes. Probably the same set of values as used in FT1-7- Transaction Code in financial messages (refer to User-defined Table 0132 - Transaction Code in Chapter 2C, Code Tables, for suggested values). See Chapter 7 for discussion of the universal service ID.

The Technical Steward for the OMC segment is Orders and Observations.

HL7 Attribute Table - OMC - Supporting Clinical Information Segment

Seq#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
OMC
1	00586	Sequence Number - Test/Observation Master File		=	[0..1]		4		NM
2	00763	Segment Action Code	MAY True: False:	C(R/X)	[1..1] [0..1]	[1..1]		0206 Segment Action Code	ID
3	00764	Segment Unique Key	MAY True: False:	C(R/X)	[1..1] [0..1]				EI
4	03444	Clinical Information Request	SHALL		[1..1]			0664	CWE
5	03445	Collection Event/Process Step	SHALL		[1..*]			0938	CWE
6	03446	Communication Location	SHALL		[1..1]			0939	CWE
7	03447	Answer Required			[0..1]			0136 Yes/no Indicator	ID
8	03448	Hint/Help Text			[0..1]				ST
9	03449	Type of Answer			[0..1]			0125 Value Type	ID
10	03450	Multiple Answers Allowed			[0..1]			0136 Yes/no Indicator	ID
11	03451	Answer Choices			[0..*]			0665	CWE
12	03452	Character Limit			[0..1]				NM
13	03453	Number of Decimals			[0..1]				NM

(Definition from OM1.1 in Ch. 8)

Definition: This field contains the first OM1 segment in a message and is described as 1, the second as 2, and so on.

(Definition from OM2.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment. Refer to Table 0648 - Units of Measure in Chapter 2C for valid values.

(Definition from OM3.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM4.1 in Ch. 8)

Definition: The OM4-1 contains a numeric value that indicates a unique set of OM1, OM2, OM3, and OM4 components; each OMn-1 in a set will have the same value as illustrated in the example below. Because the OM4 segment can repeat, but needs to have a unique number for use with OM4-17, the sequence number must be appended with a sequence number as shown in the second example below.

OM4-1 Sequence Number – Test/Observation Master File Example:

MSH|...<cr>

// start MFE Test Begin group

MFE|A|...<cr>

OM1|1|...<cr>

OM2|1|...<cr>

OM3|1|...<cr>

OM4|1|...<cr>

// end MFE Test Begin group

// start MFE_Test_Begin group

MFE|A|...<cr>

OM1|2|...<cr>

OM2|2|...<cr>

OM3|2|...<cr>

OM4|2.1|...<cr>

OM4|2.2|...<cr>

//end MFE_Test_Begin group

(Definition from OM5.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM6.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OM7.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OMC.1 in Ch. 8)

Definition: This field contains the same value as the sequence number of the associated OM1 segment.

(Definition from OMC.2 in Ch. 8)

Definition:  This field indicates whether this repetition of the segment is being added, changed or deleted.  When using dynamic update mode (See Chapter 2, Section 2.23.4.2, "Action code/unique identifier mode update definition.")  OMC-2 and OMC-3 Segment Unique Key are used to establish the "unique key" and to determine the data subject to the action. Refer to HL7 Table 0206 – Segment action code for valid values.

If the transaction uses dynamic/action code messaging, the field must be valued. 

Condition Predicate: Required if OMC-3 is valued.

(Definition from LCH.2 in Ch. 8)

Definition: This field indicates whether this repetition of the segment is being added, changed or deleted. The action code adds a validation check to indicate, from the point of view of the sending system, whether this repetition of a segment is being added, changed or deleted. This and the following field are used to implement the "unique key" mode of updating repeating segments. (See Chapter 2, section 2.10.4.2, "Action code/unique identifier mode update definition.") Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from LRL.2 in Ch. 8)

Definition: This field indicates whether this repetition of the segment is being added, changed or deleted. The action code adds a validation check to indicate, from the point of view of the sending system, whether this repetition of a segment is being added, changed or deleted. This and the following field are used to implement the "unique key" mode of updating repeating segments. (See Chapter 2, section 2.10.4.2, "Action code/unique identifier mode update definition.") Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

(Definition from RGS.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIS.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIG.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIL.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from AIP.2 in Ch. 10)

Definition: This field contains the action to be taken when updating or modifying information in this segment from previously sent interface transactions. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, Code Tables, for valid values.

This field is conditionally required. It is required for all updating or modifying trigger events.

(Definition from OMC.3 in Ch. 8)

Definition: This field contains a unique identifier for one of the multiple repetitions of this segment, to be used in conjunction with the preceding field. Each of the repetitions of the segment will be uniquely identified by this unique key field for the purposes of updates.

Condition Predicate: Required if OMC-2 is valued.

(Definition from LCH.3 in Ch. 8)

Definition: This field contains a unique identifier for one of the multiple repetitions of this segment, to be used in conjunction with the preceding field. Each of the repetitions of the segment will be uniquely identified by this unique key field for the purposes of updates.

(Definition from LRL.3 in Ch. 8)

Definition: This field contains a unique identifier for one of the multiple repetitions of this segment, to be used in conjunction with the preceding field. Each of the repetitions of the segment will be uniquely identified by this unique key field for the purposes of updates.

Definition: This field contains a variable that the diagnostic service needs to interpret the results of an ordered study. Where the observations specified here should be sent is specified in the OMC-6 (Communication Location). Refer to Table 0664 - Clinical Information Request in Chapter 2C for valid values.

Definition: This field indicates by when in the ordering process or workflow this information must be collected. Limit indicates must be done by X point in the workflow. Refer to HL7 Table 0938 – Collection Even/Process Step Limit for valid values.

Definition: This field indicates where in the message this information is expected to be communicated, e.g. PID, OBR, and SPM). Refer to HL7 Table 0939 – Communication Loction for valid values.

Definition: Must the question be answered, or just displayed and can be blank. Refer to HL7 Table 0136 – Yes/no Indicator for valid values.

Y    Answer must be provided

N    Answer not required

Definition: This field gives guidance to the provider on how to answer the question.

Definition: This field contains the allowed datatype for answers, and is drawn from HL7 Table 0125 – Value Type for valid values. Type of answers include: numeric, date, coded, text, etc.

Definition: This field indicates if multiple answers are allowed, which may impact EHR system display and selection functionality. Refer to HL7 Table 0136 – Yes/no Indicator for valid values.

Y    Multiple Answers Allowed

N    Single Answer only Allowed

Definition: Allowed coded answers to be sent in HL7 file (CWE.1) and/or display Text for Ordering system to present to provider (CWE.2). Refer to Table 0665 - Answer Choices in Chapter 2C for valid values.

The condition is valued only if OMC-9 is valued 'CWE' or 'CNE'.

Definition: Total number of characters allowed. Required for numeric and (long) text answers.

The field is valued only if OMC-9 is valued 'NM', 'SN', 'ST", 'TX', or 'FT'.

Definition: For numeric answers the number of digits after the decimal.

The field is valued only if OMC-9 is valued 'NM' or 'SN'.

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.

HL7 Attribute Table - PM1 - Payer Master File Segment

Seq#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
PM1
1	00368	Health Plan ID	SHALL		[1..1]			0072	CWE
2	00428	Insurance Company ID	SHALL		[1..*]				CX
3	00429	Insurance Company Name			[0..*]				XON
4	00430	Insurance Company Address			[0..*]				XAD
5	00431	Insurance Co Contact Person			[0..*]				XPN
6	00432	Insurance Co Phone Number			[0..*]				XTN
7	00433	Group Number		=	[0..1]		12		ST
8	00434	Group Name			[0..*]				XON
9	00437	Plan Effective Date			[0..1]				DT
10	00438	Plan Expiration Date			[0..1]				DT
11	03454	Patient DOB Required			[0..1]			0136 Yes/no Indicator	ID
12	03455	Patient Gender Required			[0..1]			0136 Yes/no Indicator	ID
13	03456	Patient Relationship Required			[0..1]			0136 Yes/no Indicator	ID
14	03457	Patient Signature Required			[0..1]			0136 Yes/no Indicator	ID
15	03458	Diagnosis Required			[0..1]			0136 Yes/no Indicator	ID
16	03459	Service Required			[0..1]			0136 Yes/no Indicator	ID
17	03460	Patient Name Required			[0..1]			0136 Yes/no Indicator	ID
18	03461	Patient Address Required			[0..1]			0136 Yes/no Indicator	ID
19	03462	Subscribers Name Required			[0..1]			0136 Yes/no Indicator	ID
20	03463	Workman's Comp Indicator			[0..1]			0136 Yes/no Indicator	ID
21	03464	Bill Type Required			[0..1]			0136 Yes/no Indicator	ID
22	03465	Commercial Carrier Name and Address Required			[0..1]			0136 Yes/no Indicator	ID
23	03466	Policy Number Pattern			[0..1]				ST
24	03467	Group Number Pattern			[0..1]				ST