Draft Website - For Review Purposes Only

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.