271 Transaction Set Listing

008020X344 Premium Payment Grace Period Notification
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. 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.
  2. The first element separator defines the element separator to be used through the entire interchange.
  3. Spaces in the example interchanges are represented by "." for clarity.
  4. The ISA segment terminator defines the segment terminator used throughout the entire interchange.
  5. All positions within each of the data elements must be filled.
TR3 Example:
ISA✱00✱..........✱01✱SECRET....✱ZZ✱SENDERS.ID.....✱ZZ✱RECEIVERS.ID...✱030101✱1253✱^✱00802✱000000905✱0✱T✱:~
ISA
✱
1
I01
Author Info
Qualifier
M 1
ID
2
✱
2
I02
Author
Information
M 1
AN
10
✱
3
I03
Security
Info Qual
M 1
ID
2
✱
4
I04
Security
Information
M 1
AN
10
✱
5
I05
Interchange
ID Qual
M 1
ID
2
✱
6
I06
Interchange
Sender ID
M 1
AN
15
✱
7
I05
Interchange
ID Qual
M 1
ID
2
✱
8
I07
Interchange
Receiver ID
M 1
AN
15
✱
9
I08
Interchange
Date
M 1
DT
6
✱
10
I09
Interchange
Time
M 1
TM
4
✱
11
I65
Repetition
Separator
M 1
✱
12
I11
Inter Ctrl
Version Num
M 1
ID
5
✱
13
I12
Inter Ctrl
Number
M 1
N
9
✱
14
I13
Ack
Requested
M 1
ID
1
✱
15
I14
Usage
Indicator
M 1
ID
1
✱
16
I15
Component
Elem Sep
M 1
~
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)
This element is fixed in length with identical minimum and maximum lengths. Spaces are inserted to meet the minimum length in an AN data element. With the associated code 00 in ISA01 or ISA03, an all space value indicates no information.
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)
This element is fixed in length with identical minimum and maximum lengths. Spaces are inserted to meet the minimum length in an AN data element. With the associated code 00 in ISA01 or ISA03, an all space value indicates no information.
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 Centers for Medicare & Medicaid Services (CMS)
28
Fiscal Intermediary Identification Number as assigned by Centers for Medicare & Medicaid Services (CMS)
29
Medicare Provider and Supplier Identification Number as assigned by Centers for Medicare & Medicaid Services (CMS)
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 Centers for Medicare & Medicaid Services (CMS)
28
Fiscal Intermediary Identification Number as assigned by Centers for Medicare & Medicaid Services (CMS)
29
Medicare Provider and Supplier Identification Number as assigned by Centers for Medicare & Medicaid Services (CMS)
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 Code
M 1
ID
5
Code specifying the version number of the interchange control segments, the version of the data elements within the control segments, and the code values within those data elements.
INDUSTRY NAME: Interchange Control Version Number
CODE
DEFINITION
00802
00802 Standards Approved for Publication by ASC X12 Procedures Review Board through December 2020
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 Code
M 1
ID
1
Code indicating sender's request for an interchange acknowledgment
INDUSTRY NAME: Acknowledgment Requested
X12.5 - Interchange Control Structure provides the purpose of the TA1 segment. The X12 Acknowledgment Reference Model provides considerable information about the TA1 segment.
CODE
DEFINITION
0
No Interchange Acknowledgment Requested
Use when the interchange contains ONLY acknowledgment Functional Groups (e.g. 999 or 824) or a TA1.
1
Interchange Acknowledgment Requested (TA1)
Use when batch process requires the return of a TA1 for the interchange.
2
Interchange Acknowledgment Requested only when Interchange is "Rejected Because Of Errors"
Use when the transaction is for real-time processing.
3
Interchange Acknowledgment Requested only when Interchange is "Rejected Because Of Errors" or "Accepted but Errors are Noted"
Use when batch processing requires the return of a TA1 for the interchange only when errors are noted.
Required
15
I14
Interchange Usage Indicator Code
M 1
ID
1
Code indicating whether data enclosed by this interchange envelope is test, production or information
INDUSTRY NAME: Interchange Usage Indicator
CODE
DEFINITION
I
Information
Use when the interchange contains ONLY a TA1.
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*HB - FUNCTIONAL GROUP HEADER

X12 Name:
Functional Group Header
X12 Purpose:
To indicate the beginning of a functional group and to provide control information
X12 Comments:
A functional group of related transaction sets, within the scope of X12 standards, consists of a collection of similar transaction sets enclosed by a functional group header and a functional group trailer.
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
GS✱XX✱SENDER CODE✱RECEIVER CODE✱19991231✱0802✱1✱X✱008020X344~
GS
✱
1
479
Functional
ID Code
M 1
ID
2
✱
2
142
Application
Send's Code
M 1
AN
2/15
✱
3
124
Application
Rec's Code
M 1
AN
2/15
✱
4
373
Date
M 1
DT
8
✱
5
337
Time
M 1
TM
4/8
✱
6
28
Group Ctrl
Number
M 1
N
1/9
✱
7
455
Responsible
Agency Code
M 1
ID
1/2
✱
8
480
Ver/Release
ID Code
M 1
AN
1/12
~
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
HB
Eligibility, Coverage or Benefit Information (271)
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
008020X344
Premium Payment Grace Period Notification

ST*271 - 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 Notes:
Use this control segment to mark the start of a transaction set. One ST segment exists for every transaction set that occurs within a functional group.
TR3 Example:
ST✱271✱1234✱008020X344~
ST
✱
1
143
TS ID
Code
M 1
ID
3
✱
2
329
TS Control
Number
M 1
AN
4/9
✱
3
1705
Imple Conv
Reference
O 1
AN
1/35
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
143
Transaction Set Identifier Code
M 1
ID
3
Code 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).
Use this code to identify the transaction set ID for the transaction set that will follow the ST segment. Each X12 standard has a transaction set identifier code that is unique to that transaction set.
CODE
DEFINITION
271
Eligibility, Coverage or Benefit Information
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 and must be a numeric value. The number (i.e. numeric value) is assigned by the originator and must be unique within a functional group (GS-GE). For example, start with the numeric value 0001 and increment from there. The Transaction Set Control Number also aids in error resolution research.
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.
  1. This element must be populated with the guide identifier named in Section 1.2.
  2. This field contains the same value as GS08. Some translator products strip off the ISA and GS segments prior to application (ST-SE) processing. Providing the information from the GS08 at this level will ensure that the appropriate application mapping is utilized at translation time.
CODE
DEFINITION
008020X344
Premium Payment Grace Period Notification

BHT*0012 - 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 Notes:
Use this required segment to start the transaction set and indicate the sequence of the hierarchical levels of information that will follow in Table 2.
TR3 Example:
BHT✱0012✱06✱12345✱20221201✱1200~ BHT✱0012✱14✱12345✱20221201✱1200~ BHT✱0012✱SU✱12345✱20221201✱1200~
BHT
✱
1
1005
Hierarch
Struct Code
M 1
ID
4
✱
2
353
TS Purpose
Code
M 1
ID
2
✱
3
127
Reference
Ident
O 1
AN
1/80
✱
4
373
Date
O 1
DT
8
✱
5
337
Time
O 1
TM
4/8
✱
6
640
Transaction
Type Code
O 1
ID
2
~
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
The Subscriber is equivalent to the term enrollee, and the Subscriber hierarchical level refers to information related to the Enrollee within this transaction.
CODE
DEFINITION
0012
Information Source, Provider of Service, Subscriber, Dependent
Required
2
353
Transaction Set Purpose Code
M 1
ID
2
Code identifying purpose of transaction set
CODE
DEFINITION
06
Confirmation
Use when the transaction is triggered by a provider's claim or eligibility request to the health plan for a patient that is in the premium payment grace period.
14
Advance Notification
Use when the transaction is a period report.
SU
Status Update
Use when the transaction is reporting about a patient(s) that was in a premium payment grace period but has reinstated their coverage by payment of their premium.
Required
3
127
Reference Identification
O 1
AN
1/80
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.
INDUSTRY NAME: Submitter Transaction Identifier
This element is to be used to trace the transaction from one point to the next point, such as when the transaction is passed from one clearinghouse to another clearinghouse.
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
Use this date for the date the transaction set was generated.
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
Use this time for the time the transaction set was generated.
Not Used
6
640
Transaction Type Code
O 1
ID
2

HL - HEALTH PLAN 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 2000A - HEALTH PLAN LEVEL
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
Use this loop to identify the health plan that is reporting premium payment grace period information to an impacted provider.
TR3 Example:
HL✱1✱✱20✱1~
HL
✱
1
628
Hierarch
ID Number
M 1
AN
1/12
✱
2
734
Hierarch
Parent ID
O 1
AN
1/12
✱
3
735
Hierarch
Level Code
M 1
ID
1/2
✱
4
736
Hierarch
Child Code
O 1
ID
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.
Use the sequentially assigned positive number to identify each specific occurrence of an HL segment within a transaction set. The first HL segment in the transaction must begin with the number 1 and be incremented by 1 for each successive occurrence of the HL segment within that specific transaction set (ST through SE).
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 specifying 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.
All data that follows this HL segment is associated with the Information Source identified by the level code. This association continues until the next occurrence of an HL segment.
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.
Use this code to indicate whether there are additional hierarchical levels subordinate to this Information Source.
CODE
DEFINITION
1
Additional Subordinate HL Data Segment in This Hierarchical Structure.

NM1*PR - HEALTH PLAN 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 2100A - HEALTH PLAN NAME
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
Use this NM1 loop to provide information about the Health Plan. See section 1.1 for description of the usage by entities for this transaction.
TR3 Example:
NM1✱PR✱2✱ACE INSURANCE COMPANY~
NM1
✱
1
98
Entity ID
Code
M 1
ID
2/3
✱
2
1065
Entity Type
Qualifier
M 1
ID
1
✱
3
1035
Name Last/
Org Name
X 1
AN
1/80
✱
4
1036
Name
First
O 1
AN
1/35
✱
5
1037
Name
Middle
O 1
AN
1/25
✱
6
1038
Name
Prefix
O 1
AN
1/10
✱
7
1039
Name
Suffix
O 1
AN
1/10
✱
8
66
ID Code
Qualifier
X 1
ID
1/2
✱
9
67
ID
Code
X 1
AN
2/80
✱
10
706
Entity
Relat Code
X 1
ID
2
✱
11
98
Entity ID
Code
O 1
ID
2/3
✱
12
1035
Name Last/
Org Name
O 1
AN
1/80
~
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
PR
Payer
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code identifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
2
Non-Person Entity
Required
3
1035
Name Last or Organization Name
X 1
AN
1/80
Individual last name or organizational name
SEGMENT SYNTAX: C1203
INDUSTRY NAME: Health Plan 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
Situational
8
66
Identification Code Qualifier
X 1
ID
1/2
Code specifying 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
XV
Standard Unique Health Plan Identifier (HPID)
CODE SOURCE: 540: Health Plan Identifier (HPID)
Situational
9
67
Identification Code
X 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
SITUATIONAL RULE: Required when reporting the Health Plan ID (HPID) or Other Entity Identifier (OEID). If not required by this implementation guide, do not send.
INDUSTRY NAME: Health Plan Identifier
Not Used
10
706
Entity Relationship Code
X 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/80

REF - HEALTH PLAN 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 2100A - HEALTH PLAN NAME
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when NM109 of this loop is not used. If not required by this implementation guide, do not send.
TR3 Example:
REF✱2U✱12345567~
REF
✱
1
128
Reference
Ident Qual
M 1
ID
2/3
✱
2
127
Reference
Ident
X 1
AN
1/80
✱
3
352
Description
X 1
AN
1/80
✱
4
C040
Reference
Identifier
O 1
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
CODE
DEFINITION
2U
Payer Identification Number
EI
Employer's Identification Number
Required
2
127
Reference Identification
X 1
AN
1/80
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Health Plan Secondary Identification
Not Used
3
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

PER*CR - HEALTH PLAN PROVIDER CONTACT INFORMATION

X12 Name:
Administrative Communications Contact
X12 Purpose:
To identify a person or office to whom administrative communications should be directed
X12 Syntax:
  1. P0304
    If either PER03 or PER04 is present, then the other is required.
  2. P0506
    If either PER05 or PER06 is present, then the other is required.
  3. P0708
    If either PER07 or PER08 is present, then the other is required.
Loop:
Loop 2100A - HEALTH PLAN NAME
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
  1. When the communication number represents a telephone number in the United States and other countries using the North American Dialing Plan (for voice, data, fax, etc.), the communication number must always include the area code and phone number using the format AAABBBCCCC where AAA is the area code, BBB is the telephone number prefix, and CCCC is the telephone number. Therefore, the following telephone number (555) 555-1234 would be represented as 5555551234. Do not submit long distance access numbers, such as 1, in the telephone number. Telephone extensions, when applicable, must be submitted in the next element immediately following the telephone number. When submitting telephone extensions, only submit the numeric extension, do not include data that indicates an extension, such as "ext" or "x-".
  2. This segment is used to report the Health Plan contact information for the provider.
TR3 Example:
PER✱CR✱JOHN SMITH✱TE✱5555551234✱EX✱123~
PER
✱
1
366
Contact
Funct Code
M 1
ID
2
✱
2
93
Name
O 1
AN
1/60
✱
3
365
Comm
Number Qual
X 1
ID
2
✱
4
364
Comm
Number
X 1
AN
1/2048
✱
5
365
Comm
Number Qual
X 1
ID
2
✱
6
364
Comm
Number
X 1
AN
1/2048
✱
7
365
Comm
Number Qual
X 1
ID
2
✱
8
364
Comm
Number
X 1
AN
1/2048
✱
9
443
Contact Inq
Reference
O 1
AN
1/20
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
366
Contact Function Code
M 1
ID
2
Code identifying the major duty or responsibility of the person or group named
CODE
DEFINITION
CR
Customer Relations
Situational
2
93
Name
O 1
AN
1/60
Free-form name
SITUATIONAL RULE: Required when it is necessary to identify an individual or other contact point to discuss information related to this transaction. If not required by this implementation guide, do not send.
INDUSTRY NAME: Health Plan Specific Customer Service Contact Name
Required
3
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0304
Use this code to specify what type of communication number is following.
CODE
DEFINITION
EM
Electronic Mail
FX
Facsimile
TE
Telephone
UR
Uniform Resource Locator (URL)
Required
4
364
Communication Number
X 1
AN
1/2048
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0304
INDUSTRY NAME: Health Plan Specific Customer Service Communication Number
Situational
5
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when PER06 is used. If not required by this implementation guide, do not send.
CODE
DEFINITION
EM
Electronic Mail
EX
Telephone Extension
FX
Facsimile
TE
Telephone
UR
Uniform Resource Locator (URL)
Situational
6
364
Communication Number
X 1
AN
1/2048
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when a second communication contact number or e-mail is needed. If not required by this implementation guide, do not send.
INDUSTRY NAME: Health Plan Specific Customer Service Communication Number
Situational
7
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0708
SITUATIONAL RULE: Required when PER08 is used. If not required by this implementation guide, do not send.
CODE
DEFINITION
EM
Electronic Mail
EX
Telephone Extension
FX
Facsimile
TE
Telephone
UR
Uniform Resource Locator (URL)
Situational
8
364
Communication Number
X 1
AN
1/2048
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0708
SITUATIONAL RULE: Required when a third communication contact number, e-mail or Web address is needed. If not required by this implementation guide, do not send.
INDUSTRY NAME: Health Plan Specific Customer Service Communication Number
Not Used
9
443
Contact Inquiry Reference
O 1
AN
1/20

PER*IC - HEALTH PLAN GRACE PERIOD URL

X12 Name:
Administrative Communications Contact
X12 Purpose:
To identify a person or office to whom administrative communications should be directed
X12 Syntax:
  1. P0304
    If either PER03 or PER04 is present, then the other is required.
  2. P0506
    If either PER05 or PER06 is present, then the other is required.
  3. P0708
    If either PER07 or PER08 is present, then the other is required.
Loop:
Loop 2100A - HEALTH PLAN NAME
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the health plan chooses to provide grace period statement information via their website. If not required by this implementation guide, may be sent at the sender's discretion but cannot be required by the receiver.
TR3 Notes:
The issuer URL identifies a location on the issuer's website that identifies grace period related information. The website may include information such as a notification purpose, grace period explanation, grace period exhaustion consequences for the enrollee or the provider. Note that any federal or state regulatory requirements may impact the minimum information available in this manner.
TR3 Example:
PER✱IC✱✱UR✱WWW.ACEINSURANCE.COM~
PER
✱
1
366
Contact
Funct Code
M 1
ID
2
✱
2
93
Name
O 1
AN
1/60
✱
3
365
Comm
Number Qual
X 1
ID
2
✱
4
364
Comm
Number
X 1
AN
1/2048
✱
5
365
Comm
Number Qual
X 1
ID
2
✱
6
364
Comm
Number
X 1
AN
1/2048
✱
7
365
Comm
Number Qual
X 1
ID
2
✱
8
364
Comm
Number
X 1
AN
1/2048
✱
9
443
Contact Inq
Reference
O 1
AN
1/20
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
366
Contact Function Code
M 1
ID
2
Code identifying the major duty or responsibility of the person or group named
CODE
DEFINITION
IC
Information Contact
Not Used
2
93
Name
O 1
AN
1/60
Required
3
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0304
CODE
DEFINITION
UR
Uniform Resource Locator (URL)
Required
4
364
Communication Number
X 1
AN
1/2048
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0304
INDUSTRY NAME: Health Plan Grace Period URL
Not Used
5
365
Communication Number Qualifier
X 1
ID
2
Not Used
6
364
Communication Number
X 1
AN
1/2048
Not Used
7
365
Communication Number Qualifier
X 1
ID
2
Not Used
8
364
Communication Number
X 1
AN
1/2048
Not Used
9
443
Contact Inquiry Reference
O 1
AN
1/20

DTP*600 - REPORTING 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 2100A - HEALTH PLAN NAME
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
This is the date that the information was reported out of the Health Plan's business system.
TR3 Example:
DTP✱600✱D8✱20221201~
DTP
✱
1
374
Date/Time
Qualifier
M 1
ID
3
✱
2
1250
Date Time
Format Qual
M 1
ID
2/3
✱
3
1251
Date Time
Period
M 1
AN
1/35
~
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
600
As Of
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.
INDUSTRY NAME: Reporting Date
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

HL - PROVIDER 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 2000B - PROVIDER LEVEL
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
Use this loop to identify the impacted provider that is receiving premium payment grace period information from the health plan.
TR3 Example:
HL✱2✱1✱21✱1~
HL
✱
1
628
Hierarch
ID Number
M 1
AN
1/12
✱
2
734
Hierarch
Parent ID
O 1
AN
1/12
✱
3
735
Hierarch
Level Code
M 1
ID
1/2
✱
4
736
Hierarch
Child Code
O 1
ID
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.
Use the sequentially assigned positive number to identify each specific occurrence of an HL segment within a transaction set. The first HL segment in the transaction must begin with the number 1 and be incremented by 1 for each successive occurrence of the HL segment within that specific transaction set (ST through SE).
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 specifying 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.
All data that follows this HL segment is associated with the Information Receiver identified by the level code. This association continues until the next occurrence of an HL segment.
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.
Use this code to indicate whether there are additional hierarchical levels subordinate to the current hierarchical level.
CODE
DEFINITION
0
No Subordinate HL Segment in This Hierarchical Structure.
Use when the transaction is a periodic report (BHT02=14) and no enrollees are in a premium payment grace period for the provider identified in this loop.
1
Additional Subordinate HL Data Segment in This Hierarchical Structure.
Use when the transaction is a periodic report (BHT02=14) with enrollees that are in a premium payment grace period for the provider identified in this loop, the transaction is a confirmation of a grace period related to a claim or eligibility and benefit check (BHT02=06), or the transaction is a notification that the enrollee previously in a premium payment grace period has paid their premium and been reinstated (BHT02=SU).

NM1*1P - 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 2100B - PROVIDER NAME
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
Use this segment to identify an entity by name and/or identification number that may be impacted by the grace period status of the patients included in the transaction. This 2100B loop is used to identify the provider.
TR3 Example:
NM1✱1P✱2✱ABC GROUP PRACTICE✱✱✱✱✱XX✱1234567890~
NM1
✱
1
98
Entity ID
Code
M 1
ID
2/3
✱
2
1065
Entity Type
Qualifier
M 1
ID
1
✱
3
1035
Name Last/
Org Name
X 1
AN
1/80
✱
4
1036
Name
First
O 1
AN
1/35
✱
5
1037
Name
Middle
O 1
AN
1/25
✱
6
1038
Name
Prefix
O 1
AN
1/10
✱
7
1039
Name
Suffix
O 1
AN
1/10
✱
8
66
ID Code
Qualifier
X 1
ID
1/2
✱
9
67
ID
Code
X 1
AN
2/80
✱
10
706
Entity
Relat Code
X 1
ID
2
✱
11
98
Entity ID
Code
O 1
ID
2/3
✱
12
1035
Name Last/
Org Name
O 1
AN
1/80
~
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
1P
Provider
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code identifying the type of entity
SEMANTIC: NM102 qualifies NM103.
Use this element to indicate whether the entity is an individual person or an organization.
CODE
DEFINITION
1
Person
2
Non-Person Entity
Required
3
1035
Name Last or Organization Name
X 1
AN
1/80
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 Provider is a person (NM102=1) AND the information is known from systems of the sender. 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 Provider is a person (NM102=1), NM103 is used AND the information is known from systems of the sender. 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 Provider is a person (NM102=1) and this information is necessary for identification of the individual, for instance when a Junior and Senior are both providers in the same practice. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Name Suffix
Situational
8
66
Identification Code Qualifier
X 1
ID
1/2
Code specifying 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
Standard Unique Health Identifier for Health Care Providers (NPI)
CODE SOURCE: 537: National Provider Identifier (NPI)
Situational
9
67
Identification Code
X 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
SITUATIONAL RULE: Required when the provider is a covered health care provider under the mandate. If not required by this implementation guide, do not send.
Not Used
10
706
Entity Relationship Code
X 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/80

REF*A6 - 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 2100B - PROVIDER NAME
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the information in 2100B NM1 is not sufficient to identify the provider. If not required by this implementation guide, may be provided at sender's discretion, but cannot be required by the receiver.
TR3 Example:
REF✱A6✱123456798~
REF
✱
1
128
Reference
Ident Qual
M 1
ID
2/3
✱
2
127
Reference
Ident
X 1
AN
1/80
✱
3
352
Description
X 1
AN
1/80
✱
4
C040
Reference
Identifier
O 1
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code identifying the Reference Identification
CODE
DEFINITION
A6
Provider Identifier
Required
2
127
Reference Identification
X 1
AN
1/80
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Provider Additonal Identifier
Not Used
3
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

N3 - PROVIDER ADDRESS

X12 Name:
Party Location
X12 Purpose:
To specify the location of the named party
Loop:
Loop 2100B - PROVIDER NAME
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
N3✱123 MAIN STREET~
N3
✱
1
166
Address
Information
M 1
AN
1/55
✱
2
166
Address
Information
O 1
AN
1/55
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
166
Address Information
M 1
AN
1/55
Address information
INDUSTRY NAME: Provider Address Line
Situational
2
166
Address Information
O 1
AN
1/55
Address information
SITUATIONAL RULE: Required when a second address line is needed. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Address Line

N4 - PROVIDER CITY, STATE, ZIP CODE

X12 Name:
Geographic Location
X12 Purpose:
To specify the geographic place of the named party
X12 Syntax:
  1. E0207
    Only one of N402 or N407 may be present.
  2. E0308
    Only one of N403 or N408 may be present.
  3. C0605
    If N406 is present, then N405 is required.
  4. C0704
    If N407 is present, then N404 is required.
Loop:
Loop 2100B - PROVIDER NAME
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
N4✱KANSAS CITY✱MO✱641051909~
N4
✱
1
19
City
Name
O 1
AN
2/30
✱
2
156
State or
Prov Code
X 1
ID
2
✱
3
116
Postal
Code
X 1
ID
3/15
✱
4
26
Country
Code
X 1
ID
2/3
✱
5
309
Location
Qualifier
X 1
ID
1/2
✱
6
310
Location
Identifier
O 1
AN
1/30
✱
7
1715
Country Sub
Code
X 1
ID
1/3
✱
8
1702
Postal Code
Formatted
X 1
AN
3/20
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
19
City Name
O 1
AN
2/30
Free-form text for city name
COMMENT: A combination of either N401 through N404, or N405 and N406 may be adequate to specify a location.
INDUSTRY NAME: Provider City Name
Situational
2
156
State or Province Code
X 1
ID
2
Code specifying the Standard State/Province as defined by appropriate government agency
SEGMENT SYNTAX: E0207
SITUATIONAL RULE: Required when the address is in the United States of America, including its territories, or Canada. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider State Code
CODE SOURCE 22: States and Provinces
Situational
3
116
Postal Code
X 1
ID
3/15
Code specifying international postal zone code excluding punctuation and blanks (zip code for United States)
COMMENT: N403 contains the postal code in an unstructured format. N408 contains the postal code in a structured format. When a postal code data field is used, the parties shall agree as to which data element (N403 or N408) shall be used in the transaction set.
SEGMENT SYNTAX: E0308
SITUATIONAL RULE: Required when the address is in the United States of America, including its territories, or Canada, or when a postal code exists for the country in N404. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Postal Zone or ZIP Code
  • CODE SOURCE 51: ZIP Code
  • CODE SOURCE 932: Universal Postal Codes
Situational
4
26
Country Code
X 1
ID
2/3
Code identifying the country
SEGMENT SYNTAX: C0704
SITUATIONAL RULE: Required when the address is outside the United States of America. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Country Code
CODE SOURCE 5: Countries, Currencies and Funds
Not Used
5
309
Location Qualifier
X 1
ID
1/2
Not Used
6
310
Location Identifier
O 1
AN
1/30
Not Used
7
1715
Country Subdivision Code
X 1
ID
1/3
Not Used
8
1702
Postal Code-Formatted
X 1
AN
3/20

HL - ENROLLEE 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 2000C - ENROLLEE LEVEL
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required when at least one enrollee within a premium payment grace period impacts the provider,
OR
Required when the transaction is a status update (BHT02=SU) reporting that a person previously reported as being in a premium payment grace period has paid their premium and their coverage has been reinstated. If not required by this implementation guide, do not send
TR3 Notes:
  1. Use this loop to identify the enrollee that is the subject of the premium payment grace period information from the health plan.
  2. See section 1.10.1 for information about reporting a dependent as an enrollee.
TR3 Example:
HL✱3✱2✱22✱1~
HL
✱
1
628
Hierarch
ID Number
M 1
AN
1/12
✱
2
734
Hierarch
Parent ID
O 1
AN
1/12
✱
3
735
Hierarch
Level Code
M 1
ID
1/2
✱
4
736
Hierarch
Child Code
O 1
ID
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.
Use the sequentially assigned positive number to identify each specific occurrence of an HL segment within a transaction set. The first HL segment in the transaction must begin with the number 1 and be incremented by 1 for each successive occurrence of the HL segment within that specific transaction set (ST through SE).
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.
This number identifies that the Enrollee Level is subordinate to the Provider Level. This element always contains "2".
Required
3
735
Hierarchical Level Code
M 1
ID
1/2
Code specifying 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.
All data that follows this HL segment is associated with the Enrollee identified by the level code. This association continues until the next occurrence of an HL segment.
CODE
DEFINITION
22
Subscriber
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.
Because of the hierarchical structure, the code value in the HL04 at the Loop 2000C level should be "1" if a Loop 2000D level (dependent) is associated with this enrollee. If no Loop 2000D level exists for this enrollee, then the code value for HL04 should be "0" (zero).
CODE
DEFINITION
0
No Subordinate HL Segment in This Hierarchical Structure.
1
Additional Subordinate HL Data Segment in This Hierarchical Structure.

TRN*1 - ENROLLEE NOTIFICATION NUMBER

X12 Name:
Trace
X12 Purpose:
To uniquely identify a transaction to an application
X12 Set Notes:
NOTE: If the Eligibility, Coverage or Benefit Inquiry Transaction Set (270) includes a TRN segment, then the Eligibility, Coverage or Benefit Information Transaction Set (271) must return the trace number identified in the TRN segment.
Loop:
Loop 2000C - ENROLLEE LEVEL
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required for an HIX notification or whenever the issuer desires to assign a trace number to the notification. If not required by this implementation guide, do not send.
TR3 Example:
TRN✱1✱123456789~
TRN
✱
1
481
Trace Type
Code
M 1
ID
1/2
✱
2
127
Reference
Ident
M 1
AN
1/80
✱
3
509
Originating
Company ID
O 1
AN
10
✱
4
127
Reference
Ident
O 1
AN
1/80
~
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/80
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: Trace Number
Not Used
3
509
Originating Company Identifier
O 1
AN
10
Not Used
4
127
Reference Identification
O 1
AN
1/80

NM1*IL - ENROLLEE 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 2100C - ENROLLEE NAME
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
NM1✱IL✱1✱DOE✱JOHN✱T✱✱JR✱MI✱123456~
NM1
✱
1
98
Entity ID
Code
M 1
ID
2/3
✱
2
1065
Entity Type
Qualifier
M 1
ID
1
✱
3
1035
Name Last/
Org Name
X 1
AN
1/80
✱
4
1036
Name
First
O 1
AN
1/35
✱
5
1037
Name
Middle
O 1
AN
1/25
✱
6
1038
Name
Prefix
O 1
AN
1/10
✱
7
1039
Name
Suffix
O 1
AN
1/10
✱
8
66
ID Code
Qualifier
X 1
ID
1/2
✱
9
67
ID
Code
X 1
AN
2/80
✱
10
706
Entity
Relat Code
X 1
ID
2
✱
11
98
Entity ID
Code
O 1
ID
2/3
✱
12
1035
Name Last/
Org Name
O 1
AN
1/80
~
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
IL
Insured or Subscriber
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code identifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
1
Person
Required
3
1035
Name Last or Organization Name
X 1
AN
1/80
Individual last name or organizational name
SEGMENT SYNTAX: C1203
INDUSTRY NAME: Enrollee Last Name
Situational
4
1036
Name First
O 1
AN
1/35
Individual first name
SITUATIONAL RULE: Required when the enrollee has a first name. If not required by this implementation guide, do not send.
INDUSTRY NAME: Enrollee First Name
Situational
5
1037
Name Middle
O 1
AN
1/25
Individual middle name or initial
SITUATIONAL RULE: Required when the enrollee has a middle name or initial of the person and is needed to identify the individual. If not required by this implementation guide, do not send.
INDUSTRY NAME: Enrollee 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 Suffix is known to the sender. If not required by this implementation guide, do not send.
INDUSTRY NAME: Enrollee Name Suffix
Required
8
66
Identification Code Qualifier
X 1
ID
1/2
Code specifying the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: P0809
CODE
DEFINITION
MI
Member Identification Number
Required
9
67
Identification Code
X 1
AN
2/80
Code identifying a party or other code
SEGMENT SYNTAX: P0809
INDUSTRY NAME: Enrollee Identifier
This is the identifier assigned by the issuer to the enrollee.
Not Used
10
706
Entity Relationship Code
X 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/80

N3 - ENROLLEE ADDRESS

X12 Name:
Party Location
X12 Purpose:
To specify the location of the named party
Loop:
Loop 2100C - ENROLLEE NAME
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the enrollee address is available for the enrollee and usage is not prohibited or restricted. If not required by this implementation guide, do not send.
TR3 Example:
N3✱123 MAIN STREET~
N3
✱
1
166
Address
Information
M 1
AN
1/55
✱
2
166
Address
Information
O 1
AN
1/55
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
166
Address Information
M 1
AN
1/55
Address information
INDUSTRY NAME: Enrollee Address Line
Situational
2
166
Address Information
O 1
AN
1/55
Address information
SITUATIONAL RULE: Required when a second address line is needed. If not required by this implementation guide, do not send.
INDUSTRY NAME: Enrollee Address Line

N4 - ENROLLEE CITY, STATE, ZIP CODE

X12 Name:
Geographic Location
X12 Purpose:
To specify the geographic place of the named party
X12 Syntax:
  1. E0207
    Only one of N402 or N407 may be present.
  2. E0308
    Only one of N403 or N408 may be present.
  3. C0605
    If N406 is present, then N405 is required.
  4. C0704
    If N407 is present, then N404 is required.
Loop:
Loop 2100C - ENROLLEE NAME
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the N3 segment of this loop is used. If not required by this implementation guide, do not send.
TR3 Example:
N4✱KANSAS CITY✱MO✱641081234~
N4
✱
1
19
City
Name
O 1
AN
2/30
✱
2
156
State or
Prov Code
X 1
ID
2
✱
3
116
Postal
Code
X 1
ID
3/15
✱
4
26
Country
Code
X 1
ID
2/3
✱
5
309
Location
Qualifier
X 1
ID
1/2
✱
6
310
Location
Identifier
O 1
AN
1/30
✱
7
1715
Country Sub
Code
X 1
ID
1/3
✱
8
1702
Postal Code
Formatted
X 1
AN
3/20
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
19
City Name
O 1
AN
2/30
Free-form text for city name
COMMENT: A combination of either N401 through N404, or N405 and N406 may be adequate to specify a location.
INDUSTRY NAME: Enrollee City Name
Situational
2
156
State or Province Code
X 1
ID
2
Code specifying the Standard State/Province as defined by appropriate government agency
SEGMENT SYNTAX: E0207
SITUATIONAL RULE: Required when the address is in the United States of America, including its territories, or Canada. If not required by this implementation guide, do not send.
INDUSTRY NAME: Enrollee State or Province Code
CODE SOURCE 22: States and Provinces
Situational
3
116
Postal Code
X 1
ID
3/15
Code specifying international postal zone code excluding punctuation and blanks (zip code for United States)
COMMENT: N403 contains the postal code in an unstructured format. N408 contains the postal code in a structured format. When a postal code data field is used, the parties shall agree as to which data element (N403 or N408) shall be used in the transaction set.
SEGMENT SYNTAX: E0308
SITUATIONAL RULE: Required when the address is in the United States of America, including its territories, or Canada, or when a postal code exists for the country in N404. If not required by this implementation guide, do not send.
INDUSTRY NAME: Enrollee Postal Zone or Zip Code
  • CODE SOURCE 51: ZIP Code
  • CODE SOURCE 932: Universal Postal Codes
Situational
4
26
Country Code
X 1
ID
2/3
Code identifying the country
SEGMENT SYNTAX: C0704
SITUATIONAL RULE: Required when the address is outside the United States of America. If not required by this implementation guide, do not send.
INDUSTRY NAME: Enrollee Country Code
CODE SOURCE 5: Countries, Currencies and Funds
Not Used
5
309
Location Qualifier
X 1
ID
1/2
Not Used
6
310
Location Identifier
O 1
AN
1/30
Not Used
7
1715
Country Subdivision Code
X 1
ID
1/3
Not Used
8
1702
Postal Code-Formatted
X 1
AN
3/20

PER*IC - HEALTH PLAN GRACE PERIOD URL

X12 Name:
Administrative Communications Contact
X12 Purpose:
To identify a person or office to whom administrative communications should be directed
X12 Syntax:
  1. P0304
    If either PER03 or PER04 is present, then the other is required.
  2. P0506
    If either PER05 or PER06 is present, then the other is required.
  3. P0708
    If either PER07 or PER08 is present, then the other is required.
Loop:
Loop 2100C - ENROLLEE NAME
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the health plan URL for grace period information related to this patient is different than any URL reported as the Health Plan website URL at 2100A. If not required by this implementation guide, do not send.
TR3 Notes:
The health plan URL identifies a location on the health plan's website that identifies grace period related information. The website may include information such as a notification purpose, grace period explanation, grace period exhaustion consequences for the enrollee or the provider. Note that any federal or state regulatory requirements may impact the minimum information available in this manner.
TR3 Example:
PER✱IC✱✱UR✱WWW.ACEINSURANCE.COM~
PER
✱
1
366
Contact
Funct Code
M 1
ID
2
✱
2
93
Name
O 1
AN
1/60
✱
3
365
Comm
Number Qual
X 1
ID
2
✱
4
364
Comm
Number
X 1
AN
1/2048
✱
5
365
Comm
Number Qual
X 1
ID
2
✱
6
364
Comm
Number
X 1
AN
1/2048
✱
7
365
Comm
Number Qual
X 1
ID
2
✱
8
364
Comm
Number
X 1
AN
1/2048
✱
9
443
Contact Inq
Reference
O 1
AN
1/20
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
366
Contact Function Code
M 1
ID
2
Code identifying the major duty or responsibility of the person or group named
CODE
DEFINITION
IC
Information Contact
Not Used
2
93
Name
O 1
AN
1/60
Required
3
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0304
CODE
DEFINITION
UR
Uniform Resource Locator (URL)
Required
4
364
Communication Number
X 1
AN
1/2048
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0304
INDUSTRY NAME: Health Plan Grace Period URL
Not Used
5
365
Communication Number Qualifier
X 1
ID
2
Not Used
6
364
Communication Number
X 1
AN
1/2048
Not Used
7
365
Communication Number Qualifier
X 1
ID
2
Not Used
8
364
Communication Number
X 1
AN
1/2048
Not Used
9
443
Contact Inquiry Reference
O 1
AN
1/20

DMG*D8 - ENROLLEE DATE OF BIRTH

X12 Name:
Demographic Information
X12 Purpose:
To supply demographic information
X12 Syntax:
  1. P0102
    If either DMG01 or DMG02 is present, then the other is required.
  2. P1011
    If either DMG10 or DMG11 is present, then the other is required.
  3. C1105
    If DMG11 is present, then DMG05 is required.
Loop:
Loop 2100C - ENROLLEE NAME
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
DMG✱D8✱19850704~
DMG
✱
1
1250
Date Time
Format Qual
X 1
ID
2/3
✱
2
1251
Date Time
Period
X 1
AN
1/35
✱
3
1068
Gender
Code
O 1
ID
1
✱
4
1067
Marital
Status Code
O 1
ID
1
✱
5
C056
Comp Race
or Ethn Inf
X 25
✱
6
1066
Citizenship
Status Code
O 1
ID
1/2
✱
7
26
Country
Code
O 1
ID
2/3
✱
8
659
Basis of
Verif Code
O 1
ID
1/2
✱
9
380
Quantity
O 1
R
1/15
✱
10
1270
Code List
Qual Code
X 1
ID
1/3
✱
11
1271
Industry
Code
X 1
AN
1/30
✱
12
26
Country
Code
O 1
ID
2/3
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Code indicating the date format, time format, or date and time format
SEGMENT SYNTAX: P0102
CODE
DEFINITION
D8
Date Expressed in Format CCYYMMDD
Required
2
1251
Date Time Period
X 1
AN
1/35
Expression of a date, a time, or range of dates, times or dates and times
SEMANTIC: DMG02 is the date of birth.
SEGMENT SYNTAX: P0102
INDUSTRY NAME: Enrollee Birth Date
Not Used
3
1068
Gender Code
O 1
ID
1
Not Used
4
1067
Marital Status Code
O 1
ID
1
Not Used
5
C056
Composite Race or Ethnicity Information
X 25
Not Used
6
1066
Citizenship Status Code
O 1
ID
1/2
Not Used
7
26
Country Code
O 1
ID
2/3
Not Used
8
659
Basis of Verification Code
O 1
ID
1/2
Not Used
9
380
Quantity
O 1
R
1/15
Not Used
10
1270
Code List Qualifier Code
X 1
ID
1/3
Not Used
11
1271
Industry Code
X 1
AN
1/30
Not Used
12
26
Country Code
O 1
ID
2/3

DTP*343 - PREMIUM PAID THROUGH 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 2100C - ENROLLEE NAME
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when mandated by regulation or contract, or the health plan desires to report the date through which the premium has been paid. If not required by this implementation guide, do not send.
TR3 Notes:
This is the last day of coverage for which a premium payment has been received.
TR3 Example:
DTP✱343✱D8✱20221031~
DTP
✱
1
374
Date/Time
Qualifier
M 1
ID
3
✱
2
1250
Date Time
Format Qual
M 1
ID
2/3
✱
3
1251
Date Time
Period
M 1
AN
1/35
~
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
343
Premium Paid to Date End
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: Premium Paid Through Date

DTP*BGP - GRACE PERIOD START 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 2100C - ENROLLEE NAME
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the transaction is a grace period notification (when BHT02 is not equal to SU). If not required by this implementation guide, do not send.
TR3 Notes:
This is the first day of the premium payment grace period.
TR3 Example:
DTP✱BGP✱D8✱20221101~
DTP
✱
1
374
Date/Time
Qualifier
M 1
ID
3
✱
2
1250
Date Time
Format Qual
M 1
ID
2/3
✱
3
1251
Date Time
Period
M 1
AN
1/35
~
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
BGP
Beginning of Grace Period
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: Grace Period Start Date

DTP*756 - GRACE PERIOD END 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 2100C - ENROLLEE NAME
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the transaction is a grace period notification (when BHT02 is not equal to SU). If not required by this implementation guide, do not send.
TR3 Notes:
This is the last day of the premium payment grace period.
TR3 Example:
DTP✱756✱D8✱20220131~
DTP
✱
1
374
Date/Time
Qualifier
M 1
ID
3
✱
2
1250
Date Time
Format Qual
M 1
ID
2/3
✱
3
1251
Date Time
Period
M 1
AN
1/35
~
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
756
End of Grace Period
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: Grace Period End Date

LX - TRANSACTION SET LINE NUMBER

X12 Name:
Transaction Set Line Number
X12 Purpose:
To reference a line number in a transaction set
Loop:
Loop 2105C - TRANSACTION SET LINE NUMBER
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
LX
✱
1
554
Assigned
Number
M 1
N
1/9
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
554
Assigned Number
M 1
N
1/9
Number assigned for differentiation within a transaction set
Start with a value of "1" in the first instance of the loop, and increment by "1" in each subsequent instance of the loop within the transaction.

EB - ELIGIBILITY OR BENEFIT INFORMATION

X12 Name:
Eligibility or Benefit Information
X12 Purpose:
To supply eligibility or benefit information
X12 Syntax:
P0910
If either EB09 or EB10 is present, then the other is required.
Loop:
Loop 2110C - ELIGIBILITY OR BENEFIT INFORMATION
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
EB✱12✱✱✱✱✱✱✱✱MN✱2~
EB
✱
1
1390
Eligibility
Benefit Inf
M 25
ID
1/2
✱
2
1207
Coverage
Level Code
O 1
ID
3
✱
3
C064
Service
Type
O 99
✱
4
1788
Ins Product
Code
O 1
ID
1/3
✱
5
1204
Plan Cvrg
Description
O 1
AN
1/50
✱
6
615
Time Period
Qualifier
O 1
ID
1/2
✱
7
782
Monetary
Amount
O 1
R
1/18
✱
8
954
Percent
O 1
R
1/10
✱
9
673
Quantity
Qualifier
X 1
ID
2
✱
10
380
Quantity
X 1
R
1/15
✱
11
1073
Yes/No Cond
Resp Code
O 1
ID
1
✱
12
1791
Netwk Indic
Code
O 1
ID
1/2
✱
13
C003
Comp. Med.
Proced. ID
O 99
✱
14
1328
Diagnosis
Code Pointr
O 12
N
1/2
✱
15
1073
Yes/No Cond
Resp Code
O 1
ID
1
✱
16
1796
Hlth Ca Ser
Rev Req Cde
O 10
ID
1/2
✱
17
C022
Health Care
Code Info.
O 99
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
1390
Eligibility or Benefit Information Code
M 25
ID
1/2
Code identifying eligibility or benefit information
SEMANTIC: All EB01 values qualify EB06 through EB10. Position of data in the repeating data element conveys no significance.
INDUSTRY NAME: Grace Period Information Code
The maximum number of occurrences of this instance of data element 1390 is 1.
CODE
DEFINITION
1
Active Coverage
Use when the transaction is a notification that a person previously in a grace period has paid their premium and been removed from the grace period (when BHT02=SU).
11
Active - Pending Receipt of Premium Payment
Use when indicating the payer has deemed the member has Active coverage, even though the member is currently in a premium payment grace period. This occurs when this transaction date is (1) prior to the enrollee's initial premium payment due date or (2) the enrollee is within the first month of the Individual Marketplace three month grace period or (3) the enrollee is within a SHOP Marketplace grace period or (4) the enrollee is in a non-HIX grace period that permits active coverage.
12
Inactive - Pending Receipt of Premium Payment
Use when indicating the payer has deemed the member has Inactive coverage, even though the member is currently in a premium payment grace period. This occurs when this transaction date is (1) after the enrollee's initial premium payment due date or (2) the enrollee is within the second and third months of the Individual Marketplace three month grace period or (3) the enrollee is in a non-HIX grace period that provides for inactive coverage.
Not Used
2
1207
Coverage Level Code
O 1
ID
3
Not Used
3
C064
Service Type
O 99
Situational
4
1788
Insurance Product Code
O 1
ID
1/3
Code identifying the type of insurance policy within a specific insurance program for eligibility purposes.
SITUATIONAL RULE: Required when the health plan is required by regulations or contract, or desires to identify the product insurance type or category. If not required by this implementation guide, do not send.
INDUSTRY NAME: Insurance Type or Category
CODE SOURCE 979: Insurance Descriptor Codes
Not Used
5
1204
Plan Coverage Description
O 1
AN
1/50
Not Used
6
615
Time Period Qualifier
O 1
ID
1/2
Not Used
7
782
Monetary Amount
O 1
R
1/18
Not Used
8
954
Percentage as Decimal
O 1
R
1/10
Situational
9
673
Quantity Qualifier
X 1
ID
2
Code specifying the type of quantity
SEGMENT SYNTAX: P0910
SITUATIONAL RULE: Required when EB10 is used. If not required by this implementation guide, do not send.
INDUSTRY NAME: Grace Period Quantity Qualifier
Use this code to identify the type of units that are being conveyed in the following data element (EB10).
CODE
DEFINITION
DY
Days
Use when the grace period unit in EB10 is in days.
MN
Month
Use when the grace period unit in EB10 is in months.
Situational
10
380
Quantity
X 1
R
1/15
Numeric value of quantity
SEGMENT SYNTAX: P0910
SITUATIONAL RULE: Required when this report is not an update identifying payment of outstanding premium(s) (when BHT02 is not equal to SU). If not required by this implementation guide, do not send.
INDUSTRY NAME: Applicable Period
  1. This indicates the number of the Grace Period Quantity units already applied within the grace period, including the current applicable unit. If the grace period is for months, a value of "1" here indicates that the patient is in the first month of the grace period, "2" indicates that the patient is in the second month of the grace period, and "3" indicates that the patient is in the third month of the grace period.
  2. When the grace period is for days, this is the day of the grace period corresponding to the date of this report. If the report is produced in the 17th day after the premium payment was due, the content of this element would be "17".
Not Used
11
1073
Yes/No Condition or Response Code
O 1
ID
1
Not Used
12
1791
Network Indicator Code
O 1
ID
1/2
Not Used
13
C003
Composite Medical Procedure Identifier
O 99
Not Used
14
1328
Diagnosis Code Pointer
O 12
N
1/2
Not Used
15
1073
Yes/No Condition or Response Code
O 1
ID
1
Not Used
16
1796
Health Care Services Review Requirement Code
O 10
ID
1/2
Not Used
17
C022
Health Care Code Information
O 99

PID*F - GRACE PERIOD TYPE

X12 Name:
Product/Item Description
X12 Purpose:
To describe a product or process in coded or free-form format
X12 Syntax:
  1. C0403
    If PID04 is present, then PID03 is required.
  2. R040510
    At least one of PID04, PID05 or PID10 is required.
  3. C0703
    If PID07 is present, then PID03 is required.
  4. C0804
    If PID08 is present, then PID04 is required.
  5. C0905
    If PID09 is present, then PID05 is required.
Loop:
Loop 2110C - ELIGIBILITY OR BENEFIT INFORMATION
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when satisfying the issuers obligation to provide a grace period notice as mandated by state or federal requirements. If not required by this implementation guide, do not send.
TR3 Notes:
Use this segment for the identification of an HIX tax credit related premium payment grace period, an HIX non-tax credit related premium payment grace period, or a non-HIX related premium payment grace period.
TR3 Example:
PID✱F✱✱✱✱FEDERAL MANDATE~
PID
✱
1
349
Item Desc
Type
M 1
ID
1
✱
2
750
Prod/Proces
Char Code
O 1
ID
2/3
✱
3
559
Agency
Qual Code
X 1
ID
2
✱
4
751
Product
Desc Code
X 1
AN
1/12
✱
5
352
Description
X 1
AN
1/80
✱
6
752
Layer/Posit
Code
O 1
ID
2
✱
7
822
Source
Subqual
O 1
AN
1/15
✱
8
1073
Yes/No Cond
Resp Code
O 1
ID
1
✱
9
819
Language
Code
O 1
ID
2/3
✱
10
286
Prod/Serv
Cond Code
X 1
ID
2
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
349
Item Description Type Code
M 1
ID
1
Code indicating the format of a description
COMMENT: If PID01 equals "F", then PID05 is used. If PID01 equals "S", then PID04 is used. If PID01 equals "X", then both PID04 and PID05 are used.
INDUSTRY NAME: Item Description Type
CODE
DEFINITION
F
Free-form
Not Used
2
750
Product/Process Characteristic Code
O 1
ID
2/3
Not Used
3
559
Agency Qualifier Code
X 1
ID
2
Not Used
4
751
Product Description Code
X 1
AN
1/12
Required
5
352
Description
X 1
AN
1/80
A free-form description to clarify the related data elements and their content
SEGMENT SYNTAX: R040510, C0905
INDUSTRY NAME: Grace Period Type
Report the type of grace period using one of the following phrases:
FEDERAL MANDATE
STATE MANDATE
Not Used
6
752
Surface/Layer/Position Code
O 1
ID
2
Not Used
7
822
Source Subqualifier
O 1
AN
1/15
Not Used
8
1073
Yes/No Condition or Response Code
O 1
ID
1
Not Used
9
819
Language Code
O 1
ID
2/3
Not Used
10
286
Product/Service Condition Code
X 1
ID
2

LS - QUALIFIED HEALTH PLAN LOOP START

X12 Name:
Loop Header
X12 Purpose:
To indicate that the next segment begins a loop
X12 Comments:
See Figures Appendix for an explanation of the use of the LS and LE segments.
Loop:
Loop 2110C - ELIGIBILITY OR BENEFIT INFORMATION
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the grace period is an HIX Premium Payment Grace Period. If not required by this implementation guide, do not send.
TR3 Notes:
Use this segment to identify the beginning of the Qualified Health Plan Name Loop. Because both the Enrollee name loop and this loop begin with NM1 segments, the LS and LE segments are used to differentiate these 2 loops.
TR3 Example:
LS✱2120~
LS
✱
1
447
Loop ID
Code
M 1
AN
1/6
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
447
Loop Identifier Code
M 1
AN
1/6
The loop ID number given on the transaction set diagram is the value for this data element in segments LS and LE
This data element must have the value of "2120".

NM1*PR - QUALIFIED HEALTH PLAN 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 2120C - QUALIFIED HEALTH PLAN NAME
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required when the grace period is an HIX Premium Payment Grace Period. If not required by this implementation guide, do not send.
TR3 Notes:
When present, the health plan identified in loop 2100A is the Issuer related to the Health Insurance Exchange. See section 1.4 for additional information.
TR3 Example:
NM1✱PR✱2✱ACE DIRECT~
NM1
✱
1
98
Entity ID
Code
M 1
ID
2/3
✱
2
1065
Entity Type
Qualifier
M 1
ID
1
✱
3
1035
Name Last/
Org Name
X 1
AN
1/80
✱
4
1036
Name
First
O 1
AN
1/35
✱
5
1037
Name
Middle
O 1
AN
1/25
✱
6
1038
Name
Prefix
O 1
AN
1/10
✱
7
1039
Name
Suffix
O 1
AN
1/10
✱
8
66
ID Code
Qualifier
X 1
ID
1/2
✱
9
67
ID
Code
X 1
AN
2/80
✱
10
706
Entity
Relat Code
X 1
ID
2
✱
11
98
Entity ID
Code
O 1
ID
2/3
✱
12
1035
Name Last/
Org Name
O 1
AN
1/80
~
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
PR
Payer
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code identifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
2
Non-Person Entity
Required
3
1035
Name Last or Organization Name
X 1
AN
1/80
Individual last name or organizational name
SEGMENT SYNTAX: C1203
INDUSTRY NAME: Qualified Health Plan 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
Not Used
8
66
Identification Code Qualifier
X 1
ID
1/2
Not Used
9
67
Identification Code
X 1
AN
2/80
Not Used
10
706
Entity Relationship Code
X 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/80

LE - LOOP TRAILER

X12 Name:
Loop Trailer
X12 Purpose:
To indicate that the loop immediately preceding this segment is complete
X12 Comments:
See Figures Appendix for an explanation of the use of the LE and LS segments.
Loop:
Loop 2110C - ELIGIBILITY OR BENEFIT INFORMATION
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the 2110C LS segment is present, if not required by this implementation guide, do not send.
TR3 Example:
LE✱2120~
LE
✱
1
447
Loop ID
Code
M 1
AN
1/6
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
447
Loop Identifier Code
M 1
AN
1/6
The loop ID number given on the transaction set diagram is the value for this data element in segments LS and LE
This data element must have the value of "2120".

HL - DEPENDENT 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 2000D - DEPENDENT LEVEL
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required when the enrollee enrolled in coverage for more than just themselves and the health plan has determined that the provider is also impacted by a dependent without a unique health plan assigned identifier. If not required by this implementation guide, do not send.
TR3 Notes:
See section 1.10.1 for information about reporting a dependent as an enrollee.
TR3 Example:
HL✱4✱3✱23✱0~
HL
✱
1
628
Hierarch
ID Number
M 1
AN
1/12
✱
2
734
Hierarch
Parent ID
O 1
AN
1/12
✱
3
735
Hierarch
Level Code
M 1
ID
1/2
✱
4
736
Hierarch
Child Code
O 1
ID
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.
Use the sequentially assigned positive number to identify each specific occurrence of an HL segment within a transaction set. The first HL segment in the transaction must begin with the number 1 and be incremented by 1 for each successive occurrence of the HL segment within that specific transaction set (ST through SE).
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.
Use this ID number to identify the specific Enrollee to which this Dependent is subordinate.
Required
3
735
Hierarchical Level Code
M 1
ID
1/2
Code specifying 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.
All data that follows this HL segment is associated with the Dependent identified by the level code. This association continues until the next occurrence of an HL segment.
CODE
DEFINITION
23
Dependent
Use the Dependent Level to identify an individual(s) who may be a dependent of the enrollee. This individual may or may not be the actual patient.
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.

NM1*03 - DEPENDENT 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 2100D - DEPENDENT NAME
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
NM1✱03✱1✱DOE✱SALLY✱J~
NM1
✱
1
98
Entity ID
Code
M 1
ID
2/3
✱
2
1065
Entity Type
Qualifier
M 1
ID
1
✱
3
1035
Name Last/
Org Name
X 1
AN
1/80
✱
4
1036
Name
First
O 1
AN
1/35
✱
5
1037
Name
Middle
O 1
AN
1/25
✱
6
1038
Name
Prefix
O 1
AN
1/10
✱
7
1039
Name
Suffix
O 1
AN
1/10
✱
8
66
ID Code
Qualifier
X 1
ID
1/2
✱
9
67
ID
Code
X 1
AN
2/80
✱
10
706
Entity
Relat Code
X 1
ID
2
✱
11
98
Entity ID
Code
O 1
ID
2/3
✱
12
1035
Name Last/
Org Name
O 1
AN
1/80
~
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
03
Dependent
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code identifying the type of entity
SEMANTIC: NM102 qualifies NM103.
CODE
DEFINITION
1
Person
Required
3
1035
Name Last or Organization Name
X 1
AN
1/80
Individual last name or organizational name
SEGMENT SYNTAX: C1203
INDUSTRY NAME: Dependent Last Name
Situational
4
1036
Name First
O 1
AN
1/35
Individual first name
SITUATIONAL RULE: Required when the person has a first name. If not required by this implementation guide, do not send.
INDUSTRY NAME: Dependent First Name
Situational
5
1037
Name Middle
O 1
AN
1/25
Individual middle name or initial
SITUATIONAL RULE: Required when the Middle Name or Initial is known to the sender. If not required by this implementation guide, do not send.
INDUSTRY NAME: Dependent 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 the Suffix is known to the sender. If not required by this implementation guide, do not send.
INDUSTRY NAME: Dependent Name Suffix
Not Used
8
66
Identification Code Qualifier
X 1
ID
1/2
Not Used
9
67
Identification Code
X 1
AN
2/80
Not Used
10
706
Entity Relationship Code
X 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/80

N3 - DEPENDENT ADDRESS

X12 Name:
Party Location
X12 Purpose:
To specify the location of the named party
Loop:
Loop 2100D - DEPENDENT NAME
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the dependent address is different than the address sent in the 2100C loop, is available for the dependent and usage is not prohibited or restricted. If not required by this implementation guide, do not send.
TR3 Example:
N3✱123 MAIN STREET~
N3
✱
1
166
Address
Information
M 1
AN
1/55
✱
2
166
Address
Information
O 1
AN
1/55
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
166
Address Information
M 1
AN
1/55
Address information
INDUSTRY NAME: Dependent Address Line
Situational
2
166
Address Information
O 1
AN
1/55
Address information
SITUATIONAL RULE: Required when a second address line is needed. If not required by this implementation guide, do not send.
INDUSTRY NAME: Dependent Address Line

N4 - DEPENDENT CITY, STATE, ZIP CODE

X12 Name:
Geographic Location
X12 Purpose:
To specify the geographic place of the named party
X12 Syntax:
  1. E0207
    Only one of N402 or N407 may be present.
  2. E0308
    Only one of N403 or N408 may be present.
  3. C0605
    If N406 is present, then N405 is required.
  4. C0704
    If N407 is present, then N404 is required.
Loop:
Loop 2100D - DEPENDENT NAME
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the N3 segment is sent. If not required by this implementation guide, do not send.
TR3 Example:
N4✱KANSAS CITY✱MO✱641081234~
N4
✱
1
19
City
Name
O 1
AN
2/30
✱
2
156
State or
Prov Code
X 1
ID
2
✱
3
116
Postal
Code
X 1
ID
3/15
✱
4
26
Country
Code
X 1
ID
2/3
✱
5
309
Location
Qualifier
X 1
ID
1/2
✱
6
310
Location
Identifier
O 1
AN
1/30
✱
7
1715
Country Sub
Code
X 1
ID
1/3
✱
8
1702
Postal Code
Formatted
X 1
AN
3/20
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
19
City Name
O 1
AN
2/30
Free-form text for city name
COMMENT: A combination of either N401 through N404, or N405 and N406 may be adequate to specify a location.
INDUSTRY NAME: Dependent City Name
Situational
2
156
State or Province Code
X 1
ID
2
Code specifying the Standard State/Province as defined by appropriate government agency
SEGMENT SYNTAX: E0207
SITUATIONAL RULE: Required when the address is in the United States of America, including its territories, or Canada. If not required by this implementation guide, do not send.
INDUSTRY NAME: Dependent State Code
CODE SOURCE 22: States and Provinces
Situational
3
116
Postal Code
X 1
ID
3/15
Code specifying international postal zone code excluding punctuation and blanks (zip code for United States)
COMMENT: N403 contains the postal code in an unstructured format. N408 contains the postal code in a structured format. When a postal code data field is used, the parties shall agree as to which data element (N403 or N408) shall be used in the transaction set.
SEGMENT SYNTAX: E0308
SITUATIONAL RULE: Required when the address is in the United States of America, including its territories, or Canada, or when a postal code exists for the country in N404. If not required by this implementation guide, do not send.
INDUSTRY NAME: Dependent Postal Zone or ZIP Code
  • CODE SOURCE 51: ZIP Code
  • CODE SOURCE 932: Universal Postal Codes
Situational
4
26
Country Code
X 1
ID
2/3
Code identifying the country
SEGMENT SYNTAX: C0704
SITUATIONAL RULE: Required when the address is outside the United States of America. If not required by this implementation guide, do not send.
INDUSTRY NAME: Dependent Country Code
CODE SOURCE 5: Countries, Currencies and Funds
Not Used
5
309
Location Qualifier
X 1
ID
1/2
Not Used
6
310
Location Identifier
O 1
AN
1/30
Not Used
7
1715
Country Subdivision Code
X 1
ID
1/3
Not Used
8
1702
Postal Code-Formatted
X 1
AN
3/20

DMG*D8 - DEPENDENT DATE OF BIRTH

X12 Name:
Demographic Information
X12 Purpose:
To supply demographic information
X12 Syntax:
  1. P0102
    If either DMG01 or DMG02 is present, then the other is required.
  2. P1011
    If either DMG10 or DMG11 is present, then the other is required.
  3. C1105
    If DMG11 is present, then DMG05 is required.
Loop:
Loop 2100D - DEPENDENT NAME
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
Use this segment to send the dependent's date of birth.
TR3 Example:
DMG✱D8✱19850704~
DMG
✱
1
1250
Date Time
Format Qual
X 1
ID
2/3
✱
2
1251
Date Time
Period
X 1
AN
1/35
✱
3
1068
Gender
Code
O 1
ID
1
✱
4
1067
Marital
Status Code
O 1
ID
1
✱
5
C056
Comp Race
or Ethn Inf
X 25
✱
6
1066
Citizenship
Status Code
O 1
ID
1/2
✱
7
26
Country
Code
O 1
ID
2/3
✱
8
659
Basis of
Verif Code
O 1
ID
1/2
✱
9
380
Quantity
O 1
R
1/15
✱
10
1270
Code List
Qual Code
X 1
ID
1/3
✱
11
1271
Industry
Code
X 1
AN
1/30
✱
12
26
Country
Code
O 1
ID
2/3
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Code indicating the date format, time format, or date and time format
SEGMENT SYNTAX: P0102
CODE
DEFINITION
D8
Date Expressed in Format CCYYMMDD
Required
2
1251
Date Time Period
X 1
AN
1/35
Expression of a date, a time, or range of dates, times or dates and times
SEMANTIC: DMG02 is the date of birth.
SEGMENT SYNTAX: P0102
INDUSTRY NAME: Dependent Birth Date
Not Used
3
1068
Gender Code
O 1
ID
1
Not Used
4
1067
Marital Status Code
O 1
ID
1
Not Used
5
C056
Composite Race or Ethnicity Information
X 25
Not Used
6
1066
Citizenship Status Code
O 1
ID
1/2
Not Used
7
26
Country Code
O 1
ID
2/3
Not Used
8
659
Basis of Verification Code
O 1
ID
1/2
Not Used
9
380
Quantity
O 1
R
1/15
Not Used
10
1270
Code List Qualifier Code
X 1
ID
1/3
Not Used
11
1271
Industry Code
X 1
AN
1/30
Not Used
12
26
Country Code
O 1
ID
2/3

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 Notes:
Use this segment to mark the end of a transaction set and provide control information on the total number of segments included in the transaction set.
TR3 Example:
SE✱123✱1234~
SE
✱
1
96
Number of
Inc Segs
M 1
N
1/10
✱
2
329
TS Control
Number
M 1
AN
4/9
~
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
The Transaction Set Control Number in ST02 and SE02 must be identical.

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~
GE
✱
1
97
Number of
TS Included
M 1
N
1/6
✱
2
28
Group Ctrl
Number
M 1
N
1/9
~
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~
IEA
✱
1
I16
Num of Incl
Funct Group
M 1
N
1/5
✱
2
I12
Inter Ctrl
Number
M 1
N
9
~
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
The Value in IEA02 must be identical to the value in ISA13.
logo

271 Premium Payment Grace Period Notification (008020X344)

JANUARY 2022

Copyright © 2008-22, X12 Incorporated, Format © 2008-22 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 Premium Payment Grace Period Notification Implementation Guide describes the use of the X12 Eligibility, Coverage or Benefit Information (271) transaction set for reporting Health Insurance Exchange (HIX) Premium Payment Grace Period, other (non-HIX) premium payment grace periods, and related information from health plans to providers.

Entities sending the transaction:

  • Health Plans which include insurance companies, third party administrators, and their business associates

Entities receiving the transaction:

  • Providers which include but are not limited to: hospitals, nursing homes, laboratories, physicians, dentists, allied professional groups, and their business associates

Preface

X12 standards are developed to identify the broadest data requirements for a transaction set. Type 3 Technical Reports (TR3), also known as implementation guides, define the explicit data requirements for a specific business purpose. Trading partners who implement according to the instructions in this TR3 can exchange data consistently with multiple trading partners.

As X12 does not define transport requirements, trading partners define their specific transport requirements separately.

1.1 Implementation Purpose and Scope

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

The purpose of this implementation guide is to provide standardized data requirements and content for the users of the Eligibility, Coverage or Benefit Information (271) for reporting Health Insurance Exchange (HIX) Premium Payment Grace Period, other (non-HIX) premium payment grace periods, and related information from health plans to providers. The Affordable Care Act and related Federal and state regulations created HIXs and require the provision of a premium payment grace period (grace period) to enrollees that have received advance payments of the premium tax credit and have previously paid at least one full month's premium during the benefit year. Notification of persons in the second and third month of the grace period to impacted providers is required. Details of the Federal regulations and requirements are specified in 45 CFR 156.270(d)(2), Notifications to HHS, and 45 CFR 156.270(d)(3), Notifications to Providers, and in accordance with the provisions of Chapter 5, Section 7.ii, Notice of Pending Claims' to Providers, of the CMS Letter to Issuers for 2014 located at
http://www.cms.gov/CCIIO/Resources/Regulations-and-Guidance/Downloads/2014_letter_to_issuers_04052013.pdf.

This implementation guide is designed to assist those who wish to send and/or receive electronic grace period information using a standardized transaction.

Entities sending the transaction are health plans, insurance companies, third party administrators, and their business associates. All of these entities are referred to as health plans within this document.

Entities receiving the transaction include, but are not limited to, hospitals, nursing homes, laboratories, physicians, dentists, allied health professional groups, and their business associates. All of these entities are referred to as providers within this document.

1.2 Version Information

This implementation guide is based on the October 2020 X12 standards, referred to as Version 8, Release 2 (008020).

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

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

  • HB   Eligibility, Coverage or Benefit Information (271)

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 transmission reconnects at a later time and picks up the response transaction. Note: The sender of the original transmission may not always be the entity that picks up the response transaction at a later time (e.g. Provider submitting through a clearinghouse.)

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 was based on requirements for batch mode. Willing trading partners may use batch or real-time mode.

1.3.2 Other Usage Limitations

There are no other usage limitations.

1.4 Business Usage

This transaction is intended to meet the particular needs of the health care industry for the reporting of premium payment grace period information from a health plan to a provider. While usage may differ in frequency, this transaction is designed to operate in three ways:

  • Created by health plans on a periodic (for example - monthly) basis and sent to or made available to providers, as an unsolicited mode. The transaction only contains information about patients in a grace period when the health plan has determined that the provider is impacted by the patient's grace period. The transaction supports identification that there are no enrollees within a grace period by identification of the health plan and provider, without inclusion of any patients.
  • Created by health plans on demand based upon health plan receipt of eligibility and benefit request(s) or claim(s) related to a patient currently in a grace period.
  • Created as a notification that a patient previously identified as within a grace period in a notification, or through another mechanism (for example, eligibility and benefit information, claim status, or remittance advice) has paid their premium and is no longer in the grace period.

Within the Health Insurance Exchange (HIX) regulations, the term "issuer" is used to identify the insurance company that is issuing the Qualified Health Plan. External to HIXs, the term "health plan" is generally used to identify the health plan, or insurance company. Anytime usage or requirements apply only to the more regulated HIX environment, the term "issuer" will be used.

This guide does not provide any guidance or requirement on how a health plan identifies that a provider is impacted by a specific patient's status being in a premium payment grace period or establish any requirement that a health plan provide any of the notifications included within the guide.

Notification Statements
At the time of publication for this guide there are federal requirements for issuers regarding HIX grace period notification. These include five different categories of statements:

  • statement of the purpose of the notification
  • explanation of the grace period
  • statement of consequences of grace period exhaustion for the patient
  • statement of consequence of grace period exhaustion for the provider
  • statement of provider options

These statements are not carried in this transaction since this information is relatively static and is not patient or provider specific. The information required is carried by reference to a location on the health plan's website that contains the detailed statements and explanation. The PER segment in the 2100A loop or 2100C, Health Plan Grace Period URL, identifies the URL where the information can be viewed when located on the health plan's website.

Uses
The transaction can be used in four ways:

  1. A periodic transaction (e.g. established by regulation or contract) can indicate that there are no patients within the grace period known to impact a provider. This is accomplished by sending Health Plan and Provider information without any patient information. This is an original notification, and can be identified by BHT02 = "14" (Advance Notification), and the absence of the Enrollee and Dependent hierarchical levels.
  2. A periodic transaction can indicate that there are patients within the grace period impacting the provider. This is accomplished by sending Health Plan, Provider and Enrollee information, and dependent information if appropriate for any specific enrollee. This is an original notification, and can be identified by BHT02 = "14" (Advance Notification), and the presence of the Enrollee hierarchical level.
  3. The transaction can indicate the removal of one or more patients (and any related dependents) from a grace period due to payment of the related premium. This optional use would occur after a prior notification of patients in the grace period either through a notification transaction, eligibility and benefit response, claim status or remittance advice. Removal is accomplished by sending Health Plan, Provider and Enrollee Information, and Dependent information if appropriate for a specific enrollee. This is a change notification, and can be identified by BHT02 = "SU" (Status Update).
  4. A transaction can indicate that a patient that was the subject of a health care eligibility and benefit check or claim is currently in a grace period. This is an original notification, and can be identified by BHT02 = "06" (Confirmation).

1.4.1 Health Care Transaction Flow

Each X12 implementation guide explains how to use X12 transaction sets to meet a single defined business purpose. The diagrams found at https://www.x12.org/flow depict the business functions supported by the X12 health care implementation guides.

1.5 Business Terminology

To ensure consistent use of terms, definitions, and acronyms across X12 products, X12 maintains the Wordbook, a comprehensive corporate glossary. The included terms are either proprietary to X12, cite definitions published by another authority, or represent common terms and definitions that are relevant to X12's work. The terms and definitions defined in the Wordbook are used in X12 work products when applicable, without modification or revision. The Wordbook can be referenced online at wordbook.x12.org.

1.6 Transaction Acknowledgments

The purpose of transaction acknowledgments is to report to the sender whether the transaction being acknowledged was accepted or rejected.

The X12 Technical Report Type 2, Acknowledgment Reference Model provides guidance on several control structures and transaction set standards intended to augment EDI auditing and control systems.

1.7 Related Transactions

There are eight transactions related to the transaction described in this implementation guide.

Three transactions that are related also can convey information about a patient being in a premium payment grace period. They are:

  • Health Care Claim Payment/Advice (835)
  • Health Care Claim Status Response (277)
  • Health Care Eligibility Benefit Response (271)

Five transactions that are related initiate an action that can result in one of the above three transactions.

  • Health Care Claim – Dental (837)
  • Health Care Claim – Institutional (837)
  • Health Care Claim – Professional (837)
  • Health Care Claim Status Request (276)
  • Health Care Eligibility and Benefit Inquiry (270)

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 Transaction Compliance

There are three types of compliance that may be relevant to a transmitted transaction.

Compliance with implementation guide requirements

Compliance with state and federal regulation

Compliance with trading partner contractual agreements

1.9.1 Transaction Compliance with Implementation Guide Requirements

A transaction complies with X12 implementation guide requirements if the transaction satisfies all format and content rules and constraints specified in the applicable X12 standards and the implementation guide (also known as a TR3) itself.

Should additional clarification of an X12 implementation guide requirement be desired, two options are available.

X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that are not TR3-compliant based on its own business process.

A receiver may specify its business rules in a trading partner agreement or companion document. As stated in §1.8, these documents do not override TR3 requirements, nor change how transaction compliance with this TR3 is determined.

1.9.2 Transaction Compliance with State and Federal Regulations

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 state or federal standard. Should this implementation guide be adopted as a standard, the adopting authority will establish compliance dates for its use by impacted entities.

X12 is not the authority for determining compliance with regulatory requirements that might further constrain implementation guide requirements. Questions of compliance for regulatory requirements should be directed to the governing authority.

X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that do not comply with applicable regulatory requirements as specified by the applicable regulation(s) or governing authority.

1.9.3 Transaction Compliance with Contractual Requirements

X12 is not the authority for determining compliance with contractual requirements that might further constrain implementation guide requirements. Questions of compliance for contractual requirements should be directed to the contracting entity.

X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that do not comply with contractual requirements as specified by the applicable contract or contracting entity.

1.10 Data Overview

This transaction is divided into five major areas – one header, and four detail hierarchical levels.

Header
The header area identifies the transaction type and implementation, as well as the transaction date and the business purpose of the specific transaction.

  • ST03
    identifies the Technical Report version and number that identify this as a Premium Payment Grace Period Notification (007030X344)
  • BHT01
    identifies the hierarchical structure of the transaction using code "0012" (Information Source, Information Receiver, Subscriber, Dependent)
  • BHT02
    identifies the specific function of the transaction. Code "14" (Advance Notification) indicates that this is an unsolicited original periodic notification containing a listing of members whose enrollment is in the grace period. Code "SU" (Status Update) indicates that this is an update of a prior original transaction, and contains a listing of members whose premium has been brought current since the last original or update transaction. Code "06" (Confirmation) indicates that this is a solicited notification after an eligibility and benefit check or claim submission by the provider.

Detail Level 1 – Health Plan Level - Information Source (2000A)
This level is required and identifies the health plan as the Information Source. The 2100A loop provides information including:

  • Health Plan Name
  • Health Plan Identifier (HPID or proprietary identifier)
  • Health Plan Address
  • Health Plan Premium Payment Grace Period Information URL
  • Health Plan's Provider customer service telephone number
  • Report Date – the date that the information was reported out of the Health Plan's business system

Detail Level 2 – Provider Level - Information Receiver (2000B)
This level is required and identifies the specific provider that is receiving the grace period notification as an impacted provider. This is usually the institution or group practice, and is only a specific individual when the provider is not incorporated or working for another organization. Information conveyed includes:

  • Impacted provider name
  • Impacted provider ID (NPI, proprietary ID, or Tax ID, whichever is applicable or mandated)
  • Impacted provider address
  • Impacted provider city, state and ZIP Code

Detail Level 3 – Enrollee (2000C)
The enrollee level is situational and identifies the individual enrollee(s) whose premium payment status is being conveyed. This level is not used when the transaction is a periodic report identifying that there are no active premium payment grace periods that impact the provider identified in the related Information Receiver level.

When this level is present in a periodic transaction (BHT02="14"), these are enrollees that are currently in the premium payment grace period that may impact the provider identified in the related Information Receiver loop.

When the transaction is a status update (BHT02="SU"), this level identifies enrollees that had previously been reported as in the grace period who have subsequently made payments that removed them from the grace period.

Information conveyed in this level includes:

  • Enrollee name
  • Enrollee identifier with the health plan
  • Enrollee date of birth
  • Enrollee address
  • Enrollee city, state and ZIP Code
  • Enrollee Country Code
  • Enrollee phone number
  • Related Qualified Health Plan (QHP)
    • Qualified Health Plan Name
    • Qualified Health Plan ID
  • Grace Period Type
  • Premium Paid Through Date
  • Trace number identifying this notification

When the transaction is a notification (BHT02="14" or "06") the following additional information is included:

  • First Day of the related premium payment grace period
  • Last Day of the related premium payment grace period
  • Identifier of the applicable current premium payment grace period month or time period (as dictated by regulation)

When the transaction is a status update (BHT02="SU"), indicating the payment of premium by the enrollee, the following information is also present:

  • Premium Paid Indicator

Detail Level 4 – Dependent (2000D)
The dependent level is situational and identifies dependents of enrollees that are related to a enrollee's coverage. They are impacted by the enrollee's failure to make the premium payment, or subsequent payment to resolve the grace period. This level is only populated when the applicable enrollee has enrolled in coverage for more than a single person. Information conveyed in this level includes:

  • Dependent name
  • Dependent Identifier (if assigned)
  • Dependent address (when different than the related enrollee information)
  • Dependent city, state, ZIP Code (when different than the related enrollee information)
  • Dependent Country Code (when different than the related enrollee information)
  • Dependent date of birth

1.10.1 Dependent as Enrollee

When a dependent of an enrollee has been assigned a unique identification number by the health plan, that dependent is considered to be an enrollee for the purposes of reporting in this transaction. Only use the dependent level (Loop 2000D) for dependents that have not been assigned unique identification numbers by the health plan identified in Loop 2000A.

2. Transaction Set

NOTE
See X12 documents X12.5, X12.6, and X12.59 to review transaction set structure, including descriptions of segments, levels, and loops.

2.1 Presentation Examples

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

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.

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.

"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, requested or rejected by the receiver when the condition is not applicable. Transmission of this data is solely at the sender's discretion when the stated condition does not apply.

"Required when <explicit condition statement>. If not required by this implementation guide, do not send."

The data qualified by such a situational rule must not be sent except as described in the explicit condition statement.

2.2.1.1 Determining Transaction Compliance with Industry Usage Requirements

A transmitted transaction complies with the governing implementation guide when it satisfies the requirements as defined within the implementation guide. Specifically, 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.

Industry Usage

Business
Condition
is

Item
is

Transaction
Complies with
Implementation
Guide?

Required

N/A

Sent

Yes

Not Sent

No

Not Used

N/A

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

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

True

Sent

Yes

Not Sent

No

Not True

Sent

No

Not Sent

Yes

2.2.2 Loops

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

  • A nested loop can be used only when the associated higher level loop is used.
  • The usage of a loop is the same as the usage of its beginning segment.
    • If a loop's beginning segment is Required, the loop is Required and must occur at least once unless it is nested in a loop that is not being used.
    • If a loop's beginning segment is Situational, the loop is Situational.
  • Subsequent segments within a loop can be sent only when the beginning segment is used.
  • Required segments in Situational loops occur only when the loop is used.

3. Examples

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

 

Appendix A. External Code Sources

Prior to this publication, X12 TR3s contained a subset of the overall Code Source Directory, formerly known as Appendix A of X12.3. External code lists are not part of the X12 standard and are provided for information purposes only. The full listing is available in Glass, X12's On-Line viewer.

Read more about Glass here: https://glasshelp.x12.org/.

Where an external code source is referenced in this publication, the implementer is required to use only the codes from that list. Codes must be reported as listed in the code source (e.g. with leading zeroes). Implementers must follow the instructions for code use that are supplied by the code set owner.

 

B.1.1 Referenced and Related Standards

This technical report is based on the X12 EDI standard which comprises a series of interdependent publications. Implementers are advised to consult these publications when using this technical report.

The following standards are required to interpret, understand, and use this technical report:

  • X12.5 - Interchange Control Structure
  • X12.6 - Application Control Structure

The following guideline is useful to interpret, understand, and use this technical report:

  • Compliance in X12

The following reference model is useful to interpret, understand, and use this technical report:

  • Acknowledgment Reference Model

All of the documents above are available online using links to X12's Online Viewer.

 

B.1.1.1 Transmission Control Schematic

Refer to X12.5 - Interchange Control Structures, Section 3.5 - Order of Control Segments, and Chapter 5 Interchange Segment Specifications.

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

 

B.1.1.2 Constraints applicable to the suite of TR3s

Refer to X12.6 - Application Control Structure, Section 3.2.8 - Minimums/Maximums.

Data element minimum and maximum lengths are set by the X12 standard. This implementation guide may further restrict minimum and maximum lengths within the bounds set by the standard. Such restrictions may occur implicitly by virtue of the allowed qualifier for the data element, or they may be stated explicitly in a note attached to the element or in the general limitations below.

 

B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification

The current X12 standard allows a maximum length greater than 50 characters for data element 127. For implementations governed by this implementation guide, unless another value is specified in an attached note, the maximum length of each occurrence of this data element is constrained to 50 characters.

 

B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount

For implementations governed by this implementation guide, unless another value is specified for an instance of Data Element 782 within Section 2 (Transaction Set), each occurrence of 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 that the decimal point and leading sign, if sent, are not part of the character count.

EXAMPLE

  • 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 Decimal

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

Appendix D. Change Summary

This Implementation Guide (008020X344) defines the X12 requirements for the Premium Payment Grace Period Notification. It is based on version/release/subrelease 008020 of the X12 standards.