277 Transaction Set Listing

Usage
Repeats

ISA - INTERCHANGE CONTROL HEADER

X12 Name:
Interchange Control Header
X12 Purpose:
To start and identify an interchange of zero or more functional groups and interchange-related control segments
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
  1. All positions within each of the data elements must be filled.
  2. For compliant implementations under this implementation guide, ISA13, the interchange Control Number, must be a positive unsigned number. Therefore, the ISA segment can be considered a fixed record length segment.
  3. The first element separator defines the element separator to be used through the entire interchange.
  4. The ISA segment terminator defines the segment terminator used throughout the entire interchange.
  5. Spaces in the example interchanges are represented by "." for clarity.
TR3 Example:
ISA✱00✱..........✱01✱SECRET....✱ZZ✱SUBMITTERS.ID..✱ZZ✱RECEIVERS.ID...✱030101✱1253✱^✱00501✱000000905✱1✱T✱:~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
I01
Authorization Information Qualifier
M 1
ID
2
Code identifying the type of information in the Authorization Information
CODE
DEFINITION
00
No Authorization Information Present (No Meaningful Information in I02)
03
Additional Data Identification
Required
2
I02
Authorization Information
M 1
AN
10
Information used for additional identification or authorization of the interchange sender or the data in the interchange; the type of information is set by the Authorization Information Qualifier (I01)
Required
3
I03
Security Information Qualifier
M 1
ID
2
Code identifying the type of information in the Security Information
CODE
DEFINITION
00
No Security Information Present (No Meaningful Information in I04)
01
Password
Required
4
I04
Security Information
M 1
AN
10
This is used for identifying the security information about the interchange sender or the data in the interchange; the type of information is set by the Security Information Qualifier (I03)
Required
5
I05
Interchange ID Qualifier
M 1
ID
2
Code indicating the system/method of code structure used to designate the sender or receiver ID element being qualified
This ID qualifies the Sender in ISA06.
CODE
DEFINITION
01
Duns (Dun & Bradstreet)
14
Duns Plus Suffix
20
Health Industry Number (HIN)
CODE SOURCE 121: Health Industry Number
27
Carrier Identification Number as assigned by Health Care Financing Administration (HCFA)
28
Fiscal Intermediary Identification Number as assigned by Health Care Financing Administration (HCFA)
29
Medicare Provider and Supplier Identification Number as assigned by Health Care Financing Administration (HCFA)
30
U.S. Federal Tax Identification Number
33
National Association of Insurance Commissioners Company Code (NAIC)
ZZ
Mutually Defined
Required
6
I06
Interchange Sender ID
M 1
AN
15
Identification code published by the sender for other parties to use as the receiver ID to route data to them; the sender always codes this value in the sender ID element
Required
7
I05
Interchange ID Qualifier
M 1
ID
2
Code indicating the system/method of code structure used to designate the sender or receiver ID element being qualified
This ID qualifies the Receiver in ISA08.
CODE
DEFINITION
01
Duns (Dun & Bradstreet)
14
Duns Plus Suffix
20
Health Industry Number (HIN)
CODE SOURCE 121: Health Industry Number
27
Carrier Identification Number as assigned by Health Care Financing Administration (HCFA)
28
Fiscal Intermediary Identification Number as assigned by Health Care Financing Administration (HCFA)
29
Medicare Provider and Supplier Identification Number as assigned by Health Care Financing Administration (HCFA)
30
U.S. Federal Tax Identification Number
33
National Association of Insurance Commissioners Company Code (NAIC)
ZZ
Mutually Defined
Required
8
I07
Interchange Receiver ID
M 1
AN
15
Identification code published by the receiver of the data; When sending, it is used by the sender as their sending ID, thus other parties sending to them will use this as a receiving ID to route data to them
Required
9
I08
Interchange Date
M 1
DT
6
Date of the interchange
The date format is YYMMDD.
Required
10
I09
Interchange Time
M 1
TM
4
Time of the interchange
The time format is HHMM.
Required
11
I65
Repetition Separator
M 1
Type is not applicable; the repetition separator is a delimiter and not a data element; this field provides the delimiter used to separate repeated occurrences of a simple data element or a composite data structure; this value must be different than the data element separator, component element separator, and the segment terminator
Required
12
I11
Interchange Control Version Number
M 1
ID
5
Code specifying the version number of the interchange control segments
CODE
DEFINITION
00501
Standards Approved for Publication by ASC X12 Procedures Review Board through October 2003
Required
13
I12
Interchange Control Number
M 1
N
9
A control number assigned by the interchange sender
  1. The Interchange Control Number, ISA13, must be identical to the associated Interchange Trailer IEA02.
  2. Must be a positive unsigned number and must be identical to the value in IEA02.
Required
14
I13
Acknowledgment Requested
M 1
ID
1
Code indicating sender's request for an interchange acknowledgment
See Section B.1.1.5.1 for interchange acknowledgment information.
CODE
DEFINITION
0
No Interchange Acknowledgment Requested
1
Interchange Acknowledgment Requested (TA1)
Required
15
I14
Interchange Usage Indicator
M 1
ID
1
Code indicating whether data enclosed by this interchange envelope is test, production or information
CODE
DEFINITION
P
Production Data
T
Test Data
Required
16
I15
Component Element Separator
M 1
Type is not applicable; the component element separator is a delimiter and not a data element; this field provides the delimiter used to separate component data elements within a composite data structure; this value must be different than the data element separator and the segment terminator

GS*HN - FUNCTIONAL GROUP HEADER

X12 Name:
Functional Group Header
X12 Purpose:
To indicate the beginning of a functional group and to provide control information
X12 Comments:
A functional group of related transaction sets, within the scope of X12 standards, consists of a collection of similar transaction sets enclosed by a functional group header and a functional group trailer.
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
GS✱XX✱SENDER CODE✱RECEIVER CODE✱19991231✱0802✱1✱X✱005010X214~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
479
Functional Identifier Code
M 1
ID
2
Code identifying a group of application related transaction sets
This is the 2-character Functional Identifier Code assigned to each transaction set by X12. The specific code for a transaction set defined by this implementation guide is presented in section 1.2, Version Information.
CODE
DEFINITION
HN
Health Care Information Status Notification (277)
Required
2
142
Application Sender's Code
M 1
AN
2/15
Code identifying party sending transmission; codes agreed to by trading partners
Use this code to identify the unit sending the information.
Required
3
124
Application Receiver's Code
M 1
AN
2/15
Code identifying party receiving transmission; codes agreed to by trading partners
Use this code to identify the unit receiving the information.
Required
4
373
Date
M 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEMANTIC: GS04 is the group date.
Use this date for the functional group creation date.
Required
5
337
Time
M 1
TM
4/8
Time expressed in 24-hour clock time as follows: HHMM, or HHMMSS, or HHMMSSD, or HHMMSSDD, where H = hours (00-23), M = minutes (00-59), S = integer seconds (00-59) and DD = decimal seconds; decimal seconds are expressed as follows: D = tenths (0-9) and DD = hundredths (00-99)
SEMANTIC: GS05 is the group time.
Use this time for the creation time. The recommended format is HHMM.
Required
6
28
Group Control Number
M 1
N
1/9
Assigned number originated and maintained by the sender
SEMANTIC: The data interchange control number GS06 in this header must be identical to the same data element in the associated functional group trailer, GE02.
For implementations compliant with this guide, GS06 must be unique within a single transmission (that is, within a single ISA to IEA enveloping structure). The authors recommend that GS06 be unique within all transmissions over a period of time to be determined by the sender.
Required
7
455
Responsible Agency Code
M 1
ID
1/2
Code identifying the issuer of the standard; this code is used in conjunction with Data Element 480
CODE
DEFINITION
X
Accredited Standards Committee X12
Required
8
480
Version / Release / Industry Identifier Code
M 1
AN
1/12
Code indicating the version, release, subrelease, and industry identifier of the EDI standard being used, including the GS and GE segments; if code in DE455 in GS segment is X, then in DE 480 positions 1-3 are the version number; positions 4-6 are the release and subrelease, level of the version; and positions 7-12 are the industry or trade association identifiers (optionally assigned by user); if code in DE455 in GS segment is T, then other formats are allowed
INDUSTRY NAME: Version, Release, or Industry Identifier Code
This is the unique Version/Release/Industry Identifier Code assigned to an implementation by X12N. The specific code for a transaction set defined by this implementation guide is presented in section 1.2, Version Information.
CODE SOURCE 881:Version / Release / Industry Identifier Code
CODE
DEFINITION
005010X214
Health Care Claim Acknowledgment

ST*277 - TRANSACTION SET HEADER

X12 Name:
Transaction Set Header
X12 Purpose:
To indicate the start of a transaction set and to assign a control number
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
ST✱277✱0001✱005010X214~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
143
Transaction Set Identifier Code
M 1
ID
3
Code uniquely identifying a Transaction Set
SEMANTIC: The transaction set identifier (ST01) is used by the translation routines of the interchange partners to select the appropriate transaction set definition (e.g., 810 selects the Invoice Transaction Set).
CODE
DEFINITION
277
Health Care Information Status Notification
Required
2
329
Transaction Set Control Number
M 1
AN
4/9
Identifying control number that must be unique within the transaction set functional group assigned by the originator for a transaction set
The Transaction Set Control Numbers in ST02 and SE02 must be identical. This unique number also aids in error resolution research. Submitter could begin sending transactions using the number 0001 in this element and increment from there. The number must be unique within a specific functional group (GS to GE) and interchange (ISA to IEA), but can be repeated in other groups and interchanges.
Required
3
1705
Implementation Convention Reference
O 1
AN
1/35
Reference assigned to identify Implementation Convention
SEMANTIC: The implementation convention reference (ST03) is used by the translation routines of the interchange partners to select the appropriate implementation convention to match the transaction set definition. When used, this implementation convention reference takes precedence over the implementation reference specified in the GS08.
INDUSTRY NAME: Version, Release, or Industry Identifier
This field contains the same value as data element GS08. The value is 005010X214. Some translator products strip off the ISA and GS segments prior to application (ST - SE) processing. Providing the information from GS08 at this level will help ensure the appropriate application mapping is utilized at translation time.
CODE
DEFINITION
005010X214
Health Care Claim Acknowledgment

BHT*0085 - BEGINNING OF HIERARCHICAL TRANSACTION

X12 Name:
Beginning of Hierarchical Transaction
X12 Purpose:
To define the business hierarchical structure of the transaction set and identify the business application purpose and reference data, i.e., number, date, and time
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
BHT✱0085✱08✱0000221✱20060201✱1635✱TH~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
1005
Hierarchical Structure Code
M 1
ID
4
Code indicating the hierarchical application structure of a transaction set that utilizes the HL segment to define the structure of the transaction set
CODE
DEFINITION
0085
Information Source, Information Receiver, Provider of Service, Patient
Required
2
353
Transaction Set Purpose Code
M 1
ID
2
Code identifying purpose of transaction set
CODE
DEFINITION
08
Status
Required
3
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: BHT03 is the number assigned by the originator to identify the transaction within the originator's business application system.
The inventory file number of the transmission assigned by the Information Source's system. This number operates as a transaction (batch) control number.
Required
4
373
Date
O 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEMANTIC: BHT04 is the date the transaction was created within the business application system.
INDUSTRY NAME: Transaction Set Creation Date
Required
5
337
Time
O 1
TM
4/8
Time expressed in 24-hour clock time as follows: HHMM, or HHMMSS, or HHMMSSD, or HHMMSSDD, where H = hours (00-23), M = minutes (00-59), S = integer seconds (00-59) and DD = decimal seconds; decimal seconds are expressed as follows: D = tenths (0-9) and DD = hundredths (00-99)
SEMANTIC: BHT05 is the time the transaction was created within the business application system.
INDUSTRY NAME: Transaction Set Creation Time
Required
6
640
Transaction Type Code
O 1
ID
2
Code specifying the type of transaction
CODE
DEFINITION
TH
Receipt Acknowledgment Advice

HL - INFORMATION SOURCE LEVEL

X12 Name:
Hierarchical Level
X12 Purpose:
To identify dependencies among and the content of hierarchically related groups of data segments
X12 Comments:
  1. The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
  2. The HL segment defines a top-down/left-right ordered structure.
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
This entity is the decision maker in the business transaction. For this business use, this entity is the payer or clearinghouse receiving the ASC X12 837 transaction.
TR3 Example:
HL✱1✱✱20✱1~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
628
Hierarchical ID Number
M 1
AN
1/12
A unique number assigned by the sender to identify a particular data segment in a hierarchical structure
COMMENT: HL01 shall contain a unique alphanumeric number for each occurrence of the HL segment in the transaction set. For example, HL01 could be used to indicate the number of occurrences of the HL segment, in which case the value of HL01 would be "1" for the initial HL segment and would be incremented by one in each subsequent HL segment within the transaction.
HL01 must begin with the value "1" and increment by one each time an HL is used in the transaction. Only numeric values are allowed in HL01.
Not Used
2
734
Hierarchical Parent ID Number
O 1
AN
1/12
Required
3
735
Hierarchical Level Code
M 1
ID
1/2
Code defining the characteristic of a level in a hierarchical structure
COMMENT: HL03 indicates the context of the series of segments following the current HL segment up to the next occurrence of an HL segment in the transaction. For example, HL03 is used to indicate that subsequent segments in the HL loop form a logical grouping of data referring to shipment, order, or item-level information.
CODE
DEFINITION
20
Information Source
Required
4
736
Hierarchical Child Code
O 1
ID
1
Code indicating if there are hierarchical child data segments subordinate to the level being described
COMMENT: HL04 indicates whether or not there are subordinate (or child) HL segments related to the current HL segment.
CODE
DEFINITION
1
Additional Subordinate HL Data Segment in This Hierarchical Structure.

NM1 - INFORMATION SOURCE NAME

X12 Name:
Individual or Organizational Name
X12 Purpose:
To supply the full name of an individual or organizational entity
X12 Syntax:
  1. P0809
    If either NM108 or NM109 is present, then the other is required.
  2. C1110
    If NM111 is present, then NM110 is required.
  3. C1203
    If NM112 is present, then NM103 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
NM1✱PR✱2✱ABC INSURANCE✱✱✱✱✱PI✱12345~ ORNM1✱AY✱2✱NATIONAL CLEARINGHOUSE✱✱✱✱✱46✱123456789012~ ORNM1✱AY✱2✱SINGLE BILLING SERVICE✱✱✱✱✱FI✱109876543~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
98
Entity Identifier Code
M 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
CODE
DEFINITION
AY
Clearinghouse
Health care clearinghouse means a public or private entity that does either of the following:

(1) Processes or facilitates the processing of information received from another entity in a nonstandard format or containing nonstandard data content into standard data elements or a standard transaction.
(2) Receives a standard transaction from another entity and processes or facilitates the processing of information into nonstandard format or nonstandard data content for a receiving entity.
PR
Payer
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code qualifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
2
Non-Person Entity
Required
3
1035
Name Last or Organization Name
O 1
AN
1/60
Individual last name or organizational name
SEGMENT SYNTAX: C1203
INDUSTRY NAME: Information Source Name
Not Used
4
1036
Name First
O 1
AN
1/35
Not Used
5
1037
Name Middle
O 1
AN
1/25
Not Used
6
1038
Name Prefix
O 1
AN
1/10
Not Used
7
1039
Name Suffix
O 1
AN
1/10
Required
8
66
Identification Code Qualifier
O 1
ID
1/2
Code designating the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: P0809
CODE
DEFINITION
46
Electronic Transmitter Identification Number (ETIN)
This number is used for entities identified in translation software typically called "Trading Partner Profiles". It is used for non-health plan entities.
FI
Federal Taxpayer's Identification Number
PI
Payor Identification
XV
Centers for Medicare and Medicaid Services PlanID
CODE SOURCE 540: Centers for Medicare and Medicaid Services PlanID
Required
9
67
Identification Code
O 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
INDUSTRY NAME: Information Source Identifier
Not Used
10
706
Entity Relationship Code
O 1
ID
2
Not Used
11
98
Entity Identifier Code
O 1
ID
2/3
Not Used
12
1035
Name Last or Organization Name
O 1
AN
1/60

TRN*1 - TRANSMISSION RECEIPT CONTROL IDENTIFIER

X12 Name:
Trace
X12 Purpose:
To uniquely identify a transaction to an application
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
TRN✱1✱20060831001~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
481
Trace Type Code
M 1
ID
1/2
Code identifying which transaction is being referenced
CODE
DEFINITION
1
Current Transaction Trace Numbers
Required
2
127
Reference Identification
M 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: TRN02 provides unique identification for the transaction.
INDUSTRY NAME: Information Source Application Trace Identifier
This is a unique trace number that identifies a specific transaction. This number is assigned by the Information Source.
Not Used
3
509
Originating Company Identifier
O 1
AN
10
Not Used
4
127
Reference Identification
O 1
AN
1/50

DTP*050 - INFORMATION SOURCE RECEIPT DATE

X12 Name:
Date or Time or Period
X12 Purpose:
To specify any or all of a date, a time, or a time period
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
DTP✱050✱D8✱20060228~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
374
Date/Time Qualifier
M 1
ID
3
Code specifying type of date or time, or both date and time
INDUSTRY NAME: Date Time Qualifier
CODE
DEFINITION
050
Received
Required
2
1250
Date Time Period Format Qualifier
M 1
ID
2/3
Code indicating the date format, time format, or date and time format
SEMANTIC: DTP02 is the date or time or period format that will appear in DTP03.
CODE
DEFINITION
D8
Date Expressed in Format CCYYMMDD
Required
3
1251
Date Time Period
M 1
AN
1/35
Expression of a date, a time, or range of dates, times or dates and times
INDUSTRY NAME: Information Source Receipt Date
This is the receipt date of the 837 by the entity creating the 277 acknowledgment. This date may or may not be the same date as the Information Source Process Date.

DTP*009 - INFORMATION SOURCE PROCESS DATE

X12 Name:
Date or Time or Period
X12 Purpose:
To specify any or all of a date, a time, or a time period
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
  1. Payers and clearinghouses often collect claim transmissions throughout the business day. A process which is usually called "batch" is initiated at least once per business day. Some entities may initiate this process more than one time per day. As claim transmission files are processed, EDI reports and or data files are generated from the entity's computer system(s) and are distributed to the Information Receiver.
  2. The Information Source Process Date applies to the processing of the 837 claim transaction file through a pre-adjudication/electronic data interchange (EDI) system. This date may or may not be the same date as the Information Source Receipt Date.
TR3 Example:
DTP✱009✱D8✱20060301~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
374
Date/Time Qualifier
M 1
ID
3
Code specifying type of date or time, or both date and time
INDUSTRY NAME: Date Time Qualifier
CODE
DEFINITION
009
Process
Required
2
1250
Date Time Period Format Qualifier
M 1
ID
2/3
Code indicating the date format, time format, or date and time format
SEMANTIC: DTP02 is the date or time or period format that will appear in DTP03.
CODE
DEFINITION
D8
Date Expressed in Format CCYYMMDD
Required
3
1251
Date Time Period
M 1
AN
1/35
Expression of a date, a time, or range of dates, times or dates and times
INDUSTRY NAME: Information Source Process Date

HL - INFORMATION RECEIVER LEVEL

X12 Name:
Hierarchical Level
X12 Purpose:
To identify dependencies among and the content of hierarchically related groups of data segments
X12 Comments:
  1. The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
  2. The HL segment defines a top-down/left-right ordered structure.
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
The Information Receiver is the entity that expects the response from the Information Source. For this business use, this entity can be a provider, a provider group, a claims clearinghouse, a service bureau, an agency, an employer etc.
TR3 Example:
HL✱2✱1✱21✱1~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
628
Hierarchical ID Number
M 1
AN
1/12
A unique number assigned by the sender to identify a particular data segment in a hierarchical structure
COMMENT: HL01 shall contain a unique alphanumeric number for each occurrence of the HL segment in the transaction set. For example, HL01 could be used to indicate the number of occurrences of the HL segment, in which case the value of HL01 would be "1" for the initial HL segment and would be incremented by one in each subsequent HL segment within the transaction.
Required
2
734
Hierarchical Parent ID Number
O 1
AN
1/12
Identification number of the next higher hierarchical data segment that the data segment being described is subordinate to
COMMENT: HL02 identifies the hierarchical ID number of the HL segment to which the current HL segment is subordinate.
Required
3
735
Hierarchical Level Code
M 1
ID
1/2
Code defining the characteristic of a level in a hierarchical structure
COMMENT: HL03 indicates the context of the series of segments following the current HL segment up to the next occurrence of an HL segment in the transaction. For example, HL03 is used to indicate that subsequent segments in the HL loop form a logical grouping of data referring to shipment, order, or item-level information.
CODE
DEFINITION
21
Information Receiver
Required
4
736
Hierarchical Child Code
O 1
ID
1
Code indicating if there are hierarchical child data segments subordinate to the level being described
COMMENT: HL04 indicates whether or not there are subordinate (or child) HL segments related to the current HL segment.
CODE
DEFINITION
0
No Subordinate HL Segment in This Hierarchical Structure.
Used when the Information Receiver STC03=U, reject entire transaction.
1
Additional Subordinate HL Data Segment in This Hierarchical Structure.
Used when the Information Receiver STC03 = WQ, accept entire transmission.

NM1*41 - INFORMATION RECEIVER NAME

X12 Name:
Individual or Organizational Name
X12 Purpose:
To supply the full name of an individual or organizational entity
X12 Syntax:
  1. P0809
    If either NM108 or NM109 is present, then the other is required.
  2. C1110
    If NM111 is present, then NM110 is required.
  3. C1203
    If NM112 is present, then NM103 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
  1. The Information Receiver identified in the NM1 is always the electronic connection to the Information Source EDI environment. The Information Receiver has a trading partner profile set up at the Information Source's site and is generally the entity that submitted the claim transaction(s) for processing.
  2. For situations where a person such as a single practitioner submits claim transactions to a payer, the entity identified in the Provider of Service Loop (HL03 = 19) will be the same entity identified here in the Information Receiver Loop (HL03 = 21). The difference may be that the trading partner profile set up in the EDI environment is a separate identification scheme from the identification number set up for the entity in the adjudication system.
  3. In the situation where there is more than one clearinghouse involved in the transmission of the Health Care Claim Acknowledgement as part of the Trading Partner Agreement, this segment will be used to identify the clearinghouse that is passing the information. This segment will be changed to display the information for the next clearinghouse before they continue passing on the transmission. This process will continue until the transmission reaches the initiator of the claim/encounter.
TR3 Example:
NM1✱41✱2✱ST HOLY HILL HOSPITAL✱✱✱✱✱46✱39999000B~ ORNM1✱41✱1✱SMITH✱ROBERT✱J✱✱✱46✱188888000A~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
98
Entity Identifier Code
M 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
CODE
DEFINITION
41
Submitter
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code qualifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
1
Person
2
Non-Person Entity
Required
3
1035
Name Last or Organization Name
O 1
AN
1/60
Individual last name or organizational name
SEGMENT SYNTAX: C1203
INDUSTRY NAME: Information Receiver Last or Organization Name
Situational
4
1036
Name First
O 1
AN
1/35
Individual first name
SITUATIONAL RULE: Required when the value in NM102 is "1". If not required by this implementation guide, do not send.
INDUSTRY NAME: Information Receiver First Name
Situational
5
1037
Name Middle
O 1
AN
1/25
Individual middle name or initial
SITUATIONAL RULE: Required if additional name information is needed to identify the Information Receiver and the value in NM102 is "1". If not required by this implementation guide, do not send.
INDUSTRY NAME: Information Receiver Middle Name
Not Used
6
1038
Name Prefix
O 1
AN
1/10
Not Used
7
1039
Name Suffix
O 1
AN
1/10
Required
8
66
Identification Code Qualifier
O 1
ID
1/2
Code designating the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: P0809
CODE
DEFINITION
46
Electronic Transmitter Identification Number (ETIN)
Required
9
67
Identification Code
O 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
INDUSTRY NAME: Information Receiver Primary Identifier
Not Used
10
706
Entity Relationship Code
O 1
ID
2
Not Used
11
98
Entity Identifier Code
O 1
ID
2/3
Not Used
12
1035
Name Last or Organization Name
O 1
AN
1/60

TRN*2 - INFORMATION RECEIVER APPLICATION TRACE IDENTIFIER

X12 Name:
Trace
X12 Purpose:
To uniquely identify a transaction to an application
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
This segment contains the value submitted in the BHT03 data element from the 837.
TR3 Example:
TRN✱2✱20060828001~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
481
Trace Type Code
M 1
ID
1/2
Code identifying which transaction is being referenced
CODE
DEFINITION
2
Referenced Transaction Trace Numbers
Required
2
127
Reference Identification
M 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: TRN02 provides unique identification for the transaction.
INDUSTRY NAME: Claim Transaction Batch Number
This element contains the value submitted in the BHT03 data element from the 837.
Not Used
3
509
Originating Company Identifier
O 1
AN
10
Not Used
4
127
Reference Identification
O 1
AN
1/50

STC - INFORMATION RECEIVER STATUS INFORMATION

X12 Name:
Status Information
X12 Purpose:
To report the status, required action, and paid information of a claim or service line
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
>1
TR3 Notes:
  1. This segment will be used to convey information about an entire unit of work (e.g. single transaction of claims). Information contained at this level will be summary details pertaining to the unit of work being acknowledged. Examples include but are not limited to accepted for processing, trading partner not authorized to submit to the Information Source's system, etc.
  2. See Section 1.4.2 - Status Information (STC) Segment Usage for specific STC segment information, composites and code use.
TR3 Example:
STC✱A1:19✱20060301✱WQ✱432.55~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
C043
Health Care Claim Status
M 1
Used to convey status of the entire claim or a specific service line
X12 COMPOSITE SEMANTIC NOTES:
  1. C043-01 is used to specify the logical groupings of Health Care Claim Status Codes (See Code Source 507).
  2. C043-02 is used to identify the status of an entire claim or a serviceline. Code Source 508 is referenced unless qualified by C043-04.
  3. C043-03 identifies the entity associated with the Health Care Claim Status Code.
  4. C043-04 is used to identify the Code Source referenced in C043-02.
Required
1-1
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Category Code
  1. For this business application acknowledgment, use of the Claim Status Category Code is limited to category types `A' for batch. For real time acknowledgements category types `A' and `E' may be used except for E0. Use of the category type `E' is limited to indicating the business application system is unavailable.
  2. CODE SOURCE 507: Health Care Claim Status Category Code
Required
1-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Code
  1. This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
  2. CODE SOURCE 508: Health Care Claim Status Code
Situational
1-3
98
Entity Identifier Code
O 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
SITUATIONAL RULE: Required when an entity must be identified to further clarify the code message in STC01-2. If not required by this implementation guide, may be provided at the sender's discretion but cannot be required by the receiver.
CODE
DEFINITION
36
Employer
40
Receiver
41
Submitter
AY
Clearinghouse
PR
Payer
Not Used
1-4
1270
Code List Qualifier Code
O 1
ID
1/3
Required
2
373
Date
O 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEMANTIC: STC02 is the effective date of the status information.
INDUSTRY NAME: Status Information Effective Date
Required
3
306
Action Code
O 1
ID
1/2
Code indicating type of action
STC03 at this level is intended to convey the electronic transmission status of the ST - SE envelope. The terms "Accept" and "Reject" refer to the electronic transmission status of the 837 transaction not the billing status.
CODE
DEFINITION
U
Reject
Required when the entire claim transaction (ST-SE) is rejected due to submitter level errors. No subordinate HL information is reported.
WQ
Accept
Required when code value "U" is not used. At least one subordinate HL loop must be reported.
Required
4
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: STC04 is the amount of original submitted charges.
INDUSTRY NAME: Total Submitted Charges for Unit Work
This will be the sum of all CLM02 values (claim charge) for the claims being acknowledged. In most instances, this will be the sum of charges submitted from ST to SE of a single 837 transaction set.

In situations where the 837 transaction from the Information Receiver is separated (e.g. due to clearinghouse involvement), this amount will be the sum of the CLM02 values for the claims being acknowledged.
Not Used
5
782
Monetary Amount
O 1
R
1/18
Not Used
6
373
Date
O 1
DT
8
Not Used
7
591
Payment Method Code
O 1
ID
3
Not Used
8
373
Date
O 1
DT
8
Not Used
9
429
Check Number
O 1
AN
1/16
Situational
10
C043
Health Care Claim Status
O 1
Used to convey status of the entire claim or a specific service line
X12 COMPOSITE SEMANTIC NOTES:
  1. C043-01 is used to specify the logical groupings of Health Care Claim Status Codes (See Code Source 507).
  2. C043-02 is used to identify the status of an entire claim or a serviceline. Code Source 508 is referenced unless qualified by C043-04.
  3. C043-03 identifies the entity associated with the Health Care Claim Status Code.
  4. C043-04 is used to identify the Code Source referenced in C043-02.
SITUATIONAL RULE: Required when additional clarification to STC01 is needed. If not required by this implementation guide, do not send.
Required
10-1
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Category Code
  1. See STC01-1 for valid values.
  2. CODE SOURCE 507: Health Care Claim Status Category Code
Required
10-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Code
  1. This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
  2. CODE SOURCE 508: Health Care Claim Status Code
Situational
10-3
98
Entity Identifier Code
O 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
SITUATIONAL RULE: Required when an entity must be identified to further clarify the code message in STC10-2. If not required by this implementation guide, may be provided at the sender's discretion but cannot be required by the receiver.
See STC01-3 for valid values.
CODE
DEFINITION
36
Employer
40
Receiver
41
Submitter
AY
Clearinghouse
PR
Payer
Not Used
10-4
1270
Code List Qualifier Code
O 1
ID
1/3
Situational
11
C043
Health Care Claim Status
O 1
Used to convey status of the entire claim or a specific service line
X12 COMPOSITE SEMANTIC NOTES:
  1. C043-01 is used to specify the logical groupings of Health Care Claim Status Codes (See Code Source 507).
  2. C043-02 is used to identify the status of an entire claim or a serviceline. Code Source 508 is referenced unless qualified by C043-04.
  3. C043-03 identifies the entity associated with the Health Care Claim Status Code.
  4. C043-04 is used to identify the Code Source referenced in C043-02.
SITUATIONAL RULE: Required when additional clarification to STC01 and STC10 is needed. If not required by this implementation guide, do not send.
Required
11-1
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Category Code
  1. See STC01-1 for valid values.
  2. CODE SOURCE 507: Health Care Claim Status Category Code
Required
11-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Code
  1. This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
  2. CODE SOURCE 508: Health Care Claim Status Code
Situational
11-3
98
Entity Identifier Code
O 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
SITUATIONAL RULE: Required when an entity must be identified to further clarify the code message in STC11-2. If not required by this implementation guide, may be provided at the sender's discretion but cannot be required by the receiver.
See STC01-3 for valid values.
CODE
DEFINITION
36
Employer
40
Receiver
41
Submitter
AY
Clearinghouse
PR
Payer
Not Used
11-4
1270
Code List Qualifier Code
O 1
ID
1/3
Not Used
12
933
Free-form Message Text
O 1
AN
1/264

QTY*90 - TOTAL ACCEPTED QUANTITY

X12 Name:
Quantity Information
X12 Purpose:
To specify quantity information
X12 Syntax:
  1. R0204
    At least one of QTY02 or QTY04 is required.
  2. E0204
    Only one of QTY02 or QTY04 may be present.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when at least one claim is accepted for this Information Receiver. If not required by this implementation guide, do not send.
TR3 Notes:
The purpose of this segment is to report the total number of claims accepted by the Information Source.
TR3 Example:
QTY✱90✱102~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
673
Quantity Qualifier
M 1
ID
2
Code specifying the type of quantity
CODE
DEFINITION
90
Acknowledged Quantity
Required
2
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEGMENT SYNTAX: R0204, E0204
INDUSTRY NAME: Total Accepted Quantity
Not Used
3
C001
Composite Unit of Measure
O 1
Not Used
4
61
Free-form Information
O 1
AN
1/30

QTY*AA - TOTAL REJECTED QUANTITY

X12 Name:
Quantity Information
X12 Purpose:
To specify quantity information
X12 Syntax:
  1. R0204
    At least one of QTY02 or QTY04 is required.
  2. E0204
    Only one of QTY02 or QTY04 may be present.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when at least one claim is rejected for this Information Receiver. If not required by this implementation guide, do not send.
TR3 Notes:
The purpose of this segment is to report the total number of claims rejected for this Information Receiver (e.g. not accepted) by the Information Source.
TR3 Example:
QTY✱AA✱98~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
673
Quantity Qualifier
M 1
ID
2
Code specifying the type of quantity
CODE
DEFINITION
AA
Unacknowledged Quantity
Required
2
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEGMENT SYNTAX: R0204, E0204
INDUSTRY NAME: Total Rejected Quantity
Not Used
3
C001
Composite Unit of Measure
O 1
Not Used
4
61
Free-form Information
O 1
AN
1/30

AMT*YU - TOTAL ACCEPTED AMOUNT

X12 Name:
Monetary Amount Information
X12 Purpose:
To indicate the total monetary amount
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when at least one claim is accepted for this Information Receiver. If not required by this implementation guide, do not send.
TR3 Notes:
The purpose of this segment is to report the total dollar amount of claims accepted by the Information Source.
TR3 Example:
AMT✱YU✱5053.52~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
522
Amount Qualifier Code
M 1
ID
1/3
Code to qualify amount
CODE
DEFINITION
YU
In Process
Required
2
782
Monetary Amount
M 1
R
1/18
Monetary amount
INDUSTRY NAME: Total Accepted Amount
Not Used
3
478
Credit/Debit Flag Code
O 1
ID
1

AMT*YY - TOTAL REJECTED AMOUNT

X12 Name:
Monetary Amount Information
X12 Purpose:
To indicate the total monetary amount
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when at least one claim is rejected for this Information Receiver. If not required by this implementation guide, do not send.
TR3 Notes:
The purpose of this segment is to report the total dollar amount of claims rejected for this Information Receiver (e.g. not accepted) by the Information Source.
TR3 Example:
AMT✱YY✱99.5~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
522
Amount Qualifier Code
M 1
ID
1/3
Code to qualify amount
CODE
DEFINITION
YY
Returned
Required
2
782
Monetary Amount
M 1
R
1/18
Monetary amount
INDUSTRY NAME: Total Rejected Amount
Not Used
3
478
Credit/Debit Flag Code
O 1
ID
1

HL - BILLING PROVIDER OF SERVICE LEVEL

X12 Name:
Hierarchical Level
X12 Purpose:
To identify dependencies among and the content of hierarchically related groups of data segments
X12 Comments:
  1. The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
  2. The HL segment defines a top-down/left-right ordered structure.
Loop:
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required when STC03 at the Information Receiver Level (2200B) is equal to "WQ" (ACCEPTED). If not required by this implementation guide, do not send.
TR3 Notes:
This loop and all subsequent loops are not used when the Information Receiver STC03 is equal to "U" (REJECT).
TR3 Example:
HL✱3✱2✱19✱1~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
628
Hierarchical ID Number
M 1
AN
1/12
A unique number assigned by the sender to identify a particular data segment in a hierarchical structure
COMMENT: HL01 shall contain a unique alphanumeric number for each occurrence of the HL segment in the transaction set. For example, HL01 could be used to indicate the number of occurrences of the HL segment, in which case the value of HL01 would be "1" for the initial HL segment and would be incremented by one in each subsequent HL segment within the transaction.
Required
2
734
Hierarchical Parent ID Number
O 1
AN
1/12
Identification number of the next higher hierarchical data segment that the data segment being described is subordinate to
COMMENT: HL02 identifies the hierarchical ID number of the HL segment to which the current HL segment is subordinate.
Required
3
735
Hierarchical Level Code
M 1
ID
1/2
Code defining the characteristic of a level in a hierarchical structure
COMMENT: HL03 indicates the context of the series of segments following the current HL segment up to the next occurrence of an HL segment in the transaction. For example, HL03 is used to indicate that subsequent segments in the HL loop form a logical grouping of data referring to shipment, order, or item-level information.
CODE
DEFINITION
19
Provider of Service
Required
4
736
Hierarchical Child Code
O 1
ID
1
Code indicating if there are hierarchical child data segments subordinate to the level being described
COMMENT: HL04 indicates whether or not there are subordinate (or child) HL segments related to the current HL segment.
CODE
DEFINITION
0
No Subordinate HL Segment in This Hierarchical Structure.
Used for Provider level rejections only.
1
Additional Subordinate HL Data Segment in This Hierarchical Structure.

NM1*85 - BILLING PROVIDER NAME

X12 Name:
Individual or Organizational Name
X12 Purpose:
To supply the full name of an individual or organizational entity
X12 Syntax:
  1. P0809
    If either NM108 or NM109 is present, then the other is required.
  2. C1110
    If NM111 is present, then NM110 is required.
  3. C1203
    If NM112 is present, then NM103 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
This segment contains information which can be found in the 837 Dental, Institutional, and Professional implementation guides at the 2010AA loop.
TR3 Example:
NM1✱85✱1✱SMITH✱JOHN✱C✱✱✱XX✱1546326780~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
98
Entity Identifier Code
M 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
CODE
DEFINITION
85
Billing Provider
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code qualifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
1
Person
2
Non-Person Entity
Required
3
1035
Name Last or Organization Name
O 1
AN
1/60
Individual last name or organizational name
SEGMENT SYNTAX: C1203
INDUSTRY NAME: Provider Last or Organization Name
Situational
4
1036
Name First
O 1
AN
1/35
Individual first name
SITUATIONAL RULE: Required when the value in NM102 is "1" and supplied on submitted claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider First Name
Situational
5
1037
Name Middle
O 1
AN
1/25
Individual middle name or initial
SITUATIONAL RULE: Required when the value in NM102 is "1" and supplied on submitted claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Middle Name
Not Used
6
1038
Name Prefix
O 1
AN
1/10
Situational
7
1039
Name Suffix
O 1
AN
1/10
Suffix to individual name
SITUATIONAL RULE: Required when the value in NM102 is "1" and supplied on submitted claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Name Suffix
Required
8
66
Identification Code Qualifier
O 1
ID
1/2
Code designating the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: P0809
CODE
DEFINITION
FI
Federal Taxpayer's Identification Number
XX
Centers for Medicare and Medicaid Services National Provider Identifier
The "XX" qualifier is required only when the National Provider ID is mandated for use.

After the National Provider ID implementation period, enumerated providers use only the NM108 and NM109 data elements and discontinue the generation of the REF segment in Loop ID 2200C.
CODE SOURCE 537: Centers for Medicare & Medicaid Services National Provider Identifier
Required
9
67
Identification Code
O 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
INDUSTRY NAME: Billing Provider Identifier
Not Used
10
706
Entity Relationship Code
O 1
ID
2
Not Used
11
98
Entity Identifier Code
O 1
ID
2/3
Not Used
12
1035
Name Last or Organization Name
O 1
AN
1/60

TRN*1 - PROVIDER OF SERVICE INFORMATION TRACE IDENTIFIER

X12 Name:
Trace
X12 Purpose:
To uniquely identify a transaction to an application
Loop:
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required when 2200C Loop is used to provide the status of a specific provider's group of claims in the STC segment or a secondary provider identifier needs to be reported in the Provider Secondary REF segment. If not required by this implementation guide, may be provided at the sender's discretion but cannot be required by the receiver.
TR3 Notes:
Because the TRN segment is syntactically required in order to use Loop 2200C, TRN02 can either be a sender assigned value or a default value of zero (0).
TR3 Example:
TRN✱1✱0~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
481
Trace Type Code
M 1
ID
1/2
Code identifying which transaction is being referenced
CODE
DEFINITION
1
Current Transaction Trace Numbers
Required
2
127
Reference Identification
M 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: TRN02 provides unique identification for the transaction.
INDUSTRY NAME: Provider of Service Information Trace Identifier
Not Used
3
509
Originating Company Identifier
O 1
AN
10
Not Used
4
127
Reference Identification
O 1
AN
1/50

STC - BILLING PROVIDER STATUS INFORMATION

X12 Name:
Status Information
X12 Purpose:
To report the status, required action, and paid information of a claim or service line
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
>1
Situational Rule:
Required when needed to provide the status of a specific Billing Provider's group of claims. If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.
TR3 Notes:
See Section 1.4.2 - Status Information (STC) Segment Usage for specific STC segment information, composites and code use.
TR3 Example:
STC✱A1:19✱✱WQ✱432.55~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
C043
Health Care Claim Status
M 1
Used to convey status of the entire claim or a specific service line
X12 COMPOSITE SEMANTIC NOTES:
  1. C043-01 is used to specify the logical groupings of Health Care Claim Status Codes (See Code Source 507).
  2. C043-02 is used to identify the status of an entire claim or a serviceline. Code Source 508 is referenced unless qualified by C043-04.
  3. C043-03 identifies the entity associated with the Health Care Claim Status Code.
  4. C043-04 is used to identify the Code Source referenced in C043-02.
Required
1-1
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Category Code
  1. For this business application acknowledgment, use of the Claim Status Category Code is limited to category types `A' for batch. For real time acknowledgements category types `A' and `E' may be used except for E0. Use of the category type `E' is limited to indicating the business application system is unavailable.
  2. CODE SOURCE 507: Health Care Claim Status Category Code
Required
1-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Code
  1. This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
  2. CODE SOURCE 508: Health Care Claim Status Code
Situational
1-3
98
Entity Identifier Code
O 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
SITUATIONAL RULE: Required when an entity must be identified to further clarify the code message in STC01-2. If not required by this implementation guide, may be provided at the sender's discretion but cannot be required by the receiver.
CODE
DEFINITION
36
Employer
40
Receiver
41
Submitter
77
Service Location
82
Rendering Provider
85
Billing Provider
87
Pay-to Provider
AY
Clearinghouse
PR
Payer
Not Used
1-4
1270
Code List Qualifier Code
O 1
ID
1/3
Not Used
2
373
Date
O 1
DT
8
Required
3
306
Action Code
O 1
ID
1/2
Code indicating type of action
STC03 at this level is intended to convey the electronic claim status of the Billing Provider Claims. The terms "Accept" and "Reject" refer to the status of claims for the Billing Provider not the billing status.
CODE
DEFINITION
U
Reject
Use this code to indicate the provider's group of claims has been rejected. If any portion of the provider's group of claims is accepted then the code "WQ" - Accept must be used.
WQ
Accept
Required
4
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: STC04 is the amount of original submitted charges.
INDUSTRY NAME: Total Submitted Charges for Unit Work
  1. Sum of the Billing Provider claims within the 837 transaction being acknowledged.
  2. In situations where the 837 transaction from the Information Receiver is separated (e.g. due to clearinghouse involvement), this amount will be the sum of the CLM02 values for the claims being acknowledged.
Not Used
5
782
Monetary Amount
O 1
R
1/18
Not Used
6
373
Date
O 1
DT
8
Not Used
7
591
Payment Method Code
O 1
ID
3
Not Used
8
373
Date
O 1
DT
8
Not Used
9
429
Check Number
O 1
AN
1/16
Situational
10
C043
Health Care Claim Status
O 1
Used to convey status of the entire claim or a specific service line
X12 COMPOSITE SEMANTIC NOTES:
  1. C043-01 is used to specify the logical groupings of Health Care Claim Status Codes (See Code Source 507).
  2. C043-02 is used to identify the status of an entire claim or a serviceline. Code Source 508 is referenced unless qualified by C043-04.
  3. C043-03 identifies the entity associated with the Health Care Claim Status Code.
  4. C043-04 is used to identify the Code Source referenced in C043-02.
SITUATIONAL RULE: Required when additional clarification to STC01 is needed. If not required by this implementation guide, do not send.
Required
10-1
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Category Code
  1. See STC01-1 for valid values.
  2. CODE SOURCE 507: Health Care Claim Status Category Code
Required
10-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Code
  1. This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
  2. CODE SOURCE 508: Health Care Claim Status Code
Situational
10-3
98
Entity Identifier Code
O 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
SITUATIONAL RULE: Required when an entity must be identified to further clarify the code message in STC10-2. If not required by this implementation guide, may be provided at the sender's discretion but cannot be required by the receiver.
See STC01-3 for valid values.
CODE
DEFINITION
36
Employer
40
Receiver
41
Submitter
77
Service Location
82
Rendering Provider
85
Billing Provider
87
Pay-to Provider
AY
Clearinghouse
PR
Payer
Not Used
10-4
1270
Code List Qualifier Code
O 1
ID
1/3
Situational
11
C043
Health Care Claim Status
O 1
Used to convey status of the entire claim or a specific service line
X12 COMPOSITE SEMANTIC NOTES:
  1. C043-01 is used to specify the logical groupings of Health Care Claim Status Codes (See Code Source 507).
  2. C043-02 is used to identify the status of an entire claim or a serviceline. Code Source 508 is referenced unless qualified by C043-04.
  3. C043-03 identifies the entity associated with the Health Care Claim Status Code.
  4. C043-04 is used to identify the Code Source referenced in C043-02.
SITUATIONAL RULE: Required when additional clarification to STC01 and STC10 is needed. If not required by this implementation guide, do not send.
Required
11-1
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Category Code
  1. See STC01-1 for valid values.
  2. CODE SOURCE 507: Health Care Claim Status Category Code
Required
11-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Code
  1. This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
  2. CODE SOURCE 508: Health Care Claim Status Code
Situational
11-3
98
Entity Identifier Code
O 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
SITUATIONAL RULE: Required when an entity must be identified to further clarify the code message in STC11-2. If not required by this implementation guide, may be provided at the sender's discretion but cannot be required by the receiver.
See STC01-3 for valid values.
CODE
DEFINITION
36
Employer
40
Receiver
41
Submitter
77
Service Location
82
Rendering Provider
85
Billing Provider
87
Pay-to Provider
AY
Clearinghouse
PR
Payer
Not Used
11-4
1270
Code List Qualifier Code
O 1
ID
1/3
Not Used
12
933
Free-form Message Text
O 1
AN
1/264

REF - PROVIDER SECONDARY IDENTIFIER

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
3
Situational Rule:
Required when no billing/service provider identifier is sent in NM109 of this loop

OR

when an identification number in addition to that provided in NM109 of this loop is necessary for the processor to identify the entity.

If not required by this implementation guide, do not send.
TR3 Example:
REF✱G2✱123456789~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
0B
State License Number
1G
Provider UPIN Number
G2
Provider Commercial Number
LU
Location Number
SY
Social Security Number
TJ
Federal Taxpayer's Identification Number
Required
2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Billing Provider Additional Identifier
Not Used
3
352
Description
O 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

QTY*QA - TOTAL ACCEPTED QUANTITY

X12 Name:
Quantity Information
X12 Purpose:
To specify quantity information
X12 Syntax:
  1. R0204
    At least one of QTY02 or QTY04 is required.
  2. E0204
    Only one of QTY02 or QTY04 may be present.
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when reporting status for a specific provider's group of claims and at least one claim is accepted. If not required by this implementation guide, do not send.
TR3 Notes:
The purpose of this segment is to report the total number of claims (sum of CLM02) accepted to the adjudication process by the Information Source for the Billing Provider in this acknowledgment.
TR3 Example:
QTY✱QA✱5~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
673
Quantity Qualifier
M 1
ID
2
Code specifying the type of quantity
CODE
DEFINITION
QA
Quantity Approved
Required
2
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEGMENT SYNTAX: R0204, E0204
INDUSTRY NAME: Total Accepted Quantity
Not Used
3
C001
Composite Unit of Measure
O 1
Not Used
4
61
Free-form Information
O 1
AN
1/30

QTY*QC - TOTAL REJECTED QUANTITY

X12 Name:
Quantity Information
X12 Purpose:
To specify quantity information
X12 Syntax:
  1. R0204
    At least one of QTY02 or QTY04 is required.
  2. E0204
    Only one of QTY02 or QTY04 may be present.
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when reporting status for a specific provider's group of claims and at least one claim is rejected. If not required by this implementation guide, do not send.
TR3 Notes:
The purpose of this segment is to report the total number of claims rejected by the Information Source for the Billing Provider.
TR3 Example:
QTY✱QC✱1~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
673
Quantity Qualifier
M 1
ID
2
Code specifying the type of quantity
CODE
DEFINITION
QC
Quantity Disapproved
Required
2
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEGMENT SYNTAX: R0204, E0204
INDUSTRY NAME: Total Rejected Quantity
Not Used
3
C001
Composite Unit of Measure
O 1
Not Used
4
61
Free-form Information
O 1
AN
1/30

AMT*YU - TOTAL ACCEPTED AMOUNT

X12 Name:
Monetary Amount Information
X12 Purpose:
To indicate the total monetary amount
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when reporting status for a specific provider's group of claims and at least one claim is accepted. If not required by this implementation guide, do not send.
TR3 Notes:
The purpose of this segment is to report the total dollar amount of claims (sum of CLM02) accepted by the Information Source for the Billing Provider in this acknowledgment.
TR3 Example:
AMT✱YU✱1000.5~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
522
Amount Qualifier Code
M 1
ID
1/3
Code to qualify amount
CODE
DEFINITION
YU
In Process
Required
2
782
Monetary Amount
M 1
R
1/18
Monetary amount
INDUSTRY NAME: Total Accepted Amount
Not Used
3
478
Credit/Debit Flag Code
O 1
ID
1

AMT*YY - TOTAL REJECTED AMOUNT

X12 Name:
Monetary Amount Information
X12 Purpose:
To indicate the total monetary amount
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when reporting status for a specific provider's group of claims and at least one claim is rejected. If not required by this implementation guide, do not send.
TR3 Notes:
The purpose of this segment is to report the total dollar amount of claims (sum of CLM02) rejected by the Information Source for the Billing Provider in this acknowledgment.
TR3 Example:
AMT✱YY✱52~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
522
Amount Qualifier Code
M 1
ID
1/3
Code to qualify amount
CODE
DEFINITION
YY
Returned
Required
2
782
Monetary Amount
M 1
R
1/18
Monetary amount
INDUSTRY NAME: Total Rejected Amount
Not Used
3
478
Credit/Debit Flag Code
O 1
ID
1

HL - PATIENT LEVEL

X12 Name:
Hierarchical Level
X12 Purpose:
To identify dependencies among and the content of hierarchically related groups of data segments
X12 Comments:
  1. The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
  2. The HL segment defines a top-down/left-right ordered structure.
Loop:
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required when reporting claim status at the patient level. If not required by this guide, do not send.
TR3 Notes:
This HL level contains information about the Patient identified in the 837 transaction. See Section 1.4.1.1 - Defining the Patient Participant for information on identifying the Patient data from the 837 Transaction.
TR3 Example:
HL✱4✱3✱PT~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
628
Hierarchical ID Number
M 1
AN
1/12
A unique number assigned by the sender to identify a particular data segment in a hierarchical structure
COMMENT: HL01 shall contain a unique alphanumeric number for each occurrence of the HL segment in the transaction set. For example, HL01 could be used to indicate the number of occurrences of the HL segment, in which case the value of HL01 would be "1" for the initial HL segment and would be incremented by one in each subsequent HL segment within the transaction.
Required
2
734
Hierarchical Parent ID Number
O 1
AN
1/12
Identification number of the next higher hierarchical data segment that the data segment being described is subordinate to
COMMENT: HL02 identifies the hierarchical ID number of the HL segment to which the current HL segment is subordinate.
Required
3
735
Hierarchical Level Code
M 1
ID
1/2
Code defining the characteristic of a level in a hierarchical structure
COMMENT: HL03 indicates the context of the series of segments following the current HL segment up to the next occurrence of an HL segment in the transaction. For example, HL03 is used to indicate that subsequent segments in the HL loop form a logical grouping of data referring to shipment, order, or item-level information.
CODE
DEFINITION
PT
Patient
Not Used
4
736
Hierarchical Child Code
O 1
ID
1

NM1*QC - PATIENT NAME

X12 Name:
Individual or Organizational Name
X12 Purpose:
To supply the full name of an individual or organizational entity
X12 Syntax:
  1. P0809
    If either NM108 or NM109 is present, then the other is required.
  2. C1110
    If NM111 is present, then NM110 is required.
  3. C1203
    If NM112 is present, then NM103 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
NM1✱QC✱1✱SMITH✱JOHN✱Q✱✱IV✱MI✱99887777~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
98
Entity Identifier Code
M 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
CODE
DEFINITION
QC
Patient
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code qualifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
1
Person
Required
3
1035
Name Last or Organization Name
O 1
AN
1/60
Individual last name or organizational name
SEGMENT SYNTAX: C1203
INDUSTRY NAME: Patient Last Name
Situational
4
1036
Name First
O 1
AN
1/35
Individual first name
SITUATIONAL RULE: Required when information was submitted on the claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Patient First Name
Situational
5
1037
Name Middle
O 1
AN
1/25
Individual middle name or initial
SITUATIONAL RULE: Required when information was submitted on the claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Patient Middle Name or Initial
Not Used
6
1038
Name Prefix
O 1
AN
1/10
Situational
7
1039
Name Suffix
O 1
AN
1/10
Suffix to individual name
SITUATIONAL RULE: Required when information was submitted on the claim. If not required by this implementation guide, do not send.
INDUSTRY NAME: Patient Name Suffix
Required
8
66
Identification Code Qualifier
O 1
ID
1/2
Code designating the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: P0809
CODE
DEFINITION
II
Standard Unique Health Identifier for each Individual in the United States
Required if the HIPAA Individual Patient Identifier is mandated for use. If not required use MI.
MI
Member Identification Number
Required
9
67
Identification Code
O 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
INDUSTRY NAME: Patient Identification Number
This may be a unique identification number for the patient or it may be the subscriber's identification number. This data element is the value from the NM109 identifying the patient in the submitted claim.

When the payer does not use a unique member identification number for the patient, the subscriber identification number should be used.
Not Used
10
706
Entity Relationship Code
O 1
ID
2
Not Used
11
98
Entity Identifier Code
O 1
ID
2/3
Not Used
12
1035
Name Last or Organization Name
O 1
AN
1/60

TRN*2 - CLAIM STATUS TRACKING NUMBER

X12 Name:
Trace
X12 Purpose:
To uniquely identify a transaction to an application
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
  1. This segment is the patient control number submitted in the CLM01 of the 837.
  2. This number must be returned exactly as submitted in the 837 up to the 20 character limit as defined in the 837 guide.
TR3 Example:
TRN✱2✱SMITHSON20060801~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
481
Trace Type Code
M 1
ID
1/2
Code identifying which transaction is being referenced
CODE
DEFINITION
2
Referenced Transaction Trace Numbers
Required
2
127
Reference Identification
M 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: TRN02 provides unique identification for the transaction.
INDUSTRY NAME: Patient Control Number
Not Used
3
509
Originating Company Identifier
O 1
AN
10
Not Used
4
127
Reference Identification
O 1
AN
1/50

STC - CLAIM LEVEL STATUS INFORMATION

X12 Name:
Status Information
X12 Purpose:
To report the status, required action, and paid information of a claim or service line
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
>1
TR3 Notes:
See Section 1.4.2 - Status Information (STC) Segment Usage for specific STC segment information, composites and code use.
TR3 Example:
STC✱A6:125:82✱20060830✱WQ✱432.65~ ORSTC✱A6:131:82✱20060830✱U✱65.32~STC✱A8:187✱20060830✱U✱70✱✱✱✱✱✱A8:453✱A8:454~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
C043
Health Care Claim Status
M 1
Used to convey status of the entire claim or a specific service line
X12 COMPOSITE SEMANTIC NOTES:
  1. C043-01 is used to specify the logical groupings of Health Care Claim Status Codes (See Code Source 507).
  2. C043-02 is used to identify the status of an entire claim or a serviceline. Code Source 508 is referenced unless qualified by C043-04.
  3. C043-03 identifies the entity associated with the Health Care Claim Status Code.
  4. C043-04 is used to identify the Code Source referenced in C043-02.
Required
1-1
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Category Code
  1. For this business application acknowledgment, use of the Claim Status Category Code is limited to category types `A' for batch. For real time acknowledgements category types `A' and `E' may be used except for E0. Use of the category type `E' is limited to indicating the business application system is unavailable.
  2. CODE SOURCE 507: Health Care Claim Status Category Code
Required
1-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Code
  1. This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
  2. CODE SOURCE 508: Health Care Claim Status Code
Situational
1-3
98
Entity Identifier Code
O 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
SITUATIONAL RULE: Required when an entity must be identified to further clarify the code message in STC01-2. If not required by this implementation guide, may be provided at the sender's discretion but cannot be required by the receiver.
CODE
DEFINITION
03
Dependent
1P
Provider
1Z
Home Health Care
40
Receiver
41
Submitter
71
Attending Physician
72
Operating Physician
73
Other Physician
77
Service Location
82
Rendering Provider
85
Billing Provider
87
Pay-to Provider
DK
Ordering Physician
DN
Referring Provider
DQ
Supervising Physician
FA
Facility
GB
Other Insured
HK
Subscriber
IL
Insured or Subscriber
LI
Independent Lab
MSC
Mammography Screening Center
PR
Payer
PRP
Primary Payer
QB
Purchase Service Provider
QC
Patient
QD
Responsible Party
SEP
Secondary Payer
TL
Testing Laboratory
TTP
Tertiary Payer
TU
Third Party Repricing Organization (TPO)
Not Used
1-4
1270
Code List Qualifier Code
O 1
ID
1/3
Required
2
373
Date
O 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEMANTIC: STC02 is the effective date of the status information.
INDUSTRY NAME: Status Information Effective Date
Required
3
306
Action Code
O 1
ID
1/2
Code indicating type of action
INDUSTRY NAME: Status Information Action Code
CODE
DEFINITION
U
Reject
WQ
Accept
Required
4
782
Monetary Amount
O 1
R
1/18
Monetary amount
SEMANTIC: STC04 is the amount of original submitted charges.
INDUSTRY NAME: Total Claim Charge Amount
  1. Zero is an acceptable amount.
  2. Sum of the charges (CLM02) submitted from original claim. If an original claim is split, report the original claim total here. Note that this amount may be reported in two or more claims.
Not Used
5
782
Monetary Amount
O 1
R
1/18
Not Used
6
373
Date
O 1
DT
8
Not Used
7
591
Payment Method Code
O 1
ID
3
Not Used
8
373
Date
O 1
DT
8
Not Used
9
429
Check Number
O 1
AN
1/16
Situational
10
C043
Health Care Claim Status
O 1
Used to convey status of the entire claim or a specific service line
X12 COMPOSITE SEMANTIC NOTES:
  1. C043-01 is used to specify the logical groupings of Health Care Claim Status Codes (See Code Source 507).
  2. C043-02 is used to identify the status of an entire claim or a serviceline. Code Source 508 is referenced unless qualified by C043-04.
  3. C043-03 identifies the entity associated with the Health Care Claim Status Code.
  4. C043-04 is used to identify the Code Source referenced in C043-02.
SITUATIONAL RULE: Required when additional clarification to STC01 is needed. If not required by this implementation guide, do not send.
Required
10-1
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Category Code
  1. See STC01-1 for valid values.
  2. CODE SOURCE 507: Health Care Claim Status Category Code
Required
10-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Code
  1. This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
  2. CODE SOURCE 508: Health Care Claim Status Code
Situational
10-3
98
Entity Identifier Code
O 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
SITUATIONAL RULE: Required when an entity must be identified to further clarify the code message in STC10-2. If not required by this implementation guide, may be provided at the sender's discretion but cannot be required by the receiver.
See STC01-3 for valid values.
CODE
DEFINITION
03
Dependent
1P
Provider
1Z
Home Health Care
40
Receiver
41
Submitter
71
Attending Physician
72
Operating Physician
73
Other Physician
77
Service Location
82
Rendering Provider
85
Billing Provider
87
Pay-to Provider
DK
Ordering Physician
DN
Referring Provider
DQ
Supervising Physician
FA
Facility
GB
Other Insured
HK
Subscriber
IL
Insured or Subscriber
LI
Independent Lab
MSC
Mammography Screening Center
PR
Payer
PRP
Primary Payer
QB
Purchase Service Provider
QC
Patient
QD
Responsible Party
SEP
Secondary Payer
TL
Testing Laboratory
TTP
Tertiary Payer
TU
Third Party Repricing Organization (TPO)
Not Used
10-4
1270
Code List Qualifier Code
O 1
ID
1/3
Situational
11
C043
Health Care Claim Status
O 1
Used to convey status of the entire claim or a specific service line
X12 COMPOSITE SEMANTIC NOTES:
  1. C043-01 is used to specify the logical groupings of Health Care Claim Status Codes (See Code Source 507).
  2. C043-02 is used to identify the status of an entire claim or a serviceline. Code Source 508 is referenced unless qualified by C043-04.
  3. C043-03 identifies the entity associated with the Health Care Claim Status Code.
  4. C043-04 is used to identify the Code Source referenced in C043-02.
SITUATIONAL RULE: Required when additional clarification to STC01 and STC10 is needed. If not required by this implementation guide, do not send.
Required
11-1
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Category Code
  1. See STC01-1 for valid values.
  2. CODE SOURCE 507: Health Care Claim Status Category Code
Required
11-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Code
  1. This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
  2. CODE SOURCE 508: Health Care Claim Status Code
Situational
11-3
98
Entity Identifier Code
O 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
SITUATIONAL RULE: Required when an entity must be identified to further clarify the code message in STC11-2. If not required by this implementation guide, may be provided at the sender's discretion but cannot be required by the receiver.
See STC01-3 for valid values.
CODE
DEFINITION
03
Dependent
1P
Provider
1Z
Home Health Care
40
Receiver
41
Submitter
71
Attending Physician
72
Operating Physician
73
Other Physician
77
Service Location
82
Rendering Provider
85
Billing Provider
87
Pay-to Provider
DK
Ordering Physician
DN
Referring Provider
DQ
Supervising Physician
FA
Facility
GB
Other Insured
HK
Subscriber
IL
Insured or Subscriber
LI
Independent Lab
MSC
Mammography Screening Center
PR
Payer
PRP
Primary Payer
QB
Purchase Service Provider
QC
Patient
QD
Responsible Party
SEP
Secondary Payer
TL
Testing Laboratory
TTP
Tertiary Payer
TU
Third Party Repricing Organization (TPO)
Not Used
11-4
1270
Code List Qualifier Code
O 1
ID
1/3
Situational
12
933
Free-form Message Text
O 1
AN
1/264
Free-form message text
SEMANTIC: STC12 allows additional free-form status information.
SITUATIONAL RULE: Required when Health Care Claim Status Code 448 is used in STC01-2, STC10-2, or STC11-2. If not required by this implementation guide, do not send.
INDUSTRY NAME: Free Form Message Text
See Section 1.4.2.1 for more information on use of STC12 and Status Code `448'.

REF*1K - PAYER CLAIM CONTROL NUMBER

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when a payer assigns a specific number to the claim for processing and the number is available at the time of this acknowledgment. If not required by this implementation guide, do not send.
TR3 Notes:
This number will be used to track the adjudication of the claim throughout the adjudication system.
TR3 Example:
REF✱1K✱012421017500~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
1K
Payor's Claim Number
Required
2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Payer Claim Control Number
Not Used
3
352
Description
O 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF*D9 - CLAIM IDENTIFIER FOR TRANSMISSION INTERMEDIARIES

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the Claim Identifier Number for Clearinghouse and Other Transmission Intermediary was sent in the 837. If not required by this implementation guide, do not send.
TR3 Notes:
This number must be returned as received in the 837.
TR3 Example:
REF✱D9✱012421017501~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
D9
Claim Number
Required
2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Clearinghouse Trace Number
Not Used
3
352
Description
O 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF*BLT - INSTITUTIONAL BILL TYPE IDENTIFICATION

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required for Institutional claims when Institutional Type of Bill was received on the claim. If not required by this implementation guide, do not send.
TR3 Example:
REF✱BLT✱111~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
BLT
Billing Type
Use this code only for an Institutional Claim.
Required
2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Bill Type Identifier
See 837 Institutional Implementation Guide for definition of Institutional Bill Type components.

Concatenate the 837I CLM05-1 (Facility Type Code) and CLM05-3 (Claim Frequency Code) values. Code Source = 236 - Uniform Billing Claim Form Bill Type, Code Source 235 - Claim Frequency Type Code respectively.
Not Used
3
352
Description
O 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

DTP*472 - CLAIM LEVEL SERVICE DATE

X12 Name:
Date or Time or Period
X12 Purpose:
To specify any or all of a date, a time, or a time period
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
For Institutional claims, it is the statement period in loop 2300 (DTP01 - 434). For Professional claims this information is derived from the earliest service level dates in loop 2400 (DTP01-472) to the latest service level date. For Dental claims it is the service date at the claim loop 2300 (DTP01=472).
TR3 Example:
DTP✱472✱RD8✱20180820-20180825~ ORDTP✱472✱D8✱20180823~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
374
Date/Time Qualifier
M 1
ID
3
Code specifying type of date or time, or both date and time
INDUSTRY NAME: Date Time Qualifier
CODE
DEFINITION
472
Service
Required
2
1250
Date Time Period Format Qualifier
M 1
ID
2/3
Code indicating the date format, time format, or date and time format
SEMANTIC: DTP02 is the date or time or period format that will appear in DTP03.
CODE
DEFINITION
D8
Date Expressed in Format CCYYMMDD
RD8
Range of Dates Expressed in Format CCYYMMDD-CCYYMMDD
Required
3
1251
Date Time Period
M 1
AN
1/35
Expression of a date, a time, or range of dates, times or dates and times
INDUSTRY NAME: Claim Service Period

SVC - SERVICE LINE INFORMATION

X12 Name:
Service Information
X12 Purpose:
To supply payment and control information to a provider for a particular service
Loop:
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required when a service line is being rejected and caused the rejection of a claim. If not required by this implementation guide, do not send.
TR3 Notes:
  1. Not used if the claim is being accepted into the adjudication system.
  2. For Institutional claims, when both an NUBC revenue code and HCPCS or HIPPS code are reported, the HCPCS or HIPPS code is reported in SVC01-2 and the revenue code is reported in SVC04. When only a revenue code is used, it is reported in SVC01-2.
TR3 Example:
SVC✱NU:0710✱15.61~ ORSVC✱HC:99213✱35~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
C003
Composite Medical Procedure Identifier
M 1
To identify a medical procedure by its standardized codes and applicable modifiers
SEMANTIC: SVC01 is the medical procedure upon which adjudication is based.
COMMENT: For Medicare Part A claims, SVC01 would be the Health Care Financing Administration (HCFA) Common Procedural Coding System (HCPCS) Code (see code source 130) and SVC04 would be the Revenue Code (see code source 132).
X12 COMPOSITE SEMANTIC NOTES:
  1. C003-01 qualifies C003-02 and C003-08.
  2. If C003-08 is used, then C003-02 represents the beginning value in the range in which the code occurs.
  3. C003-03 modifies the value in C003-02 and C003-08.
  4. C003-04 modifies the value in C003-02 and C003-08.
  5. C003-05 modifies the value in C003-02 and C003-08.
  6. C003-06 modifies the value in C003-02 and C003-08.
  7. C003-07 is the description of the procedure identified in C003-02.
  8. C003-08 represents the ending value in the range in which the code occurs.
Required
1-1
235
Product/Service ID Qualifier
M 1
ID
2
Code identifying the type/source of the descriptive number used in Product/Service ID (234)
INDUSTRY NAME: Procedure Code
CODE
DEFINITION
AD
American Dental Association Codes
CODE SOURCE 135: American Dental Association
ER
Jurisdiction Specific Procedure and Supply Codes
This code set is not allowed for use under HIPAA at the time of this writing. The qualifier can only be used:
If a new rule names the Jurisdiction Specific Procedure and Supply Codes as an allowable code set under HIPAA,
OR
The Secretary grants an exception to use the code set as a pilot project as allowed under the law,
OR
For claims which are not covered under HIPAA.
CODE SOURCE 576: Workers Compensation Specific Procedure and Supply Codes
HC
Health Care Financing Administration Common Procedural Coding System (HCPCS) Codes
CODE SOURCE 130: Healthcare Common Procedure Coding System
HP
Health Insurance Prospective Payment System (HIPPS) Skilled Nursing Facility Rate Code
CODE SOURCE 716: Health Insurance Prospective Payment System (HIPPS) Rate Code for Skilled Nursing Facilities
IV
Home Infusion EDI Coalition (HIEC) Product/Service Code
CODE SOURCE 513: Home Infusion EDI Coalition (HIEC) Product/Service Code List
NU
National Uniform Billing Committee (NUBC) UB92 Codes
This is the NUBC code.
CODE SOURCE 132: National Uniform Billing Committee (NUBC) Codes
WK
Advanced Billing Concepts (ABC) Codes
CODE SOURCE 843: Advanced Billing Concepts (ABC) Codes
Required
1-2
234
Product/Service ID
M 1
AN
1/48
Identifying number for a product or service
INDUSTRY NAME: Procedure Code
  1. If the value in SVC01-1 is "NU", then this element is an NUBC Revenue Code. If the Revenue Code is present in SVC01-2, then SVC04 is not used.
  2. Value submitted on the original claim.
Situational
1-3
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required if submitted on the original claim service line. If not required by this implementation guide, do not send.
Situational
1-4
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required if submitted on the original claim service line. If not required by this implementation guide, do not send.
Situational
1-5
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required if submitted on the original claim service line. If not required by this implementation guide, do not send.
Situational
1-6
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required if submitted on the original claim service line. If not required by this implementation guide, do not send.
Not Used
1-7
352
Description
O 1
AN
1/80
Not Used
1-8
234
Product/Service ID
O 1
AN
1/48
Required
2
782
Monetary Amount
M 1
R
1/18
Monetary amount
SEMANTIC: SVC02 is the submitted service charge.
INDUSTRY NAME: Line Item Charge Amount
Zero is an acceptable amount.
Not Used
3
782
Monetary Amount
O 1
R
1/18
Situational
4
234
Product/Service ID
O 1
AN
1/48
Identifying number for a product or service
SEMANTIC: SVC04 is the National Uniform Billing Committee Revenue Code.
SITUATIONAL RULE: Required on institutional claims to report a NUBC revenue code when a HCPCS or HIPPS code is reported in the SVC01-2. If not required by this implementation guide, do not send.
INDUSTRY NAME: Revenue Code
Not Used
5
380
Quantity
O 1
R
1/15
Not Used
6
C003
Composite Medical Procedure Identifier
O 1
Situational
7
380
Quantity
O 1
R
1/15
Numeric value of quantity
SEMANTIC: SVC07 is the original submitted units of service.
SITUATIONAL RULE: Required if submitted on the original claim service line. If not required by this implementation guide, do not send.
INDUSTRY NAME: Original Units of Service Count

STC - SERVICE LINE LEVEL STATUS INFORMATION

X12 Name:
Status Information
X12 Purpose:
To report the status, required action, and paid information of a claim or service line
Loop:
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
>1
TR3 Notes:
See Section 1.4.2 - Status Information (STC) Segment Usage for specific STC segment information, composites and code use.
TR3 Example:
STC✱A1:19✱✱U~STC✱A8:187✱✱U✱✱✱✱✱✱✱A8:453✱A8:454~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
C043
Health Care Claim Status
M 1
Used to convey status of the entire claim or a specific service line
X12 COMPOSITE SEMANTIC NOTES:
  1. C043-01 is used to specify the logical groupings of Health Care Claim Status Codes (See Code Source 507).
  2. C043-02 is used to identify the status of an entire claim or a serviceline. Code Source 508 is referenced unless qualified by C043-04.
  3. C043-03 identifies the entity associated with the Health Care Claim Status Code.
  4. C043-04 is used to identify the Code Source referenced in C043-02.
Required
1-1
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Category Code
  1. For this business application acknowledgment, use of the Claim Status Category Code is limited to category types `A' for batch. For real time acknowledgements category types `A' and `E' may be used except for E0. Use of the category type `E' is limited to indicating the business application system is unavailable.
  2. CODE SOURCE 507: Health Care Claim Status Category Code
Required
1-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Code
  1. This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
  2. CODE SOURCE 508: Health Care Claim Status Code
Situational
1-3
98
Entity Identifier Code
O 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
SITUATIONAL RULE: Required when an entity must be identified to further clarify the code message in STC01-2. If not required by this implementation guide, may be provided at the sender's discretion but cannot be required by the receiver.
CODE
DEFINITION
03
Dependent
1P
Provider
1Z
Home Health Care
40
Receiver
41
Submitter
71
Attending Physician
72
Operating Physician
73
Other Physician
77
Service Location
82
Rendering Provider
85
Billing Provider
87
Pay-to Provider
DK
Ordering Physician
DN
Referring Provider
DQ
Supervising Physician
FA
Facility
GB
Other Insured
HK
Subscriber
IL
Insured or Subscriber
LI
Independent Lab
MSC
Mammography Screening Center
PR
Payer
PRP
Primary Payer
QB
Purchase Service Provider
QC
Patient
QD
Responsible Party
SEP
Secondary Payer
TL
Testing Laboratory
TTP
Tertiary Payer
TU
Third Party Repricing Organization (TPO)
Not Used
1-4
1270
Code List Qualifier Code
O 1
ID
1/3
Not Used
2
373
Date
O 1
DT
8
Required
3
306
Action Code
O 1
ID
1/2
Code indicating type of action
CODE
DEFINITION
U
Reject
Not Used
4
782
Monetary Amount
O 1
R
1/18
Not Used
5
782
Monetary Amount
O 1
R
1/18
Not Used
6
373
Date
O 1
DT
8
Not Used
7
591
Payment Method Code
O 1
ID
3
Not Used
8
373
Date
O 1
DT
8
Not Used
9
429
Check Number
O 1
AN
1/16
Situational
10
C043
Health Care Claim Status
O 1
Used to convey status of the entire claim or a specific service line
X12 COMPOSITE SEMANTIC NOTES:
  1. C043-01 is used to specify the logical groupings of Health Care Claim Status Codes (See Code Source 507).
  2. C043-02 is used to identify the status of an entire claim or a serviceline. Code Source 508 is referenced unless qualified by C043-04.
  3. C043-03 identifies the entity associated with the Health Care Claim Status Code.
  4. C043-04 is used to identify the Code Source referenced in C043-02.
SITUATIONAL RULE: Required when additional clarification to STC01 is needed. If not required by this implementation guide, do not send.
Required
10-1
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Category Code
  1. See STC01-1 for valid values.
  2. CODE SOURCE 507: Health Care Claim Status Category Code
Required
10-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Code
  1. This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
  2. CODE SOURCE 508: Health Care Claim Status Code
Situational
10-3
98
Entity Identifier Code
O 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
SITUATIONAL RULE: Required when an entity must be identified to further clarify the code message in STC10-2. If not required by this implementation guide, may be provided at the sender's discretion but cannot be required by the receiver.
See STC01-3 for valid values.
CODE
DEFINITION
03
Dependent
1P
Provider
1Z
Home Health Care
40
Receiver
41
Submitter
71
Attending Physician
72
Operating Physician
73
Other Physician
77
Service Location
82
Rendering Provider
85
Billing Provider
87
Pay-to Provider
DK
Ordering Physician
DN
Referring Provider
DQ
Supervising Physician
FA
Facility
GB
Other Insured
HK
Subscriber
IL
Insured or Subscriber
LI
Independent Lab
MSC
Mammography Screening Center
PR
Payer
PRP
Primary Payer
QB
Purchase Service Provider
QC
Patient
QD
Responsible Party
SEP
Secondary Payer
TL
Testing Laboratory
TTP
Tertiary Payer
TU
Third Party Repricing Organization (TPO)
Not Used
10-4
1270
Code List Qualifier Code
O 1
ID
1/3
Situational
11
C043
Health Care Claim Status
O 1
Used to convey status of the entire claim or a specific service line
X12 COMPOSITE SEMANTIC NOTES:
  1. C043-01 is used to specify the logical groupings of Health Care Claim Status Codes (See Code Source 507).
  2. C043-02 is used to identify the status of an entire claim or a serviceline. Code Source 508 is referenced unless qualified by C043-04.
  3. C043-03 identifies the entity associated with the Health Care Claim Status Code.
  4. C043-04 is used to identify the Code Source referenced in C043-02.
SITUATIONAL RULE: Required when additional clarification to STC01 and STC10 is needed. If not required by this implementation guide, do not send.
Required
11-1
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Category Code
  1. See STC01-1 for valid values.
  2. CODE SOURCE 507: Health Care Claim Status Category Code
Required
11-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Code
  1. This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
  2. CODE SOURCE 508: Health Care Claim Status Code
Situational
11-3
98
Entity Identifier Code
O 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
SITUATIONAL RULE: Required when an entity must be identified to further clarify the code message in STC11-2. If not required by this implementation guide, may be provided at the sender's discretion but cannot be required by the receiver.
See STC01-3 for valid values.
CODE
DEFINITION
03
Dependent
1P
Provider
1Z
Home Health Care
40
Receiver
41
Submitter
71
Attending Physician
72
Operating Physician
73
Other Physician
77
Service Location
82
Rendering Provider
85
Billing Provider
87
Pay-to Provider
DK
Ordering Physician
DN
Referring Provider
DQ
Supervising Physician
FA
Facility
GB
Other Insured
HK
Subscriber
IL
Insured or Subscriber
LI
Independent Lab
MSC
Mammography Screening Center
PR
Payer
PRP
Primary Payer
QB
Purchase Service Provider
QC
Patient
QD
Responsible Party
SEP
Secondary Payer
TL
Testing Laboratory
TTP
Tertiary Payer
TU
Third Party Repricing Organization (TPO)
Not Used
11-4
1270
Code List Qualifier Code
O 1
ID
1/3
Situational
12
933
Free-form Message Text
O 1
AN
1/264
Free-form message text
SEMANTIC: STC12 allows additional free-form status information.
SITUATIONAL RULE: Required when Health Care Claim Status Code 448 is used in STC01-2, STC10-2, or STC11-2. If not required by this implementation guide, do not send.
INDUSTRY NAME: Free Form Message Text
See Section 1.4.2.1 for more information on use of STC12 and Status Code `448'.

REF*FJ - SERVICE LINE ITEM IDENTIFICATION

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
This is the Line Item Control Number exactly as submitted in the 837 transaction for the original claim in Loop ID 2400, REF02 (REF01 = 6R). If a Line Item Control Number is not submitted, this will be the line sequence number Loop ID 2400 LX01.
TR3 Example:
REF✱FJ✱001~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
FJ
Line Item Control Number
Required
2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Line Item Control Number
Not Used
3
352
Description
O 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF*XZ - PHARMACY PRESCRIPTION NUMBER

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when a Pharmacy Prescription Number was sent in the 837 at the Service Line. If not required by this implementation guide, do not send.
TR3 Example:
REF✱XZ✱1234567~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
XZ
Pharmacy Prescription Number
Required
2
127
Reference Identification
O 1
AN
1/50
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Pharmacy Prescription Number
Not Used
3
352
Description
O 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

DTP*472 - SERVICE LINE DATE

X12 Name:
Date or Time or Period
X12 Purpose:
To specify any or all of a date, a time, or a time period
Loop:
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the Date of Service from the original submitted claim for a specific line item is present. If not required by this implementation guide, do not send.
TR3 Example:
DTP✱472✱RD8✱20180820-20180825~ ORDTP✱472✱D8✱20180823~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
374
Date/Time Qualifier
M 1
ID
3
Code specifying type of date or time, or both date and time
INDUSTRY NAME: Date Time Qualifier
CODE
DEFINITION
472
Service
Required
2
1250
Date Time Period Format Qualifier
M 1
ID
2/3
Code indicating the date format, time format, or date and time format
SEMANTIC: DTP02 is the date or time or period format that will appear in DTP03.
CODE
DEFINITION
D8
Date Expressed in Format CCYYMMDD
RD8
Range of Dates Expressed in Format CCYYMMDD-CCYYMMDD
Required
3
1251
Date Time Period
M 1
AN
1/35
Expression of a date, a time, or range of dates, times or dates and times
INDUSTRY NAME: Service Line Date

SE - TRANSACTION SET TRAILER

X12 Name:
Transaction Set Trailer
X12 Purpose:
To indicate the end of the transaction set and provide the count of the transmitted segments (including the beginning (ST) and ending (SE) segments)
X12 Comments:
SE is the last segment of each transaction set.
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
SE✱55✱0001~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
96
Number of Included Segments
M 1
N
1/10
Total number of segments included in a transaction set including ST and SE segments
INDUSTRY NAME: Transaction Segment Count
Required
2
329
Transaction Set Control Number
M 1
AN
4/9
Identifying control number that must be unique within the transaction set functional group assigned by the originator for a transaction set
Data value in SE02 must be identical to ST02.

GE - FUNCTIONAL GROUP TRAILER

X12 Name:
Functional Group Trailer
X12 Purpose:
To indicate the end of a functional group and to provide control information
X12 Comments:
The use of identical data interchange control numbers in the associated functional group header and trailer is designed to maximize functional group integrity. The control number is the same as that used in the corresponding header.
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
GE✱1✱1~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
97
Number of Transaction Sets Included
M 1
N
1/6
Total number of transaction sets included in the functional group or interchange (transmission) group terminated by the trailer containing this data element
Required
2
28
Group Control Number
M 1
N
1/9
Assigned number originated and maintained by the sender
SEMANTIC: The data interchange control number GE02 in this trailer must be identical to the same data element in the associated functional group header, GS06.

IEA - INTERCHANGE CONTROL TRAILER

X12 Name:
Interchange Control Trailer
X12 Purpose:
To define the end of an interchange of zero or more functional groups and interchange-related control segments
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
IEA✱1✱000000905~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
I16
Number of Included Functional Groups
M 1
N
1/5
A count of the number of functional groups included in an interchange
Required
2
I12
Interchange Control Number
M 1
N
9
A control number assigned by the interchange sender

277 Health Care Claim Acknowledgment (005010X214, 005010X214E1, 005010X214E2)

MAY 2019

All rights reserved.

Abstract

The ASC X12 Health Care Claim Acknowledgment (277) implementation guide is a business application level acknowledgment for the ASC X12 Health Care Claim (837) transactions. This acknowledges the validity and acceptability of the claims at the pre-processing stage.

Version 1.3

This is the third presentation of this document originally published on 1/1/2007. Errata that does not affect the transmissions between trading partners was published on 4/1/2008 and January 2009. This presentation incorporates those errata documents and is known as an X12 Consolidated Guide which aids in transaction implementation by combining official material into one user friendly document. Although the Consolidated Guides have not been explicitly mandated under HIPAA, they incorporate the individual guides that have been named into a single document. In the event that there is a conflict between the Consolidated Guides and the ASC X12 Type 3 Technical Reports or any subsequent errata, the underlying ASC X12 publications are the authoritative source.

1. Purpose and Business Information

1.1 Implementation Purpose and Scope

For the health care industry to achieve the potential administrative cost savings with Electronic Data Interchange (EDI), standards have been developed and need to be implemented consistently by all organizations. To facilitate a smooth transition into the EDI environment, uniform implementation is critical.

The purpose of this implementation guide is to provide standardized data requirements and content for all users of ASC X12, Health Care Information Status Notification (277). This implementation guide focuses on the use of the 277 as an acknowledgment of receipt of claim submission(s). This implementation guide provides a detailed explanation of the transaction set by defining uniform data content, identifying valid code tables and specifying values applicable for the business focus of the 277 claim submission acknowledgment. The intention of the developers of the 277 is represented in this guide.

Entities receiving this application of the 277 include, but are not limited to, hospitals, nursing homes, laboratories, physicians, dentists, allied health professional groups, employers and supplemental (i.e., other than primary payer) health care claims adjudication processors.

Organizations sending this application of the 277 include payers, who may be insurance companies; Third Party Administrators (TPA); service corporations; state and federal agencies and their contractors; plan purchasers; and any other entity that processes health care claims.

Other business partners affiliated with the 277 include billing services; consulting services; vendors of systems; software and EDI translators; and EDI network intermediaries such as health care clearinghouses, value-added networks and telecommunication services.

1.2 Version Information

This implementation guide is based on the October 2003 ASC X12 standards, referred to as Version 5, Release 1, Sub-release 0 (005010).

The unique Version/Release/Industry Identifier Code for transaction sets that are defined by this implementation guide is 005010X214.

The two-character Functional Identifier Code for the transaction set included in this implementation guide:

  • HN Health Care Information Status Notification (277)

The Version/Release/Industry Identifier Code and the applicable Functional Identifier Code must be transmitted in the Functional Group Header (GS segment) that begins a functional group of these transaction sets. For more information, see the descriptions of GS01 and GS08 in Appendix C, EDI Control Directory.

1.3 Implementation Limitations

1.3.1 Batch and Real-time Usage

There are multiple methods available for sending and receiving business transactions electronically. Two common modes for EDI transactions are batch and real-time.

Batch - In a batch mode the sender does not remain connected while the receiver processes the transactions. Processing is usually completed according to a set schedule. If there is an associated business response transaction (such as a 271 Response to a 270 Request for Eligibility), the receiver creates the response transaction and stores it for future delivery. The sender of the original transmission reconnects at a later time and picks up the response transaction. This implementation guide does not set specific response time parameters for these activities.

Real Time - In real-time mode the sender remains connected while the receiver processes the transactions and returns a response transaction to the sender. This implementation guide does not set specific response time parameters for implementers.

This implementation guide is intended to support use in batch mode. This implementation guide is not intended to support use in real-time mode. A statement that the transaction is not intended to support a specific mode does not preclude its use in that mode between willing trading partners.

1.3.2 Other Usage Limitations

There are usage limitations.

There are Category Code usage limitations between Batch and Real Time. See Section 1.4.2.1 - STC Composite and Code Use Rules for more information.

While not specifically precluded from use, the authors of this implementation guide do not recommend this transaction be used as a "real-time" function. This philosophy is consistent with that expressed in the Health Care Claim submission (ASC X12 837) implementation guides (Dental, Institutional, Professional).

1.4 Business Usage

The ASC X12 Health Care Claim Acknowledgement (277) implementation guide is a business application level acknowledgement for the ASC X12 Health Care Claim (837) transaction(s). This acknowledges the validity and acceptability of the claims at the pre-processing stage.

Payers may pre-process claims to determine whether or not to introduce them to their adjudication system. This pre-adjudication process is performed so claims that are incorrectly formatted or missing information can be corrected and resubmitted by the provider.

The level of editing in pre-adjudication programs will vary from system to system. Although the level of editing may vary, this transaction provides a standard method of reporting acknowledgement of claims. The business function identifies claims that are accepted for adjudication as well as those that are not accepted. This 277 transaction is the only notification of pre-adjudication claim status.

Claims failing the pre-adjudication editing process are not forwarded to the claims adjudication system and therefore are never reported in the ASC X12 Health Care Claim Payment/Advice (835).

Claims passing the pre-adjudication editing process are forwarded to the claims adjudication system and handled according to claims processing guidelines.

Final adjudication of claims is reported in the 835. See Section 1.4.3 Figure 1.2 for the entire transaction flow.

Figure 1.1 - Information Flow of ASC X12 Health Care Claim Acknowledgment

Information Flow of ASC X12 Health Care Claim Acknowledgment

1.4.1 Transaction Participants

The relationships between the hierarchical levels are described by the hierarchical level code data elements, also known as HL01 and HL02. The data element, HL03, identifies the participants within the transaction.

When HL03 = 20, the hierarchical level contains the Information Source. This entity is the decision maker in the business transaction. For this business use, this entity is the payer or clearinghouse generating the 277 Health Care Claim Acknowledgement.

When HL03 = 21, the hierarchical level contains the Information Receiver. This entity expects the response from the Information Source.

When HL03 = 19, the hierarchical level contains the Provider of Service. This entity delivered the health care service.

When HL03 = PT, the hierarchical level contains the Patient information. This entity is the receiver of the health care service.

A detailed view of the segments and data elements used to describe the participants and their relationship is presented below. The segments and data elements are found in Loop ID-2000 and Loop ID-2100.

The Information Receiver and the Provider of Service hierarchical levels have a unique relationship. Information Receiver refers to the entity that processes the detailed information contained within the transaction set. In some cases the Information Receiver is a service bureau entity acting on behalf of the Provider of Service. When this occurs, the service bureau entity is described when the HL03 = 21, and the Provider of Service is described when the HL03 = 19. In other instances, the Information Receiver also is the Provider of Service. When this occurs, the same entity is described at two hierarchical levels (e.g., HL03 = 21 and HL03 = 19).

The coding examples are presented sequentially as found within an actual transaction set; however, for reading ease each segment begins on a new line.

The following is a coding example of the Information Source hierarchical level:

HL*1**20*1~
NM1*PR*2*ABC INSURANCE*****PI*12345~

The following is a coding example of the Information Receiver hierarchical level:

HL*2*1*21*1~
NM1*41*2*ST HOLY HILL HOSPITAL*****46*39999000B~

The following is a coding example of the Provider of Service hierarchical level:

HL*3*2*19*1~
NM1*85*2*FAMILY CLINIC*****FI*401001234~

The following is a coding example of the Patient Hierarchical level:

HL*4*3*PT~
NM1*QC*1*SMITH*JOHN*Q**IV*MI*99887777~

1.4.1.1 Defining the "Patient" Participant

The Patient information identified in the 277 Claim Acknowledgement Transaction is derived from two possible locations within the 837 Transaction.

  • When the patient is the subscriber, the patient name and identification information resides in the 2000B loop of the 837 for Dental, Institutional and Professional transactions.

  • When the patient is a dependent of a subscriber but can be uniquely identified to the payer by a unique identification number, the 837 transaction considers the patient to be the subscriber and the patient name and identification information resides in the 2000B loop of the 837 for Dental, Institutional and Professional transactions.

  • When the patient is a dependent of the subscriber (for example, spouse, children, others) and does not have a unique Identification Number separate from the subscriber, the patient identification number resides in the subscriber 2000B loop while the patient name information resides in the 2000C loop of the 837 for the Dental, Institutional and Professional transactions.

1.4.2 Status Information (STC) Segment Usage

The primary vehicle for the claim status information in the 277 Transaction is the Status Information (STC) Segment. The level of information returned in the STC Segment may vary from payer to payer. Payers are urged to provide the greatest level of detail information. See Section 1.4.2.1 - STC Composite and Code Use Rules, for additional information.

The STC segment contains three iterations of the C043 (Health Care Claim Status) composite within STC01, STC10 and STC11.

The Health Care Claim Status composite (C043) consists of four elements:

The first element in the C043 composite (C043-01) is the Health Care Claim Status Category Code (Code Source 507). The Category Code indicates the level of pre-adjudication status of the claim. This implementation guide will only utilize Category Codes indicating Acknowledgement (Ax) and Errors (Ex).

The second element in the C043 composite (C043-02) is the Health Care Claim Status Code (Code Source 508). The Status Code provides more specific information about the claim or line item. Examples of status messages include "19 - entity acknowledges receipt of claim/encounter" or "122 - missing/ invalid data prevents payer from processing claim".

The third element in the C043 composite (C043-03) is the Entity Identifier Code (ASC X12 data element 98). The Entity Identifier code is used to clarify the entity when referred to in the status message (CO43-02). The code list identifies an organizational entity, a physical location, property, or an individual. A list of appropriate code values for data element 98 appears within the STC segments in Section 2.4.

The fourth element in the C043 composite (C043-04) is the Code List Qualifier Code (ASC X12 data element 1270). This element is Not Used in this version of the implementation guide.

A committee of health care industry representatives from payer, provider and vendor organizations maintains the Health Care Claim Status Category Codes and Health Care Claim Status Codes (Code Sources 507 and 508). They are updated after each ASC X12 trimester meeting. Version specific code additions or deactivations are noted on the code lists.

The Blue Cross Blue Shield Association (BCBSA) is the owner of these code lists. The primary distribution source is the Washington Publishing Company web site (www.wpc-edi.com). This web site offers an online conferencing facility that allows interested parties to submit requests for new codes, changes to existing codes, or simply view comments on pending requests. Individuals who are unable to access the Internet may contact BCBSA directly.

1.4.2.1 STC Composite and Code Use Rules

The following rules apply to use of the composites and codes within the STC segment:

  • STC01 is required

  • STC10 and STC11 are situational and provide additional clarification to STC01 when needed.

  • The Status Category Code for STC10 and STC11 must be within the same Status Category Code group as that used in STC01, but not necessarily the same Status Category Code. (For example, if STC01 uses the Category Code 'A8 - Acknowledgement / Rejected for relational field in error', STC10 and STC11 must use Category Codes from the 'Acknowledgments Category Group' but not necessarily the 'A8' value. STC10 and STC11 could use Category Codes A6 - Acknowledgement/Rejected for Missing Information or A7 - Acknowledgement/Rejected for Invalid Information.)

  • For this business application acknowledgment, use of the Claim Status Category Code is limited to category types 'Ax' for batch. For real time acknowledgements category types 'Ax' and 'Ex' may be used except for E0. Use of the category type 'Ex' is limited to indicating the business application system is unavailable.

  • Use of STC12 and Health Care Status Code value '448 - Invalid billing combination' is limited to Claim and Service level status (Loops 2200D and 2220D).

  • Use of STC12 and Health Care Status Code value '448 - Invalid billing combination' may be used when the assignment of a Health Care Claim Status Code is pending review and publication (between meetings of the Claim Adjustment Reason and Claim Status Code Committee).

  • Additional use of STC12 and Health Care Status Code value '448 - Invalid billing combination' is strongly discouraged by the guide authors as use of the free form text element dilutes the transaction's business purpose and automation capabilities. Use of Category Code A8 - Acknowledgement / Rejected for relational field in error' is encouraged over use of the 448 status code.

  • Multiple STC segments must be reported for unrelated edits or statuses.

1.4.3 277 Transaction Usages

The Health Care Information Status Notification (277) transaction set has multiple implementation conventions to meet various business needs of the health care industry. The transaction set can be used to provide health care claim information in the following business scenarios:

  • ASC X12 Health Care Claim Acknowledgement (277), which is a business application response to the ASC X12 837 claim/encounter transactions. This function is supported in this implementation guide.

  • ASC X12 Health Care Claim Status Request and Response (276/277), where the 277 is a response to a request for claim status information. This function is not supported in this implementation guide.

  • ASC X12 Health Care Claim Request for Additional information (277), which is a payer's request for additional information to support a health care claim. This function is not supported in this implementation guide.

  • ASC X12 Health Care Claim Pending Status Information (277), which is used as a listing of pended claims in a payer's system. This function is not supported in this implementation guide.

Element BHT06, in addition to the ST03 and GS08 values, is used to distinguish between these varied business functions. The various 277 - BHT06 code values are:

  • NO - Notice (Health Care Claim Pending Status Information)

  • TH - Receipt Acknowledgement Advice (Health Care Claim Acknowledgement)

  • RQ - Request (Care Claim Request for Additional Information)

  • DG - Response (Health Care Claim Status Request and Response)

Figure 1.2 illustrates the flow of information related to several usages of the 277.

Figure 1.2 - General ASC X12 Health Care Claim Information Flow

General ASC X12 Health Care Claim Information Flow

1.5 Business Terminology

The following business terms are used in this implementation guide.

Claims

Throughout this implementation guide, the reference to "claim(s)" means claims or encounters or groupings of claims or encounters.

Information Source Process Date

The Information Source Process Date applies to the processing of the 837 claim transaction file through a pre-adjudication/electronic data interchange (EDI) system.

1.6 Transaction Acknowledgments

There are several acknowledgment implementation transactions available for use. The IG developers have noted acknowledgment requirements in this section. Other recommendations of acknowledgment transactions may be used at the discretion of the trading partners. A statement that the acknowledgment is not required does not preclude its use between willing trading partners.

1.6.1 997 Functional Acknowledgment

The 997 informs the submitter that the functional group arrived at the destination. It may include information about the syntactical quality of the functional group.

The Functional Acknowledgment (997) transaction is not required as a response to receipt of a batch transaction compliant with this implementation guide.

The Functional Acknowledgment (997) transaction is not required as a response to receipt of a real-time transaction compliant with this implementation guide.

A 997 Implementation Guide is being developed for use by the insurance industry and is expected to be available for use with this version of this Implementation Guide.

1.6.2 999 Implementation Acknowledgment

The 999 informs the submitter that the functional group arrived at the destination. It may include information about the syntactical quality of the functional group and the implementation guide compliance.

The Implementation Acknowledgment (999) transaction is not required as a response to receipt of a batch transaction compliant with this implementation guide.

The Implementation Acknowledgment (999) transaction is not required as a response to receipt of a real-time transaction compliant with this implementation guide.

A 999 Implementation Guide is being developed for use by the insurance industry and is expected to be available for use with this version of this Implementation Guide.

1.6.3 824 Application Advice

The 824 informs the submitter of the results of the receiving application system's data content edits of transaction sets.

The Application Advice (824) transaction is not required as a response to receipt of a batch transaction compliant with this implementation guide.

The Application Advice (824) transaction is not required as a response to receipt of a real-time transaction compliant with this implementation guide.

An 824 Implementation Guide is being developed for use by the insurance industry and is expected to be available for use with this version of this Implementation Guide.

1.7 Related Transactions

There are one or more transactions related to the transactions described in this implementation guide.

1.7.1 The Claim (837)

Submitting a claim using the 837 format initiates the creation of the Health Care Claim Acknowledgment (277) transaction. This transaction provides confirmation that the receiver has received the claim file and will process or forward the accepted claims on for adjudication. This transaction is instrumental in tracking claim submissions through to payer adjudication.

1.8 Trading Partner Agreements

Trading partner agreements are used to establish and document the relationship between trading partners. A trading partner agreement must not override the specifications in this implementation guide if a transmission is reported in GS08 to be a product of this implementation guide.

1.9 HIPAA Role in Implementation Guides

Administrative Simplification provisions of the Health Insurance Portability and Accountability Act of 1996 (PL 104-191 - known as HIPAA) direct the Secretary of Health and Human Services to adopt standards for transactions to enable health information to be exchanged electronically and to adopt specifications for implementing each standard.

This implementation guide has been developed for use as an insurance industry implementation guide. At the time of publication it has not been adopted as a HIPAA standard. Should the Secretary adopt this implementation guide as a standard, the Secretary will establish compliance dates for its use by HIPAA covered entities.

1.10 Data Overview

This section introduces the structure of the 277 Health Care Information Status Notification and describes the positioning of the business data within the structure. Familiarity with ASC X12 nomenclature, segments, data elements, hierarchical levels, and looping structure is recommended. For a review, see Appendix B, Nomenclature and Appendix C, EDI Control Directory.

1.10.1 Overall Data Architecture

Two formats, or views, are used to present the transaction set: the implementation view and the standard view. The intent of the implementation view is to clarify the purpose and use of the segments by restricting the view to display only those segments used with their assigned health care names. The implementation view for the 277 is presented in Section 2.3.1, Implementation. The standard view for the 277 displays all segments available within the transaction set with their assigned ASC X12 names. This view is presented in Section 2.3.2, X12 Standard.

The transaction set is divided into two levels, or tables, Table 1 and Table 2.

Table 1

Table 1 is named the Header Level and contains the transaction control information. The ST segment identifies the start of a transaction and the specific transaction set. The BHT identifies the transactions business purpose and the hierarchical structure used in Table 2.

Table 2

Table 2 is named the Detail Level because it contains the detail information for the business function of the transactions. This table uses the hierarchical level structure. Each hierarchical level (HL) is a series of loops, which are identified by numbers. The hierarchical level that identifies the patient is Loop ID- 2000D. The patient name is contained in Loop ID-2100D. Specific claim details begin with Loop ID-2200D.

The following are HL segment coding examples and the data element significance within the HL segments:

HL*1**20*1~

Information Source level

HL*2*1*21*1~

Information Receiver level

HL*3*2*19*1~

Service Provider level

HL*4*3*PT~

Patient level
  • HLs are sequentially numbered. The sequential number is found in HL01, which is the first data element in the HL segment.

  • The second element, HL02, indicates the sequential number of the parent hierarchical level to which this hierarchical level is subordinate. The absence of a data value in HL02, indicates it is the highest hierarchical level. In this example, the Information Source is the highest parent. The Information Receiver level is subordinate to the Information Source hierarchical level numbered 1 (HL01 =1). The provider of service level is subordinate to the Information Receiver hierarchical level numbered 2 (HL01=2), etc.

  • The data value in data element HL03 describes the hierarchical level entity. For example, when HL03 = 20, the hierarchical level is the Information Source. When HL03 = PT, the hierarchical level is the Patient.

  • Data element HL04 indicates whether or not child (subordinate) hierarchical levels exist. A value of "1" indicates subordinate hierarchical levels exist. A value of "0" or the absence of a data value indicates that no subordinate hierarchical levels exist.

2. Transaction Set

NOTE

See Appendix B, Nomenclature, to review the transaction set structure, including descriptions of segments, data elements, levels, and loops.

2.1 Presentation Examples

The ASC X12 standards are generic. For example, multiple trading communities use the same PER segment to specify administrative communication contacts. Each community decides which elements to use and which code values in those elements are applicable.

This implementation guide uses a format that depicts both the generalized standard and the insurance industry-specific implementation. In this implementation guide, IMPLEMENTATION specifies the requirements for this implementation. X12 STANDARD is included as a reference only.

The transaction set presentation is comprised of two main sections with subsections within the main sections:

2.3 Transaction Set Listing

There are two sub-sections under this general title. The first sub-section concerns this implementation of a generic X12 transaction set. The second sub-section concerns the generic X12 standard itself.

This section lists the levels, loops, and segments contained in this implementation. It also serves as an index to the segment detail.

This section is included as a reference.

2.4 Segment Detail

There are three sub-sections under this general title. This section repeats once for each segment used in this implementation providing segment specific detail and X12 standard detail.

This section is included as a reference.

This section is included as a reference. It provides a pictorial view of the standard and shows which elements are used in this implementation.

This section specifies the implementation details of each data element.

These illustrations (Figures 2.1 through 2.5) are examples and are not extracted from the Section 2 detail in this implementation guide. Annotated illustrations, presented below in the same order they appear in this implementation guide, describe the format of the transaction set that follows.

Figure 2.1 - Transaction Set Key - Implementation

Transaction Set Key - Implementation

Figure 2.2 - Transaction Set Key - Standard

Transaction Set Key - Standard

Figure 2.3 - Segment Key - Implementation

Segment Key - Implementation

Figure 2.4 - Segment Key - Diagram

Segment Key - Diagram

Figure 2.5 - Segment Key - Element Summary

Segment Key - Element Summary

2.2 Implementation Usage

2.2.1 Industry Usage

Industry Usage describes when loops, segments, and elements are to be sent when complying with this implementation guide. The three choices for Usage are required, not used, and situational. To avoid confusion, these are named differently than the X12 standard Condition Designators (mandatory, optional, and relational).

Required

This loop/segment/element must always be sent.

Required segments in Situational loops only occur when the loop is used.

Required elements in Situational segments only occur when the segment is used.

Required component elements in Situational composite elements only occur when the composite element is used.

Not Used

This element must never be sent.

Situational

Use of this loop/segment/element varies, depending on data content and business context as described in the defining rule. The defining rule is documented in a Situational Rule attached to the item.

There are two forms of Situational Rules.

The first form is "Required when <explicit condition statement>. If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver." The data qualified by such a situational rule cannot be required or requested by the receiver, transmission of this data is solely at the sender's discretion.

The alternative form is "Required when <explicit condition statement>. If not required by this implementation guide, do not send." The data qualified by such a situational rule cannot be sent except as described in the explicit condition statement.

2.2.1.1 Transaction Compliance Related to Industry Usage

A transmitted transaction complies with an implementation guide when it satisfies the requirements as defined within the implementation guide. The presence or absence of an item (loop, segment, or element) complies with the industry usage specified by this implementation guide according to the following table.

Required

Business condition: N/A

Item is Transaction complies with implementation guide?
Sent Yes
Not Sent No
Not Used

Business condition: N/A

Item is Transaction complies with implementation guide?
Sent No
Not Sent Yes
Situational (Required when [explicit condition statement])

If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.

Business Condition is Item is Transaction complies with implementation guide?
True Sent Yes
Not Sent No
Not True Sent Yes
Not Sent Yes
Situational (Required when [explicit condition statement])

If not required by this implementation guide, do not send.

Business Condition is Item is Transaction complies with implementation guide?
True Sent Yes
Not Sent No
Not True Sent No
Not Sent Yes

2.2.2 Loops

Loop requirements depend on the context or location of the loop within the transaction. See Appendix B for more information on loops.

  • A nested loop can be used only when the associated higher level loop is used.

  • The usage of a loop is the same as the usage of its beginning segment.

    • If a loop's beginning segment is Required, the loop is Required and must occur at least once unless it is nested in a loop that is not being used.

    • If a loop's beginning segment is Situational, the loop is Situational.

  • Subsequent segments within a loop can be sent only when the beginning segment is used.

  • Required segments in Situational loops occur only when the loop is used.

3. Examples

3.1 Business Scenario 1: Clearinghouse Example - Accepted File (some claims rejected)

In the following example, Best Billing Service (Electronic Transmitter ID Number S00001) submitted an 837 Professional claim file to First Clearinghouse (Electronic Transmitter ID Number CLHR00) on February 5, 2006 for Smith Clinic (Employer Tax ID Number 123456789). First Clearinghouse processed the file on February 5, 2006 and notified Best Billing Service that although the file for charges totaling $1,000.00 was accepted, there were individual claims that were rejected. Following is the status information for the claims contained in the 837 claims transmission file:

John Doe's (Member ID Number 00ABCD1234) claim for $200.00 for dates of service January 28, 2006 through January 31, 2006 was accepted and forwarded to the payer.

Jane Doe's (Member ID Number 45613027602) claim for $500.00 for date of service January 15, 2006 was rejected because it is missing the rendering provider number on the service/detail line with the HCPC procedure code of "22305" with a modifier of "22" for a charge of $350.00. This is required for the payer to process the claim, so the clearinghouse has established an edit to prohibit acceptance of claims without the necessary identification number.

Helen Vest's (Member ID Number 45602708901) claim for $300.00 for date of service January 20, 2006 was rejected because the source of payment (claim filing indicator) was not valid for the payer for this claim.

ST*277*0001*005010X214~
BHT*0085*08*277X2140001*20060205*1635*TH~
HL*1**20*1~
NM1*AY*2*FIRST CLEARINGHOUSE*****46*CLHR00~
TRN*1*200102051635S00001ABCDEF~
DTP*050*D8*20060205~
DTP*009*D8*20060205~
HL*2*1*21*1~
NM1*41*2*BEST BILLING SERVICE*****46*S00001~
TRN*2*2002020542857~
STC*A0:16:PR*20060205*WQ*1000~
QTY*90*1~
QTY*AA*2~
AMT*YU*200~
AMT*YY*800~
HL*3*2*19*1~
NM1*85*2*SMITH CLINIC*****FI*123456789~
HL*4*3*PT~
NM1*QC*1*DOE*JOHN****MI*00ABCD1234~
TRN*2*DOE01428~
STC*A0:16:PR*20060205*WQ*200~
REF*1K*22029500123407X~
DTP*472*RD8*20060128-20060131~
HL*5*3*PT~
NM1*QC*1*DOE*JANE****MI*45613027602~
TRN*2*DOE0221~
STC*A3:21:82*20060205*U*500~
DTP*472*D8*20060115~
SVC*HC:22305:22*350*****1~
STC*A3:122**U*******A3:153:82~
REF*FJ*11~
HL*6*3*PT~
NM1*QC*1*VEST*HELEN****MI*45602708901~
TRN*2*VEST0303~
STC*A3:401*20060205*U*300~
DTP*472*RD8*20060120-20060120~
SE*37*0001~

3.2 Business Scenario 2: Clearinghouse Example - Rejected File (invalid submitter)

In the following example, Last Billing Service (Electronic transmitter ID number S00002) submitted an 837 Professional claim file with 3 claims totaling $800.00 to First Clearinghouse (Electronic transmitter ID number CLHR00) on January 31, 2006 for Smith Clinic. This file was transmitted after the cutoff time for same day processing, so First Clearinghouse processed the file on February 1, 2006 and notified Last Billing Service on February 1, 2006 that their file was rejected as they have not completed the trading partner enrollment process, therefore, they are not a valid trading partner with First Clearinghouse. Please note that the 277 acknowledgment is immediately terminated and no additional hierarchical levels are sent/acknowledged.

ST*277*0002*005010X214~
BHT*0085*08*277X2140002*20060201*0405*TH~
HL*1**20*1~
NM1*AY*2*FIRST CLEARINGHOUSE*****46*CLHR00~
TRN*1*200201312005S00002XYZABC~
DTP*050*D8*20060131~
DTP*009*D8*20060201~
HL*2*1*21*0~
NM1*41*2*LAST BILLING SERVICE*****46*S00002~
TRN*2*20020131052389~
STC*A3:24:41**U~
QTY*AA*3~
AMT*YY*800~
SE *14*00002~

3.3 Business Scenario 3: Payer Response - Accepted File (some claims rejected)

In the following example, Dr. Harry B. Jones (Electronic Transmitter ID Number S00003) submitted an 837 Professional claim file with inventory file number 2002022045678 in BHT03 directly to "Your Insurance Company" (Payer ID Number YIC01) on February 20, 2006 for himself (Tax ID Number 234567894). Your Insurance Company processed the file on February 21, 2006 and notified Dr. Jones that although the file containing five claims for charges totaling $365.50 was accepted, there were two individual claims that were rejected. Following is the status information for the claims contained in the 837 claims transmission file:

Female Patient's (Member ID Number 2222222222) claim for $100.00 for date of service February 14, 2006 was accepted and an internal claim control number of 220216359803X was assigned to this claim.

Male Patient's (Member ID Number 3333333333) claim for $65.00 was rejected because the date of service was either missing or invalid. (Note that the DTP segment is not present within this loop since most translators will not generate/echo an invalid date.)

Larry Jones' (Member ID Number 4444444444) claim for $100.00 for date of service February 11, 2006 was rejected because the place of service was missing or invalid.

Mary Johnson's (Member ID Number 5555555555) claim for $50.50 for date of service February 10, 2006 was accepted and an internal claim control number of 220216359806X was assigned to this claim.

Harriett Mills' (Member ID Number 6666666666) claim for $50.00 for date of service February 5, 2006 was accepted and an internal claim control number of 220216359807X was assigned to this claim.

ST*277*0003*005010X214~
BHT*0085*08*277X2140003*20060221*1025*TH~
HL*1**20*1~
NM1*PR*2*YOUR INSURANCE COMPANY*****PI*YIC01~
TRN*1*0091182~
DTP*050*D8*20060220~
DTP*009*D8*20060221~
HL*2*1*21*1~
NM1*41*1*JONES*HARRY*B**MD*46*S00003~
TRN*2*2002022045678~
STC*A1:19:PR*20060221*WQ*365.5~
QTY*90*3~
QTY*AA*2~
AMT*YU*200.5~
AMT*YY*165~
HL*3*2*19*1~
NM1*85*1*JONES*HARRY*B**MD*FI*234567894~
HL*4*3*PT~
NM1*QC*1*PATIENT*FEMALE****MI*2222222222~
TRN*2*PATIENT22222~
STC*A2:20:PR*20060221*WQ*100~
REF*1K*220216359803X~
DTP*472*RD8*20060214~
HL*5*3*PT~
NM1*QC*1*PATIENT*MALE****MI*3333333333~
TRN*2*PATIENT33333~
STC*A3:187:PR*20060221*U*65~
DTP*472*20090221~
HL*6*3*PT~
NM1*QC*1*JONES*LARRY****MI*4444444444~
TRN*2*JONES44444~
STC*A3:21:77*20060221*U*100~
DTP*472*D8*20060211~
HL*7*3*PT~
NM1*QC*1*JOHNSON*MARY****MI*5555555555~
TRN*2*JOHNSON55555~
STC*A2:20:PR*20060221*WQ*50.5~
REF*1K*220216359806X~
DTP*472*D8*20060210~
HL*8*3*PT~
NM1*QC*1*MILLS*HARRIETT****MI*6666666666~
TRN*2*MILLS66666~
STC*A2:20:PR*20060221*WQ*50~
REF*1K*220216359807X~
DTP*472*D8*20060205~
SE*46*0003~

3.4 Business Scenario 4: Payer Response - 1st Provider - Claims Accepted and 2nd Provider - Claims Rejected

In the following example, Dr. Ewell B King (Electronic transmitter ID number S00005) submitted an 837 Professional claim file to "Our Insurance Company" (Payer ID Number OIC02) on March 20, 2006 for himself and Dr. I. B. Reed (SSN-56701234). This file was transmitted after the cutoff time for same day processing, so Our Insurance Company processed the file on March 21, 2006 and notified Dr. King on March 21, 2006 that although the file of eight claims for charges totaling $455.00 was accepted, there were individual claims (two) that were rejected and that all three of Dr. Reed's claims were rejected as he has not completed the trading partner enrollment process to be an electronic submitter. Please note that the 277 acknowledgment is immediately terminated and no additional hierarchical levels are sent related to Dr. Reed's claims.

Following is the status information for Dr. King's the claims contained in the 837 claims transmission file:

Female Patient's (Member ID Number 2222222222) claim for $55.00 for date of service March 14, 2006 was accepted and an internal claim control number of 220216359803X was assigned to this claim.

Male Patient's (Member ID Number 3333333333) claim for $50.00 was rejected because the date of service was either missing or invalid. (Note that the DTP segment is not present within this loop since most translators will not generate/echo an invalid date.)

Mary Jones' (Member ID Number 4444444444) claim for $100.00 for date of service March 11, 2006 was rejected because the claim was submitted to the wrong payer.

Jimmy Johnson's (Member ID Number 5555555555) claim for $50.00 for date of service March 10, 2006 was accepted and an internal claim control number of 220216359806X was assigned to this claim.

Haley Mills' (Member ID Number 6666666666) claim for $50.00 for date of service March 5, 2006 was accepted and an internal claim control number of 220216359807X was assigned to this claim.

All 3 of Dr. Reed's claims totaling $150.00 were rejected because the Billing Provider (Dr. Reed) is not approved as an electronic submitter.

ST*277*0004*005010X214~
BHT*0085*08*277X2140004*20060321*1025*TH~
HL*1**20*1~
NM1*PR*2*OUR INSURANCE COMPANY*****PI*OIC02~
TRN*1*00911232~
DTP*050*D8*20060320~
DTP*009*D8*20060321~
HL*2*1*21*1~
NM1*41*1*KING*EWELL*B**MD*46*S00005~
TRN*2*200203207890~
STC*A1:19:PR*20060321*WQ*455~
QTY*90*3~
QTY*AA*5~
AMT*YU*155~
AMT*YY*300~
HL*3*2*19*1~
NM1*85*1*KING*EWELL*B**MD*XX*5365432101~
TRN*2*00098765432~
STC*A1:19:PR**WQ*305~
HL*4*3*PT~
NM1*QC*1*PATIENT*FEMALE****MI*2222222222~
TRN*2*PATIENT22222~
STC*A2:20:PR*20060321*WQ*55~
REF*1K*220216359803X~
DTP*472*D8*20060314~
HL*5*3*PT~
NM1*QC*1*PATIENT*MALE****MI*3333333333~
TRN*2*PATIENT33333~
STC*A3:187:PR*20060321*U*50~
HL*6*3*PT~
NM1*QC*1*JONES*MARY****MI*4444444444~
TRN*2*JONES44444~
STC*A3:116*20060321*U*100~
DTP*472*D8*20060311~
HL*7*3*PT~
NM1*QC*1*JOHNSON*JIMMY****MI*5555555555~
TRN*2*JOHNSON55555~
STC*A2:20:PR*20060321*WQ*50~
REF*1K*220216359806X~
DTP*472*D8*20060310~
HL*8*3*PT~
NM1*QC*1*MILLS*HALEY****MI*6666666666~
TRN*2*MILLS66666~
STC*A2:20:PR*20060321*WQ*50~
REF*1K*220216359807X~
DTP*472*D8*20060305~
HL*9*2*19*0~
NM1*85*1*REED*I*B**MD*FI*567012345~
TRN*2*00023456789~
STC*A3:24:85*20060321*U*150~
QTY*QC*3~
AMT*YY*150~
SE*53*0004~

Appendix A. External Code Sources

A.1 External Code Sources

130 Healthcare Common Procedure Coding System

SIMPLE DATA ELEMENT/CODE REFERENCES

235/HC, 1270/BO, 1270/BP

SOURCE

Healthcare Common Procedure Coding System

AVAILABLE FROM

Centers for Medicare & Medicaid Services (CMS)

7500 Security Boulevard

Baltimore, MD 21244

ABSTRACT

HCPCS is Centers for Medicare & Medicaid Services (CMS) coding scheme to group procedures performed for payment to providers.

132 National Uniform Billing Committee (NUBC) Codes

SIMPLE DATA ELEMENT/CODE REFERENCES

235/NU, 235/RB, 1270/BE, 1270/BG, 1270/BH, 1270/BI, 1270/NUB

SOURCE

National Uniform Billing Data Element Specifications

AVAILABLE FROM

National Uniform Billing Committee

American Hospital Association

One North Franklin

Chicago, IL 60606

ABSTRACT

Revenue codes are a classification of hospital charges in a standard grouping that is controlled by the National Uniform Billing Committee.

135 American Dental Association

SIMPLE DATA ELEMENT/CODE REFERENCES

1361, 235/AD, 1270/JO, 1270/JP, 1270/TQ, 1270/AAY

SOURCE

Current Dental Terminology (CDT) Manual

AVAILABLE FROM

Salable Materials

American Dental Association

211 East Chicago Avenue

Chicago, IL 60611-2678

ABSTRACT

The CDT manual contains the American Dental Association's codes for dental procedures and nomenclature and is the accepted set of numeric codes and descriptive terms for reporting dental treatments and descriptors.

507 Health Care Claim Status Category Code

SIMPLE DATA ELEMENT/CODE REFERENCES

1271

SOURCE

Health Care Claim Status Category Code

AVAILABLE FROM

The Blue Cross Blue Shield Association Interplan Teleprocessing Services Division 676 North St. Clair Street Chicago, IL 60611

ABSTRACT

Code used to organize the Health Care Claim Status Codes into logical groupings

508 Health Care Claim Status Code

SIMPLE DATA ELEMENT/CODE REFERENCES

1271, 1270/65

SOURCE

Health Care Claim Status Code

AVAILABLE FROM

The Blue Cross Blue Shield Association Interplan Teleprocessing Services Division 676 North St. Clair Street Chicago, IL 60611

ABSTRACT

Code identifying the status of an entire claim or service line

513 Home Infusion EDI Coalition (HIEC) Product/Service Code List

SIMPLE DATA ELEMENT/CODE REFERENCES

235/IV, 1270/HO

SOURCE

Home Infusion EDI Coalition (HIEC) Coding System

AVAILABLE FROM

HIEC Chairperson

HIBCC (Health Industry Business Communications Council)

5110 North 40th Street

Suite 250

Phoenix, AZ 85018

ABSTRACT

This list contains codes identifying home infusion therapy products/services.

537 Centers for Medicare & Medicaid Services National Provider Identifier

SIMPLE DATA ELEMENT/CODE REFERENCES

66/XX, 128/HPI

SOURCE

National Provider System

AVAILABLE FROM

Centers for Medicare & Medicaid Services

Office of Financial Management

Division of Provider/Supplier Enrollment

C4-10-07

7500 Security Boulevard

Baltimore, MD 21244-1850

ABSTRACT

The Centers for Medicare & Medicaid Services is developing the National Provider Identifier (NPI), which has been proposed as the standard unique identifier for each health care provider under the Health Insurance Portability and Accountability Act of 1996.

540 Centers for Medicare and Medicaid Services PlanID

SIMPLE DATA ELEMENT/CODE REFERENCES

66/XV, 128/ABY

SOURCE

PlanID Database

AVAILABLE FROM

Centers for Medicare and Medicaid Services

Center of Beneficiary Services, Membership Operations Group

Division of Benefit Coordination

S1-05-06

7500 Security Boulevard

Baltimore, MD 21244-1850

ABSTRACT

The Centers for Medicare and Medicaid Services has joined with other payers to develop a unique national payer identification number. The Centers for Medicare and Medicaid Services is the authorizing agent for enumerating payers through the services of a PlanID Registrar. It may also be used by other payers on a voluntary basis.

576 Workers Compensation Specific Procedure and Supply Codes

SIMPLE DATA ELEMENT/CODE REFERENCES

235/ER

SOURCE

IAIABC Jurisdiction Medical Bill Report Implementation Guide

AVAILABLE FROM

IAIABC EDI Implementation Manager

International Association of Industrial Accident Boards and Commissions

8643 Hauses - Suite 200

87th Parkway

Shawnee Mission, KS 66215

ABSTRACT

The IAIABC Jurisdiction Medical Bill Report Implementation Guide describes the requirements for submitting and the data contained within a jurisdiction medical report. The Implementation Guide includes: Reporting scenarios, data definitions, trading partner requirements tables, reference to industry codes, and IAIABC maintained code lists.

716 Health Insurance Prospective Payment System (HIPPS) Rate Code for Skilled Nursing Facilities

SIMPLE DATA ELEMENT/CODE REFERENCES

235/HP

SOURCE

Health Insurance Prospective Payment System (HIPPS) Rate Code for Skilled Nursing Facilities

AVAILABLE FROM

Division of Institutional Claims Processing

Centers for Medicare and Medicaid Services

C4-10-07

7500 Security Boulevard

Baltimore, MD 21244-1850

ABSTRACT

The Centers for Medicare and Medicaid services develops and publishes the HIPPS codes to establish a coding system for claims submission and claims payment under prospective payment systems. These codes represent the case mix classification groups that are used to determine payment rates under prospective payment systems. Case mix classification groups include, but may not be limited to, resource utilization groups (RUGs) for skilled nursing facilities, home health resource groups (HHRGs) for home health agencies, and case mix groups (CMGs) for inpatient rehabilitation facilities.

843 Advanced Billing Concepts (ABC) Codes

SIMPLE DATA ELEMENT/CODE REFERENCES

235/WK, 1270/CAH

SOURCE

The CAM and Nursing Coding Manual

AVAILABLE FROM

Alternative Link

6121 Indian School Road NE

Suite 131

Albuquerque, NM 87110

ABSTRACT

The manual contains the Advanced Billing Concepts (ABC) codes, descriptive terms and identifiers for reporting complementary or alternative medicine, nursing, and other integrative health care procedures.

Appendix B. Nomenclature

B.1 ASC X12 Nomenclature

B.1.1 Interchange and Application Control Structures

Appendix B is provided as a reference to the X12 syntax, usage, and related information. It is not a full statement of Interchange and Control Structure rules. The full X12 Interchange and Control Structures and other rules (X12.5, X12.6, X12.59, X12 dictionaries, other X12 standards and official documents) apply unless specifically modified in the detailed instructions of this implementation guide (see Section B.1.1.3.1.2 - Decimal for an example of such a modification).

B.1.1.1 Interchange Control Structure

The transmission of data proceeds according to very strict format rules to ensure the integrity and maintain the efficiency of the interchange. Each business grouping of data is called a transaction set. For instance, a group of benefit enrollments sent from a sponsor to a payer is considered a transaction set.

Each transaction set contains groups of logically related data in units called segments. For instance, the N4 segment used in the transaction set conveys the city, state, ZIP Code, and other geographic information. A transaction set contains multiple segments, so the addresses of the different parties, for example, can be conveyed from one computer to the other. An analogy would be that the transaction set is like a freight train; the segments are like the train's cars; and each segment can contain several data elements the same as a train car can hold multiple crates.

The sequence of the elements within one segment is specified by the ASC X12 standard as well as the sequence of segments in the transaction set. In a more conventional computing environment, the segments would be equivalent to records, and the elements equivalent to fields.

Similar transaction sets, called "functional groups," can be sent together within a transmission. Each functional group is prefaced by a group start segment; and a functional group is terminated by a group end segment. One or more functional groups are prefaced by an interchange header and followed by an interchange trailer. Figure B.1 - Transmission Control Schematic, illustrates this interchange control.

Figure B.1 - Transmission Control Schematic

Transmission Control Schematic

The interchange header and trailer segments envelop one or more functional groups or interchange-related control segments and perform the following functions:

  1. Define the data element separators and the data segment terminator.

  2. Identify the sender and receiver.

  3. Provide control information for the interchange.

  4. Allow for authorization and security information.

B.1.1.2 Application Control Structure Definitions and Concepts

B.1.1.2.1 Basic Structure

A data element corresponds to a data field in data processing terminology. A data segment corresponds to a record in data processing terminology. The data segment begins with a segment ID and contains related data elements. A control segment has the same structure as a data segment; the distinction is in the use. The data segment is used primarily to convey user information, but the control segment is used primarily to convey control information and to group data segments.

B.1.1.2.2 Basic Character Set

The section that follows is designed to have representation in the common character code schemes of EBCDIC, ASCII, and CCITT International Alphabet 5. The ASC X12 standards are graphic-character-oriented; therefore, common character encoding schemes other than those specified herein may be used as long as a common mapping is available. Because the graphic characters have an implied mapping across character code schemes, those bit patterns are not provided here.

The basic character set of this standard, shown in Table B.1 - Basic Character Set, includes those selected from the uppercase letters, digits, space, and special characters as specified below.

Table B.1 - Basic Character Set

A...Z 0...9 ! " & ' ( ) + *
, - . / : ; ? = ” (space)

B.1.1.2.3 Extended Character Set

An extended character set may be used by negotiation between the two parties and includes the lowercase letters and other special characters as specified in Table B.2 - Extended Character Set.

Table B.2 - Extended Character Set

a...z % ~ @ [ ] _ { }
\ | < > ^ ` # $

Note that the extended characters include several character codes that have multiple graphical representations for a specific bit pattern. The complete list appears in other standards such as CCITT S.5. Use of the USA graphics for these codes presents no problem unless data is exchanged with an international partner. Other problems, such as the translation of item descriptions from English to French, arise when exchanging data with an international partner, but minimizing the use of codes with multiple graphics eliminates one of the more obvious problems.

For implementations compliant with this guide, either the entire extended character set must be acceptable, or the entire extended character set must not be used. In the absence of a specific trading partner agreement to the contrary, trading partners will assume that the extended character set is acceptable. Use of the extended character set allows the use of the "@" character in email addresses within the PER segment. Users should note that characters in the extended character set, as well as the basic character set, may be used as delimiters only when they do not occur in the data as stated in Section B.1.1.2.4.1 - Base Control Set.

B.1.1.2.4 Control Characters

Two control character groups are specified; they have restricted usage. The common notation for these groups is also provided, together with the character coding in three common alphabets. In Table B.3 - Base Control Set, the column IA5 represents CCITT V.3 International Alphabet 5.

B.1.1.2.4.1 Base Control Set

The base control set includes those characters that will not have a disruptive effect on most communication protocols. These are represented by:

Table B.3 - Base Control Set

NOTATIONNAMEEBCDICASCIIIA5
BELbell2F0707
HThorizontal tab050909
LFline feed250A0A
VTvertical tab0B0B0B
FFform feed0C0C0C
CRcarriage return0D0D0D
FSfile separator1C1C1C
GSgroup separator1D1D1D
RSrecord separator1E1E1E
USunit separator1F1F1F
NL new line 15

The Group Separator (GS) may be an exception in this set because it is used in the 3780 communications protocol to indicate blank space compression.

B.1.1.2.4.2 Extended Control Set

The extended control set includes those that may have an effect on a transmission system. These are shown in Table B.4 - Extended Control Set.

Table B.4 - Extended Control Set

NOTATIONNAMEEBCDICASCIIIA5
SOHstart of header010101
STXstart of text020202
ETXend of text030303
EOTend of transmission370404
ENQenquiry2D0505
ACKacknowledge2E0606
DC1device control 1111111
DC2device control 2121212
DC3device control 3131313
DC4device control 43C1414
NAKnegative acknowledge3D1515
SYNsynchronous idle321616
ETBend of block261717
B.1.1.2.5 Delimiters

A delimiter is a character used to separate two data elements or component elements or to terminate a segment. The delimiters are an integral part of the data.

Delimiters are specified in the interchange header segment, ISA. The ISA segment can be considered in implementations compliant with this guide (see Appendix C, ISA Segment Note 1) to be a 105 byte fixed length record, followed by a segment terminator. The data element separator is byte number 4; the repetition separator is byte number 83; the component element separator is byte number 105; and the segment terminator is the byte that immediately follows the component element separator.

Once specified in the interchange header, the delimiters are not to be used in a data element value elsewhere in the interchange. For consistency, this implementation guide uses the delimiters shown in Table B.5 - Delimiters, in all examples of EDI transmissions.

Table B.5 - Delimiters

CHARACTERNAMEDELIMITER
*AsteriskData Element Separator
^CaratRepetition Separator
:ColonComponent Element Separator
~TildeSegment Terminator

The delimiters above are for illustration purposes only and are not specific recommendations or requirements. Users of this implementation guide should be aware that an application system may use some valid delimiter characters within the application data. Occurrences of delimiter characters in transmitted data within a data element will result in errors in translation. The existence of asterisks (*) within transmitted application data is a known issue that can affect translation software.

B.1.1.3 Business Transaction Structure Definitions and Concepts

The ASC X12 standards define commonly used business transactions (such as a health care claim) in a formal structure called "transaction sets." A transaction set is composed of a transaction set header control segment, one or more data segments, and a transaction set trailer control segment. Each segment is composed of the following:

  • A unique segment ID

  • One or more logically related data elements each preceded by a data element separator

  • A segment terminator

B.1.1.3.1 Data Element

The data element is the smallest named unit of information in the ASC X12standard. Data elements are identified as either simple or component. A data element that occurs as an ordinally positioned member of a composite data structure is identified as a component data element. A data element that occurs in a segment outside the defined boundaries of a composite data structure is identified as a simple data element. The distinction between simple and component data elements is strictly a matter of context because a data element can be used in either capacity.

Data elements are assigned a unique reference number. Each data element has a name, description, type, minimum length, and maximum length. For ID type data elements, this guide provides the applicable ASC X12 code values and their descriptions or references where the valid code list can be obtained.

A simple data element within a segment may have an attribute indicating that it may occur once or a specific number of times more than once. The number of permitted repeats are defined as an attribute in the individual segment where the repeated data element occurs.

Each data element is assigned a minimum and maximum length. The length of the data element value is the number of character positions used except as noted for numeric, decimal, and binary elements.

The data element types shown in Table B.6 - Data Element Types, appear in this implementation guide.

Table B.6 - Data Element Types

SYMBOLTYPE
NnNumeric
RDecimal
IDIdentifier
ANString
DTDate
TMTime
BBinary

The data element minimum and maximum lengths may be restricted in this implementation guide for a compliant implementation. Such restrictions may occur by virtue of the allowed qualifier for the data element or by specific instructions regarding length or format as stated in this implementation guide.

B.1.1.3.1.1 Numeric

A numeric data element is represented by one or more digits with an optional leading sign representing a value in the normal base of 10. The value of a numeric data element includes an implied decimal point. It is used when the position of the decimal point within the data is permanently fixed and is not to be transmitted with the data.

This set of guides denotes the number of implied decimal positions. The representation for this data element type is "Nn" where N indicates that it is numeric and n indicates the number of decimal positions to the right of the implied decimal point.

If n is 0, it need not appear in the specification; N is equivalent to N0. For negative values, the leading minus sign (-) is used. Absence of a sign indicates a positive value. The plus sign (+) must not be transmitted.

EXAMPLE

A transmitted value of 1234, when specified as numeric type N2, represents a value of 12.34.

Leading zeros must be suppressed unless necessary to satisfy a minimum length requirement. The length of a numeric type data element does not include the optional sign.

B.1.1.3.1.2 Decimal

A decimal data element may contain an explicit decimal point and is used for numeric values that have a varying number of decimal positions. This data element type is represented as "R."

The decimal point always appears in the character stream if the decimal point is at any place other than the right end. If the value is an integer (decimal point at the right end) the decimal point must be omitted. For negative values, the leading minus sign (-) is used. Absence of a sign indicates a positive value. The plus sign (+) must not be transmitted.

Leading zeros must be suppressed unless necessary to satisfy a minimum length requirement. Trailing zeros following the decimal point must be suppressed unless necessary to indicate precision. The use of triad separators (for example, the commas in 1,000,000) is expressly prohibited. The length of a decimal type data element does not include the optional leading sign or decimal point.

EXAMPLE

A transmitted value of 12.34 represents a decimal value of 12.34.

While the ASC X12 standard supports usage of exponential notation, this guide prohibits that usage.

For implementation of this guide under the rules promulgated under the Health Insurance Portability and Accountability Act (HIPAA), decimal data elements in Data Element 782 (Monetary Amount) will be limited to a maximum length of 10 characters including reported or implied places for cents (implied value of 00 after the decimal point). Note the statement in the preceding paragraph that the decimal point and leading sign, if sent, are not part of the character count.

EXAMPLE

For implementations mandated under HIPAA rules:

  • The following transmitted value represents the largest positive dollar amount that can be sent: 99999999.99

  • The following transmitted value is the longest string of characters that can be sent representing whole dollars: 99999999

  • The following transmitted value is the longest string of characters that can be sent representing negative dollars and cents: -99999999.99

  • The following transmitted value is the longest string of characters that can be sent representing negative whole dollars: -99999999

B.1.1.3.1.3 Identifier

An identifier data element always contains a value from a predefined list of codes that is maintained by the ASC X12 Committee or some other body recognized by the Committee. Trailing spaces must be suppressed unless they are necessary to satisfy a minimum length. An identifier is always left justified. The representation for this data element type is "ID."

B.1.1.3.1.4 String

A string data element is a sequence of any characters from the basic or extended character sets. The string data element must contain at least one non-space character. The significant characters shall be left justified. Leading spaces, when they occur, are presumed to be significant characters. Trailing spaces must be suppressed unless they are necessary to satisfy a minimum length. The representation for this data element type is"AN."

B.1.1.3.1.5 Date

A date data element is used to express the standard date in either YYMMDD or CCYYMMDD format in which CC is the first two digits of the calendar year, YY is the last two digits of the calendar year, MM is the month (01 to 12), and DD is the day in the month (01 to 31). The representation for this data element type is "DT." Users of this guide should note that all dates within transactions are 8-character dates (millennium compliant) in the format CCYYMMDD. The only date data element that is in format YYMMDD is the Interchange Date data element in the ISA segment and the TA1 segment where the century is easily determined because of the nature of an interchange header.

B.1.1.3.1.6 Time

A time data element is used to express the ISO standard time HHMMSSd..d format in which HH is the hour for a 24 hour clock (00 to 23), MM is the minute (00 to 59), SS is the second (00 to 59) and d..d is decimal seconds. The representation for this data element type is "TM." The length of the data element determines the format of the transmitted time.

EXAMPLE

Transmitted data elements of four characters denote HHMM. Transmitted data elements of six characters denote HHMMSS.

B.1.1.3.1.7 Binary

The binary data element is any sequence of octets ranging in value from binary 00000000 to binary 11111111. This data element type has no defined maximum length. Actual length is specified by the immediately preceding data element. Within the body of a transaction set (from ST to SE) implemented according to this technical report, the binary data element type is only used in the segments Binary Data Segment BIN, and Binary Data Structure BDS. Within those segments, Data Element 785 Binary Data is a string of octets which can assume any binary pattern from hexadecimal 00 to FF, and can be used to send text as well as coded data, including data from another application in its native format. The binary data type is also used in some control and security structures.

Not all transaction sets use the Binary Data Segment BIN or Binary Data Structure BDS.

B.1.1.3.2 Repeating Data Elements

Simple or composite data elements within a segment can be designated asrepeating data elements. Repeating data elements are adjacent data elements that occur up to a number of times specified in the standard as number of repeats. The implementation guide may also specify the number of repeats of a repeating data element in a specific location in the transaction that are permitted in a compliant implementation. Adjacent occurrences of the same repeating simple data element or composite data structure in a segment shall be separated by a repetition separator.

B.1.1.3.3 Composite Data Structure

The composite data structure is an intermediate unit of information in a segment. Composite data structures are composed of one or more logically related simple data elements, each, except the last, followed by a sub-element separator. The final data element is followed by the next data element separator or the segment terminator. Each simple data element within a composite is called a component.

Each composite data structure has a unique four-character identifier, a name, and a purpose. The identifier serves as a label for the composite. A composite data structure can be further defined through the use of syntax notes, semantic notes, and comments. Each component within the composite is further characterized by a reference designator and a condition designator. The reference designators and the condition designators are described in Section B.1.1.3.8 - Reference Designator and Section B.1.1.3.9 - Condition Designator.

A composite data structure within a segment may have an attribute indicating that it may occur once or a specific number of times more than once. The number of permitted repeats are defined as an attribute in the individual segment where the repeated composite data structure occurs.

B.1.1.3.4 Data Segment

The data segment is an intermediate unit of information in a transaction set. In the data stream, a data segment consists of a segment identifier, one or more composite data structures or simple data elements each preceded by a data element separator and succeeded by a segment terminator.

Each data segment has a unique two- or three-character identifier, a name, and a purpose. The identifier serves as a label for the data segment. A segment can be further defined through the use of syntax notes, semantic notes, and comments. Each simple data element or composite data structure within the segment is further characterized by a reference designator and a condition designator.

B.1.1.3.5 Syntax Notes

Syntax notes describe relational conditions among two or more data segment units within the same segment, or among two or more component data elements within the same composite data structure. For a complete description of the relational conditions, See Section B.1.1.3.9 - Condition Designator.

B.1.1.3.6 Semantic Notes

Simple data elements or composite data structures may be referenced by a semantic note within a particular segment. A semantic note provides important additional information regarding the intended meaning of a designated data element, particularly a generic type, in the context of its use within a specific data segment. Semantic notes may also define a relational condition among data elements in a segment based on the presence of a specific value (or one of a set of values) in one of the data elements.

B.1.1.3.7 Comments

A segment comment provides additional information regarding the intended use of the segment.

B.1.1.3.8 Reference Designator

Each simple data element or composite data structure in a segment is provideda structured code that indicates the segment in which it is used and thesequential position within the segment. The code is composed of the segmentidentifier followed by a two-digit number that defines the position of thesimple data element or composite data structure in that segment.

For purposes of creating reference designators, the composite data structureis viewed as the hierarchical equal of the simple data element. Each componentdata element in a composite data structure is identified by a suffix appended tothe reference designator for the composite data structure of which it is amember. This suffix is prefixed with a hyphen and definesthe position of the component data element in the composite data structure.

EXAMPLE

  • The first simple element of the CLP segment would be identified as CLP01.

  • The first position in the SVC segment is occupied by a composite data structure that contains seven component data elements, the reference designator for the second component data element would be SVC01-02.

B.1.1.3.9 Condition Designator

This section provides information about X12 standard conditions designators. It is provided so that users will have information about the general standard. Implementation guides may impose other conditions designators. See implementation guide section 2.1 Presentation Examples for detailed information about the implementation guide Industry Usage requirements for compliant implementation.

Data element conditions are of three types: mandatory, optional, and relational. They define the circumstances under which a data element may be required to be present or not present in a particular segment.

Table B.7 - Condition Designator

DESIGNATOR DESCRIPTION
M- Mandatory The designation of mandatory is absolute in the sense that there is no dependency on other data elements. This designation may apply to either simple data elements or composite data structures. If the designation applies to a composite data structure, then at least one value of a component data element in that composite data structure shall be included in the data segment.
O- OptionalThe designation of optional means that there is no requirement for a simple data element or composite data structure to be present in the segment. The presence of a value for a simple data element or the presence of value for any of the component data elements of a composite data structure is at the option of the sender.
X- RelationalRelational conditions may exist among two or more simple data elements within the same data segment based on the presence or absence of one of those data elements (presence means a data element must not be empty). Relational conditions are specified by a condition code (see table below) and the reference designators of the affected data elements. A data element may be subject to more than one relational condition.
The definitions for each of the condition codes used within syntax notes are detailed below:
CONDITION CODEDEFINITION
P- Paired or Multiple If any element specified in the relational condition is present, then all of the elements specified must be present.
R- RequiredAt least one of the elements specified in the condition must be present.
E- Exclusion Not more than one of the elements specified in the condition may be present.
C- ConditionalIf the first element specified in the condition is present, then all other elements must be present. However, any or all of the elements not specified as the first element in the condition may appear without requiring that the first element be present. The order of the elements in the condition does not have to be the same as the order of the data elements in the data segment.
L- List Conditional If the first element specified in the condition is present, then at least one of the remaining elements must be present. However, any or all of the elements not specified as the first element in the condition may appear without requiring that the first element be present. The order of the elements in the condition does not have to be the same as the order of the data elements in the data segment.
B.1.1.3.10 Absence of Data

Any simple data element that is indicated as mandatory must not be empty if the segment is used. At least one component data element of a composite data structure that is indicated as mandatory must not be empty if the segment is used. Optional simple data elements and/or composite data structures and their preceding data element separators that are not needed must be omitted if they occur at the end of a segment. If they do not occur at the end of the segment, the simple data element values and/or composite data structure values may be omitted. Their absence is indicated by the occurrence of their preceding data element separators, in order to maintain the element's or structure's position as defined in the data segment.

Likewise, when additional information is not necessary within a composite, the composite may be terminated by providing the appropriate data element separator or segment terminator.

If a segment has no data in any data element within the segment (an "empty" segment), that segment must not be sent.

B.1.1.3.11 Control Segments

A control segment has the same structure as a data segment, but it is used fortransferring control information rather than application information.

B.1.1.3.11.1 Loop Control Segments

Loop control segments are used only to delineate bounded loops. Delineation of the loop shall consist of the loop header (LS segment) and the loop trailer (LE segment). The loop header defines the start of a structure that must contain one or more iterations of a loop of data segments and provides the loop identifier for this loop. The loop trailer defines the end of the structure. The LS segment appears only before the first occurrence of the loop, and the LE segment appears only after the last occurrence of the loop. Unbounded looping structures do not use loop control segments.

B.1.1.3.11.2 Transaction Set Control Segments

The transaction set is delineated by the transaction set header (ST segment) and the transaction set trailer (SE segment). The transaction set header identifies the start and identifier of the transaction set. The transaction set trailer identifies the end of the transaction set and provides a count of the data segments, which includes the ST and SE segments.

B.1.1.3.11.3 Functional Group Control Segments

The functional group is delineated by the functional group header (GS segment) and the functional group trailer (GE segment). The functional group header starts and identifies one or more related transaction sets and provides a control number and application identification information. The functional group trailer defines the end of the functional group of related transaction sets and provides a count of contained transaction sets.

B.1.1.3.11.4 Relations among Control Segments

The control segment of this standard must have a nested relationship as is shown and annotated in this subsection. The letters preceding the control segment name are the segment identifier for that control segment. The indentation of segment identifiers shown below indicates the subordination among control segments.

GS Functional Group Header, starts a group of related transaction sets.

ST Transaction Set Header, starts a transaction set.

LS Loop Header, starts a bounded loop of data segments but is not part of the loop.

LS Loop Header, starts an inner, nested, bounded loop.

LE Loop Trailer, ends an inner, nested bounded loop.

LE Loop Trailer, ends a bounded loop of data segments but is not part of the loop.

SE Transaction Set Trailer, ends a transaction set.

GE Functional Group Trailer, ends a group of related transaction sets.

More than one ST/SE pair, each representing a transaction set, may be used within one functional group. Also more than one LS/LE pair, each representing a bounded loop, may be used within one transaction set.

B.1.1.3.12 Transaction Set

The transaction set is the smallest meaningful set of information exchanged between trading partners. The transaction set consists of a transaction set header segment, one or more data segments in a specified order, and a transaction set trailer segment. See Figure B.1 - Transmission Control Schematic.

B.1.1.3.12.1 Transaction Set Header and Trailer

A transaction set identifier uniquely identifies a transaction set. This identifier is the first data element of the Transaction Set Header Segment (ST). A user assigned transaction set control number in the header must match the control number in the Trailer Segment (SE) for any given transaction set. The value for the number of included segments in the SE segment is the total number of segments in the transaction set, including the ST and SE segments.

B.1.1.3.12.2 Data Segment Groups

The data segments in a transaction set may be repeated as individual data segments or as unbounded or bounded loops.

B.1.1.3.12.3 Repeated Occurrences of Single Data Segments

When a single data segment is allowed to be repeated, it may have a specified maximum number of occurrences defined at each specified position within a given transaction set standard. Alternatively, a segment may be allowed to repeat an unlimited number of times. The notation for an unlimited number of repetitions is ">1."

B.1.1.3.12.4 Loops of Data Segments

Loops are groups of semantically related segments. Data segment loops may be unbounded or bounded.

Unbounded Loops

To establish the iteration of a loop, the first data segment in the loop must appear once and only once in each iteration. Loops may have a specified maximum number of repetitions. Alternatively, the loop may be specified as having an unlimited number of iterations. The notation for an unlimited number of repetitions is ">1."

A specified sequence of segments is in the loop. Loops themselves are optional or mandatory. The requirement designator of the beginning segment of a loop indicates whether at least one occurrence of the loop is required. Each appearance of the beginning segment defines an occurrence of the loop.

The requirement designator of any segment within the loop after the beginning segment applies to that segment for each occurrence of the loop. If there is a mandatory requirement designator for any data segment within the loop after the beginning segment, that data segment is mandatory for each occurrence of the loop. If the loop is optional, the mandatory segment only occurs if the loop occurs.

Bounded Loops

The characteristics of unbounded loops described previously also apply to bounded loops. In addition, bounded loops require a Loop Start Segment (LS) to appear before the first occurrence and a Loop End Segment (LE) to appear after the last consecutive occurrence of the loop. If the loop does not occur, the LS and LE segments are uppressed.

B.1.1.3.12.5 Data Segments in a Transaction Set

When data segments are combined to form a transaction set, three characteristics are applied to each data segment: a requirement designator, a position in the transaction set, and a maximum occurrence.

B.1.1.3.12.6 Data Segment Requirement Designators

A data segment, or loop, has one of the following requirement designators for health care and insurance transaction sets, indicating its appearance in the data stream of a transmission. These requirement designators are represented by a single character code.

Table B.8 - Data Segment Requirement Designators

DESIGNATORDESCRIPTION
M- MandatoryThis data segment must be included in the transaction set. (Note that a data segment may be mandatory in a loop of data segments, but the loop itself is optional if the beginning segment of the loop is designated as optional.)
O- OptionalThe presence of this data segment is the option of the sending party.
B.1.1.3.12.7 Data Segment Position

The ordinal positions of the segments in a transaction set are explicitly specified for that transaction. Subject to the flexibility provided by the optional requirement designators of the segments, this positioning must be maintained.

B.1.1.3.12.8 Data Segment Occurrence

A data segment may have a maximum occurrence of one, a finite number greater than one, or an unlimited number indicated by ">1."

B.1.1.3.13 Functional Group

A functional group is a group of similar transaction sets that is bounded by a functional group header segment and a functional group trailer segment. The functional identifier defines the group of transactions that may be included within the functional group. The value for the functional group control number in the header and trailer control segments must be identical for any given group. The value for the number of included transaction sets is the total number of transaction sets in the group. See Figure B.1 - Transmission Control Schematic.

B.1.1.4 Envelopes and Control Structures

B.1.1.4.1 Interchange Control Structures

Typically, the term "interchange" connotes the ISA/IEA envelope that istransmitted between trading/business partners. Interchange control is achievedthrough several "control" components. The interchange control number iscontained in data element ISA13 of the ISA segment. The identical control numbermust also occur in data element 02 of the IEA segment. Most commercialtranslation software products will verify that these two elements are identical.In most translation software products, if these elements are different theinterchange will be "suspended" in error.

There are many other features of the ISA segment that are used for controlmeasures. For instance, the ISA segment contains data elements such asauthorization information, security information, sender identification, andreceiver identification that can be used for control purposes. These dataelements are agreed upon by the trading partners prior to transmission. Theinterchange date and time data elements as well as the interchange controlnumber within the ISA segment are used for debugging purposes when there is aproblem with the transmission or the interchange.

Data Element ISA12, Interchange Control Version Number, indicates the versionof the ISA/IEA envelope. GS08 indicates the version of the transaction setscontained within the ISA/IEA envelope. The versions are not required to be thesame. An Interchange Acknowledgment can be requested through data element ISA14.The interchange acknowlegement is the TA1 segment. Data element ISA15, TestIndicator, is used between trading partners to indicate that the transmission isin a "test" or "production" mode. Data element ISA16, Subelement Separator, isused by the translator for interpretation of composite data elements.

The ending component of the interchange or ISA/IEA envelope is the IEAsegment. Data element IEA01 indicates the number of functional groups that areincluded within the interchange. In most commercial translation softwareproducts, an aggregate count of functional groups is kept while interpreting theinterchange. This count is then verified with data element IEA01. If there is adiscrepancy, in most commercial products, the interchange is suspended. Theother data element in the IEA segment is IEA02 which is referenced above.

See Appendix C, EDI Control Directory, for a complete detailing of theinter-change control header and trailer. The authors recommend that when twotransactions with different X12 versions numbers are sent in one interchangecontrol structure (multiple functional groups within one ISA/IEA envelope), theInterchange Control version used should be that of the most recent transactionversion included in the envelope. For the transmission of HIPAA transactionswith mixed versions, this would be a compliant enveloping structure.

B.1.1.4.2 Functional Groups

Control structures within the functional group envelope include the functionalidentifier code in GS01. The Functional Identifier Code is used by thecommercial translation software during interpretation of the interchange todetermine the different transaction sets that may be included within thefunctional group. If an inappropriate transaction set is contained within thefunctional group, most commercial translation software will suspend thefunctional group within the interchange. The Application Sender's Code in GS02can be used to identify the sending unit of the transmission. The ApplicationReceiver's Code in GS03 can be used to identify the receiving unit of thetransmission. The functional group contains a creation date (GS04) and creationtime (GS05) for the functional group. The Group Control Number is contained inGS06. These data elements (GS04, GS05, and GS06) can be used for debuggingpurposes. GS08,Version/Release/Industry Identifier Code is theversion/release/sub-release of the transaction sets being transmitted in thisfunctional group.

The Functional Group Control Number in GS06 must be identical to data element02 of the GE segment. Data element GE01 indicates the number of transaction setswithin the functional group. In most commercial translation software products,an aggregate count of the transaction sets is kept while interpreting thefunctional group. This count is then verified with data element GE01.

See Appendix C, EDI Control Directory, for a complete detailing of thefunctional group header and trailer.

B.1.1.4.3 HL Structures

The HL segment is used in several X12 transaction sets to identify levels of detail information using a hierarchical structure, such as relating dependents to a subscriber. Hierarchical levels may differ from guide to guide.

For example, each provider can bill for one or more subscribers, each subscriber can have one or more dependents and the subscriber and the dependents can make one or more claims.

Each guide states what levels are available, the level's usage, number of repeats, and whether that level has subordinate levels within a transaction set.

For implementations compliant with this guide, the repeats of the loopsidentified by the HL structure shall appear in the hierarchical order specifiedin BHT01, when those particular hierarchical levels exist. That is, an HL parentloop must be followed by the subordinate child loops, if any, prior tocommencing a new HL parent loop at the same hierarchical level.

The following diagram, from transaction set 837, illustrates a typicalhierarchy.

The two examples below illustrate this requirement:

Example 1 based on Implementation Guide 811X201:

INSURER

First STATE in transaction (child of INSURER)

First POLICY in transaction (child of first STATE)

First VEHICLE in transaction (child of first POLICY)

Second POLICY in transaction (child of first STATE)

Second VEHICLE in transaction (child of second POLICY)

Third VEHICLE in transaction (child of second POLICY)

Second STATE in transaction (child of INSURER)

Third POLICY in transaction (child of second STATE)

Fourth VEHICLE in transaction (child of third POLICY)

Example 2 based on Implementation Guide 837X141

First PROVIDER in transaction

First SUBSCRIBER in transaction (child of first PROVIDER)

Second PROVIDER in transaction

Second SUBSCRIBER in transaction (child of second PROVIDER)

First DEPENDENT in transaction (child of second SUBSCRIBER)

Second DEPENDENT in transaction (child of second SUBSCRIBER)

Third SUBSCRIBER in transaction (child of second PROVIDER)

Third PROVIDER in transaction

Fourth SUBSCRIBER in transaction (child of third PROVIDER)

Fifth SUBSCRIBER in transaction (child of third PROVIDER)

Third DEPENDENT in transaction (child of fifth SUBSCRIBER)

B.1.1.5 Acknowledgments

B.1.1.5.1 Interchange Acknowledgment, TA1

The TA1 segment provides the capability for the interchange receiver to notify the sender that a valid envelope was received or that problems were encountered with the interchange control structure. The TA1 verifies the envelopes only. Transaction set-specific verification is accomplished through use of the Functional Acknowledgment Transaction Set, 997. See Section B.1.1.5.2 - Functional Acknowledgment, 997, for more details. The TA1 is unique in that it is a single segment transmitted without the GS/GE envelope structure. A TA1 can be included in an interchange with other functional groups and transactions.

Encompassed in the TA1 are the interchange control number, interchange date and time, interchange acknowledgment code, and the interchange note code. The interchange control number, interchange date and time are identical to those that were present in the transmitted interchange from the trading partner. This provides the capability to associate the TA1 with the transmitted interchange. TA104, Interchange Acknowledgment Code, indicates the status of the interchange control structure. This data element stipulates whether the transmitted interchange was accepted with no errors, accepted with errors, or rejected because of errors. TA105, Interchange Note Code, is a numerical code that indicates the error found while processing the interchange control structure. Values for this data element indicate whether the error occurred at the interchange or functional group envelope.

B.1.1.5.2 Functional Acknowledgment, 997

The Functional Acknowledgment Transaction Set, 997, has been designed to allow trading partners to establish a comprehensive control function as a part of their business exchange process. This acknowledgment process facilitates control of EDI. There is a one-to-one correspondence between a 997 and a functional group. Segments within the 997 can identify the acceptance or rejection of the functional group, transaction sets or segments. Data elements in error can also be identified. There are many EDI implementations that have incorporated the acknowledgment process in all of their electronic communications. The 997 is used as a functional acknowledgment to a previously transmitted functional group.

The 997 is a transaction set and thus is encapsulated within the interchange control structure (envelopes) for transmission.

B.2 Object Descriptors

Object Descriptors (OD) provide a method to uniquely identify specific locations within an implementation guide. There is an OD assigned at every level of the X12N implementation:

  1. Transaction Set

  2. Loop

  3. Segment

  4. Composite Data Element

  5. Component Data Element

  6. Simple Data Element

ODs at the first four levels are coded using X12 identifiers separated by underbars:

EntityExample
1. Transaction Set Identifier plus a unique 2 character value837Q1
2. Above plus under bar plus Loop Identifier as assigned within an implementation guide837Q1_2330C
3. Above plus under bar plus Segment Identifier837Q1_2330C_NM1
4. Above plus Reference Designator plus under bar plus Composite Identifier837Q1_2400_SV101_C003

The fifth and sixth levels add a name derived from the "Industry Term" defined in the X12NData Dictionary. The name is derived by removing the spaces.

EntityExample
5. Number 4 above plus composite sequence plus under bar plus name837Q1_2400_SV101_C00302_ProcedureCode
6. Number 3 above plus Reference Designator plus two under bars plus name837Q1_2330C_NM109__OtherPayerPatientPrimaryIdentifier

Said in another way, ODs contain a coded component specifying a location in animplementation guide, a separator, and a name portion. For example:

Since ODs are unique across all X12N implementation guides, they can be used for a variety of purposes. For example, as a cross reference to older data transmission systems, like the National Standard Format for health care claims, or to form XML tags for newer data transmission systems.

Appendix D. Change Summary

This Implementation Guide defines X12N implementation 005010X214of the Health Care Claim Acknowledgment (277). It is based on version/release/sub-release 005010 of the ASC X12 standards.

The previous X12N implementation Guide of the Health Care Claim Acknowledgment (277) was 004040X167. It was based on version/release/ sub-release 004040 of the ASC X12 standards.

The 005010X214 Implementation Guide contains significant changes and clarifications. This appendix provides a high level description of changes between 004040X167 and 005010X214.

D.1 Overall Changes

  1. Sections one and two were revised in accordance with version 5010 of the ASC X12N Implementation Guide Handbook.

  2. All Situational loops, segments and data elements notes were modified in accordance with the ASC X12N Implementation Guide Handbook. See Section 2.2.1 Industry Usage and Section 2.2.2 Transaction Compliance Related to Industry Usage for further information about the Situational Rule format.

  3. Appendix A and Appendix B have been revised in accordance with version 5010 of the X12N Implementation Guide Handbook.

  4. The guide number (005010X214) is now documented in Section 1.2 Version Information. This identifier must be inserted as elements GS08 and ST03 in all Claim Acknowledgments created according to this implementation guide.

  5. The Functional Identifier Code "HN" is now documented in Section 1.2 Version Information. This identifier must be inserted in element GS01 in all Claim Acknowledgments created according to this implementation guide.

  6. All STC Segments have been revised to provide clarity and consistency.

  7. All examples have been reviewed and brought up to date.

  8. All Alias names have been deleted.

D.2 Front Matter Changes

  1. The Front Matter sections were rewritten and condensed for the purpose of clarity and consistency.

  2. Section 1.1.1 - Trading Partner Agreements is now Section 1.8.

  3. Section 1.1.2 - HIPAA Role in Implementation Guides is now Section 1.9.

  4. Section 1.1.3 - Disclaimers Within The Transactions was eliminated.

  5. Section 1.3 - Business Use is now - Implementation Limitations

  6. Section 1.4 - Information Flows is now Business Usage

  7. Section 1.5 - Batch and Real Time Definitions is now - Business Terminology

  8. Section 1.6 - Additional Syntax Support is now - Transaction Acknowledgments

  9. Section 1.7 - Related Transactions has been added.

  10. Section 2 - Data Overview is now Section 1.10

  11. Section 2 - Transaction Set is now in accordance with version 5010 of the ASC X12N Implementation Guide Handbook.

  12. Section 3 - Transactions Set has been eliminated. That information is now available in Section 2.

  13. Section 2.3.2 - X12 Standard has been added.

D.3 277 Health Care Claim Acknowledgment Loop, Segment, Element Changes

Table 2 - Information Source Detail

  1. Loop 2000A Information Source Level HL - Segment note added.

  2. Loop 2200A TRN - Segment notes added.

  3. Loop 2200A DTP*050 - Segment note moved to DTP03 element note.

  4. Loop 2200A DTP*009 - Segment notes revised and condensed.

Table 2 - Information Receiver Detail

  1. Loop 2000B Information Receiver Level HL04 - Element notes added.

  2. Loop 2100B Information Receiver Name NM1 - Segment note 1 revised.

  3. Loop 2100B Information Receiver Name NM106 changed to Not Used.

  4. Loop 2100B Information Receiver Name NM107 changed to Not Used.

  5. Loop 2200B TRN02 - Element note revised.

  6. Loop 2200B STC - Segment note added.

  7. Loop 2200B STC01-1 Element notes revised.

  8. Loop 2200B STC01-2 Element note revised.

  9. Loop 2200B STC01-4 Usage changed from Required to Not Used.

  10. Loop 2200B STC03 - Qualifier definitions revised.

  11. Loop 2200B STC04 - Element note revised.

  12. Loop 2200B STC10-1 - Element note revised.

  13. Loop 2200B STC10-2 Element note revised.

  14. Loop 2200B STC10-3 Element note revised.

  15. Loop 2200B STC10-4 - Usage changed from Required to Not Used.

  16. Loop 2200B STC11-1 - Element note revised.

  17. Loop 2200B STC11-2 Element note revised.

  18. Loop 2200B STC11-3 Element note revised.

  19. Loop 2200B STC11-4 - Usage changed from Required to Not Used.

  20. Loop 2200B QTY*90 - Segment notes added.

  21. QTY Implementation Names changed for consistency.

  22. Loop 2200B QTY02 - Element note moved to TR3 Segment note.

  23. Loop 2200B QTY*AA - Segment notes revised.

  24. Loop 2200B AMT*YU - Segment note revised.

  25. AMT implementation names changed for consistency.

  26. Loop 2200B AMT02 - Element note moved to TR3 Segment note.

  27. Loop 2200B AMT*YY - Segment note revised.

Table 2 - Billing Provider of Service Detail

  1. Loop 2000C Billing Provider of Service Level - Name changed from 'Billing/Pay-To Provider' to 'Billing Provider of Service Detail' and usage changed from Required to Situational.

  2. Loop 2000C Billing Provider of Service Level - Segment notes revised.

  3. Loop 2000C Billing Provider of Service Level - HL04 - Additional code "0" added.

  4. Loop 2100C Provider Name NM1 - Segment notes revised.

  5. Loop 2100C Provider Name NM101 - Qualifier "87" deleted.

  6. Loop 2100C Provider Name NM105 - Element note revised.

  7. Loop 2100C Provider Name NM106 - Usage changed from Situational to Not Used.

  8. Loop 2100C Provider Name NM107 - element note revised.

  9. Loop 2100C, NM108 - Deleted 24 and 34 qualifiers and added FI qualifier.

  10. Loop 2200C TRN - Provider of Service Information Trace Identifier - Segment note revised.

  11. Loop 2200C STC - Billing Provider Status Information - Segment notes revised.

  12. Loop 2200C STC01-1 Element notes revised.

  13. Loop 2200C STC01-2 Element note revised.

  14. Loop 2200C STC01-4 Usage changed from Required to Not Used.

  15. Loop 2200C STC03 - Qualifier definitions revised.

  16. Loop 2200C STC04 - Element note revised.

  17. Loop 2200C STC10-1 - Element note revised.

  18. Loop 2200C STC10-2 Element note revised.

  19. Loop 2200C STC10-3 Element note revised.

  20. Loop 2200C STC10-4 - Usage changed from Required to Not Used.

  21. Loop 2200C STC11-1 - Element note revised.

  22. Loop 2200C STC11-2 Element note revised.

  23. Loop 2200C STC11-3 Element note revised.

  24. Loop 2200C STC11-4 - Usage changed from Required to Not Used.

  25. Loop 2200C REF - Provider Secondary Identifier - Segment notes revised.

  26. QTY Implementation Names changed for consistency.

  27. Loop 2200C AMT - Total Accepted Amount - Segment notes revised.

  28. AMT implementation names changed for consistency.

Table 2 - Patient Detail

  1. Loop 2000D Subscriber Level HL - Segment notes revised.

  2. Loop 2000D HL04 - Usage changed from Required to Not Used.

  3. Loop 2000D NM1 - Patient Name - Segment note removed.

  4. Loop 2100D NM1 - Patient Name - NM104 usage changed from Required to Situational.

  5. Loop 2200D TRN - Patient Control Number - Segment name and note revised.

  6. Loop 2200D TRN02 - Element note removed.

  7. Loop 2200D STC - Billing Provider Status Information - Segment notes revised.

  8. Loop 2200D STC01-1 Element notes revised.

  9. Loop 2200D STC01-2 Element note revised.

  10. Loop 2200D STC01-4 Usage changed from Required to Not Used.

  11. Loop 2200D STC03 - Qualifier definitions revised.

  12. Loop 2200D STC04 - Element note revised.

  13. Loop 2200D STC10-1 - Element note revised.

  14. Loop 2200D STC10-2 Element note revised.

  15. Loop 2200D STC10-3 Element note revised.

  16. Loop 2200D STC10-4 - Usage changed from Required to Not Used.

  17. Loop 2200D STC11-1 - Element note revised.

  18. Loop 2200D STC11-2 Element note revised.

  19. Loop 2200D STC11-3 Element note revised.

  20. Loop 2200D STC11-4 - Usage changed from Required to Not Used.

  21. Loop 2200D REF- Information Source Control Identification Number - Segment notes revised.

  22. Loop 2200D REF02 - Element note moved to TR3 Note.

  23. Loop 2200D REF- Claim Identifier Number for Clearinghouse and Other Transmission Intermediaries - Segment note revised.

  24. Loop 2200D DTP - Claim Level Service Date - Segment notes revised and D8 qualifier added.

  25. Loop 2220D SVC01-1 - Qualifiers "ID", "N4" and "ZZ" were deleted and qualifiers "ER and "HP" were added.

  26. Loop 2220D SVC01-8 - Added as Not Used.

  27. Loop 2220D STC - Billing Provider Status Information - Segment notes revised.

  28. Loop 2220D STC01-1 Element notes revised.

  29. Loop 2220D STC01-2 Element note revised.

  30. Loop 2220D STC01-4 Usage changed from Required to Not Used.

  31. Loop 2220D STC03 - Qualifier definitions revised.

  32. Loop 2220D STC04 - Element note revised.

  33. Loop 2220D STC10-1 - Element note revised.

  34. Loop 2220D STC10-2 Element note revised.

  35. Loop 2220D STC10-3 Element note revised.

  36. Loop 2220D STC10-4 - Usage changed from Required to Not Used.

  37. Loop 2220D STC11-1 - Element note revised.

  38. Loop 2220D STC11-2 Element note revised.

  39. Loop 2220D STC11-3 Element note revised.

  40. Loop 2220D STC11-4 - Usage changed from Required to Not Used.

  41. Loop 2220D REF- Service Line Item Identification - Segment note added.

  42. Loop 2220D DTP - Service Line Date - Segment note revised and D8 qualifier added.

D.4 Appendix Changes

Appendix A changed from "ACS X12 Nomenclature" to "External Code Sources"

  1. Code source 131 removed.

  2. Code source 240 removed.

Appendix B changed from "EDI Control Directory" to "Nomenclature"

Appendix C changed from "External Code Sources" to "EDI Control Directory"

Appendix D Change Summary

  1. Updated with changes from 004040X167 to 005010X214.