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✱0✱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✱20071231✱0802✱1✱X✱005010X364~
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
005010X364
Data Reporting 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✱005010X364~
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 005010X364. 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
005010X364
Data Reporting 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✱20180201✱1635~
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
Not Used
6
640
Transaction Type Code
O 1
ID
2

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 data receiver or clearinghouse receiving the ASC X12 837 transaction. Examples of Data Receivers include payers, All Payer Claim Databases, and Health Insurance Exchanges.
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*ACV - 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✱ACV✱2✱DATA AGENCY✱✱✱✱✱46✱9876543~
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
ACV
Information Source
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)
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✱ABC12345~
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✱20180228~
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:
The Information Source Process Date applies to the processing of the 837 claim transaction file through a processing system. This date may or may not be the same date as the Information Source Receipt Date.
TR3 Example:
DTP✱009✱D8✱20180301~
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.
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 Loop ID 2200B STC03=U.
1
Additional Subordinate HL Data Segment in This Hierarchical Structure.
Used when the Information Receiver Loop ID 2200B STC03 = WQ.

NM1*40 - 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 Example:
NM1✱40✱2✱ABC INSURANCE✱✱✱✱✱46✱39999000B~
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
40
Receiver
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 Receiver Last or Organization 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)
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 Example:
TRN✱2✱206438976580901~
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, and trading partner not authorized to submit to the Information Source's system.
  2. See Section 1.4.2 - Status Information (STC) Segment Usage for specific STC segment information, composites and code use.
TR3 Example:
STC✱DR01:19✱20180301✱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
For this business application acknowledgment, use of the Health Care Claim Status Category Code is limited to category codes beginning with `DR'.
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
This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
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
40
Receiver
Use when identifying the receiver entity in Loop 1000B of the 837.
41
Submitter
Use when identifying the submitter entity in Loop 1000A of the 837.
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 processing 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
See STC01-1 for valid values.
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
This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
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
40
Receiver
Use when identifying the receiver entity in Loop 1000B of the 837.
41
Submitter
Use when identifying the submitter entity in Loop 1000A of the 837.
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
See STC01-1 for valid values.
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
This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
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
40
Receiver
Use when identifying the receiver entity in Loop 1000B of the 837.
41
Submitter
Use when identifying the submitter entity in Loop 1000A of the 837.
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. Accepted claims include those where Loop ID 2200D STC03 = WQ (Accept) and/or EZ (Exception Occurred).
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 of the claim charge amount (Sum of Loop ID 2300 CLM02) of claims accepted by the Information Source. Accepted claims include those where Loop ID 2200D STC03 = WQ (Accept) and/or EZ (Exception Occurred).
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 of the claim charge amount (Sum of Loop ID 2300 CLM02) of claims rejected 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/SERVICE PROVIDER HIERARCHICAL 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 Loop ID 2200B STC03 is equal to `WQ' (Accept). If not required by this implementation guide, do not send.
TR3 Notes:
This loop and all subsequent loops are not used when Loop ID 2200B 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.
Use when the reject reason is related to 837 Loop ID 2010AA provider information.
1
Additional Subordinate HL Data Segment in This Hierarchical Structure.

NM1*85 - BILLING/SERVICE 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 Loop 2010AA of the 837 implementation guides.
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
Situational
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
SITUATIONAL RULE: Required when NM109 is used. If not required by this implementation guide, do not send.
CODE
DEFINITION
XX
Centers for Medicare and Medicaid Services National Provider Identifier
CODE SOURCE: 537: Centers for Medicare & Medicaid Services National Provider Identifier
Situational
9
67
Identification Code
O 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
SITUATIONAL RULE: Required when National Provider ID (NPI) was sent in Loop 2010AA of the 837. If not required by this implementation guide, do not send.
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 - BILLING/SERVICE PROVIDER 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 a secondary provider identifier needs to be reported in the Loop ID 2200C REF Billing/Service Provider Secondary Identifier segment, or to provide the status of a specific billing/service provider's group of claims in the Loop ID 2200C STC Billing/Service Provider Status Information. 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/SERVICE 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/Service 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✱DR01: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
For this business application acknowledgment, use of the Health Care Claim Status Category Code is limited to category codes beginning with `DR'.
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
This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
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
85
Billing Provider
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
Use this code to indicate that 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
Sum of the Billing/Service Provider claims within the 837 transaction 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
See STC01-1 for valid values.
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
This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
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
85
Billing Provider
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
See STC01-1 for valid values.
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
This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
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
85
Billing Provider
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 - BILLING/SERVICE 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:
5
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
1J
Facility ID Number
G2
Provider Commercial Number
LU
Location 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 billing/service 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 accepted by the Information Source for the Billing/Service Provider. Accepted claims include those where Loop ID 2200D STC03 = WQ (Accept) and/or EZ (Exception Occurred).
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 billing/service 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/Service 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 billing/service 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/Service Provider in this acknowledgment. Accepted claims include those where Loop ID 2200D STC03 = WQ (Accept) and/or EZ (Exception Occurred).
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 billing/service 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/Service 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 Loop ID 2200B STC03 is equal to `WQ' (Accept). If not required by this implementation 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
Use when the HIPAA Individual Patient Identifier is mandated for use.
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 is the patient identifier. This data element is the value from Loop 2010CA NM109 of the submitted claim. If there is no value is in the Loop 2010CA NM109, then use the value from the Loop 2010BA NM109 of the submitted claim.
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✱DR02:20✱20180830✱WQ✱432.65~STC✱DR06:131:82✱20180830✱U✱65.32~STC✱DR08:187✱20180830✱EZ✱70✱✱✱✱✱✱DR08:453✱DR08: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
For this business application acknowledgment, use of the Health Care Claim Status Category Code is limited to category codes beginning with `DR'.
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
This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
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
40
Receiver
41
Submitter
45
Drop-off Location
71
Attending Physician
72
Operating Physician
73
Other Physician
77
Service Location
82
Rendering Provider
85
Billing Provider
DK
Ordering Physician
DN
Referring Provider
DQ
Supervising Physician
IL
Insured or Subscriber
P3
Primary Care Provider
PR
Payer
PRP
Primary Payer
PW
Pickup Address
QB
Purchase Service Provider
QC
Patient
SEP
Secondary Payer
SJ
Service Provider
TTP
Tertiary Payer
ZD
Party to Receive Reports
ZZ
Mutually Defined
Use when indicating the Entity is an Other Operating Physician.
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
EZ
Exception Occurred
Use when the Health Care Claim Status Code(s) reported in this segment and/or a line level STC segment serves as a warning to the submitter an error has been detected, but is not significant enough to reject the claim.
U
Reject
Use when there is a claim level reject reason OR any of the Loop ID 2220D claim service lines have been assigned an STC03 Action Code of `U' (Reject). Claim splitting of accepted vs rejected lines is not supported in this implementation.
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. This is the Loop ID 2300 CLM02 Total Claim Charge Amount from the submitted 837.
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
See STC01-1 for valid values.
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
This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
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
40
Receiver
41
Submitter
45
Drop-off Location
71
Attending Physician
72
Operating Physician
73
Other Physician
77
Service Location
82
Rendering Provider
85
Billing Provider
DK
Ordering Physician
DN
Referring Provider
DQ
Supervising Physician
IL
Insured or Subscriber
P3
Primary Care Provider
PR
Payer
PRP
Primary Payer
PW
Pickup Address
QB
Purchase Service Provider
QC
Patient
SEP
Secondary Payer
SJ
Service Provider
TTP
Tertiary Payer
ZD
Party to Receive Reports
ZZ
Mutually Defined
Use when indicating the Entity is an Other Operating Physician.
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
See STC01-1 for valid values.
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
This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
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
40
Receiver
41
Submitter
45
Drop-off Location
71
Attending Physician
72
Operating Physician
73
Other Physician
77
Service Location
82
Rendering Provider
85
Billing Provider
DK
Ordering Physician
DN
Referring Provider
DQ
Supervising Physician
IL
Insured or Subscriber
P3
Primary Care Provider
PR
Payer
PRP
Primary Payer
PW
Pickup Address
QB
Purchase Service Provider
QC
Patient
SEP
Secondary Payer
SJ
Service Provider
TTP
Tertiary Payer
ZD
Party to Receive Reports
ZZ
Mutually Defined
Use when indicating the Entity is an Other Operating Physician.
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 in the judgment of the sender, the Claim Status Code(s) reported in this segment do not definitively define the related edit causing this claim to be rejected or accepted with error, ANDSTC03 is not `WQ'.If not required by this implementation guide, do not send.
INDUSTRY NAME: Free Form Message Text
When an Information Source deems there is a need to use the Free Form Message Text enabled by this element, the Information Source is expected to request a new Health Care Claim Status Category and/or Health Care Claim Status code(s) to enable codification of the message thereby eliminating the need to use this field for that given purpose.

REF*F8 - DATA RECEIVER 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 the Data Receiving Entity of the 837 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 Example:
REF✱F8✱0167568004563~
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
F8
Original Reference 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: Data Receiver Claim Control Number
Not Used
3
352
Description
O 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

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 acknowledging a Post Adjudicated Claim Data Reporting (PACDR) 837 and Loop ID 2320 SBR06 = `6'. If not required by this implementation guide, do not send.
TR3 Notes:
This is the Other Payer Claim Control Number from Loop 2330B (REF*F8) when SBR06 = `6' in Loop 2320.
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 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

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 and Data Reporting claims, this is the statement period submitted in Loop ID 2300 (DTP01 = 434).

For Professional claims this information is derived from the earliest service level dates in Loop ID 2400 (DTP01 = 472) to the latest service level date.

For Dental claims this is the service date submitted in Loop ID 2300 (DTP01 = 472). If there is no service date in Loop ID 2300 (DTP01=472), then this is:

the service date in Loop ID 2400 (DTP01=472),
OR
it is the treatment start in Loop ID ID 2400 (DTP01=196),
OR
the treatment end in Loop ID 2400 (DTP01=198),
OR
both the treatment start and treatment end dates in Loop ID 2400 listing the date range as from treatment start date to the treatment end date.
TR3 Example:
DTP✱472✱RD8✱20180820-20180825~DTP✱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 Reject Action Code (Loop ID 2220D STC03 = `U') is being assigned to a service line.
OR
Required when an Exception Occurred Action Code (Loop ID 2220D STC03 = `EZ') is being assigned to a service line.

If not required by this implementation guide, do not send.
TR3 Notes:
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~SVC✱HC:99213✱35~SVC✱HC:99213✱35✱✱0510~
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
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
NU
National Uniform Billing Committee (NUBC) UB92 Codes
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 when 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 when 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 when 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 when 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 when 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✱DR07:187✱✱U✱✱✱✱✱✱✱DR07:453✱DR07: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
For this business application acknowledgment, use of the Health Care Claim Status Category Code is limited to category codes beginning with `DR'.
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
This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
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
45
Drop-off Location
72
Operating Physician
77
Service Location
82
Rendering Provider
DD
Assistant Surgeon
DK
Ordering Physician
DN
Referring Provider
DQ
Supervising Physician
P3
Primary Care Provider
PW
Pickup Address
QB
Purchase Service Provider
ZZ
Mutually Defined
Use when indicating the Entity is an Other Operating Physician.
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
EZ
Exception Occurred
Use when the Health Care Claim Status Code(s) reported in this segment and/or a line level STC segment serves as a warning to the submitter an error has been detected, but is not significant enough to reject the claim.
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
See STC01-1 for valid values.
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
This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
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
45
Drop-off Location
72
Operating Physician
77
Service Location
82
Rendering Provider
DD
Assistant Surgeon
DK
Ordering Physician
DN
Referring Provider
DQ
Supervising Physician
P3
Primary Care Provider
PW
Pickup Address
QB
Purchase Service Provider
ZZ
Mutually Defined
Use when indicating the Entity is an Other Operating Physician.
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
See STC01-1 for valid values.
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
This code provides further detail of the status. See Section 1.4.2 Status Information (STC Segment Usage).
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
45
Drop-off Location
72
Operating Physician
77
Service Location
82
Rendering Provider
DD
Assistant Surgeon
DK
Ordering Physician
DN
Referring Provider
DQ
Supervising Physician
P3
Primary Care Provider
PW
Pickup Address
QB
Purchase Service Provider
ZZ
Mutually Defined
Use when indicating the Entity is an Other Operating Physician.
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 in the judgment of the sender, the Claim Status Code(s) reported in this segment do not definitively define the related edit causing this claim to be rejected or accepted with error, ANDSTC03 is not `WQ'.If not required by this implementation guide, do not send.
INDUSTRY NAME: Free Form Message Text
When an Information Source deems there is a need to use the Free Form Message Text enabled by this element, the Information Source is expected to request a new Health Care Claim Status Category and/or Health Care Claim Status code(s) to enable codification of the message thereby eliminating the need to use this field for that given purpose.

REF*6R - LINE ITEM 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:
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✱6R✱KFD980976~
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
6R
Provider 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~DTP✱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 Data Reporting Acknowledgment (005010X364)

FEBRUARY 2019

Copyright © 2019, X12 Incorporated, Format © 2019-21 Washington Publishing Company. Exclusively published by the Washington Publishing Company. No part of this publication may be distributed, posted, reproduced, stored in a retrieval system, or transmitted in any form or by any means without the prior written permission of the copyright owner.

All rights reserved.

Abstract

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

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

The level of editing in pre-process 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 as well as those that are not accepted. This 277 transaction is the only notification of claim status.

1.1 Implementation Purpose and Scope

For the health care industry to achieve the potential administrative 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 an 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 data reporting claim submission(s). This implementation guide provides a detailed explanation of the transaction set by defining uniform data content, identifying valid code sources and specifying values applicable for the business focus of the 277 data reporting claim submission acknowledgment.

Examples of entities receiving this implementation of the 277 include payers, providers, clearinghouses, and Third Party Administrators (TPA).

Examples of entities sending this implementation of the 277 include payers, All Payer Claim Databases, clearinghouses, and Health Insurance Exchanges.


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 005010X364.

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.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 or transmits the response transaction back to the sender of the original transaction. The sender of the original transmissioIn 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 activitiesn reconnects at a later time and picks up the response transaction if the transaction was not transmitted back to the sender of the original 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 no other usage limitations.


1.4 Business Usage

The ASC X12 Data Reporting Acknowledgement (277) implementation guide is a business application level acknowledgement for the ASC X12 Post Adjudicated Claim Data Reporting (837) and Health Care Service: Data Reporting (837) transaction(s). This acknowledges the validity and acceptability of the claims.

An Information Source may process claims to determine whether or not to introduce them to their system. This process is performed so claims that are incorrectly formatted or missing information can be corrected and resubmitted by the Information Receiver.


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 is the entity generating the 277 Data Reporting 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.


1.4.1.1 Defining the "Patient" Participant

The Patient information identified in the 277 Data Reporting 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 Loop ID 2010BA of the 837 transaction.
  • When the patient is a dependent of the subscriber (e.g., spouse, children, others), the patient name and identification information resides in Loop ID 2010CA of the 837 transaction.

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 Information Source to Information Source. Information Sources are urged to report the greatest level of detail available. 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:

  1. 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 process status of the claim. This implementation guide will only utilize Category Codes indicating Data Reporting Acknowledgement (DRxx).
  2. 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.
  3. 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.
  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.

1.4.2.1 STC Composite and Code Use Rules

The following requirements 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.
  • Multiple STC segments must be reported for unrelated edits or statuses.

1.4.2.2 STC Action Code Definition and Usage

The Action Code reported in STC03 advises the Information Receiver of the Information Source processing result. Based upon the edits that determine the STC composite results, Action Codes advise of the outcome. The possible outcomes include Accept, Exception Occurred (Accepted with Error), or Reject. The use of each of these codes is different depending upon the loop they are reported in. The following sections describe how the codes are to be used and interpreted.


1.4.2.2.1 Accept (STC03 = WQ)

  • When an Accept Action Code is used in Loop ID 2200B Information Receiver, this indicates at least one of the claim(s) within the transaction (ST/SE) has been accepted or accepted with errors, and passed to the Information Source's processing system.
  • When an Accept Action Code is used in Loop ID 2200C Billing/Service Provider Status Information, this indicates at least one of the claim(s) for this provider has been accepted or accepted with errors, and passed to the Information Source's processing system.
  • When an Accept Action Code is used in Loop ID 2200D Claim Status Tracking, this indicates the claim has been accepted, without errors, and passed to the Information Source's processing system. If one or more of the lines reported in Loop ID 2220D are rejected, an Accept Action Code must not be used at this level.
  • An Accept Action Code is not available for use in Loop ID 2220D Service Line Information. Accepted lines are not reported in this implementation.

1.4.2.2.2 Exception Occurred (STC03 = EZ)

Exception Occurred is a warning to the submitter that an error has been detected at either the line or claim level or both, but the error is not significant enough to reject the claim at the time of processing. The Information Source may change these to Reject errors or stop reporting them, at their discretion.

  • An Exception Occurred Action Code is not available for use in Loop ID 2200B Information Receiver.
  • An Exception Occurred Action Code is not available for use in Loop ID 2200C Billing/Service Provider Status Information.
  • When an Exception Occurred Action Code is used in Loop ID 2200D Claim Status Tracking, this indicates an error was detected within either the claim level information or the line level information, but the claim has been accepted and passed to the Information Source's processing system. If any of the lines reported in Loop ID 2220D are rejected, the claim must be rejected and Exception Occurred is not used at this level.
  • When an Exception Occurred Action Code is used in Loop ID 2220D Service Line Information, this indicates an error was detected within the line level information, but the claim is not being rejected because of that error. See the claim level status to determine whether the claim has been accepted and passed to the Information Source's processing system.

1.4.2.2.3 Reject (STC03 = U)

  • When a Reject Action Code is used in Loop ID 2200B Information Receiver, this indicates all claims within the transaction (ST/SE) have been rejected and returned to the Information Receiver.
  • When a Reject Action Code is used in Loop ID 2200C Billing/Service Provider Status Information, this indicates that all of the claims for this provider have been rejected and returned to the Information Receiver.
  • When a Reject Action Code is used in Loop ID 2200D Claim Status Tracking, this indicates the claim has been rejected and returned to the Information Receiver. If any of the lines within a claim are reported with a Reject Action Code, the Action Code at this level must be 'U' Reject. Partial acceptance of a claim is not permitted.
  • When a Reject Action Code is used in Loop ID 2220D Service Line Information, this indicates an error was detected within the line level information and the claim is being rejected because of that/those error(s).

1.5 Business Terminology

No special business terms are used in this implementation guide.


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 Health Care Claim (837)

Submitting a data reporting claim using the 837 format initiates the creation of the Data Reporting Acknowledgment (277) transaction.


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 StatusNotification 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, Nomenclatureand 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 implementation is identified in ST03.The BHT identifies 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.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 is used.
  • Required segments in Situational loops occur only when the loop is used.

3. Examples

Business scenario examples for use of this transaction can be found on the ASC X12 Examples website at http://examples.x12.org. The ASC X12 Examples website provides convenient access to examples of ASC X12 transaction transmissions, including the data stream and a description of the associated scenario.


Appendix A. External Code Sources

121 Health Industry Number

SIMPLE DATA ELEMENT/CODE REFERENCES

66/21, 128/HI, 1270/HI, I05/20

SOURCE

Health Industry Number Database

AVAILABLE FROM

Health Industry Business Communications Council
5110 North 40th Street
Phoenix, AZ 85018

ABSTRACT

The HIN is a coding system, developed and administered by the Health Industry Business Communications Council, that assigns a unique code number to hospitals other provider organizations, and manufacturers and distributors.

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.

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.

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.

881 Version / Release / Industry Identifier Code

SIMPLE DATA ELEMENT/CODE REFERENCES

480

SOURCE

Data Interchange Standards Association

AVAILABLE FROM

Data Interchange Standards Association
7600 Leesburg Pike, Suite 430
Falls Church, VA 22043

ABSTRACT

Code indicating the version, release, sub-release, 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 sub-release, 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.


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 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.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 Figure B.2., Basic Character Set, includes those selected from the uppercase letters, digits, space, and special characters as specified below.

Figure B.2 - 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 Figure B.3., Extended Character Set.

Figure B.3 - 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.5.


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 the Matrix B.1., 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:

Matrix B.1. Base Control Set

NOTATION NAME EBCDIC ASCII IA5
BEL bell 2F 07 07
HT horizontal tab 05 09 09
LF line feed 25 0A 0A
VT vertical tab 0B 0B 0B
FF form feed 0C 0C 0C
CR carriage return 0D 0D 0D
FS file separator 1C 1C 1C
GS group separator 1D 1D 1D
RS record separator 1E 1E 1E
US unit separator 1F 1F 1F
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 Matrix B.2., Extended Control Set.

Matrix B.2. Extended Control Set

NOTATION NAME EBCDIC ASCII IA5
SOH start of header 01 01 01
STX start of text 02 02 02
ETX end of text 03 03 03
EOT end of transmission 37 04 04
ENQ enquiry 2D 05 05
ACK acknowledge 2E 06 06
DC1 device control 1 11 11 11
DC2 device control 2 12 12 12
DC3 device control 3 13 13 13
DC4 device control 4 3C 14 14
NAK negative acknowledge 3D 15 15
SYN synchronous idle 32 16 16
ETB end of block 26 17 17


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.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 Matrix B.3., Delimiters, in all examples of EDI transmissions.

Matrix B.3. Delimiters

CHARACTER NAME DELIMITER
* Asterisk Data Element Separator
^ Caret Repetition Separator
: Colon Component Element Separator
~ Tilde Segment 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 X12 standard. 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 Matrix B.4., Data Element Types, appear in this implementation guide.

Matrix B.4. Data Element Types

SYMBOL TYPE
Nn Numeric
R Decimal
ID Identifier
AN String
DT Date
TM Time
B Binary


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 as repeating 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 Sections B.1.1.3.8 and B.1.1.3.9.

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 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 provided a structured code that indicates the segment in which it is used and the sequential position within the segment. The code is composed of the segment identifier followed by a two-digit number that defines the position of the simple data element or composite data structure in that segment.

For purposes of creating reference designators, the composite data structure is viewed as the hierarchical equal of the simple data element. Each component data element in a composite data structure is identified by a suffix appended to the reference designator for the composite data structure of which it is a member. This suffix is prefixed with a hyphen and defines the 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.5. 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- Optional The 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- Relational Relational 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 CODE DEFINITION
P- Paired or Multiple If any element specified in the relational condition is present, then all of the elements specified must be present.
R- Required At 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- Conditional If 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 for transferring 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.


B.1.1.3.12.4.1 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.


B.1.1.3.12.4.2 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 suppressed.


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.

DESIGNATOR DESCRIPTION
M- Mandatory This 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- Optional The 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.1 Interchange Control Structures

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

There are many other features of the ISA segment that are used for control measures. For instance, the ISA segment contains data elements such as authorization information, security information, sender identification, and receiver identification that can be used for control purposes. These data elements are agreed upon by the trading partners prior to transmission. The interchange date and time data elements as well as the interchange control number within the ISA segment are used for debugging purposes when there is a problem with the transmission or the interchange.

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

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

See the Appendix C, EDI Control Directory, for a complete detailing of the interchange control header and trailer. The authors recommend that when two transactions with different X12 versions numbers are sent in one interchange control structure (multiple functional groups within one ISA/IEA envelope), the Interchange Control version used should be that of the most recent transaction version included in the envelope. For the transmission of HIPAA transactions with 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 functional identifier code in GS01. The Functional Identifier Code is used by the commercial translation software during interpretation of the interchange to determine the different transaction sets that may be included within the functional group. If an inappropriate transaction set is contained within the functional group, most commercial translation software will suspend the functional group within the interchange. The Application Sender's Code in GS02 can be used to identify the sending unit of the transmission. The Application Receiver's Code in GS03 can be used to identify the receiving unit of the transmission. The functional group contains a creation date (GS04) and creation time (GS05) for the functional group. The Group Control Number is contained in GS06. These data elements (GS04, GS05, and GS06) can be used for debugging purposes. GS08,Version/Release/ Industry Identifier Code is the version/release/sub-release of the transaction sets being transmitted in this functional group.

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

See the Appendix C, EDI Control Directory, for a complete detailing of the functional 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 loops identified by the HL structure shall appear in the hierarchical order specified in BHT01, when those particular hierarchical levels exist. That is, an HL parent loop must be followed by the subordinate child loops, if any, prior to commencing a new HL parent loop at the same hierarchical level.

The following diagram, from transaction set 837, illustrates a typical hierarchy.

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

Entity Example
1. Transaction Set Identifier plus a unique 2 character value 837Q1
2. Above plus under bar plus Loop Identifier as assigned within an implementation guide 837Q1_2330C
3. Above plus under bar plus Segment Identifier 837Q1_2330C_NM1
4. Above plus Reference Designator plus under bar plus Composite Identifier 837Q1_2400_SV101_C003

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

Entity Example
5. Number 4 above plus composite sequence plus under bar plus name 837Q1_2400_SV101_C00302_ProcedureCode
6. Number 3 above plus Reference Designator plus two under bars plusname 837Q1_2330C_NM109__OtherPayerPatientPrimaryIdentifier

Said in another way, ODs contain a coded component specifying a location in an implementation 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 (005010X364) defines the X12 requirements for the Data Reporting Acknowledgment. It is based on version/release/subrelease 005010 of the ASC X12 standards.


Appendix E - Industry Names

This section contains an alphabetic listing of data elements used in this implementation guide. Consult the X12N Data Element Dictionary for a complete list of all X12N Data Elements. Data element names in normal type are generic ASC X12 names. Italic type indicates a health care industry defined name.

Legend

Industry Name
Industry name definition.
800 - Transaction Set ID and Name
H=Header, D=Detail, S=Summary | Loop ID | Reference Designator | Composite ID-Position in Composite | X12 Data Element Number

Action Code
Code indicating type of action
277 - Data Reporting Acknowledgment
D | 2200B | STC03 | - | 306
D | 2200C | STC03 | - | 306
D | 2220D | STC03 | - | 306

Amount Qualifier Code
Code to qualify amount.
277 - Data Reporting Acknowledgment
D | 2200B | AMT01 | - | 522
D | 2200B | AMT01 | - | 522
D | 2200C | AMT01 | - | 522
D | 2200C | AMT01 | - | 522

Billing Provider Additional Identifier
Identifies another or additional distinguishing code number associated with the billing provider.
277 - Data Reporting Acknowledgment
D | 2200C | REF02 | - | 127

Billing Provider Identifier
Identification number for the provider or organization in whose name the bill is submitted and to whom payment should be made.
277 - Data Reporting Acknowledgment
D | 2100C | NM109 | - | 67

Claim Service Period
The beginning and end dates for the service period covered by a claim.
277 - Data Reporting Acknowledgment
D | 2200D | DTP03 | - | 1251

Claim Transaction Batch Number
This field corresponds to the BHT03 data element from the submitted claim transaction.
277 - Data Reporting Acknowledgment
D | 2200B | TRN02 | - | 127

Clearinghouse Trace Number
Unique tracking number for the transaction assigned by a clearinghouse.
277 - Data Reporting Acknowledgment
D | 2200D | REF02 | - | 127

Data Receiver Claim Control Number
Unique number for the claim assigned by the data receiving entity.
277 - Data Reporting Acknowledgment
D | 2200D | REF02 | - | 127

Date Time Period Format Qualifier
Code indicating the date format, time format, or date and time format.
277 - Data Reporting Acknowledgment
D | 2200A | DTP02 | - | 1250
D | 2200A | DTP02 | - | 1250
D | 2200D | DTP02 | - | 1250
D | 2220D | DTP02 | - | 1250

Date Time Qualifier
Code specifying the type of date or time or both date and time.
277 - Data Reporting Acknowledgment
D | 2200A | DTP01 | - | 374
D | 2200A | DTP01 | - | 374
D | 2200D | DTP01 | - | 374
D | 2220D | DTP01 | - | 374

Entity Identifier Code
Code identifying an organizational entity, a physical location, property or an individual.
277 - Data Reporting Acknowledgment
D | 2100A | NM101 | - | 98
D | 2100B | NM101 | - | 98
D | 2200B | STC01 | C043-03 | 98
D | 2200B | STC10 | C043-03 | 98
D | 2200B | STC11 | C043-03 | 98
D | 2100C | NM101 | - | 98
D | 2200C | STC01 | C043-03 | 98
D | 2200C | STC10 | C043-03 | 98
D | 2200C | STC11 | C043-03 | 98
D | 2100D | NM101 | - | 98
D | 2200D | STC01 | C043-03 | 98
D | 2200D | STC10 | C043-03 | 98
D | 2200D | STC11 | C043-03 | 98
D | 2220D | STC01 | C043-03 | 98
D | 2220D | STC10 | C043-03 | 98
D | 2220D | STC11 | C043-03 | 98

Entity Type Qualifier
Code qualifying the type of entity.
277 - Data Reporting Acknowledgment
D | 2100A | NM102 | - | 1065
D | 2100B | NM102 | - | 1065
D | 2100C | NM102 | - | 1065
D | 2100D | NM102 | - | 1065

Free Form Message Text
Text used to convey information related to the transaction.
277 - Data Reporting Acknowledgment
D | 2200D | STC12 | - | 933
D | 2220D | STC12 | - | 933

Health Care Claim Status Category Code
Code indicating the category of the associated claim status code.
277 - Data Reporting Acknowledgment
D | 2200B | STC01 | C043-01 | 1271
D | 2200B | STC10 | C043-01 | 1271
D | 2200B | STC11 | C043-01 | 1271
D | 2200C | STC01 | C043-01 | 1271
D | 2200C | STC10 | C043-01 | 1271
D | 2200C | STC11 | C043-01 | 1271
D | 2200D | STC01 | C043-01 | 1271
D | 2200D | STC10 | C043-01 | 1271
D | 2200D | STC11 | C043-01 | 1271
D | 2220D | STC01 | C043-01 | 1271
D | 2220D | STC10 | C043-01 | 1271
D | 2220D | STC11 | C043-01 | 1271

Health Care Claim Status Code
Code conveying the status of a health care claim.
277 - Data Reporting Acknowledgment
D | 2200B | STC01 | C043-02 | 1271
D | 2200B | STC10 | C043-02 | 1271
D | 2200B | STC11 | C043-02 | 1271
D | 2200C | STC01 | C043-02 | 1271
D | 2200C | STC10 | C043-02 | 1271
D | 2200C | STC11 | C043-02 | 1271
D | 2200D | STC01 | C043-02 | 1271
D | 2200D | STC10 | C043-02 | 1271
D | 2200D | STC11 | C043-02 | 1271
D | 2220D | STC01 | C043-02 | 1271
D | 2220D | STC10 | C043-02 | 1271
D | 2220D | STC11 | C043-02 | 1271

Hierarchical Child Code
Code indicating if there are hierarchical child data segments subordinate to the level being described.
277 - Data Reporting Acknowledgment
D | 2000A | HL04 | - | 736
D | 2000B | HL04 | - | 736
D | 2000C | HL04 | - | 736

Hierarchical ID Number
A unique number assigned by the sender to identify a particular data segment in a hierarchical structure.
277 - Data Reporting Acknowledgment
D | 2000A | HL01 | - | 628
D | 2000B | HL01 | - | 628
D | 2000C | HL01 | - | 628
D | 2000D | HL01 | - | 628

Hierarchical Level Code
Code defining the characteristic of a level in a hierarchical structure.
277 - Data Reporting Acknowledgment
D | 2000A | HL03 | - | 735
D | 2000B | HL03 | - | 735
D | 2000C | HL03 | - | 735
D | 2000D | HL03 | - | 735

Hierarchical Parent ID Number
Identification number of the next higher hierarchical data segment that the data segment being described is subordinate to.
277 - Data Reporting Acknowledgment
D | 2000B | HL02 | - | 734
D | 2000C | HL02 | - | 734
D | 2000D | HL02 | - | 734

Hierarchical Structure Code
Code indicating the hierarchical application structure of a transaction set that utilizes the HL segment to define the structure of the transaction set
277 - Data Reporting Acknowledgment
H | | BHT01 | - | 1005

Identification Code Qualifier
Code designating the system/method of code structure used for Identification Code (67).
277 - Data Reporting Acknowledgment
D | 2100A | NM108 | - | 66
D | 2100B | NM108 | - | 66
D | 2100C | NM108 | - | 66
D | 2100D | NM108 | - | 66

Information Receiver Last or Organization Name
The name of the organization or last name of the individual that expects to receive information or is receiving information.
277 - Data Reporting Acknowledgment
D | 2100B | NM103 | - | 1035

Information Receiver Primary Identifier
The Identification number of the individual or organization who expects to receive the information in response to a claim submission.
277 - Data Reporting Acknowledgment
D | 2100B | NM109 | - | 67

Information Source Application Trace Identifier
This is a unique trace number that identifies a specific transaction.
277 - Data Reporting Acknowledgment
D | 2200A | TRN02 | - | 127

Information Source Identifier
The Identification number of the individual or organization who provides the information in this transaction.
277 - Data Reporting Acknowledgment
D | 2100A | NM109 | - | 67

Information Source Name
The name of the organization who provides the information in this transaction.
277 - Data Reporting Acknowledgment
D | 2100A | NM103 | - | 1035

Information Source Process Date
The date the information request was processed by the Information Source's adjudication system.
277 - Data Reporting Acknowledgment
D | 2200A | DTP03 | - | 1251

Information Source Receipt Date
This is the receipt date of the 837 by the entity creating the 277 acknowledgment.
277 - Data Reporting Acknowledgment
D | 2200A | DTP03 | - | 1251

Line Item Charge Amount
Charges related to this service.
277 - Data Reporting Acknowledgment
D | 2220D | SVC02 | - | 782

Line Item Control Number
Identifier assigned by the submitter/provider to this line item.
277 - Data Reporting Acknowledgment
D | 2220D | REF02 | - | 127

Original Units of Service Count
Original units of service that were submitted by the provider (in days or units).
277 - Data Reporting Acknowledgment
D | 2220D | SVC07 | - | 380

Patient Control Number
Patient's unique alpha-numeric identification number for this claim assigned by the provider to facilitate retrieval of individual case records and posting of payment.
277 - Data Reporting Acknowledgment
D | 2200D | TRN02 | - | 127

Patient First Name
The first name of the individual to whom the services were provided.
277 - Data Reporting Acknowledgment
D | 2100D | NM104 | - | 1036

Patient Identification Number
The Identification number of the individual who is the patient in a claim within this transaction.
277 - Data Reporting Acknowledgment
D | 2100D | NM109 | - | 67

Patient Last Name
The last name of the individual to whom the services were provided.
277 - Data Reporting Acknowledgment
D | 2100D | NM103 | - | 1035

Patient Middle Name or Initial
The middle name or initial of the individual to whom the services were provided.
277 - Data Reporting Acknowledgment
D | 2100D | NM105 | - | 1037

Patient Name Suffix
Suffix to the name of the individual to whom the services were provided.
277 - Data Reporting Acknowledgment
D | 2100D | NM107 | - | 1039

Payer Claim Control Number
A number assigned by the payer to identify a claim. The number is usually referred to as an Internal Control Number (ICN), Claim Control Number (CCN) or a Document Control Number (DCN).
277 - Data Reporting Acknowledgment
D | 2200D | REF02 | - | 127

Pharmacy Prescription Number
A unique identification number assigned to the prescription claim for the purpose of identification.
277 - Data Reporting Acknowledgment
D | 2220D | REF02 | - | 127

Procedure Code
Code identifying the procedure, product or service.
277 - Data Reporting Acknowledgment
D | 2220D | SVC01 | C003-01 | 235
D | 2220D | SVC01 | C003-02 | 234

Procedure Modifier
This identifies special circumstances related to the performance of the service.
277 - Data Reporting Acknowledgment
D | 2220D | SVC01 | C003-03 | 1339
D | 2220D | SVC01 | C003-04 | 1339
D | 2220D | SVC01 | C003-05 | 1339
D | 2220D | SVC01 | C003-06 | 1339

Provider First Name
The first name of the provider of care submitting a transaction or related to the information provided in or request by the transaction.
277 - Data Reporting Acknowledgment
D | 2100C | NM104 | - | 1036

Provider Last or Organization Name
The last name of the provider of care or name of the provider organization submitting a transaction or related to the information provided in or request by the transaction.
277 - Data Reporting Acknowledgment
D | 2100C | NM103 | - | 1035

Provider Middle Name
The middle name of the provider of care submitting a transaction or related to the information provided in or request by the transaction.
277 - Data Reporting Acknowledgment
D | 2100C | NM105 | - | 1037

Provider Name Suffix
The name suffix of the provider of care submitting a transaction or related to the information provided in or request by the transaction.
277 - Data Reporting Acknowledgment
D | 2100C | NM107 | - | 1039

Provider of Service Information Trace Identifier
A placeholder number used to complete ASC X12 Syntax Loop requirements when providing status for a specific provider's group of claims.
277 - Data Reporting Acknowledgment
D | 2200C | TRN02 | - | 127

Quantity Qualifier
Code specifying the type of quantity.
277 - Data Reporting Acknowledgment
D | 2200B | QTY01 | - | 673
D | 2200B | QTY01 | - | 673
D | 2200C | QTY01 | - | 673
D | 2200C | QTY01 | - | 673

Reference Identification
The identification value assigned by the sender for this particular transaction.
277 - Data Reporting Acknowledgment
H | | BHT03 | - | 127

Reference Identification Qualifier
Code qualifying the reference identification.
277 - Data Reporting Acknowledgment
D | 2200C | REF01 | - | 128
D | 2200D | REF01 | - | 128
D | 2200D | REF01 | - | 128
D | 2200D | REF01 | - | 128
D | 2220D | REF01 | - | 128
D | 2220D | REF01 | - | 128

Revenue Code
A code that identifies a specific accommodation, ancillary service or billing calculation.
277 - Data Reporting Acknowledgment
D | 2220D | SVC04 | - | 234

Service Line Date
Date of service of the identified service line on the claim.
277 - Data Reporting Acknowledgment
D | 2220D | DTP03 | - | 1251

Status Information Action Code
Code indicating type of action taken for this data.
277 - Data Reporting Acknowledgment
D | 2200D | STC03 | - | 306

Status Information Effective Date
The date that the status information provided is effective.
277 - Data Reporting Acknowledgment
D | 2200B | STC02 | - | 373
D | 2200D | STC02 | - | 373

Total Accepted Amount
Total dollar amount of the accepted claims.
277 - Data Reporting Acknowledgment
D | 2200B | AMT02 | - | 782
D | 2200C | AMT02 | - | 782

Total Accepted Quantity
Total number of accepted claims.
277 - Data Reporting Acknowledgment
D | 2200B | QTY02 | - | 380
D | 2200C | QTY02 | - | 380

Total Claim Charge Amount
The sum of all charges included within this claim.
277 - Data Reporting Acknowledgment
D | 2200D | STC04 | - | 782

Total Rejected Amount
Total dollar amount of the rejected claims.
277 - Data Reporting Acknowledgment
D | 2200B | AMT02 | - | 782
D | 2200C | AMT02 | - | 782

Total Rejected Quantity
Total number of rejected claims.
277 - Data Reporting Acknowledgment
D | 2200B | QTY02 | - | 380
D | 2200C | QTY02 | - | 380

Total Submitted Charges for Unit Work
Sum of the dollar amount for the claims being reported for an entity.
277 - Data Reporting Acknowledgment
D | 2200B | STC04 | - | 782
D | 2200C | STC04 | - | 782

Trace Type Code
Code identifying the type of re-association which needs to be performed.
277 - Data Reporting Acknowledgment
D | 2200A | TRN01 | - | 481
D | 2200B | TRN01 | - | 481
D | 2200C | TRN01 | - | 481
D | 2200D | TRN01 | - | 481

Transaction Segment Count
A tally of all segments between the ST and the SE segments including the ST and SE segments.
277 - Data Reporting Acknowledgment
D | | SE01 | - | 96

Transaction Set Control Number
The unique identification number within a transaction set.
277 - Data Reporting Acknowledgment
H | | ST02 | - | 329
D | | SE02 | - | 329

Transaction Set Creation Date
Identifies the date the submitter created the transaction.
277 - Data Reporting Acknowledgment
H | | BHT04 | - | 373

Transaction Set Creation Time
Time file is created for transmission.
277 - Data Reporting Acknowledgment
H | | BHT05 | - | 337

Transaction Set Identifier Code
Code uniquely identifying a Transaction Set.
277 - Data Reporting Acknowledgment
H | | ST01 | - | 143

Transaction Set Purpose Code
Code identifying purpose of transaction set.
277 - Data Reporting Acknowledgment
H | | BHT02 | - | 353

Version, Release, or Industry Identifier
Code indicating the version, release, sub-release and industry identification of the EDI standard being used.
277 - Data Reporting Acknowledgment
H | | ST03 | - | 1705