The FT1 segment contains the detail data necessary to post charges, payments, adjustments, etc., to patient accounting records.

HL7 Attribute Table - FT1 - Financial Transaction Segment

Seq#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
FT1
1	00355	Set ID - FT1			[0..1]	[1..4]			SI
2	00356	Transaction ID			[0..1]	[1..12]			CX
3	00357	Transaction Batch ID			[0..1]	[1..10]			ST
4	00358	Transaction Date	SHALL		[1..1]				DR
5	00359	Transaction Posting Date			[0..1]				DTM
6	00360	Transaction Type	SHALL		[1..1]			0017 Transaction Type	CWE
7	00361	Transaction Code	SHALL		[1..1]			0132	CWE
8	00362	Transaction Description	SHALL NOT	W	[0..0]
9	00363	Transaction Description - Alt	SHALL NOT	W	[0..0]
10	00364	Transaction Quantity		=	[0..1]		6		NM
11	00365	Transaction Amount - Extended			[0..1]				CP
12	00366	Transaction Amount - Unit			[0..1]				CP
13	00367	Department Code			[0..1]			0049	CWE
14	00368	Health Plan ID			[0..1]			0072	CWE
15	00369	Insurance Amount			[0..1]				CP
16	00133	Assigned Patient Location			[0..1]				PL
17	00370	Fee Schedule			[0..1]			0024	CWE
18	00148	Patient Type			[0..1]			0018	CWE
19	00371	Diagnosis Code - FT1			[0..*]			0051	CWE
20	00372	Performed By Code			[0..*]			0084	XCN
21	00373	Ordered By Code			[0..*]				XCN
22	00374	Unit Cost			[0..1]				CP
23	00217	Filler Order Number			[0..1]				EI
24	00765	Entered By Code			[0..*]				XCN
25	00393	Procedure Code			[0..1]				CNE
26	01316	Procedure Code Modifier			[0..*]				CNE
27	01310	Advanced Beneficiary Notice Code			[0..1]			0339 Advanced Beneficiary Notice Code	CWE
28	01646	Medically Necessary Duplicate Procedure Reason			[0..1]			0476	CWE
29	01845	NDC Code			[0..1]			0549	CWE
30	01846	Payment Reference ID			[0..1]				CX
31	01847	Transaction Reference Key			[0..*]	[1..4]			SI
32	02361	Performing Facility			[0..*]				XON
33	02362	Ordering Facility			[0..1]				XON
34	02363	Item Number			[0..1]				CWE
35	02364	Model Number		=	[0..1]		20		ST
36	02365	Special Processing Code			[0..*]				CWE
37	02366	Clinic Code			[0..1]				CWE
38	02367	Referral Number			[0..1]				CX
39	02368	Authorization Number			[0..1]				CX
40	02369	Service Provider Taxonomy Code			[0..1]				CWE
41	01600	Revenue Code			[0..1]			0456 Revenue code	CWE
42	00325	Prescription Number		=	[0..1]		20		ST
43	02370	NDC Qty and UOM			[0..1]				CQ
44	03496	DME Certificate of Medical Necessity Transmission Code			[0..1]				CWE
45	03497	DME Certification Type Code			[0..1]				CWE
46	03498	DME Duration Value			[0..1]				NM
47	03499	DME Certification Revision Date			[0..1]				DT
48	03500	DME Initial Certification Date			[0..1]				DT
49	03501	DME Last Certification Date			[0..1]				DT
50	03502	DME Length of Medical Necessity Days			[0..1]				NM
51	03503	DME Rental Price			[0..1]				MO
52	03504	DME Purchase Price			[0..1]				MO
53	03505	DME Frequency Code			[0..1]				CWE
54	03506	DME Certification Condition Indicator			[0..1]				ID
55	03507	DME Condition Indicator Code			[0..2]				CWE
56	03508	Service Reason Code			[0..1]			0964	CWE

Definition: This field contains the number that identifies this transaction. For the first occurrence of the segment the sequence number shall be 1, for the second occurrence it shall be 2, etc.

Definition: This field contains a number assigned by the sending system for control purposes. The number can be returned by the receiving system to identify errors.

Definition: This field uniquely identifies the batch in which this transaction belongs.

Definition: This field contains the date/time or date/time range of the transaction. For example, this field would be used to identify the date a procedure, item, or test was conducted or used. It may be defaulted to today's date. To specify a single point in time, only the first component is valued. When the second component is valued, the field specifies a time interval during which the transaction took place.

Definition: This field contains the date of the transaction that was sent to the financial system for posting.

Definition: This field contains the code that identifies the type of transaction. Refer to User-defined Table 0017 - Transaction Type in Chapter 2C, Code Tables, for suggested values.

(Definition from FT1.7 in Ch. 6)

Definition: This field contains the code assigned by the institution for the purpose of uniquely identifying the transaction based on the Transaction Type (FT1-6). For example, this field would be used to uniquely identify a procedure, supply item, or test for charges, or to identify the payment medium for payments. Refer to User-defined Table 0132 - Transaction Code in Chapter 2C, Code Tables, for suggested values. See Chapter 7 for a discussion of the universal service ID for charges.

(Definition from ITM.12 in Ch. 17)

Definition: This field contains the code assigned by the institution for the purpose of uniquely identifying a patient billing code specific for a supply item. In the context of this message, this is a code that is a cross-reference to the Item Code/Id. This field would be used to uniquely identify a procedure, supply item, or test for charges; or to identify the payment medium for payments. It can reference, for example, a CBC (a lab charge), or an Elastic Bandage 3'' (supply charge), or Chest 1 View (radiology charge). For instance the code would be 300-0001, with a description of CBC.

Refer to User-defined Table 0132 - Transaction Code in Chapter 2C, Code Tables, for suggested values. See Chapter 7 for a discussion of the universal service ID for charges.

(Definition from PCE.3 in Ch. 17)

Definition: This field contains a code that is used by a billing system to charge for the inventory supply item, the descriptive name of the patient charge for that system (as it may appear on a patient's bill or charge labels) and the name of the coding system that assigned the charge code. Refer to User-defined Table 0132 – Transaction Codes in Chapter 6, Financial Management, for suggested values.

(Definition from IVT.12 in Ch. 17)

Definition: This field contains a code that is used by a billing system to charge for the inventory supply item, the descriptive name of the patient charge for that system (as it may appear on a patient's bill or charge labels) and the name of the coding system that assigned the charge code. Refer to User-defined Table 0132 – Transaction Codes in Chapter 2C, Code Tables, for suggested values.

Attention: FT1-8 was deprecated as of v 2.3 and the detail was withdrawn and removed from the standard as of v 2.6.

Attention: FT1-9 was deprecated as of v 2.3 and the detail was withdrawn and removed from the standard as of v 2.6.

Definition: This field contains the quantity of items associated with this transaction.

Definition: This field contains the amount of a transaction. It may be left blank if the transaction is automatically priced. Total price for multiple items.

(Definition from FT1.12 in Ch. 6)

Definition: This field contains the unit price of a transaction. Price of a single item.

(Definition from ITM.13 in Ch. 17)

Definition: Unit price of transaction. Price of a single item. This field contains the dollar amount charged to patients for this item.

(Definition from PCE.4 in Ch. 17)

Definition: The price that a department charges to a patient for this inventory supply item when using the Patient Charge Billing code present in this segment.

(Definition from IVT.13 in Ch. 17)

Definition: This field contains the dollar amount charged to patients for this single inventory supply item.

Definition: This field contains the department code that controls the transaction code described above. Refer to User-defined Table 0049 - Department Code in Chapter 2C, Code Tables, for suggested values.

(Definition from FT1.14 in Ch. 6)

Definition: This field contains the identifier of the primary insurance plan with which this transaction should be associated. Refer to User-defined Table 0072 - Insurance Plan ID in Chapter 2C, Code Tables, for suggested values.

(Definition from IN1.2 in Ch. 6)

Definition: This field contains a unique identifier for the insurance plan. Refer to User-defined Table 0072 - Insurance Plan ID in Chapter 2C, Code Tables, for suggested values. To eliminate a plan, the plan could be sent with Delete Indication values in each subsequent element. If the respective systems can support it, a Delete Indication value can be sent in the plan field.

The assigning authority for IN1-2, Health Plan ID is assumed to be the Entity named in IN1-3, Insurance Company ID.

(Definition from PM1.1 in Ch. 8)

Definition: This field contains a unique identifier for the insurance plan. Refer to User-defined Table 0072 - Insurance Plan ID in Chapter 2C, Code Tables, for suggested values. To eliminate a plan, the plan could be sent with null values in each subsequent element. If the respective systems can support it, a null value can be sent in the plan field.

The assigning authority for PM1-1, Health Plan ID is assumed to be the Entity named in PM1-2, Insurance Company ID.

Definition: This field contains the amount to be posted to the insurance plan referenced above.

(Definition from PV1.3 in Ch. 3)

Definition: This field contains the patient's initial assigned location or the location to which the patient is being moved. The first component may be the nursing station for inpatient locations, or clinic or department, for locations other than inpatient. For canceling a transaction or discharging a patient, the current location (after the cancellation event or before the discharge event) should be in this field. If a value exists in the fifth component (location status), it supersedes the value in PV1-40 - Bed Status.

(Definition from FT1.16 in Ch. 6)

Definition: This field contains the current patient location. This can be the location of the patient when the charge item was ordered or when the charged service was rendered. For the current assigned patient location, use PV1-3 - Assigned Patient Location.

Definition: This field contains the code used to select the appropriate fee schedule to be used for this transaction posting. Refer to User-defined Table 0024 - Fee Schedule in chapter 2C, Code Tables, for suggested values.

(Definition from PV1.18 in Ch. 3)

Definition: This field contains site-specific values that identify the patient type. Refer to User-defined Table 0018 - Patient Type in Chapter 2C, Code Tables, for suggested values.

(Definition from FT1.18 in Ch. 6)

Definition: This field contains the type code assigned to the patient for this episode of care (visit or stay). Refer to User-defined Table 0018 - Patient Type in Chapter 2C, Code Tables, for suggested values. This is for use when the patient type for billing purposes is different than the visit patient type in PV1-18 - Patient Type.

Definition: This field contains the primary diagnosis code for billing purposes. ICD9-CM is assumed for all diagnosis codes. This is the most current diagnosis code that has been assigned to the patient. ICD10 can also be used. The name of coding system (third component) indicates which coding system is used. Refer to User-defined Table 0051 - Diagnosis Code in Chapter 2C, Code Tables, for suggested values.

Definition: This field contains the composite number/name of the person/group that performed the test/procedure/transaction, etc. This is the service provider. Refer to User-defined Table 0084 - Performed by in Chapter 2C, Code Tables, for suggested values. As of v 2.7, if XCN.1 - ID Number is populated, then the XCN.13 - Identifier Type Code and the XCN.9 - Assigning Authority or XCN.22 - Assigning Jurisdiction or XCN.23 - Assigning Agency or Department are required. If XCN.2 - Family Name is populated, then the XCN.10 - Name Type Code is required. No assumptions can be safely made based on position or sequence. Specification of meaning based on sequence is deprecated.

Definition: This field contains the composite number/name of the person/group that ordered the test/ procedure/transaction, etc. As of v 2.7, if XCN.1 - ID Number is populated, then the XCN.13 - Identifier Type Code and the XCN.9 - Assigning Authority or XCN.22 - Assigning Jurisdiction or XCN.23 - Assigning Agency or Department are required. If XCN.2 - Family Name is populated, then the XCN.10 - Name Type Code is required. No assumptions can be safely made based on position or sequence. Specification of meaning based on sequence is deprecated. .

Definition: This field contains the unit cost of transaction. The cost of a single item.

(Definition from ORC.3 in Ch. 4)

Definition: This field is the order number associated with the filling application. It is a case of the Entity Identifier data type (Section 2.A.28). Its first component is a string that identifies an order detail segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filler (receiving) application. This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.

The second through fourth components contain the filler application ID, in the form of the HD data type (see Section 2.A.36, "HD – hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.

A given institution or group of intercommunicating institutions should establish a list of applications that may be potential placers and fillers of orders and assign each a unique application ID. The application ID list becomes one of the institution's master dictionary lists that is documented in Chapter 8. Since third- party applications (those other than the placer and filler of an order) can send and receive ORM and ORR messages, the filler application ID in this field may not be the same as any sending and receiving application on the network (as identified in the MSH segment).

The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.

From that perspective each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.

If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). Note that if both ORC-2 and OBR-2 are valued, then they must be valued the same; as well, if both ORC-3 and OBR-3 are valued, then they must be valued the same. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments. It is recommended that the initiating system should provide a unique number for the placer order number when a new order is placed or a unique number for the filler order number when an unsolicited result is initially communicated.

The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.

Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.

(Definition from OBR.3 in Ch. 4)

Definition: This field is the order number associated with the filling application. This is a permanent identifier for an order and its associated observations. It is a special case of the Entity Identifier data type (see Chapter 2, section 2.A.28, "EI – entity identifier").

The first component is a string that identifies an individual order segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filling (receiving) application. It identifies an order uniquely among all orders from a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.

The second through fourth components contain the filler application ID, in the form of the HD data type (see section 2.A.36, "HD – hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.

See ORC-3-filler order number for information on when this field must be valued.

The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.

From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.

If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.

It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.

The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.

Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.

(Definition from FT1.23 in Ch. 6)

Definition: This field is used when the billing system is requesting observational reporting justification for a charge. This is the number used by a filler to uniquely identify a result. See Chapter 4 for a complete description.

(Definition from OBR.3 in Ch. 7)

Definition: This field is the order number associated with the filling application. This is a permanent identifier for an order and its associated observations. It is a special case of the Entity Identifier data type (see Chapter 2, section 2.A.28, "EI – entity identifier").

The first component is a string that identifies an individual order segment (i.e., ORC segment and associated order detail segment). It is assigned by the order filling (receiving) application. It identifies an order uniquely among all orders from a particular filling application (e.g., clinical laboratory). This uniqueness must persist over time.

The second through fourth components contain the filler application ID, in the form of the HD data type (see section 2.A.36, "HD – hierarchic designator"). The second component is a user-defined coded value that uniquely defines the application from other applications on the network. A limit of six (6) characters is suggested but not required. The second component of the filler order number always identifies the actual filler of an order.

See ORC-3-filler order number for information on when this field must be valued.

The conditions which make this field required are divided into two main issues. The data in ORC-2 and OBR-2 are logically the same thing: a placer id. The data in ORC-3 and OBR-3 are logically the same thing: the filler id.

From that perspective, each message must have either a placer or a filler id with an exception for the case of a "Send Number" control code since its purpose is to request a placer id.

If both ORC and OBR are present in a message, then only one of the Segments must contain the value(s). If both segments contain either ORC-2/OBR-2 or ORC-3/OBR-3, then each pair must be a matching pair. The sending system can include both the filler and the placer number in both the ORC and OBR segments as long as the data is the same between the two segments.

It is recommended that the initiating system should provide a unique number when a new order or unsolicited result is initially communicated.

The filler order number (OBR-3 or ORC-3) also uniquely identifies an order and its associated observations. For example, suppose that an institution collects observations from several ancillary applications into a common database and this common database is queried by yet another application for observations. In this case, the filler order number and placer order number transmitted by the common database application would be that of the original filler and placer, respectively, rather than a new one assigned by the common database application.

Similarly, if a third-party application, not the filler or placer, of an order were authorized to modify the status of an order (say, cancel it), the third-party application would send the filler an ORM message containing an ORC segment with ORC-1-order control equal to "CA" and containing the original placer order number and filler order number, rather than assign either itself.

(Definition from TXA.15 in Ch. 9)

Definition: This field is the order number associated with the filling application. Where a transcription service or similar organization creates the document and uses an internally unique identifier, that number should be inserted in this field. Its first component is a string of characters that identifies an order detail segment (i.e., OBR). This string must uniquely identify the order (as specified in the order detail segment) from other orders in a particular filling application (i.e., transcription service). This uniqueness must persist over time. Where a number is reused over time, a date can be affixed to the non-unique number to make it unique.

The second through fourth components contains the (filler) assigning authority. The (filler) assigning authority is a string of characters that uniquely defines the application from other applications on the network. The second through fourth components of the filler order number always identify the actual filler of an order.

TXA-15 - Condition: If corresponding ORC and/or OBR segments are present in the message and ORC-3 or OBR-3 is valued, this field must be blank. If TXA-14 is valued while ORC-3 or OBR-3 is valued it shall be ignored. See message definitions including TXA for further guidanceon which ORC/OBR pairs to consider.

For further details, please see the definitions provided in Chapter 4, "Orders".

(Definition from ARQ.25 in Ch. 10)

Definition: This field is the order number assigned by the filler application for the order associated with this scheduling request.

This field is described in detail in Chapter 4, section 4.5.1.3, "ORC-3 – Filler Order Number.” It is conditionally mandatory depending on the presence of the Placer order number (ARQ-24 – Placer Order Number). This conditionally mandatory requirement addresses the concern that a Scheduling system cannot and should not create or fill an order. Therefore, an order must have been accepted by the filler application before scheduling the resources associated with that order.

(Definition from SCH.27 in Ch. 10)

Definition: This field is the order number assigned by the filler application for the order associated with this scheduling filler response.

This field is described in detail in Chapter 4, Orders, section 4.5.1.3. It is conditionally mandatory depending on the presence of the placer order number (section 10.6.2.26). This conditionally mandatory requirement addresses the concern that a Scheduling system cannot and should not create or fill an order. Therefore, an order must have been accepted by the order filler application before scheduling the resources associated with that order.

Definition: This field identifies the composite number/name of the person who entered the insurance information.

(Definition from OBR.44 in Ch. 4)

Definition: This field contains a unique identifier assigned to the procedure, if any, associated with the charge. Refer to Externally-defined table 0088 – Procedure code in Chapter 2C, Code Tables, for suggested values. This field is a coded data type for compatibility with clinical and ancillary systems.

As of version 2.6, applicable external coding systems include those in the referenced table. If the code set used is in the referenced table, then the coding scheme designation in the table shall be used.

(Definition from FT1.25 in Ch. 6)

Definition: This field contains a unique identifier assigned to the procedure, if any, associated with the charge. Refer to Externally-defined Table 0088 - Procedure Code in Chapter 2C, Code Tables, for suggested values. This field is a coded data type for compatibility with clinical and ancillary systems.

As of v 2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.

Procedure Code Coding Systems (from HL7 Table 0396)

Code	Description	Comment / Source
C4	CPT-4	American Medical Association, P.O. Box 10946, Chicago IL 60610.
C5	CPT-5	(under development – same contact as above)
HCPCS	CMS (formerly HCFA) Common Procedure Coding System	HCPCS: contains codes for medical equipment, injectable drugs, transportation services, and other services not found in CPT4.
HPC	CMS (formerly HCFA )Procedure Codes (HCPCS)	Health Care Financing Administration (HCFA) Common Procedure Coding System (HCPCS) including modifiers.
I10P	ICD-10 Procedure Codes	Procedure Coding System (ICD-10-PCS.) See http://www/hcfa.gov/stats/icd10.icd10.htm for more information.

(Definition from PR1.3 in Ch. 6)

Definition: This field contains a unique identifier assigned to the procedure. Refer to Externally-defined Table 0088 - Procedure Code in Chapter 2C, Code Tables, for suggested values. This field is a CNE data type for compatibility with clinical and ancillary systems.

(Definition from OBR.44 in Ch. 7)

Definition: This field contains a unique identifier assigned to the procedure, if any, associated with the charge. Refer to Externally-defined table 0088 – Procedure code in Chapter 2C, Code Tables, for suggested values. This field is a coded data type for compatibility with clinical and ancillary systems.

As of version 2.6, applicable external coding systems include those in the referenced table. If the code set used is in the referenced table, then the coding scheme designation in the table shall be used.

(Definition from CDM.7 in Ch. 8)

Definition: This field contains the procedure code for procedure, if any, associated with this charge description. Repeating field allows for different procedure coding systems such as CPT4, ICD9. Coded entry made up of code plus coding schema. Refer to Externally-defined Table 0088 - Procedure Code in Chapter 2C, Code Tables, for suggested values.

(Definition from IIM.14 in Ch. 17)

Definition: This field contains a unique identifier assigned to the service item, if any, associated with the charge. In the United States this is often the HCPCS code. Refer to Externally Defined Table 0088 - Procedure Code in Chapter 2C, Code Tables, for suggested values. This field is a CNE data type for compatibility with clinical and ancillary systems.

As of v2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.

Procedure Code Coding Systems

Coding System	Description	Comment
C4	CPT-4	American Medical Association, P.O. Box 10946, Chicago IL 60610.
C5	CPT-5	(under development – same contact as above)
HCPCS	CMS (formerly HCFA) Common Procedure Coding System	HCPCS: contains codes for medical equipment, injectable drugs, transportation services, and other services not found in CPT4.
HPC	CMS (formerly HCFA) Procedure Codes (HCPCS)	Health Care Financing Administration (HCFA) Common Procedure Coding System (HCPCS) including modifiers.

(Definition from ITM.27 in Ch. 17)

Definition: This field contains a unique identifier assigned to the service item, if any, associated with the charge. In the United States this is often the HCPCS code. Refer to Externally defined Table 0088 - Procedure code for suggested values. This field is a CNE data type for compatibility with clinical and ancillary systems. Refer to HL7 Table 0088 – Procedure Coding Systems in Chapter 2C, Code Tables, for valid values.

As of v2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.

(Definition from SCD.32 in Ch. 17)

Definition: The unique identifier indicating the type of procedure performed on the patient with the supplies being sterilized.

Refer to HL7 Table 0088 – Procedure Code in Chapter 2C, Code Tables, for suggested values.

As of v2.6, the known applicable external coding systems include those in the referenced table. If the code set you are using is in this table, then you must use that designation.

(Definition from OBR.45 in Ch. 4)

Definition: This field contains the procedure code modifier to the procedure code reported in OBR-44-procedure code, when applicable. Procedure code modifiers are defined by regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. The modifiers are sequenced in priority according to user entry. In the USA, this is a requirement of the UB and the 1500 claim forms. Multiple modifiers are allowed and the order placed on the form affects reimbursement. Refer to Externally- defined table 0340 – Procedure code modifier in Chapter 2C, Code Tables, for suggested values.

Usage Rule: This field can only be used if OBR-44 – procedure code contains certain procedure codes that require a modifier in order to be billed or performed. For example, HCPCS codes that require a modifier to be precise.

As of version 2.6, applicable external coding systems include those in the referenced table. If the code set used is in the referenced table, then the coding scheme designation in the table shall be used.

(Definition from FT1.26 in Ch. 6)

Definition: This field contains the procedure code modifier to the procedure code reported in FT1-25 - Procedure Code, when applicable. Procedure code modifiers are defined by regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. The modifiers are sequenced in priority according to user entry. This is a requirement of the UB and the 1500 claim forms. Multiple modifiers are allowed and the order placed on the form affects reimbursement. Refer to Externally-defined Table 0340 - Procedure Code Modifier in Chapter 2C, Code Tables, for suggested values.

Usage Rule: This field can only be used if FT1-25 - Procedure Code contains certain procedure codes that require a modifier in order to be billed or performed. For example, HCPCS codes that require a modifier to be precise.

As of v 2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.

Procedure Code Modifier Coding Systems (From HL7 Table 0396)

Code	Description	Comment / Source
CPTM	CPT Modifier Code	Available for the AMA at the address listed for CPT above. These codes are found in Appendix A of CPT 2000 Standard Edition. (CPT 2000 Standard Edition, American Medical Association, Chicago, IL).
HPC	CMS (formerly HCFA )Procedure Codes (HCPCS)	Health Care Financing Administration (HCFA) Common Procedure Coding System (HCPCS) including modifiers.
I10P	ICD-10 Procedure Codes	Procedure Coding System (ICD-10-PCS.) See http://www/hcfa.gov/stats/icd10.icd10.htm for more information.
I9C	ICD-9CM	Commission on Professional and Hospital Activities, 1968 Green Road, Ann Arbor, MI 48105 (includes all procedures and diagnostic tests).
ICD10AM	ICD-10 Australian modification
ICD10CA	ICD-10 Canada

(Definition from PR1.16 in Ch. 6)

Definition: This field contains the procedure code modifier to the procedure code reported in field 3, when applicable. Procedure code modifiers are defined by regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. Refer to Externally-defined Table 0340 - Procedure Code Modifier in Chapter 2C, Code Tables, for suggested values.

(Definition from OBR.45 in Ch. 7)

Definition: This field contains the procedure code modifier to the procedure code reported in OBR-44-procedure code, when applicable. Procedure code modifiers are defined by regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. The modifiers are sequenced in priority according to user entry. In the USA, this is a requirement of the UB and the 1500 claim forms. Multiple modifiers are allowed and the order placed on the form affects reimbursement. Refer to Externally- defined table 0340 – Procedure code modifier in Chapter 2C, Code Tables, for suggested values.

Usage Rule: This field can only be used if OBR-44 – procedure code contains certain procedure codes that require a modifier in order to be billed or performed. For example, HCPCS codes that require a modifier to be precise.

As of version 2.6, applicable external coding systems include those in the referenced table. If the code set used is in the referenced table, then the coding scheme designation in the table shall be used.

(Definition from IIM.15 in Ch. 17)

Definition: This field contains the procedure code modifier to the procedure code reported in IIM-14 Procedure Code, when applicable. Procedure code modifiers are defined by USA regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. Refer to Externally defined Table 0340 - Procedure Code Modifier in Chapter 2C, Code Tables, for suggested values.

As of v2.6, the known applicable external coding systems include those in the table below. If the code set you are using is in this table, then you must use that designation.

(Definition from ITM.28 in Ch. 17)

Definition: This field contains the procedure code modifier to the procedure code reported in ITM-27, Procedure Code, when applicable. Procedure code modifiers are defined by USA regulatory agencies such as CMS and the AMA. Multiple modifiers may be reported. Refer to Externally-defined Table 0340 - Procedure Code Modifier in Chapter 2C, Code Tables, for suggested values.

(Definition from ORC.20 in Ch. 4)

Definition: This field indicates the status of the patient's or the patient's representative's consent for responsibility to pay for potentially uninsured services. This element is introduced to satisfy CMS Medical Necessity requirements for outpatient services. This element indicates (a) whether the associated diagnosis codes for the service are subject to medical necessity procedures, (b) whether, for this type of service, the patient has been informed that they may be responsible for payment for the service, and (c) whether the patient agrees to be billed for this service. The values for this field are drawn from User-Defined Table 0339 – Advanced Beneficiary Notice Code in Chapter 2C, Code Tables.

(Definition from FT1.27 in Ch. 6)

Definition: This field indicates the status of the patient's or the patient's representative's consent for responsibility to pay for potentially uninsured services. This element is introduced to satisfy CMS Medical Necessity requirements for outpatient services. This element indicates (a) whether the associated diagnosis codes for the service are subject to medical necessity procedures, (b) whether, for this type of service, the patient has been informed that they may be responsible for payment for the service, and (c) whether the patient agrees to be billed for this service. Refer to User-defined Table 0339 - Advanced Beneficiary Notice Code in Chapter 2C, Code Tables, for suggested values.

(Definition from OBR.48 in Ch. 4)

Definition: This field is used to document why the procedure found in OBR-44 - Procedure Code is a duplicate of one ordered/charged previously for the same patient within the same date of service and has been determined to be medically necessary. The reason may be coded or it may be a free text entry.

This field is intended to provide financial systems information on who to bill for duplicate procedures.

Refer to User-Defined Table 0476 – Medically Necessary Duplicate Procedure Reason in Chapter 2C, Code Tables, for suggested values.

(Definition from FT1.28 in Ch. 6)

Definition: This field is used to document why the procedure found in FT1-25 - Procedure Code is a duplicate of one ordered/charged previously for the same patient within the same date of service and has been determined to be medically necessary. The reason may be coded or it may be a free text entry. This field is intended to provide financial systems information on who to bill for duplicate procedures. Refer to User-Defined Table 0476 – Medically Necessary Duplicate Procedure Reason in Chapter 2C, Code Tables, for suggested values.

(Definition from OBR.48 in Ch. 7)

Definition: This field is used to document why the procedure found in OBR-44 - Procedure Code is a duplicate of one ordered/charged previously for the same patient within the same date of service and has been determined to be medically necessary. The reason may be coded or it may be a free text entry.

This field is intended to provide financial systems information on who to bill for duplicate procedures.

Refer to User-Defined Table 0476 – Medically Necessary Duplicate Procedure Reason in Chapter 2C, Code Tables, for suggested values.

Definition: This field has been defined for NDC codes that are required by HIPAA for electronic claims for Pharmacy charges. Refer to Externally-defined Table 0549- NDC Codes in Chapter 2C, Code Tables, for suggested values.

If a system supports multiple NDC codes for a charge, this information will be sent in OBX segments. FT1-29 and FT1-43 can be used for single NDC codes and quantities instead of using OBX.

Definition: The payment reference number of the payment medium reported in FT1-7 - Transaction Code.

Definition: The reference key linking the payment to the corresponding charge in an e-claim. This field should contain the FT1-1 - Set ID FT1 that identifies the charge corresponding to the payment. This field is repeating to allow a payment to be posted against multiple charges.

Definition: This field contains the name of the Facility where the service is performed by the Provider Person/Group identified in FT1-20 – Performed By Code.

Definition: This field contains the name of the Facility where the service is ordered by the Ordering Provider/Group identified in FT1-21 – Ordered By Code.

Definition: This field contains the Item Number for a product. If valued, this field will override the value in the Service Catalog. Item Number (along with Model Number) can be seen as a supplemental number for specific equipment or inventory-related charges.

Definition: This field contains the Model Number for a product. If valued, this field will override the value in the Service Catalog. Model Number (along with Item Number) can be seen as a supplemental number for specific equipment or inventory-related charges.

Definition: This field contains a Special Processing Code that is available in reimbursement expressions. If valued, this field will override the value in the Service Catalog.

Definition: This field contains the state specific or payer specific type of service or place of service.

Definition: This field contains the Referral Number associated with the charge.

Definition: This field contains an authorization number assigned to the referral charge.

Definition: This field contains the Taxonomy code for the Service Provider. It allows the provider to identify their specialty category for the particular service.

(Definition from FT1.41 in Ch. 6)

Definition: This field contains the Revenue Code for the charge. If valued, this field will override the value in the Service Catalog. Refer to User-defined Table 0456 – Revenue Code in Chapter 2C, Code Tables, for suggested values.

(Definition from GP1.2 in Ch. 6)

Definition: This field is the same as UB92 Form Locator 42 "Revenue Code". Refer to User-defined Table 0456 - Revenue Code in Chapter 2C, Code Tables, for suggested values. This field identifies revenue codes that are not linked to a HCPCS/CPT code. It is used for claiming for non-medical services such as telephone, TV or cafeteria charges, etc. There can be many per visit or claim. This field is defined by CMS or other regulatory agencies.

There can also be a revenue code linked to a HCPCS/CPT code. These are found in GP2-1 - Revenue Code. Refer to UB92 specifications.

(Definition from GP2.1 in Ch. 6)

Definition: This field identifies a specific ancillary service for each HCPC/CPT This field is the same as UB92 Form Locator 42 "Revenue Code". Refer to User-defined Table 0456 - Revenue Code in Chapter 2C, Code Tables, for suggested values. This field is defined by CMS or other regulatory agencies.

(Definition from RXE.15 in Ch. 4A)

Definition: This field contains the prescription number as assigned by the pharmacy or treatment application. Equivalent in uniqueness to the pharmacy/treatment filler order number. At some sites, this may be the pharmacy or treatment system (internal) sequential form. At other sites, this may be an external form. This is a required field in RXE when used in pharmacy/treatment messages, but it is not required when used in product experience messages (see Chapter 7).

(Definition from RXD.7 in Ch. 4A)

Definition: This field is equivalent in uniqueness to the pharmacy/treatment supplier filler order number. At some sites, this may be the pharmacy/treatment supplier (internal) sequential form. At other sites, this may be an external number.

(Definition from FT1.42 in Ch. 6)

Definition: This field contains the prescription number as assigned by the pharmacy or treatment application. Equivalent in uniqueness to the pharmacy/treatment filler order number. At some sites, this may be the pharmacy or treatment system (internal) sequential form. At other sites, this may be an external form.

Definition: This field contains the Drug Code Quantity and the Units of Measurement for the corresponding NDC-Code in FT1-29 – NDC Code.

Definition: This code defines the timing, transmission method, or format by which a DME Certificate of Medical Necessity report is to be sent for the service.

For the US realm, the ANSI ASC X12 PWK DMERC CMN Indicator Segment, reference element PWK02, listed below is suggested to map to the X12 837 values:

AB	Previously Submitted to Payer
AD	Certification Included in this Claim
AF	Narrative Segment Included in this Claim
AG	No Documentation is Required
NS	Not Specified

Definition: This code identifies the type of certification for the durable medical equipment service.

For the US realm, the ANSI ASC X12 CR3 Durable Medical Equipment Certification Segment, reference element CR301, listed below is suggested to map to the X12 837 values:

I	Initial
R	Renewal
S	Revised

Definition: This is the length of time, in months, the durable medical equipment is needed.

Definition: This is the durable medical equipment certification revision/recertification date. It is required when the DME Certification Type Code is set to Renewal or Revised.

Definition: This is durable medical equipment initial certification date. It is used to indicate the beginning of therapy and the DME Certification Type Code is set to Initial.

Definition: This is the durable medical equipment last certification date. This is required if it is necessary to include supporting documentation in an electronic form for Medicare DMERC claims for which the provider is required to obtain a Certificate of Medical Necessity (CMN) from the physician.

Definition: This is the length of duration, in days, of medical necessity for the purchased or rental durable medical equipment service.

Definition: This is the rental price of the durable medical equipment.

Definition: This is the purchase price for the durable medical equipment.

Definition: This is the frequency or type of payment for the rental of durable medical equipment.

For the US realm, the ANSI ASC X12 SV5 Durable Medical Equipment Service Segment, reference element SV506, listed below is suggested to map to the X12 837 values:

1	Weekly
4	Monthly
6	Daily

Definition: This field indicates if the DME Condition Codes apply to the service. Refer to HL7 Table 0136 - Yes/no Indicator for valid values. A "Y" value indicates the condition codes apply. An "N" value indicates the condition codes do not apply.

Definition: This the condition indicator code for durable medical equipment. It is used on the claim service line when this information is necessary for adjudication. Two occurrences are supported.

For the US realm, the ANSI ASC X12 CRC DMERC Condition Indicator Segment, reference element CRC03, listed below is suggested to map to the X12 837 values:

38	Certification signed by the physician is on file at the supplier’s office
ZV	Replacement Item

Definition: This field contains the reason why the service has been performed. Refer to User-defined Table HL70964 –Service Reason Code for suggested values.

The DG1 segment contains patient diagnosis information of various types, for example, admitting, primary, etc. The DG1 segment is used to send multiple diagnoses (for example, for medical records encoding). It is also used when the FT1-19 - Diagnosis Code - FT1 does not provide sufficient information for a billing system. This diagnosis coding should be distinguished from the clinical problem segment used by caregivers to manage the patient (see Chapter 12, Patient Care). Coding methodologies are also defined.

HL7 Attribute Table - DG1 - Diagnosis Segment

Seq#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
DG1
1	00375	Set ID - DG1	SHALL		[1..1]	[1..4]			SI
2	00376	Diagnosis Coding Method	SHALL NOT	W	[0..0]
3	00377	Diagnosis Code - DG1	SHALL		[1..1]			0051	CWE
4	00378	Diagnosis Description	SHALL NOT	W	[0..0]
5	00379	Diagnosis Date/Time			[0..1]				DTM
6	00380	Diagnosis Type	SHALL		[1..1]			0052 Diagnosis Type	CWE
7	00381	Major Diagnostic Category	SHALL NOT	W	[0..0]			0118	CNE
8	00382	Diagnostic Related Group	SHALL NOT	W	[0..0]			0055	CNE
9	00383	DRG Approval Indicator	SHALL NOT	W	[0..0]			0136 Yes/no Indicator	ID
10	00384	DRG Grouper Review Code	SHALL NOT	W	[0..0]			0056	CWE
11	00385	Outlier Type	SHALL NOT	W	[0..0]			0083 Outlier Type	CWE
12	00386	Outlier Days	SHALL NOT	W	[0..0]				NM
13	00387	Outlier Cost	SHALL NOT	W	[0..0]				CP
14	00388	Grouper Version And Type	SHALL NOT	W	[0..0]
15	00389	Diagnosis Priority		=	[0..1]		2	0359 Diagnosis Priority	NM
16	00390	Diagnosing Clinician			[0..*]				XCN
17	00766	Diagnosis Classification			[0..1]			0228 Diagnosis Classification	CWE
18	00767	Confidential Indicator			[0..1]	[1..1]		0136 Yes/no Indicator	ID
19	00768	Attestation Date/Time			[0..1]				DTM
20	01850	Diagnosis Identifier	MAY True: False:	C	[1..1] [0..1]				EI
21	01894	Diagnosis Action Code	MAY True: False:	C	[1..1] [0..1]	[1..1]		0206 Segment Action Code	ID
22	02152	Parent Diagnosis	MAY True: False:	C	[1..1] [0..1]				EI
23	02153	DRG CCL Value Code			[0..1]			0728 CCL Value	CWE
24	02154	DRG Grouping Usage			[0..1]	[1..1]		0136 Yes/no Indicator	ID
25	02155	DRG Diagnosis Determination Status			[0..1]			0731 DRG Diagnosis Determination Status	CWE
26	02288	Present On Admission			[0..1]			0895 Present On Admission (POA) Indicator	CWE

Definition: This field contains the number that identifies this transaction. For the first occurrence of the segment the sequence number shall be 1, for the second occurrence it shall be 2, etc.

Attention: DG1-2 was deprecated as of v 2.3 and the detail was withdrawn and removed from the standard as of v 2.6 .

Definition: DG1-3 - Diagnosis Code - DG1 contains the diagnosis code assigned to this diagnosis. Refer to User-defined Table 0051 - Diagnosis Code in Chapter 2C, Code Tables, for suggested values. This field is a CWE data type for compatibility with clinical and ancillary systems. Either DG1-3.1-Identifier or DG1-3.2-Text is required. When a code is used in DG1-3.1-Identifier, a coding system is required in DG1-3.3-Name of Coding System.

Names of various diagnosis coding systems are listed in Chapter 2, Section 2.16.4, "Coding system table."

Attention: DG1-4 was deprecated as of v 2.3 and the detail was withdrawn and removed from the standard as of v 2.6.

Definition: This field contains the date/time that the diagnosis was determined.

Definition: This field contains a code that identifies the type of diagnosis being sent. Refer to User-defined Table 0052 - Diagnosis Type in Chapter 2C, Code Tables, for suggested values. This field should no longer be used to indicate "DRG" because the DRG fields have moved to the new DRG segment.

(Definition from DG1.7 in Ch. 6)

Attention: DG1-7 was deprecated as of v 2.3 and the detail was withdrawn and removed from the standard as of v 2.6 .

(Definition from DMI.2 in Ch. 8)

Definition: This field indicates the determined Major Diagnostic Category (MDC) value. Refer to External Table 0118 – Major Diagnostic Category in Chapter 2C, Code Tables, for suggested values.

(Definition from DG1.8 in Ch. 6)

Attention: DG1-8 was deprecated as of v 2.3 and the detail was withdrawn and removed from the standard as of v 2.6.

(Definition from DRG.1 in Ch. 6)

Definition: This field contains the DRG for the transaction. Interim DRG's could be determined for an encounter. Refer to Externally-defined Table 0055 – Diagnosis Related Group in Chapter 2C, Code Tables, for suggested values.

(Definition from DMI.1 in Ch. 8)

Definition: This field contains the DRG for the transaction. Interim DRG's could be determined for an encounter. Refer to External Table 0055 – Diagnosis Related Group in Chapter 2C, Code Tables, for suggested values.

(Definition from DG1.9 in Ch. 6)

Attention: DG1-9 was deprecated as of v 2.3 and the detail was withdrawn and removed from the standard as of v 2.6

(Definition from DRG.3 in Ch. 6)

Definition: This field indicates if the DRG has been approved by a reviewing entity. Refer to HL7 Table 0136 - Yes/no Indicator for valid values.

• Y    the DRG has been approved by a reviewing entity

• N    the DRG has not been approved

(Definition from DG1.10 in Ch. 6)

Attention: DG1-10 was deprecated as of v 2.3 and the detail was withdrawn and removed from the standard as of v 2.6

(Definition from DRG.4 in Ch. 6)

Definition: This code indicates that the grouper results have been reviewed and approved. Refer to User-defined Table 0056 - DRG Grouper Review Code in Chapter 2C, Code Tables, for suggested values.

(Definition from DG1.11 in Ch. 6)

Attention: DG1-11 was deprecated as of v 2.3 and the detail was withdrawn and removed from the standard as of v 2.6

(Definition from DRG.5 in Ch. 6)

Definition: Refers to the type of outlier (i.e., period of care beyond DRG-standard stay in facility) that has been paid. Refer to User-defined Table 0083 - Outlier Type in Chapter 2C, code Tables, for suggested values.

(Definition from DG1.12 in Ch. 6)

Attention: DG1-12 was deprecated as of v 2.3 and the detail was withdrawn and removed from the standard as of v 2.6

(Definition from DRG.6 in Ch. 6)

Definition: This field contains the number of days that have been approved as an outlier payment.

(Definition from DG1.13 in Ch. 6)

Attention: DG1-13 was deprecated as of v 2.3 and the detail was withdrawn and removed from the standard as of v 2.6

(Definition from DRG.7 in Ch. 6)

Definition: This field contains the amount of money that has been approved for an outlier payment.

(Definition from GP1.5 in Ch. 6)

Definition: This field contains the amount that exceeds the outlier limitation as defined by APC regulations. This field is analogous to DRG-7 - Outlier Cost; however, the definition in this field note supersedes the DRG-7 definition.

Attention: DG1-14 was deprecated as of v 2.3 and the detail was withdrawn and removed from the standard as of v 2.6

Definition: This field contains the number that identifies the significance or priority of the diagnosis code. Refer to HL7 Table 0359 - Diagnosis Priority in Chapter 2C, Code Tables, for suggested values.

Note: As of v 2.7, the data type has been changed to numeric. The meaning of the values remains the same as those in HL7 Table 0418 – Procedure Priority, The value 0 conveys that this procedure is not included in the ranking. The value 1 means that this is the primary procedure. Values 2-99 convey ranked secondary procedures.

Definition: This field contains the individual responsible for generating the diagnosis information. As of v 2.7, if XCN.1 - ID Number is populated, then the XCN.13 - Identifier Type Code and the XCN.9 - Assigning Authority or XCN.22 - Assigning Jurisdiction or XCN.23 - Assigning Agency or Department are required. If XCN.2 - Family Name is populated, then the XCN.10 - Name Type Code is required. No assumptions can be safely made based on position or sequence. Specification of meaning based on sequence is deprecated.

Definition: This field indicates if the patient information is for a diagnosis or a non-diagnosis code. Refer to User-defined Table 0228 - Diagnosis Classification in Chapter 2C, Code Tables, for suggested values.

(Definition from DG1.18 in Ch. 6)

Definition: This field indicates whether the diagnosis is confidential. Refer to HL7 Table 0136 - Yes/no Indicator in Chapter 2C, "Code Tables", for valid values.

• Y    the diagnosis is a confidential diagnosis

• N    the diagnosis does not contain a confidential diagnosis

(Definition from DRG.10 in Ch. 6)

Definition: This field indicates if the DRG contains a confidential diagnosis. Refer to HL7 Table 0136 - Yes/no Indicator in Chapter 2C, Code Tables, for valid values.

• Y    the DRG contains a confidential diagnosis

• N    the DRG does not contain a confidential diagnosis

Definition: This field contains the time stamp that indicates the date and time that the attestation was signed.

Definition: This field contains a value that uniquely identifies a single diagnosis for an encounter. It is unique across all segments and messages for an encounter. This field is required in all implementations employing Update Diagnosis/Procedures (P12) messages.

Definition: This field defines the action to be taken for this diagnosis. Refer to HL7 Table 0206 - Segment Action Code in Chapter 2C, "Code Tables", for valid values. This field is required for the update diagnosis/procedures (P12) message. In all other events it is optional.

Definition: This field contains the entity identifier for the parent diagnosis. This field links the "current" manifestation diagnosis ("*") to the entity identifier of the "parent" etiological diagnosis ("+").

Definition: This field indicates the CCL value for the determined DRG for this diagnosis. Refer to Externally-defined Table 0728 - CCL Value in Chapter 2C, Code Tables, for suggested values.

Definition: This field identifies whether this particular diagnosis has been used for the DRG determination. Refer to HL7 Table 0136 – Yes/No Indicator in Chapter 2C, Code Tables, for suggested values. The values have the following meaning for this field:

Y    Yes - Indicates that the diagnosis has been used for the DRG determination

N    No – Indicates that the diagnosis has not been used for the DRG determination

Definition: This field contains the status of this particular diagnosis for the DRG determination. Refer to User-defined Table 0731 – DRG Diagnosis Determination Status in Chapter 2C, Code Tables, for suggested values.

Definition: This field contains the present on admission indicator for this particular diagnosis. US reimbursement formulas for some states and Medicare have mandated that each diagnosis code be flagged as to whether it was present on admission or not. Refer to User-defined Table 0895 – Present On Admission (POA) Indicator in Chapter 2C, Code Tables, for suggested values.

The DRG segment contains diagnoses-related grouping information of various types. The DRG segment is used to send the DRG information, for example, for billing and medical records encoding.

HL7 Attribute Table - DRG - Diagnosis Related Group Segment

Seq#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
DRG
1	00382	Diagnostic Related Group			[0..1]			0055	CNE
2	00769	DRG Assigned Date/Time			[0..1]				DTM
3	00383	DRG Approval Indicator			[0..1]			0136 Yes/no Indicator	ID
4	00384	DRG Grouper Review Code			[0..1]			0056	CWE
5	00385	Outlier Type			[0..1]			0083 Outlier Type	CWE
6	00386	Outlier Days			[0..1]				NM
7	00387	Outlier Cost			[0..1]				CP
8	00770	DRG Payor			[0..1]			0229 DRG Payor	CWE
9	00771	Outlier Reimbursement			[0..1]				CP
10	00767	Confidential Indicator			[0..1]	[1..1]		0136 Yes/no Indicator	ID
11	01500	DRG Transfer Type			[0..1]			0415 Transfer Type	CWE
12	02156	Name of Coder			[0..1]				XPN
13	02157	Grouper Status			[0..1]			0734 Grouper Status	CWE
14	02158	PCCL Value Code			[0..1]			0728 CCL Value	CWE
15	02159	Effective Weight		#	[0..1]		5		NM
16	02160	Monetary Amount			[0..1]				MO
17	02161	Status Patient			[0..1]			0739 DRG Status Patient	CWE
18	02162	Grouper Software Name		#	[0..1]		100		ST
19	02282	Grouper Software Version		#	[0..1]		100		ST
20	02163	Status Financial Calculation			[0..1]			0742 DRG Status Financial Calculation	CWE
21	02164	Relative Discount/Surcharge			[0..1]				MO
22	02165	Basic Charge			[0..1]				MO
23	02166	Total Charge			[0..1]				MO
24	02167	Discount/Surcharge			[0..1]				MO
25	02168	Calculated Days		=	[0..1]		5		NM
26	02169	Status Gender			[0..1]			0749 DRG Grouping Status	CWE
27	02170	Status Age			[0..1]			0749 DRG Grouping Status	CWE
28	02171	Status Length of Stay			[0..1]			0749 DRG Grouping Status	CWE
29	02172	Status Same Day Flag			[0..1]			0749 DRG Grouping Status	CWE
30	02173	Status Separation Mode			[0..1]			0749 DRG Grouping Status	CWE
31	02174	Status Weight at Birth			[0..1]			0755 Status Weight At Birth	CWE
32	02175	Status Respiration Minutes			[0..1]			0757 DRG Status Respiration Minutes	CWE
33	02176	Status Admission			[0..1]			0759 Status Admission	CWE

(Definition from DG1.8 in Ch. 6)

Attention: DG1-8 was deprecated as of v 2.3 and the detail was withdrawn and removed from the standard as of v 2.6.

(Definition from DRG.1 in Ch. 6)

Definition: This field contains the DRG for the transaction. Interim DRG's could be determined for an encounter. Refer to Externally-defined Table 0055 – Diagnosis Related Group in Chapter 2C, Code Tables, for suggested values.

(Definition from DMI.1 in Ch. 8)

Definition: This field contains the DRG for the transaction. Interim DRG's could be determined for an encounter. Refer to External Table 0055 – Diagnosis Related Group in Chapter 2C, Code Tables, for suggested values.

Definition: This field contains the time stamp to indicate the date and time that the DRG was assigned.

(Definition from DG1.9 in Ch. 6)

Attention: DG1-9 was deprecated as of v 2.3 and the detail was withdrawn and removed from the standard as of v 2.6

(Definition from DRG.3 in Ch. 6)

Definition: This field indicates if the DRG has been approved by a reviewing entity. Refer to HL7 Table 0136 - Yes/no Indicator for valid values.

• Y    the DRG has been approved by a reviewing entity

• N    the DRG has not been approved

(Definition from DG1.10 in Ch. 6)

Attention: DG1-10 was deprecated as of v 2.3 and the detail was withdrawn and removed from the standard as of v 2.6

(Definition from DRG.4 in Ch. 6)

Definition: This code indicates that the grouper results have been reviewed and approved. Refer to User-defined Table 0056 - DRG Grouper Review Code in Chapter 2C, Code Tables, for suggested values.

(Definition from DG1.11 in Ch. 6)

Attention: DG1-11 was deprecated as of v 2.3 and the detail was withdrawn and removed from the standard as of v 2.6

(Definition from DRG.5 in Ch. 6)

Definition: Refers to the type of outlier (i.e., period of care beyond DRG-standard stay in facility) that has been paid. Refer to User-defined Table 0083 - Outlier Type in Chapter 2C, code Tables, for suggested values.

(Definition from DG1.12 in Ch. 6)

Attention: DG1-12 was deprecated as of v 2.3 and the detail was withdrawn and removed from the standard as of v 2.6

(Definition from DRG.6 in Ch. 6)

Definition: This field contains the number of days that have been approved as an outlier payment.

(Definition from DG1.13 in Ch. 6)

Attention: DG1-13 was deprecated as of v 2.3 and the detail was withdrawn and removed from the standard as of v 2.6

(Definition from DRG.7 in Ch. 6)

Definition: This field contains the amount of money that has been approved for an outlier payment.

(Definition from GP1.5 in Ch. 6)

Definition: This field contains the amount that exceeds the outlier limitation as defined by APC regulations. This field is analogous to DRG-7 - Outlier Cost; however, the definition in this field note supersedes the DRG-7 definition.

Definition: This field indicates the associated DRG Payor. Refer to User-defined Table 0229 - DRG Payor in Chapter 2C, Code Tables, for suggested values.

Definition: Where applicable, the outlier reimbursement amount indicates the part of the total reimbursement designated for reimbursement of outlier conditions (day or cost).

(Definition from DG1.18 in Ch. 6)

Definition: This field indicates whether the diagnosis is confidential. Refer to HL7 Table 0136 - Yes/no Indicator in Chapter 2C, "Code Tables", for valid values.

• Y    the diagnosis is a confidential diagnosis

• N    the diagnosis does not contain a confidential diagnosis

(Definition from DRG.10 in Ch. 6)

Definition: This field indicates if the DRG contains a confidential diagnosis. Refer to HL7 Table 0136 - Yes/no Indicator in Chapter 2C, Code Tables, for valid values.

• Y    the DRG contains a confidential diagnosis

• N    the DRG does not contain a confidential diagnosis

Definition: This field indicates the type of hospital receiving a transfer patient, which affects how a facility is reimbursed under diagnosis related group (DRG's), for example, exempt or non-exempt. Refer to User-defined Table 0415 - DRG Transfer Type in Chapter 2C, code Tables, for suggested values.

Definition: This field holds the name of the person ("coder") who supervised or undertook the determination of the DRG code.

Definition: This field indicates the grouper status in general. Refer to Externally-defined Table 0734 - Grouper Status in Chapter 2C, Code Tables, for suggested values.

Definition: This field indicates the PCCL (Patient Clinical Complexity Level) value for the calculated DRG as a single value. This value is calculated based on all individual CCL values calculated so far in relation to the basic DRG. Refer to Externally-defined Table 0728 - CCL Value in Chapter 2C, Code Tables, for suggested values.

Definition: This field contains the effective weight as calculated for this DRG. When exceeding the upper or lower trim point the effective weight is lower or higher.

Definition: This field contains the monetary amount as calculated for this DRG, i.e., the sum of money the insurance company will pay.

Definition: This field contains the status of the patient concerning the financial aspects. It indicates whether the length of stay is normal or respectively shorter or longer than normal. Refer to User-defined Table 0739 – DRG Status Patient in Chapter 2C, Code Tables, for suggested values.

This field is also used along with DRG-23 and DRG-24 as an indication of whether a surcharge (long length of stay) or a discount (short length of stay) has been determined.

Definition: This field contains the name of the software used for grouping.

Definition: This field contains the version information of the software used for grouping.

Definition: This field contains the status of the DRG calculation regarding the financial aspects. Refer to User-defined Table 0742 – DRG Status Financial Calculation in Chapter 2C, Code Tables, for suggested values.

Definition: There will be a discount/surcharge for the calculated price due to a very short stay, early referral or a very long stay. This field contains the discount or surcharge that is included in the final price.

Definition: The basic charge is calculated as a multiplication of the relative weight with the base rate.

Definition: This field contains the total charge including surcharges or discounts.

Definition: This field contains the discount/surcharge as determined for this DRG. The addition/reduction is indicated by DRG-17 - Status Patient.

Definition: This field contains the number of days, for which a surcharge/discount has been determined. The addition/reduction is indicated by DRG-17 - Status Patient.

Definition: This field contains the status of the use of the gender information for DRG determination. Refer to User-defined Table 0749 – DRG Grouping Status in Chapter 2C, Code Tables, for suggested values.

Definition: This field contains the status of the use of the age information for DRG determination. Refer to User-defined Table 0749 – DRG Grouping Status in Chapter 2C, Code Tables, for suggested values.

Definition: This field contains the status of the DRG calculation for the length of stay information. Refer to User-defined Table 0749 – DRG Grouping Status in Chapter 2C, Code Tables, for suggested values.

Definition: This field contains the status of the use of the same day information for DRG determination. Refer to User-defined Table 0749 – DRG Grouping Status in Chapter 2C, Code Tables, for suggested values.

Definition: This field contains the status of the use of the separation mode information for DRG determination. Refer to User-defined Table 0749 – DRG Grouping Status in Chapter 2C, Code Tables, for suggested values.

Definition: This field contains the status of the use of the weight at birth information for DRG determination. Refer to User-defined Table 0755 – DRG Status Weight At Birth in Chapter 2C, Code Tables, for suggested values.

Definition: This field contains the status of the use of the respiration minutes information for DRG determination. Refer to User-defined Table 0757 – DRG Status Respiration Minutes in Chapter 2C, Code Tables, for suggested values.

Definition: This field contains the admission status for the DRG determination. Refer to User-defined Table 0759 – Status Admission in Chapter 2C, Code Tables, for suggested values.

The PR1 segment contains information relative to various types of procedures that can be performed on a patient. The PR1 segment can be used to send procedure information, for example: Surgical, Nuclear Medicine, X-ray with contrast, etc. The PR1 segment is used to send multiple procedures, for example, for medical records encoding or for billing systems.

HL7 Attribute Table - PR1 - Procedures Segment

Seq#	DataElement	Description	Must Implement	Flags	Cardinality	Length	C.LEN	Vocabulary	DataType
PR1
1	00391	Set ID - PR1	SHALL		[1..1]	[1..4]			SI
2	00392	Procedure Coding Method	SHALL NOT	W	[0..0]
3	00393	Procedure Code	SHALL		[1..1]				CNE
4	00394	Procedure Description	SHALL NOT	W	[0..0]
5	00395	Procedure Date/Time	SHALL		[1..1]				DTM
6	00396	Procedure Functional Type			[0..1]			0230 Procedure Functional Type	CWE
7	00397	Procedure Minutes		=	[0..1]		4		NM
8	00398	Anesthesiologist	SHALL NOT	W	[0..0]
9	00399	Anesthesia Code			[0..1]			0019	CWE
10	00400	Anesthesia Minutes		=	[0..1]		4		NM
11	00401	Surgeon	SHALL NOT	W	[0..0]
12	00402	Procedure Practitioner	SHALL NOT	W	[0..0]
13	00403	Consent Code			[0..1]			0059	CWE
14	00404	Procedure Priority			[0..1]	[1..2]		0418 Procedure Priority	NM
15	00772	Associated Diagnosis Code			[0..1]			0051	CWE
16	01316	Procedure Code Modifier			[0..*]				CNE
17	01501	Procedure DRG Type			[0..1]			0416 Procedure DRG Type	CWE
18	01502	Tissue Type Code			[0..*]			0417 Tissue Type Code	CWE
19	01848	Procedure Identifier	MAY True: False:	C	[1..1] [0..1]				EI
20	01849	Procedure Action Code	MAY True: False:	C	[1..1] [0..1]	[1..1]		0206 Segment Action Code	ID
21	02177	DRG Procedure Determination Status			[0..1]			0761 DRG Procedure Determination Status	CWE
22	02178	DRG Procedure Relevance			[0..1]			0763 DRG Procedure Relevance	CWE
23	02371	Treating Organizational Unit			[0..*]				PL
24	02372	Respiratory Within Surgery			[0..1]	[1..1]		0136 Yes/no Indicator	ID
25	02373	Parent Procedure ID			[0..1]				EI