838 Transaction Set Listing

008020X305 Provider Enrollment for EDI Services
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*TD - 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✱008020X305~
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
TD
Trading Partner Profile (838)
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
008020X305
Provider Enrollment for EDI Services

ST*838 - TRANSACTION SET HEADER

X12 Name:
Transaction Set Header
X12 Purpose:
To indicate the start of a transaction set and to assign a control number
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
ST✱838✱0001✱008020X305~
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).
CODE
DEFINITION
838
Trading Partner Profile
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.
INDUSTRY NAME: Implementation Guide Version Name
  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 used at translation time.
CODE
DEFINITION
008020X305
Provider Enrollment for EDI Services

BTP*13 - BEGINNING SEGMENT FOR TRADING PARTNER PROFILE

X12 Name:
Beginning Segment For Trading Partner Profile
X12 Purpose:
To indicate the type and purpose of the profile data
X12 Syntax:
  1. C0807
    If BTP08 is present, then BTP07 is required.
  2. C0908
    If BTP09 is present, then BTP08 is required.
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
BTP✱13✱1234567✱20210101✱1800✱RQ~
BTP
✱
1
353
TS Purpose
Code
M 1
ID
2
✱
2
127
Reference
Ident
M 1
AN
1/80
✱
3
373
Date
M 1
DT
8
✱
4
337
Time
M 1
TM
4/8
✱
5
640
Transaction
Type Code
M 1
ID
2
✱
6
353
TS Purpose
Code
O 1
ID
2
✱
7
127
Reference
Ident
X 1
AN
1/80
✱
8
373
Date
X 1
DT
8
✱
9
337
Time
O 1
TM
4/8
✱
10
591
Payment
Method Code
O 1
ID
3
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
353
Transaction Set Purpose Code
M 1
ID
2
Code identifying purpose of transaction set
SEMANTIC: BTP01 indicates the purpose of this EDI transmission.
INDUSTRY NAME: Transaction Type
CODE
DEFINITION
13
Request
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: BTP02 is the identifying number of this transaction.
INDUSTRY NAME: Trace Number
  1. Use BTP02 for the unique value identifying this request
  2. Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Required
3
373
Date
M 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEMANTIC: BTP03 and BTP04 are the transaction set date and time.
INDUSTRY NAME: Transaction Set Creation Date
Use BTP03 for the creation date of the transaction.
Required
4
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)
INDUSTRY NAME: Transaction Set Creation Time
This is the creation time of the transaction.
Required
5
640
Transaction Type Code
M 1
ID
2
Code specifying the type of transaction
CODE
DEFINITION
RQ
Request
Not Used
6
353
Transaction Set Purpose Code
O 1
ID
2
Not Used
7
127
Reference Identification
X 1
AN
1/80
Not Used
8
373
Date
X 1
DT
8
Not Used
9
337
Time
O 1
TM
4/8
Not Used
10
591
Payment Method Code
O 1
ID
3

LX - ENROLLMENT INFORMATION

X12 Name:
Transaction Set Line Number
X12 Purpose:
To reference a line number in a transaction set
Loop:
Loop 1000 - ENROLLMENT INFORMATION
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
LX✱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
LX01 must contain the value "1".

N1*41 - SUBMITTER NAME

X12 Name:
Party Identification
X12 Purpose:
To identify a party by type of organization, name, and code
X12 Syntax:
  1. R0203
    At least one of N102 or N103 is required.
  2. P0304
    If either N103 or N104 is present, then the other is required.
  3. C0703
    If N107 is present, then N103 is required.
Loop:
Loop 1100A - SUBMITTER NAME
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
N1✱41✱HC Clearinghouse✱46✱654321✱✱AY~
N1
✱
1
98
Entity ID
Code
M 1
ID
2/3
✱
2
93
Name
X 1
AN
1/60
✱
3
66
ID Code
Qualifier
X 1
ID
1/2
✱
4
67
ID
Code
X 1
AN
2/80
✱
5
706
Entity
Relat Code
O 1
ID
2
✱
6
98
Entity ID
Code
O 1
ID
2/3
✱
7
C076
Composite
ID Codes
O 1
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
98
Entity Identifier Code
M 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
CODE
DEFINITION
41
Submitter
Required
2
93
Name
X 1
AN
1/60
Free-form name
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Submitter Name
This is the last name of the submitter when N101 is 41 - Submitter and the submitter is an individual. This is the organization name for all other submitter types.
Required
3
66
Identification Code Qualifier
X 1
ID
1/2
Code specifying the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: R0203, P0304, C0703
CODE
DEFINITION
46
Electronic Transmitter Identification Number (ETIN)
Required
4
67
Identification Code
X 1
AN
2/80
Code identifying a party or other code
COMMENT: This segment, used alone, provides the most efficient method of providing organizational identification. To obtain this efficiency the "ID Code" (N104) must provide a key to the table maintained by the transaction processing party.
SEGMENT SYNTAX: P0304
This is the electronic submitter identification number for the submitter in the EDI relationship with the receiver of this transaction.
Not Used
5
706
Entity Relationship Code
O 1
ID
2
Required
6
98
Entity Identifier Code
O 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
INDUSTRY NAME: Missing
CODE
DEFINITION
1P
Provider
AY
Clearinghouse
BV
Billing Service
VN
Vendor
Not Used
7
C076
Composite Identification Codes
O 1

N2 - SUBMITTER FIRST NAME OR OTHER NAME

X12 Name:
Additional Name Information
X12 Purpose:
To specify additional names
Loop:
Loop 1100A - SUBMITTER NAME
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the submitter is a provider reported in the 1100A N1 Submitter Name segment with N101 = 41, the provider is an individual and has a first name or when the receiver knows the submitter by another name. If not required by this implementation guide, do not send.
TR3 Notes:
Use this N2 segment to provide the "doing business as" (dba) or trade name under which the entity may be known.
TR3 Example:
N2✱Health Care Clearinghouse~
N2
✱
1
93
Name
M 1
AN
1/60
✱
2
93
Name
O 1
AN
1/60
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
93
Name
M 1
AN
1/60
Free-form name
INDUSTRY NAME: Submitter Other Name
This is the first name of the submitter when N101 is 41 - Submitter and the submitter is an individual.
This is the organization name for all other submitter types.
Not Used
2
93
Name
O 1
AN
1/60

PER*SM - SUBMITTER 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 1100A - SUBMITTER NAME
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
2
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. The contact information in this segment identifies the person in the submitter organization who deals with data transmission issues. If data transmission problems arise, this is the person to contact in the submitter organization.
  3. There are 2 repetitions of the PER segment to allow for six possible communication numbers including extensions.
TR3 Example:
PER✱SM✱✱TE✱8005551212~
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
SM
Submitting Contact
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: Submitter Contact Name
Required
3
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0304
CODE
DEFINITION
EM
Electronic Mail
FX
Facsimile
TE
Telephone
Required
4
364
Communication Number
X 1
AN
1/2048
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0304
Situational
5
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when this information is deemed necessary by the submitter. If not required by this implementation guide, do not send.
CODE
DEFINITION
EM
Electronic Mail
EX
Telephone Extension
Use when reporting a telephone extension for the preceding telephone number.
FX
Facsimile
TE
Telephone
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 this information is deemed necessary by the submitter. If not required by this implementation guide, do not send.
Situational
7
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0708
SITUATIONAL RULE: Required when this information is deemed necessary by the submitter. If not required by this implementation guide, do not send.
CODE
DEFINITION
EM
Electronic Mail
EX
Telephone Extension
Use when reporting a telephone extension for the preceding telephone number.
FX
Facsimile
TE
Telephone
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 this information is deemed necessary by the submitter. If not required by this implementation guide, do not send.
Not Used
9
443
Contact Inquiry Reference
O 1
AN
1/20

N1*40 - RECEIVER NAME

X12 Name:
Party Identification
X12 Purpose:
To identify a party by type of organization, name, and code
X12 Syntax:
  1. R0203
    At least one of N102 or N103 is required.
  2. P0304
    If either N103 or N104 is present, then the other is required.
  3. C0703
    If N107 is present, then N103 is required.
Loop:
Loop 1100B - RECEIVER NAME
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
N1✱40✱HC Clearinghouse✱46✱654321✱✱AY~
N1
✱
1
98
Entity ID
Code
M 1
ID
2/3
✱
2
93
Name
X 1
AN
1/60
✱
3
66
ID Code
Qualifier
X 1
ID
1/2
✱
4
67
ID
Code
X 1
AN
2/80
✱
5
706
Entity
Relat Code
O 1
ID
2
✱
6
98
Entity ID
Code
O 1
ID
2/3
✱
7
C076
Composite
ID Codes
O 1
~
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
Identify the receiver of the transaction being asked to enroll or disenroll a provider.
CODE
DEFINITION
40
Receiver
Required
2
93
Name
X 1
AN
1/60
Free-form name
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Receiver Name
This is the legal name of the receiver of the transaction.
Required
3
66
Identification Code Qualifier
X 1
ID
1/2
Code specifying the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: R0203, P0304, C0703
CODE
DEFINITION
46
Electronic Transmitter Identification Number (ETIN)
Required
4
67
Identification Code
X 1
AN
2/80
Code identifying a party or other code
COMMENT: This segment, used alone, provides the most efficient method of providing organizational identification. To obtain this efficiency the "ID Code" (N104) must provide a key to the table maintained by the transaction processing party.
SEGMENT SYNTAX: P0304
This is the electronic identification number for the receiver in the EDI relationship with the submitter of this transaction.
Not Used
5
706
Entity Relationship Code
O 1
ID
2
Required
6
98
Entity Identifier Code
O 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
INDUSTRY NAME: Missing
CODE
DEFINITION
AY
Clearinghouse
BV
Billing Service
PR
Payer
VN
Vendor
Not Used
7
C076
Composite Identification Codes
O 1

N2 - RECEIVER OTHER NAME

X12 Name:
Additional Name Information
X12 Purpose:
To specify additional names
Loop:
Loop 1100B - RECEIVER NAME
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the submitter knows the receiver by a name other than that sent in the Loop 1100B N1 - Receiver Name, N102 element and is known to impact enrollment processing. If not required by this implementation guide, do not send.
TR3 Notes:
Use this N2 segment to provide the "doing business as" (dba) or trade name under which the entity may be known.
TR3 Example:
N2✱Health Care Clearinghouse~
N2
✱
1
93
Name
M 1
AN
1/60
✱
2
93
Name
O 1
AN
1/60
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
93
Name
M 1
AN
1/60
Free-form name
INDUSTRY NAME: Receiver Other Name
Not Used
2
93
Name
O 1
AN
1/60

N1 - REQUESTING PROVIDER NAME

X12 Name:
Party Identification
X12 Purpose:
To identify a party by type of organization, name, and code
X12 Syntax:
  1. R0203
    At least one of N102 or N103 is required.
  2. P0304
    If either N103 or N104 is present, then the other is required.
  3. C0703
    If N107 is present, then N103 is required.
Loop:
Loop 1100C - REQUESTING PROVIDER NAME
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
Identify the facility, individual or group provider that is requesting the addition, change or cancellation of EDI services.
TR3 Example:
N1✱FA✱Center City Clinic✱XX✱12345678980~
N1
✱
1
98
Entity ID
Code
M 1
ID
2/3
✱
2
93
Name
X 1
AN
1/60
✱
3
66
ID Code
Qualifier
X 1
ID
1/2
✱
4
67
ID
Code
X 1
AN
2/80
✱
5
706
Entity
Relat Code
O 1
ID
2
✱
6
98
Entity ID
Code
O 1
ID
2/3
✱
7
C076
Composite
ID Codes
O 1
~
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
Use when identifying an individual.
FA
Facility
QV
Group Practice
Required
2
93
Name
X 1
AN
1/60
Free-form name
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Provider Name
This is the organization name when N101 is equal to FA or QV.
Situational
3
66
Identification Code Qualifier
X 1
ID
1/2
Code specifying the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: R0203, P0304, C0703
SITUATIONAL RULE: Required when the provider has a National Provider identifier (NPI). If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Identifier
CODE
DEFINITION
XX
Standard Unique Health Identifier for Health Care Providers (NPI)
SEE CODE SOURCE 537
CODE SOURCE: 537: National Provider Identifier (NPI)
Situational
4
67
Identification Code
X 1
AN
2/80
Code identifying a party or other code
COMMENT: This segment, used alone, provides the most efficient method of providing organizational identification. To obtain this efficiency the "ID Code" (N104) must provide a key to the table maintained by the transaction processing party.
SEGMENT SYNTAX: P0304
SITUATIONAL RULE: Required when the provider has a National Provider identifier (NPI). If not required by this implementation guide, do not send.
This is the provider's NPI.
Not Used
5
706
Entity Relationship Code
O 1
ID
2
Not Used
6
98
Entity Identifier Code
O 1
ID
2/3
Not Used
7
C076
Composite Identification Codes
O 1

N2 - REQUESTING PROVIDER OTHER NAME

X12 Name:
Additional Name Information
X12 Purpose:
To specify additional names
Loop:
Loop 1100C - REQUESTING PROVIDER NAME
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the receiver or any payer may know the provider by another name or when the provider is an individual (N101=1P) that has a first name. If not required by this implementation guide, do not send.
TR3 Example:
N2✱Center City Health Clinic~
N2
✱
1
93
Name
M 1
AN
1/60
✱
2
93
Name
O 1
AN
1/60
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
93
Name
M 1
AN
1/60
Free-form name
This is the first name of the provider when Loop 1100C N101 is 1P (Provider).
This is the organizational other business name for all other provider types.
Not Used
2
93
Name
O 1
AN
1/60

N3 - REQUESTING PROVIDER MAILING ADDRESS

X12 Name:
Party Location
X12 Purpose:
To specify the location of the named party
Loop:
Loop 1100C - REQUESTING PROVIDER NAME
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
This is the actual mailing address of the provider and may be a PO Box or a physical location.
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
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.

N4 - REQUESTING PROVIDER MAILING 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 1100C - REQUESTING PROVIDER NAME
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
This is the mailing city, state and ZIP Code of the provider.
TR3 Example:
N4✱Rivercity✱PA✱12345~
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: Requesting 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.
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.
  • 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.
Use the alpha-2 country codes from Part 1 of ISO 3166.
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
Situational
7
1715
Country Subdivision Code
X 1
ID
1/3
Code identifying the country subdivision
SEGMENT SYNTAX: E0207, C0704
SITUATIONAL RULE: Required when the address is not in the United States of America, including its territories, or Canada, and the country in N404 has administrative subdivisions such as but not limited to states, provinces, cantons, etc. If not required by this implementation guide, do not send.
Use the country subdivision codes from Part 2 of ISO 3166.
CODE SOURCE 5: Countries, Currencies and Funds
Not Used
8
1702
Postal Code-Formatted
X 1
AN
3/20

N9 - REQUESTING PROVIDER OTHER IDENTIFIER

X12 Name:
Extended Reference Information
X12 Purpose:
To transmit identifying information as specified by the Reference Identification Qualifier
X12 Syntax:
  1. R0203
    At least one of N902 or N903 is required.
  2. C0605
    If N906 is present, then N905 is required.
Loop:
Loop 1100C - REQUESTING PROVIDER NAME
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
2
Situational Rule:
Required when the request relates to electronic funds transfer or when an additional identifier is known to be necessary for the payer to process the requested transaction. If not required by this implementation guide, do not send.
TR3 Example:
N9✱TJ✱123456789~
N9
✱
1
128
Reference
Ident Qual
M 1
ID
2/3
✱
2
127
Reference
Ident
X 1
AN
1/80
✱
3
369
Free-Form
Description
X 1
AN
1/45
✱
4
373
Date
O 1
DT
8
✱
5
337
Time
X 1
TM
4/8
✱
6
623
Time
Code
O 1
ID
2
✱
7
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
TJ
Federal Taxpayer's Identification Number
Use when related to Payment transactions.
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 Other Identifier
Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
369
Free-form Description
X 1
AN
1/45
Not Used
4
373
Date
O 1
DT
8
Not Used
5
337
Time
X 1
TM
4/8
Not Used
6
623
Time Code
O 1
ID
2
Not Used
7
C040
Reference Identifier
O 1

N9*PXC - REQUESTING PROVIDER TAXONOMY INFORMATION

X12 Name:
Extended Reference Information
X12 Purpose:
To transmit identifying information as specified by the Reference Identification Qualifier
X12 Syntax:
  1. R0203
    At least one of N902 or N903 is required.
  2. C0605
    If N906 is present, then N905 is required.
Loop:
Loop 1100C - REQUESTING PROVIDER NAME
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
6
Situational Rule:
Required when the payer's enrollment is known to be impacted by the provider's taxonomy code. If not required by this implementation guide, do not send.
TR3 Notes:
Multiple N9 segments can be used to report multiple provider Taxonomy values when appropriate. The multiple segments must report different taxonomy codes in N902.
TR3 Example:
N9✱PXC✱193200000X~
N9
✱
1
128
Reference
Ident Qual
M 1
ID
2/3
✱
2
127
Reference
Ident
X 1
AN
1/80
✱
3
369
Free-Form
Description
X 1
AN
1/45
✱
4
373
Date
O 1
DT
8
✱
5
337
Time
X 1
TM
4/8
✱
6
623
Time
Code
O 1
ID
2
✱
7
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
PXC
Health Care Provider Taxonomy Code
CODE SOURCE: 682: Health Care Provider Taxonomy
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 Taxonomy Code
Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
369
Free-form Description
X 1
AN
1/45
Not Used
4
373
Date
O 1
DT
8
Not Used
5
337
Time
X 1
TM
4/8
Not Used
6
623
Time Code
O 1
ID
2
Not Used
7
C040
Reference Identifier
O 1

PER*PH - REQUESTING PROVIDER CONTACT

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 1100C - REQUESTING PROVIDER NAME
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
2
Situational Rule:
Required when different than the information carried in the PER segments in loop 1100A. If not required by this implementation guide, may be sent at the sender's discretion but cannot be required by receiver.
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. The contact information in this segment identifies the person in the submitter organization who deals with data transmission issues. If data transmission problems arise, this is the person to contact in the submitter organization.
  3. There are 2 repetitions of the PER segment to allow for six possible communication numbers including extensions.
TR3 Example:
PER✱PH✱✱TE✱8005551212~
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
PH
Provider
Situational
2
93
Name
O 1
AN
1/60
Free-form name
SITUATIONAL RULE: Required when the contact name is different than the name contained in the N1 Segment (Requesting Provider Name) of this loop. If not required, do not send.
Required
3
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0304
CODE
DEFINITION
EM
Electronic Mail
FX
Facsimile
TE
Telephone
Required
4
364
Communication Number
X 1
AN
1/2048
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0304
Situational
5
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when this information is deemed necessary by the submitter. If not required by this implementation guide, do not send.
CODE
DEFINITION
EM
Electronic Mail
EX
Telephone Extension
Use when reporting a telephone extension for the preceding telephone number.
FX
Facsimile
TE
Telephone
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 is needed. If not required by this implementation guide, do not send.
Situational
7
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0708
SITUATIONAL RULE: Required when an extension applies to the previous communications contact number (PER06). If not required by this implementation guide, do not send.
CODE
DEFINITION
EX
Telephone Extension
Use when reporting a telephone extension for the preceding telephone number.
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 an extension applies to the previous communications contact number (PER06). If not required by this implementation guide, do not send.
Not Used
9
443
Contact Inquiry Reference
O 1
AN
1/20

ENE - REQUEST DETAIL

X12 Name:
Electronic Systems Environment
X12 Purpose:
To specify electronic systems environment
X12 Syntax:
P0405
If either ENE04 or ENE05 is present, then the other is required.
Loop:
Loop 1200 - REQUEST DETAIL
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
  1. Identifies the communications information related to the EDI enrollment actions requested.
  2. The values identified allow communications protocols when the payer specifies the value in a trading partner agreement. When the Payer does not require specific values or the values are unknown, use SC for ENE01, ED for for ENE02 and "NOT APPLICABLE" for ENE03.
TR3 Example:
ENE✱PP✱ED✱123456789~
ENE
✱
1
709
Comm
Envir Code
M 1
ID
2
✱
2
365
Comm
Number Qual
M 1
ID
2
✱
3
364
Comm
Number
M 1
AN
1/2048
✱
4
66
ID Code
Qualifier
X 1
ID
1/2
✱
5
67
ID
Code
X 1
AN
2/80
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
709
Communications Environment Code
M 1
ID
2
Code indicating EDI systems media capability
Refer to TR3 note.
CODE
DEFINITION
PP
Point to Point
Use when a direct connection exists between the entity that will be sending the EDI transaction and the entity that will be receiving the EDI transaction.
SC
Service Contracted Provider
Use when a direct connection does not exist between the entity that will be sending the EDI transaction and the entity that will be receiving the EDI transaction, and a communications carrier will be used for the connection.
Required
2
365
Communication Number Qualifier
M 1
ID
2
Code identifying the type of communication number
Refer to TR3 note.
CODE
DEFINITION
ED
Electronic Data Interchange Access Number
Required
3
364
Communication Number
M 1
AN
1/2048
Complete communications number including country or area code when applicable
INDUSTRY NAME: EDI Communications Identifier
  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. If ENE01 identifies this as Point to Point, this is the identifier related to the direct connection between the trading partners. If ENE01 identifies Service Contracted Provider, this is the identification of the sender's end of the connection. For instance, if the service type is dial-up telephone, this is the sender's data phone number. If the service type is Internet, this is the sender's Internet Protocol (IP) address.
  3. Refer to TR3 note.
Not Used
4
66
Identification Code Qualifier
X 1
ID
1/2
Not Used
5
67
Identification Code
X 1
AN
2/80

N1 - AFFILIATED PROVIDER NAME

X12 Name:
Party Identification
X12 Purpose:
To identify a party by type of organization, name, and code
X12 Syntax:
  1. R0203
    At least one of N102 or N103 is required.
  2. P0304
    If either N103 or N104 is present, then the other is required.
  3. C0703
    If N107 is present, then N103 is required.
Loop:
Loop 1210A - AFFILIATED PROVIDER NAME
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required when the Requesting Provider identified in the 1100C loop has N101 value of FA (Facility) or QV (Group Practice) and the payer requires the iteration of affiliated providers or facilities. If not required by this implementation guide, do not send.
TR3 Notes:
This loop identifies an individual provider or facility that is a member of the group identified in loop 1100C. Mulitple 1210A loops are used to identify all individual providers of the 1100C loop group provider.
TR3 Example:
N1✱1P✱Doe✱XX✱1234567893~N1✱FA✱ABC Surgery Center - Any Town✱XX✱1234567890~
N1
✱
1
98
Entity ID
Code
M 1
ID
2/3
✱
2
93
Name
X 1
AN
1/60
✱
3
66
ID Code
Qualifier
X 1
ID
1/2
✱
4
67
ID
Code
X 1
AN
2/80
✱
5
706
Entity
Relat Code
O 1
ID
2
✱
6
98
Entity ID
Code
O 1
ID
2/3
✱
7
C076
Composite
ID Codes
O 1
~
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
Use when identifying an individual within a group practice.
FA
Facility
Use when reporting a non-person entity.
Required
2
93
Name
X 1
AN
1/60
Free-form name
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Provider Name
This is the last name of the provider when N101 is 1P - Provider. This is the organization name for all other submitter types.
Situational
3
66
Identification Code Qualifier
X 1
ID
1/2
Code specifying the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: R0203, P0304, C0703
SITUATIONAL RULE: Required when the provider has a National Provider identifier (NPI). 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
4
67
Identification Code
X 1
AN
2/80
Code identifying a party or other code
COMMENT: This segment, used alone, provides the most efficient method of providing organizational identification. To obtain this efficiency the "ID Code" (N104) must provide a key to the table maintained by the transaction processing party.
SEGMENT SYNTAX: P0304
SITUATIONAL RULE: Required when the provider has a National Provider identifier (NPI). If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Identifier
Not Used
5
706
Entity Relationship Code
O 1
ID
2
Not Used
6
98
Entity Identifier Code
O 1
ID
2/3
Not Used
7
C076
Composite Identification Codes
O 1

N2 - AFFILIATED PROVIDER OTHER NAME

X12 Name:
Additional Name Information
X12 Purpose:
To specify additional names
Loop:
Loop 1210A - AFFILIATED PROVIDER NAME
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the affiliated provider is an individual and has a first name.
OR
When the affiliated provider is not an individual and the receiver knows the organization by another name (DBA or trade name). If not required by this implementation guide, do not send.
TR3 Example:
N2✱Jack~
N2
✱
1
93
Name
M 1
AN
1/60
✱
2
93
Name
O 1
AN
1/60
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
93
Name
M 1
AN
1/60
Free-form name
This is the first name of the individual when N101 is 1P - Provider.
This is the organization name for all other entity types.
Not Used
2
93
Name
O 1
AN
1/60

N9 - AFFILIATED PROVIDER OTHER IDENTIFIER

X12 Name:
Extended Reference Information
X12 Purpose:
To transmit identifying information as specified by the Reference Identification Qualifier
X12 Syntax:
  1. R0203
    At least one of N902 or N903 is required.
  2. C0605
    If N906 is present, then N905 is required.
Loop:
Loop 1210A - AFFILIATED PROVIDER NAME
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
2
Situational Rule:
Required when identification of the affiliated provider is dependent upon an identification number beyond that supplied in the N1 segment. If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.
TR3 Example:
N9✱TJ✱123456789~
N9
✱
1
128
Reference
Ident Qual
M 1
ID
2/3
✱
2
127
Reference
Ident
X 1
AN
1/80
✱
3
369
Free-Form
Description
X 1
AN
1/45
✱
4
373
Date
O 1
DT
8
✱
5
337
Time
X 1
TM
4/8
✱
6
623
Time
Code
O 1
ID
2
✱
7
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
TJ
Federal Taxpayer'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: Affiliated Provider's Other Identifier
Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
369
Free-form Description
X 1
AN
1/45
Not Used
4
373
Date
O 1
DT
8
Not Used
5
337
Time
X 1
TM
4/8
Not Used
6
623
Time Code
O 1
ID
2
Not Used
7
C040
Reference Identifier
O 1

N9*PXC - AFFILIATED PROVIDER TAXONOMY INFORMATION

X12 Name:
Extended Reference Information
X12 Purpose:
To transmit identifying information as specified by the Reference Identification Qualifier
X12 Syntax:
  1. R0203
    At least one of N902 or N903 is required.
  2. C0605
    If N906 is present, then N905 is required.
Loop:
Loop 1210A - AFFILIATED PROVIDER NAME
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
6
Situational Rule:
Required when the payer's enrollment is known to be impacted by the provider's taxonomy code. If not required by this implementation guide, do not send.
TR3 Notes:
Multiple N9 segments can be used to report multiple provider Taxonomy values when appropriate. The multiple segments must report different taxonomy codes in N902.
TR3 Example:
N9✱PXC✱208D00000X~
N9
✱
1
128
Reference
Ident Qual
M 1
ID
2/3
✱
2
127
Reference
Ident
X 1
AN
1/80
✱
3
369
Free-Form
Description
X 1
AN
1/45
✱
4
373
Date
O 1
DT
8
✱
5
337
Time
X 1
TM
4/8
✱
6
623
Time
Code
O 1
ID
2
✱
7
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
PXC
Health Care Provider Taxonomy Code
CODE SOURCE: 682: Health Care Provider Taxonomy
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's Taxonomy Code
Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
369
Free-form Description
X 1
AN
1/45
Not Used
4
373
Date
O 1
DT
8
Not Used
5
337
Time
X 1
TM
4/8
Not Used
6
623
Time Code
O 1
ID
2
Not Used
7
C040
Reference Identifier
O 1

PER*PH - AFFILIATED 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 1210A - AFFILIATED PROVIDER NAME
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the Affiliated Provider has contact information different than the Requesting Provider contact information in loop 1100C. If not required by this implementation guide, do not send.
TR3 Example:
PER✱PH✱✱TE✱8005551212~
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
PH
Provider
Situational
2
93
Name
O 1
AN
1/60
Free-form name
SITUATIONAL RULE: Required when the contact name is different than the name contained in the N1 Segment (Affiliated Provider Name) of this loop. If not required, do not send.
Situational
3
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0304
SITUATIONAL RULE: Required when the communication number is different than the communication number contained in the Requesting Provider contact information in loop 1100C. If not required by this implementation guide, do not send.
CODE
DEFINITION
EM
Electronic Mail
FX
Facsimile
TE
Telephone
Situational
4
364
Communication Number
X 1
AN
1/2048
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0304
SITUATIONAL RULE: Required when the communication number is different than the communication number contained in the Requesting Provider contact information in loop 1100C. If not required by this implementation guide, do not send.
Situational
5
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when the communication number is different than the communication number contained in the Requesting Provider contact information in loop 1100C. If not required by this implementation guide, do not send.
CODE
DEFINITION
EM
Electronic Mail
EX
Telephone Extension
Use when reporting a telephone extension for the preceding telephone number.
FX
Facsimile
TE
Telephone
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 the communication number is different than the communication number contained in the Requesting Provider contact information in loop 1100C. If not required by this implementation guide, do not send.
Situational
7
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0708
SITUATIONAL RULE: Required when the communication number is different than the communication number contained in the Requesting Provider contact information in loop 1100C. If not required by this implementation guide, do not send.
CODE
DEFINITION
EM
Electronic Mail
EX
Telephone Extension
Use when reporting a telephone extension for the preceding telephone number.
FX
Facsimile
TE
Telephone
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 the communication number is different than the communication number contained in the Requesting Provider contact information in loop 1100C. If not required by this implementation guide, do not send.
Not Used
9
443
Contact Inquiry Reference
O 1
AN
1/20

N1*PR - PAYER NAME

X12 Name:
Party Identification
X12 Purpose:
To identify a party by type of organization, name, and code
X12 Syntax:
  1. R0203
    At least one of N102 or N103 is required.
  2. P0304
    If either N103 or N104 is present, then the other is required.
  3. C0703
    If N107 is present, then N103 is required.
Loop:
Loop 1210B - PAYER NAME
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required when the receiver of the transaction identified in Loop 1100B N1 - Receiver Name is not the payer, or additional identifiers are needed to identify the payer in Loop 1100B. If not required by this implementation guide, do not send.
TR3 Notes:
  1. One transaction set can identify multiple payers, and actions related to each payer by using multiple 1200 loops.
  2. When this loop is used to convey addition identifiers for the payer in loop 1100B, the values in N103 and N104 mirror the values from the 1100B N1 for that payer. The additional identifiers are reported in the N9 Segment of this loop.
TR3 Example:
N1✱PR✱All Inclusive Health Plan✱46✱1234567890~
N1
✱
1
98
Entity ID
Code
M 1
ID
2/3
✱
2
93
Name
X 1
AN
1/60
✱
3
66
ID Code
Qualifier
X 1
ID
1/2
✱
4
67
ID
Code
X 1
AN
2/80
✱
5
706
Entity
Relat Code
O 1
ID
2
✱
6
98
Entity ID
Code
O 1
ID
2/3
✱
7
C076
Composite
ID Codes
O 1
~
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
Situational
2
93
Name
X 1
AN
1/60
Free-form name
SEGMENT SYNTAX: R0203
SITUATIONAL RULE: Use when the receiver identified in Loop 1100B - Receiver Name is not the payer. If not required by this implementation guide, do not use.
INDUSTRY NAME: Payer Name
Required
3
66
Identification Code Qualifier
X 1
ID
1/2
Code specifying the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: R0203, P0304, C0703
This is any mutually agreed upon ID that is used between trading partners and is generally used within the enrolled transaction to identify each party.
CODE
DEFINITION
46
Electronic Transmitter Identification Number (ETIN)
Required
4
67
Identification Code
X 1
AN
2/80
Code identifying a party or other code
COMMENT: This segment, used alone, provides the most efficient method of providing organizational identification. To obtain this efficiency the "ID Code" (N104) must provide a key to the table maintained by the transaction processing party.
SEGMENT SYNTAX: P0304
This is the electronic identification number for the receiver in the EDI relationship with the submitter of this transaction.
Not Used
5
706
Entity Relationship Code
O 1
ID
2
Not Used
6
98
Entity Identifier Code
O 1
ID
2/3
Not Used
7
C076
Composite Identification Codes
O 1

N2 - PAYER OTHER NAME

X12 Name:
Additional Name Information
X12 Purpose:
To specify additional names
Loop:
Loop 1210B - PAYER NAME
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the receiver of the transaction identified in Loop 1100B N1 - Receiver Name is not the payer and the payer identified in 1210B N1 is known by another name. If not required by this implementation guide, do not send.
TR3 Example:
N2✱AIHP~
N2
✱
1
93
Name
M 1
AN
1/60
✱
2
93
Name
O 1
AN
1/60
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
93
Name
M 1
AN
1/60
Free-form name
INDUSTRY NAME: Payer Other Name
Not Used
2
93
Name
O 1
AN
1/60

N9*2U - PAYER OTHER IDENTIFIER

X12 Name:
Extended Reference Information
X12 Purpose:
To transmit identifying information as specified by the Reference Identification Qualifier
X12 Syntax:
  1. R0203
    At least one of N902 or N903 is required.
  2. C0605
    If N906 is present, then N905 is required.
Loop:
Loop 1210B - PAYER NAME
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when an additional identifier is needed to clearly identify the payer. If not required by this implementation guide, do not send.
TR3 Example:
N9✱2U✱12345~
N9
✱
1
128
Reference
Ident Qual
M 1
ID
2/3
✱
2
127
Reference
Ident
X 1
AN
1/80
✱
3
369
Free-Form
Description
X 1
AN
1/45
✱
4
373
Date
O 1
DT
8
✱
5
337
Time
X 1
TM
4/8
✱
6
623
Time
Code
O 1
ID
2
✱
7
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
Use when reporting the proprietary or legacy ID specific to the payer.
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: Additional Payer Identifier
Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
369
Free-form Description
X 1
AN
1/45
Not Used
4
373
Date
O 1
DT
8
Not Used
5
337
Time
X 1
TM
4/8
Not Used
6
623
Time Code
O 1
ID
2
Not Used
7
C040
Reference Identifier
O 1

N1*MJ - FINANCIAL INSTITUTION NAME

X12 Name:
Party Identification
X12 Purpose:
To identify a party by type of organization, name, and code
X12 Syntax:
  1. R0203
    At least one of N102 or N103 is required.
  2. P0304
    If either N103 or N104 is present, then the other is required.
  3. C0703
    If N107 is present, then N103 is required.
Loop:
Loop 1210C - FINANCIAL INSTITUTION NAME
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required when the action involves electronic funds transfer. If not required by this implementation guide, do not send.
TR3 Example:
N1✱MJ✱First National Bank✱13✱12345678~
N1
✱
1
98
Entity ID
Code
M 1
ID
2/3
✱
2
93
Name
X 1
AN
1/60
✱
3
66
ID Code
Qualifier
X 1
ID
1/2
✱
4
67
ID
Code
X 1
AN
2/80
✱
5
706
Entity
Relat Code
O 1
ID
2
✱
6
98
Entity ID
Code
O 1
ID
2/3
✱
7
C076
Composite
ID Codes
O 1
~
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
MJ
Financial Institution
Required
2
93
Name
X 1
AN
1/60
Free-form name
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Financial Institution Name
Required
3
66
Identification Code Qualifier
X 1
ID
1/2
Code specifying the system/method of code structure used for Identification Code (67)
SEGMENT SYNTAX: R0203, P0304, C0703
CODE
DEFINITION
13
Federal Reserve Routing Code (FRRC)
CODE SOURCE: 4: ABA Routing Number
CF
Canadian Financial Institution Routing Number
CODE SOURCE: 91: Canadian Financial Institution Branch and Institution Number
Required
4
67
Identification Code
X 1
AN
2/80
Code identifying a party or other code
COMMENT: This segment, used alone, provides the most efficient method of providing organizational identification. To obtain this efficiency the "ID Code" (N104) must provide a key to the table maintained by the transaction processing party.
SEGMENT SYNTAX: P0304
INDUSTRY NAME: ABA Routing Number
This is the routing number of the financial institution.
Not Used
5
706
Entity Relationship Code
O 1
ID
2
Not Used
6
98
Entity Identifier Code
O 1
ID
2/3
Not Used
7
C076
Composite Identification Codes
O 1

N3 - FINANCIAL INSTITUTION ADDRESS

X12 Name:
Party Location
X12 Purpose:
To specify the location of the named party
Loop:
Loop 1210C - FINANCIAL INSTITUTION NAME
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
This is the address of the financial institution that is used by the provider for their account.
TR3 Example:
N3✱234 Market 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: Financial Institution Address Line
Situational
2
166
Address Information
O 1
AN
1/55
Address information
SITUATIONAL RULE: Required when the financial institution has a second address line to their address. If not required by this implementation guide, do not send.
INDUSTRY NAME: Financial Institution Address Line

N4 - FINANCIAL INSTITUTION CITY, STATE AND 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 1210C - FINANCIAL INSTITUTION NAME
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
N4✱Rivercity✱PA✱12345~
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.
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.
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.
  • 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.
Use the alpha-2 country codes from Part 1 of ISO 3166.
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
Situational
7
1715
Country Subdivision Code
X 1
ID
1/3
Code identifying the country subdivision
SEGMENT SYNTAX: E0207, C0704
SITUATIONAL RULE: Required when the address is not in the United States of America, including its territories, or Canada, and the country in N404 has administrative subdivisions such as but not limited to states, provinces, cantons, etc. If not required by this implementation guide, do not send.
Use the country subdivision codes from Part 2 of ISO 3166.
CODE SOURCE 5: Countries, Currencies and Funds
Not Used
8
1702
Postal Code-Formatted
X 1
AN
3/20

N9 - ACCOUNT INFORMATION

X12 Name:
Extended Reference Information
X12 Purpose:
To transmit identifying information as specified by the Reference Identification Qualifier
X12 Syntax:
  1. R0203
    At least one of N902 or N903 is required.
  2. C0605
    If N906 is present, then N905 is required.
Loop:
Loop 1210C - FINANCIAL INSTITUTION NAME
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
N9✱11✱654321~
N9
✱
1
128
Reference
Ident Qual
M 1
ID
2/3
✱
2
127
Reference
Ident
X 1
AN
1/80
✱
3
369
Free-Form
Description
X 1
AN
1/45
✱
4
373
Date
O 1
DT
8
✱
5
337
Time
X 1
TM
4/8
✱
6
623
Time
Code
O 1
ID
2
✱
7
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
11
Account Number
Use when the account is a demand deposit (checking) account.
SG
Savings
Subset 278 of the current version of the Health Care Services Type Codes List represents the codes that are available for use in this element.
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: Payee Account Number
  1. This is the payee's account number at the financial institution that is related to the EFT Payment.
  2. Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
369
Free-form Description
X 1
AN
1/45
Not Used
4
373
Date
O 1
DT
8
Not Used
5
337
Time
X 1
TM
4/8
Not Used
6
623
Time Code
O 1
ID
2
Not Used
7
C040
Reference Identifier
O 1

PER*EA - FINANCIAL INSTITUTION 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 1210C - FINANCIAL INSTITUTION NAME
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
This is the contact telephone number at the provider's financial institution for EFT issues.
TR3 Example:
PER✱EA✱✱TE✱8005551212~
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
EA
EDI Coordinator
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
TE
Telephone
Required
4
364
Communication Number
X 1
AN
1/2048
Complete communications number including country or area code when applicable
SEGMENT SYNTAX: P0304
This is the telephone number for the EDI Coordinator.
Situational
5
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when there is an extension associated with the telephone number in PER04. If not required by this implementation guide, do not send.
CODE
DEFINITION
EX
Telephone Extension
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 there is an extension associated with the telephone number in PER04. If not required by this implementation guide, do not send.
INDUSTRY NAME: Financial Institution Communication Number
This is the extension for the telephone number for the EDI Coordinator.
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

N1*J2 - PROVIDER AUTHORIZED AGENT NAME

X12 Name:
Party Identification
X12 Purpose:
To identify a party by type of organization, name, and code
X12 Syntax:
  1. R0203
    At least one of N102 or N103 is required.
  2. P0304
    If either N103 or N104 is present, then the other is required.
  3. C0703
    If N107 is present, then N103 is required.
Loop:
Loop 1210D - PROVIDER AUTHORIZED AGENT NAME
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required when the provider has an authorized agent. Authorized agent must be an individual. If not required by this guide, do not send.
TR3 Notes:
This loop identifies the individual that has the authority to act on behalf of the provider for enrollment in EDI or EFT transactions with a payer.
TR3 Example:
N1✱J2✱Brown~
N1
✱
1
98
Entity ID
Code
M 1
ID
2/3
✱
2
93
Name
X 1
AN
1/60
✱
3
66
ID Code
Qualifier
X 1
ID
1/2
✱
4
67
ID
Code
X 1
AN
2/80
✱
5
706
Entity
Relat Code
O 1
ID
2
✱
6
98
Entity ID
Code
O 1
ID
2/3
✱
7
C076
Composite
ID Codes
O 1
~
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
J2
Authorized Entity
Required
2
93
Name
X 1
AN
1/60
Free-form name
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Provider Authorized Name
This is the Last Name of the Provider Authorized Agent.
Not Used
3
66
Identification Code Qualifier
X 1
ID
1/2
Not Used
4
67
Identification Code
X 1
AN
2/80
Not Used
5
706
Entity Relationship Code
O 1
ID
2
Not Used
6
98
Entity Identifier Code
O 1
ID
2/3
Not Used
7
C076
Composite Identification Codes
O 1

N2 - PROVIDER AUTHORIZED AGENT FIRST NAME

X12 Name:
Additional Name Information
X12 Purpose:
To specify additional names
Loop:
Loop 1210D - PROVIDER AUTHORIZED AGENT NAME
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when Provider Authorized Agent has a first name.
TR3 Example:
N2✱PAUL~
N2
✱
1
93
Name
M 1
AN
1/60
✱
2
93
Name
O 1
AN
1/60
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
93
Name
M 1
AN
1/60
Free-form name
INDUSTRY NAME: Provider Authorized Agent First Name
Not Used
2
93
Name
O 1
AN
1/60

N9*SUB - PROVIDER AUTHORIZED AGENT TITLE

X12 Name:
Extended Reference Information
X12 Purpose:
To transmit identifying information as specified by the Reference Identification Qualifier
X12 Syntax:
  1. R0203
    At least one of N902 or N903 is required.
  2. C0605
    If N906 is present, then N905 is required.
Loop:
Loop 1210D - PROVIDER AUTHORIZED AGENT NAME
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
N9✱SUB✱Chief Financial Officer~
N9
✱
1
128
Reference
Ident Qual
M 1
ID
2/3
✱
2
127
Reference
Ident
X 1
AN
1/80
✱
3
369
Free-Form
Description
X 1
AN
1/45
✱
4
373
Date
O 1
DT
8
✱
5
337
Time
X 1
TM
4/8
✱
6
623
Time
Code
O 1
ID
2
✱
7
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
SUB
Title Reference
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 Authorized Agent Title
  1. This is the position title of the Provider Authorized Agent with the provider in their role as agent.
  2. Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
369
Free-form Description
X 1
AN
1/45
Not Used
4
373
Date
O 1
DT
8
Not Used
5
337
Time
X 1
TM
4/8
Not Used
6
623
Time Code
O 1
ID
2
Not Used
7
C040
Reference Identifier
O 1

PER*AA - PROVIDER AUTHORIZED AGENT CONTACT

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 1210D - PROVIDER AUTHORIZED AGENT NAME
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
PER✱AA✱✱TE✱8005551212~
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
AA
Authorized Representative
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
TE
Telephone
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: Provider Authorized Agent Communications 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 there is an extension associated with the telephone number in PER04. If not required by this implementation guide, do not send.
CODE
DEFINITION
EX
Telephone Extension
Use when reporting a telephone extension for the preceding telephone number.
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 there is an extension associated with the telephone number in PER04. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Authorized Agent Communications 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 the Authorized Agent has an email and requires it for some communication. If not required by this implementation guide, do not send.
INDUSTRY NAME: Missing
CODE
DEFINITION
EM
Electronic Mail
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 PER07 is used. If not required by this implementation guide, do not send.
INDUSTRY NAME: Missing
Not Used
9
443
Contact Inquiry Reference
O 1
AN
1/20

N1*FD - PROVIDER PHYSICAL ADDRESS

X12 Name:
Party Identification
X12 Purpose:
To identify a party by type of organization, name, and code
X12 Syntax:
  1. R0203
    At least one of N102 or N103 is required.
  2. P0304
    If either N103 or N104 is present, then the other is required.
  3. C0703
    If N107 is present, then N103 is required.
Loop:
Loop 1210E - PROVIDER PHYSICAL ADDRESS
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required when the providers identified in 1210A loop have a different physical address than provided in the 1100C loop;
Or
Required when the address provided in loop 1100C is not a physical address and the physical address is required for processing by the receiver of the request. If not required by this implementation guide do not send.
TR3 Example:
N1✱FD✱Center City Clinic~
N1
✱
1
98
Entity ID
Code
M 1
ID
2/3
✱
2
93
Name
X 1
AN
1/60
✱
3
66
ID Code
Qualifier
X 1
ID
1/2
✱
4
67
ID
Code
X 1
AN
2/80
✱
5
706
Entity
Relat Code
O 1
ID
2
✱
6
98
Entity ID
Code
O 1
ID
2/3
✱
7
C076
Composite
ID Codes
O 1
~
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
FD
Physical Address
Required
2
93
Name
X 1
AN
1/60
Free-form name
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Physical Address Name
This is the name associated with the physical address.
Not Used
3
66
Identification Code Qualifier
X 1
ID
1/2
Not Used
4
67
Identification Code
X 1
AN
2/80
Not Used
5
706
Entity Relationship Code
O 1
ID
2
Not Used
6
98
Entity Identifier Code
O 1
ID
2/3
Not Used
7
C076
Composite Identification Codes
O 1

N3 - PROVIDER PHYSICAL ADDRESS

X12 Name:
Party Location
X12 Purpose:
To specify the location of the named party
Loop:
Loop 1210E - PROVIDER PHYSICAL ADDRESS
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
N3✱234 Broad Street✱Suite 4C~
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 Physical Address
Situational
2
166
Address Information
O 1
AN
1/55
Address information
SITUATIONAL RULE: Required when the provider's physical address has a second address line. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Physical Address

N4 - PROVIDER PHYSICAL 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 1210E - PROVIDER PHYSICAL ADDRESS
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
N4✱Rivercity✱PA✱12345~
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 Physical City
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 Physical State
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 Physical 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 Physical Country Code
Use the alpha-2 country codes from Part 1 of ISO 3166.
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
Situational
7
1715
Country Subdivision Code
X 1
ID
1/3
Code identifying the country subdivision
SEGMENT SYNTAX: E0207, C0704
SITUATIONAL RULE: Required when the address is not in the United States of America, including its territories, or Canada, and the country in N404 has administrative subdivisions such as but not limited to states, provinces, cantons, etc. If not required by this implementation guide, do not send.
INDUSTRY NAME: Provider Physical Country Subdivision
Use the country subdivision codes from Part 2 of ISO 3166.
CODE SOURCE 5: Countries, Currencies and Funds
Not Used
8
1702
Postal Code-Formatted
X 1
AN
3/20

N1*VN - PROVIDER SOFTWARE VENDOR INFORMATION

X12 Name:
Party Identification
X12 Purpose:
To identify a party by type of organization, name, and code
X12 Syntax:
  1. R0203
    At least one of N102 or N103 is required.
  2. P0304
    If either N103 or N104 is present, then the other is required.
  3. C0703
    If N107 is present, then N103 is required.
Loop:
Loop 1210F - PROVIDER SOFTWARE VENDOR INFORMATION
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required when the provider uses a software vendor for the processing of the transactions identified in the related 1220 loop and the payer requires the information for onboarding purposes. If not required by this implementation guide, do not send.
TR3 Notes:
This loop is not used when the provider has created and maintains their own software for processing the related transactions.
TR3 Example:
N1✱VN✱Provider Software Solutions~
N1
✱
1
98
Entity ID
Code
M 1
ID
2/3
✱
2
93
Name
X 1
AN
1/60
✱
3
66
ID Code
Qualifier
X 1
ID
1/2
✱
4
67
ID
Code
X 1
AN
2/80
✱
5
706
Entity
Relat Code
O 1
ID
2
✱
6
98
Entity ID
Code
O 1
ID
2/3
✱
7
C076
Composite
ID Codes
O 1
~
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
VN
Vendor
Required
2
93
Name
X 1
AN
1/60
Free-form name
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Vendor Name
Not Used
3
66
Identification Code Qualifier
X 1
ID
1/2
Not Used
4
67
Identification Code
X 1
AN
2/80
Not Used
5
706
Entity Relationship Code
O 1
ID
2
Not Used
6
98
Entity Identifier Code
O 1
ID
2/3
Not Used
7
C076
Composite Identification Codes
O 1

N9*V0 - SOFTWARE PRODUCT IDENTIFICATION

X12 Name:
Extended Reference Information
X12 Purpose:
To transmit identifying information as specified by the Reference Identification Qualifier
X12 Syntax:
  1. R0203
    At least one of N902 or N903 is required.
  2. C0605
    If N906 is present, then N905 is required.
Loop:
Loop 1210F - PROVIDER SOFTWARE VENDOR INFORMATION
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the payer requires the information for onboarding purposes. If not required by this implementation guide, do not send.
TR3 Example:
N9✱V0✱V12.4.2.1✱PMS Plus~
N9
✱
1
128
Reference
Ident Qual
M 1
ID
2/3
✱
2
127
Reference
Ident
X 1
AN
1/80
✱
3
369
Free-Form
Description
X 1
AN
1/45
✱
4
373
Date
O 1
DT
8
✱
5
337
Time
X 1
TM
4/8
✱
6
623
Time
Code
O 1
ID
2
✱
7
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
V0
Version
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: Software Product Version
Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Required
3
369
Free-form Description
X 1
AN
1/45
Free-form descriptive text
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Software Product Name
Not Used
4
373
Date
O 1
DT
8
Not Used
5
337
Time
X 1
TM
4/8
Not Used
6
623
Time Code
O 1
ID
2
Not Used
7
C040
Reference Identifier
O 1

TXN - TRANSACTION REQUEST DETAIL

X12 Name:
Transaction Capabilities
X12 Purpose:
To indicate EDI transaction capabilities
X12 Syntax:
  1. P020304
    If either TXN02, TXN03 or TXN04 are present, then the others are required.
  2. E0410
    Only one of TXN04 or TXN10 may be present.
Loop:
Loop 1220 - TRANSACTION REQUEST DETAIL
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
TXN✱1✱X✱835✱005010X221A1✱R✱12345✱54321✱20160430~TXN✱1✱✱✱✱R✱✱✱20140430✱✱I:ACH CCD+:NACHA OPERATING RULES~
TXN
✱
1
306
Action
Code
M 1
ID
1/2
✱
2
455
Responsible
Agency Code
X 1
ID
1/2
✱
3
143
TS ID
Code
X 1
ID
3
✱
4
480
Ver/Release
ID Code
X 1
AN
1/12
✱
5
306
Action
Code
M 1
ID
1/2
✱
6
124
Application
Rec's Code
O 1
AN
2/15
✱
7
142
Application
Send's Code
O 1
AN
2/15
✱
8
373
Date
O 1
DT
8
✱
9
337
Time
O 1
TM
4/8
✱
10
C053
Standards
Information
X 1
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
306
Action Code
M 1
ID
1/2
Code indicating type of action
CODE
DEFINITION
1
Add
2
Change (Update)
3
Delete
4
Verify
Situational
2
455
Responsible Agency Code
X 1
ID
1/2
Code identifying the issuer of the standard; this code is used in conjunction with Data Element 480
SEGMENT SYNTAX: P020304
SITUATIONAL RULE: Required when the action is related to an X12 transaction/Technical Report. If not required by this implementation guide, do not send.
CODE
DEFINITION
X
Accredited Standards Committee X12
Situational
3
143
Transaction Set Identifier Code
X 1
ID
3
Code identifying a Transaction Set
SEGMENT SYNTAX: P020304
SITUATIONAL RULE: Required when the action is related to an X12 transaction/Technical Report. If not required by this implementation guide, do not send.
Identify the related transaction by its three character ST01 value (i.e. 835, 837). For request/response transactions described under the same technical report, identify only the identifier of the request transaction (i.e. for the Health Care Claim Status Request and Response (276/277) use 276).
Situational
4
480
Version / Release / Industry Identifier Code
X 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
SEMANTIC: Use either TXN04 or TXN10 to identify the EDI standard and implementation guideline for which a capability is being reported.
SEGMENT SYNTAX: P020304, E0410
SITUATIONAL RULE: Required when the action is related to an X12 transaction/Technical Report. If not required by this implementation guide, do not send.
INDUSTRY NAME: Version, Release, or Industry Identifier Code
Identify the related X12 Type 3 Technical Report that identifies the transaction(s) (i.e. - for the Health Care Claim: Professional identified in guide 005010X222 plus addenda A1, use 005010X222A1). This is the same value that is included in the GS segment, element 08 of the Functional Group.
CODE SOURCE 881: Version / Release / Industry Identifier Code
Required
5
306
Action Code
M 1
ID
1/2
Code indicating type of action
INDUSTRY NAME: Environment Action Code
CODE
DEFINITION
8
In Production Send
K
In Production Send and Receive
Use when another code is not supported by trading partner agreement.
O
In Test/Send
P
In Test/Receive
Q
In Test/Send and Receive
R
In Production Receive
Situational
6
124
Application Receiver's Code
O 1
AN
2/15
Code identifying party receiving transmission; codes agreed to by trading partners
SITUATIONAL RULE: Required when TXN03 is used and the information is known. If not required by this implementation guide, do not send.
Identify the value expected to be seen in the GS segment, element 03 for the transaction identified by TXN03 and TXN04.
Situational
7
142
Application Sender's Code
O 1
AN
2/15
Code identifying party sending transmission; codes agreed to by trading partners
SITUATIONAL RULE: Required when TXN03 is used and the information is known. If not required by this implementation guide, do not send.
Identify the value expected to be seen in the GS segment, element 02 for the transaction identified in TXN03.
Situational
8
373
Date
O 1
DT
8
Date expressed as CCYYMMDD where CC represents the first two digits of the calendar year
SEMANTIC: If used, TXN08 and TXN09 indicate the effective date and time.
SITUATIONAL RULE: Required when a specific effective date is being requested for the action. If not required by this implementation guide, do not send.
INDUSTRY NAME: Enrollment Effective Date
This is the date that the requestor desires the action to take effect.
Not Used
9
337
Time
O 1
TM
4/8
Situational
10
C053
Standards Information
X 1
To identify the EDI standard, version, release and any applicable industry guideline
SITUATIONAL RULE: Required when the action is related to electronic funds transfer. If not required by this implementation guide, do not send.
Required
10-1
922
Electronic Form Standards Type Code
M 1
ID
1
Code identifying the standard type being transferred using the electronic form
CODE
DEFINITION
I
Industry Standard Code List
Required
10-2
1707
Electronic Form Standards Identifier
M 1
AN
1/15
The coded identification of the applicable electronic business transaction
INDUSTRY NAME: Payment Method and Format Code
  1. Reference front matter section 1.4.2 (Response to a Solicited Health Care Claim Request for Additional Information).
  2. Use to send the value "ACH CCD+" meaning Automated Clearing House (ACH) Cash Concentration/Disbursement plus Addenda (CCD+)
Required
10-3
1705
Implementation Convention Reference
M 1
AN
1/35
Reference assigned to identify Implementation Convention
  1. NACHA OPERATING RULES
  2. Use to send the value "NACHA OPERATING RULES" identifying that the reference is for the current version of NACHA operating rules for Health Care EFT.
Not Used
10-4
799
Version Identifier
O 1
AN
1/30
Not Used
10-5
796
Revision Value
O 1
AN
1/30

N9*TQ - SUBMITTER TRACE NUMBER

X12 Name:
Extended Reference Information
X12 Purpose:
To transmit identifying information as specified by the Reference Identification Qualifier
X12 Syntax:
  1. R0203
    At least one of N902 or N903 is required.
  2. C0605
    If N906 is present, then N905 is required.
Loop:
Loop 1220 - TRANSACTION REQUEST DETAIL
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the Submitter identified in this transaction is not the provider and has assigned a unique trace identifier to the action within the Submitter/Receiver relationship. If not required by this implementation guide, do not send.
TR3 Example:
N9✱TQ✱835-12345~
N9
✱
1
128
Reference
Ident Qual
M 1
ID
2/3
✱
2
127
Reference
Ident
X 1
AN
1/80
✱
3
369
Free-Form
Description
X 1
AN
1/45
✱
4
373
Date
O 1
DT
8
✱
5
337
Time
X 1
TM
4/8
✱
6
623
Time
Code
O 1
ID
2
✱
7
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
TQ
Tracer Action Request 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: Submitter Trace Number
  1. This is the submitter assigned trace identifier related to this action request, and is a unique value within the sender/receiver relationship. This must be returned in the response, unaltered.
  2. Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
369
Free-form Description
X 1
AN
1/45
Not Used
4
373
Date
O 1
DT
8
Not Used
5
337
Time
X 1
TM
4/8
Not Used
6
623
Time Code
O 1
ID
2
Not Used
7
C040
Reference Identifier
O 1

N9*F8 - PROVIDER TRACE NUMBER

X12 Name:
Extended Reference Information
X12 Purpose:
To transmit identifying information as specified by the Reference Identification Qualifier
X12 Syntax:
  1. R0203
    At least one of N902 or N903 is required.
  2. C0605
    If N906 is present, then N905 is required.
Loop:
Loop 1220 - TRANSACTION REQUEST DETAIL
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
N9✱F8✱835-12345~
N9
✱
1
128
Reference
Ident Qual
M 1
ID
2/3
✱
2
127
Reference
Ident
X 1
AN
1/80
✱
3
369
Free-Form
Description
X 1
AN
1/45
✱
4
373
Date
O 1
DT
8
✱
5
337
Time
X 1
TM
4/8
✱
6
623
Time
Code
O 1
ID
2
✱
7
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
F8
Original Reference 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: Provider Trace Number
  1. This is the Provider's assigned trace identifier related to this action request, and is a unique value within the Provider/Payer relationship. This must be returned in the response, unaltered.
  2. Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
Not Used
3
369
Free-form Description
X 1
AN
1/45
Not Used
4
373
Date
O 1
DT
8
Not Used
5
337
Time
X 1
TM
4/8
Not Used
6
623
Time Code
O 1
ID
2
Not Used
7
C040
Reference Identifier
O 1

SE - TRANSACTION SET TRAILER

X12 Name:
Transaction Set Trailer
X12 Purpose:
To indicate the end of the transaction set and provide the count of the transmitted segments (including the beginning (ST) and ending (SE) segments)
X12 Comments:
SE is the last segment of each transaction set.
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
SE✱50✱0001~
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

838 Provider Enrollment for EDI Services (008020X305)

SEPTEMBER 2021

Copyright © 2021, X12 Incorporated, Format © 2021 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 Provider Enrollment for EDI Services Technical Report Type 3 describes the use of the X12 Trading Partner Profile (838) transaction set, version 0008020 for the following business usage:

  • Request and respond to requests for enrollment to conduct electronic data interchange services (including but not limited to the exchange of transactions mandated under HIPAA), as well as to update provider or agent information.
  • The Provider Enrollment for EDI Services will facilitate the transition when trading partners move from paper to electronic services.

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 standardized exchange is to eliminate challenges with redundancies and to reduce costs of Provider Electronic Data Interchange (EDI) Enrollment. The main benefit of introducing an electronic method to replace the current manual process is streamlining EDI enrollment requests and responses. This is accomplished by standardizing the information and requirements for enrollments. This document will not describe the internal payer process once the exchange is received, but does describe the required response.

To facilitate a smooth transition into the EDI environment, uniform implementation is critical. In order to achieve the potential administrative cost savings with EDI, standards have been developed and work optimally when implemented consistently by all organizations. Currently the enrollment process used in EDI services is proprietary, manual, and varies greatly. The manual processes often cause problems downstream and adversely impact business operations for all industry trading partners. There are many opportunities for improvement. By automating the enrollment process to conduct electronic data interchange services, the process is expedited, becomes standardized and reduces the number of potential errors. This transaction will help increase trading partner satisfaction and efficiency and minimize manual rework.

The scope for EDI enrollment includes, but is not limited to, the exchange of transactions mandated under HIPAA. This transaction will address provider EDI enrollment exclusively. The credentialing or contracting with health plans, frequently referred to as "provider enrollment", is out of scope.

As of this publication, this transaction supports enrollment for all X12 transactions (including those mandated under HIPAA) as well elements to support enrollment for Electronic Funds Transfer (EFT) transactions.

Benefits of this transaction include:

  • Standardization – Currently, disparate forms and information requirements are in place for EDI enrollment depending upon the requested transaction. Development of a single enrollment transaction will provide a single, standardized data set for all EDI enrollment and enrollment management activities.
  • Error reduction – The introduction of an electronic transaction that can be integrated into downstream systems will reduce manual workflows and errors. The reduction of manually completed forms will also help to mitigate the incidence of illegible forms or handwriting.
  • Simplified updates – On-going updates and enrollment modifications for providers can be managed electronically.
  • Paperwork reduction – The multiple paper forms related to new requests, updates, and deletions to existing Trading Partner information will no longer be necessary.
  • Reduced Resource Requirements – The cost and resources to support multiple manual processes currently in place can be allocated elsewhere.
  • Leverages existing standardization efforts – The transaction will contain data elements currently identified with federal and other state mandated regulatory initiatives.
  • Scalability – With the introduction of an electronic transaction, greater amounts of data can be exchanged efficiently and expeditiously.
  • Upfront data requirements – As with other EDI transactions, the identification of required data is clearly defined. This ensures completeness of the required data elements and a reduction of rework.
  • Storage – Electronic transactions eliminate the need for physical storage space. Transactions will be stored electronically and as a result they become more accessible to employees.

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 008020X305.

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

  • TD  Trading Partner Profile (838)

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

This transaction assumes that any contractual relationship and connectivity requirements have been established according to the business needs of the participating entities.

1.4 Business Usage

This transaction supports trading partners and may include, but is not limited to:

  • Individual providers, clinicians, groups of individuals, laboratories, pharmacies, institutions, facilities, NPI eligible and atypical providers
  • Health Plans (payers)
  • Health Information Exchange (HIE), Health Insurance Exchange (HIX)
  • Property and Casualty Payers and associated entities
  • Agents, e.g., clearinghouses, billing services, vendors

The transaction is designed to support the data necessary for a payer to initiate the processing of an EDI enrollment and to communicate the status of that process back to the submitter. This transaction supports enrollment in all provider and payer transactions, including but not limited to those, listed in Section 1.4.1 - Health Care Transaction Flow after the transactions for EDI enrollment, and excluding Post Adjudication.

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.4.2 General Business Flow

The enrollment request and response identifies four parties:

  • Payer – the entity that is being asked to take the action about the Electronic Data Interchange (EDI) transaction relationship and is identified in loop 1100B when the payer is the receiver (N101 = PR) or in loop 1210B when the payer is not the receiver.
  • Provider – the entity (identified in loop 1100C) that initiates the action about the EDI transaction relationship with a payer.
  • Receiver – the entity (identified in loop 1100B) that is receiving the action request or responding to the action request. The receiver may be a payer, or a business associate of either the payer or provider, such as a clearinghouse or vendor.
  • Submitter – the entity (identified in loop 1100A) that sends the action request and receives the answer to the action request. The submitter may be a provider, or a business associate of either the payer or provider, such as a clearinghouse or vendor.

One transaction set (ST-SE) can involve only one provider, submitter and receiver. A new transaction set is required, for instance, to identify a separate provider. However, one transaction set can identify multiple payers and actions related to each payer, by use of multiple 1200 loops. One enrollment request is contained in each 1220 loop, and can be an action to add, change, delete or verify a request/response.

When the provider/facility is a professional provider group, practice or health system (hospital) (reported in the 1100C loop along with their mailing address), individuals, clinics or facilities associated with that group are identified in the 1210A loop.

Other entities or locations identified include:

  • Provider Authorized Agent – the person that is authorized to enter into EDI relationships with intermediaries and payer (loop 1210D).
  • Financial Institution – the provider's financial institution for receipt of electronic funds transfers (loop 1210C).
  • Physical Address – the physical address of the provider when not the same as the provider's mailing address in loop 1100C (1210E).
  • Requesting Provider Address on File – within the response, the payer or receiver can supply a the provider address they have on file when the address for the provider within the payer's system is different than the address reported in the 1100C loop of the request (1100D).
  • Provider Software Vendor – the request will identify the vendor of software, version of the software, and (if applicable) product name (1210F) generating, communicating or consuming the requested EDI transaction(s). This information is present only when the provider uses commercial software to support the related transaction and the payer requires the information for on-boarding purposes.

1.4.3.1 Payer Business Requirements

This transaction supports an initial enrollment with either of the following methods:

Method 1
Initial EDI enrollment is done manually using paper with an original wet signature or web based with an electronic signature.

The transaction is then used for subsequent EDI enrollment requests to add, modify, verify, and delete EDI enrollment profiles.

Method 2
A Payer uses this standard to automate the entire Trading Partner (i.e., Clearinghouse, Billing Service, and Provider) EDI enrollment process that includes initial and subsequent enrollment activities.

1.4.3.2 Provider Business Requirements

This transaction supports an EDI enrollment with the following method:

A provider and their technology vendors (i.e., Clearinghouse, Billing Service and Practice Management Systems) use this transaction to request additions, modifications, verification of existing data, and cancellation of EDI enrollment profiles to one or more payers.

1.4.3.3 Clearinghouse Business Requirements

This transaction supports an EDI enrollment with either of the following methods:

Method 1
A clearinghouse will send an EDI enrollment transaction directly to one payer to successfully enroll one or more providers with requested payer. Separate EDI Enrollment Transactions will go to separate payers.

Method 2
A clearinghouse will send an EDI enrollment transaction through one or more trading partners (clearinghouse, HIE, etc.) to one or more payers in order to successfully enroll one provider.

1.4.4 Workflow Diagrams

While multiple requests can be sent in a single file, each enrollment request must be uniquely identified by a trace number. This ensures that each transaction can be received, acted upon and traced independently of others. Because there is no central repository of unique transaction IDs, each party must ensure that they assign a unique transaction ID between the two parties. To facilitate point to point and end to end communication, each request transaction sent will contain the sender's unique trace ID and each response will contain the request sender's unique trace ID as well as the receiver's unique trace ID. In addition to the point to point unique sender/receiver trace IDs, the transaction requires an end to end set of unique trace IDs: a Provider trace ID sent all the way to the Enrolling Payer and a Payer trace ID to be sent back to the Provider independent on the number of intermediaries involved. An overview of the trace numbers involved in a multiple intermediary scenario is below. Additionally, each workflow documented below shows the trace ID flow.

Trace ID Overview

Request Sender (Transactions flow from Left to Right)

Originating Party (send to clearinghouse CH1)

CH1 (send to clearinghouse CH2)

CH2 (send to clearinghouse CH3)

CH3 (send to Enrollment Processing Party)

Enrollment Processing Party (Generally Payer)

Provider Trace Number

N9*F8*Prov123~

N9*F8*Prov123~

N9*F8*Prov123~

N9*F8*Prov123~

Payer Stores Value

CH1 Trace Number

 

N9*TQ*CH1-00001~

 

 

 

Ch2 Trace Number

 

 

N9*TQ*CH2-10002~

 

 

CH3 Trace Number

 

 

 

N9*TQ*CH3-30015~

Payer Stores Value

Enrollment Processing Party TRN

          

 

Respose Sender (Transactions flow from Right to Left)

Originating Party (Receive from clearinghouse CH1)

CH1 (Receive from clearinghouse CH2)

CH2 (Receive from clearinghouse CH3)

CH3 (Receive from Enrollment Processing Party)

Enrollment Processing Party (Generally Payer)

Provider Trace Number

 

N9*F8*Prov123~

N9*F8*Prov123~

N9*F8*Prov123~

N9*F8*Prov123~

CH1 Trace Number

Provider Stores Value

N9*2H*CH1-00001~

N9*TQ*CH1-00001~

 

 

Ch2 Trace Number

 

 

N9*2H*CH2-10002~

N9*TQ*CH2-10002~

 

CH3 Trace Number

 

 

 

N9*2H*CH3-30015~

N9*TQ*CH3-30015~

Enrollment Processing Party TRN

Provider Stores Value

N9*2I*322225~

N9*2I*322225~

N9*2I*322225~

N9*2I*322225~

1.4.4.1 Direct To Payer Submission

ACTORS (ROLE): Provider/Third Party Agent (Submitter), Payer (Receiver)

REQUEST ACTIONS: Add, Modify, Delete or Verify EDI services

The diagram below represents the provider/third party agent on behalf of a provider sending the EDI enrollment request to a payer. A response can be sent back from the payer to the provider/third party agent indicating the status of the request, which may include effective date to begin exchanging the new transaction, or when a modification will be completed. Multiple responses can be provided throughout the process to identify the current state of the request until completed.

Figure 1.1 - Accepted Transaction

Accepted Transaction

IDs in Transaction Flows (Direct Provider to Payer)

Provider Sends Request with

N9*F8*Prov123~

Payer Sends Receipt Response

N9*F8*Prov123~
N9*2I*322225~

1.4.4.2 Request Through Single Intermediary Submissions

ACTORS (ROLE): Provider/Third Party Agent (Submitter), Intermediary(s) (Receiver/Submitter), Payer(s) (Receiver)

REQUEST ACTIONS: Add, Modify, Delete or Verify EDI services

The diagram below represents the provider/third party agent on behalf of a provider sending an EDI enrollment request to the payer through one intermediary (third party network, clearinghouse, exchange). Multiple responses can be provided throughout the process to identify the current state of the request until completed. Responses may include an acknowledgment (as identified in section 1.6) or the 838 EDI Enrollment Response.

Figure 1.2 - Request Through Single Intermediary Submission

Request Through Single Intermediary Submission, Add transaction from Receiver Submitter an acknowledgement 838

IDs in Transaction Flows (1 Intermediary)

Provider Sends Request with

N9*F8*Prov123~

ClearingHouse 1 Sends Response

N9*F8*Prov123~
N9*2H*CH1-00001~

ClearingHouse 1 Sends Request

N9*F8*Prov123~
N9*TQ*CH1-00001~

Payer Sends Receipt Response

N9*F8*Prov123~
N9*TQ*CH1-00001~
N9*2I*322225~

ClearingHouse 1 Sends Response

N9*F8*Prov123~
N9*2H*CH1-00001~
N9*2I*322225~

1.4.4.3. Request Through Multiple Intermediary Submissions

ACTORS (ROLE): Provider/Third Party Agent (Submitter), Intermediary(s) (Receiver/Submitter), Payer(s) (Receiver)

REQUEST ACTIONS: Add, Modify, Delete or Verify EDI services

The diagram below represents the provider/third party agent on behalf of the provider sending an EDI enrollment request to the payer through multiple intermediaries (third party network, clearinghouse, exchange). Responses can be sent back from the payer to the provider/third party agent through these intermediaries indicating the status of the request which may include the effective date to begin exchanging the new transaction, or when a modification will be completed. Multiple responses for each request can be provided throughout the process to identify the current state of the request until completed.

Figure 1.3 - Request Through Multiple Intermediaries

Request Through Multiple Intermediaries

IDs in Transaction Flows (3 Intermediaries)

Provider Sends Request with

N9*F8*Prov123~

ClearingHouse 1 Sends Response

N9*F8*Prov123~
N9*2H*CH1-00001~

ClearingHouse 1 Sends Request

N9*F8*Prov123~
N9*TQ*CH1-00001~

ClearingHouse 2 Sends Response

N9*F8*Prov123~
N9*2H*CH2-10002~

ClearingHouse 2 Sends Request

N9*F8*Prov123~
N9*TQ*CH2-10002~

ClearingHouse 3 Sends Response

N9*F8*Prov123~
N9*2H*CH3-30015~

ClearingHouse 3 Sends Request

N9*F8*Prov123~
N9*TQ*CH3-30015~

Payer Sends Receipt Response

N9*F8*Prov123~
N9*TQ*CH3-30015~
N9*2I*322225~

ClearingHouse 3 Sends Response

N9*F8*Prov123~
N9*TQ*CH2-10002~
N9*2H*CH3-30015~
N9*2I*322225~

ClearingHouse 2 Sends Response

N9*F8*Prov123~
N9*TQ*CH1-00001~
N9*2H*CH2-10002~
N9*2I*322225~

ClearingHouse 1 Sends Response

N9*F8*Prov123~
N9*2H*CH1-00001~
N9*2I*322225~

1.4.5 Requests

A request is a particular provider application to add, change, verify, or delete EDI enrollment in a specific EDI transaction with a payer. Responses will be at the request level and each request will have at least one response returned.

The request is capable of requesting EDI or EFT transactions in both test and production environments. There are four types of actions possible:

ADD – Use to request a new service (transaction and version specific).

CHANGE – Use to modify details of an existing service. For example,

  • Changing bank accounts or banks for EFT
  • Changing sender/receiver identifiers
  • Changing environment (for example, Test to Production) of existing enrollment record

DELETE – Use to cancel an existing service (transaction and version specific in test or production)

VERIFY – Use to confirm the current status of a provider and their associated enrollment transaction information.

1.4.6. Responses

A response is a status from the receiver to the sender on the state of the request. Each response will correspond to a single request and each request will have at least one response returned.

This guide supports a variety of 838 responses including, but not limited, to the following:

  • An acknowledgment of receipt of a request from receiver to a sender
  • A detailed receipt of the transaction request and the results of the request
  • Verification of Provider enrollment status
  • Instructions on how to follow up completion of the request
  • Approval of request
  • Disapproval of request
  • Request is pended
  • Detailed information related to the request, such as:
    • Payer contact information
    • Effective date
    • Website address
    • Provider/Submitter Trace Number - sent in the request/returned in response
    • Payer Assigned Trace Number - returned in the response and any future correspondence
    • Receiver Assigned Trace Number - Identity used to uniquely identify the transaction at an Intermediary
    • Return the Sender ID to use in ISA and GS elements at a per transaction level
    • Incomplete Information Received
    • Environment (test or production)
    • Support for the requested transaction
    • Messaging to support disapproved request
    • Whether or not there will be subsequent electronic responses related to the original request

1.4.7. Response Combinations

The response to an enrollment add, change or delete request uses multiple elements in order to convey the complete message. Different values apply depending upon the type of request, as well as the status of the response. The following table identifies these parts and what values/combinations are appropriate for the most basic business situations, and what they mean. Support by payers and intermediaries for these four response combinations is required. Section 1.10.1 provides optional responses that may be used between trading partners when agreed upon.

Note – rows in this table relate to a specific business function used in a specific mode – i.e., in production send, or in test receive – and within the constraints established by the identifiers provided in TXN06 and TXN07, when present.

Table 1.1 - Minimum Required Response Combinations

Response Scenario

Requested Action (TXN01)

Response (TXN01)

Response (TXN05)

Pended Request – the request action has been pended by the receiver of the request.

ALL

A4 - Pended

86 - Pended for Follow Up

Approved - the request has been approved for production as described, effective on the date in TXN08.

ALL

11 - Approve

K - In Production Send and Receive

8 – In Production Send

R – In Production Receive

Rejected - the request has been rejected due to lack of necessary information. The information needed is identified in the text of N903 when N901=7G.

ALL

21 – Disapprove

U - Reject

Inability to accept for processing due to the lack of required information

Confirmed – the verify request has been confirmed. Any difference in provider information is identified in loop 1100D of the response.

Verify

CF- Confirmed

CL – Closed

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 is no direct relationship between this transaction and other EDI transactions. This transaction is used to support enrollment processes for other EDI transactions.

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.1. Optional Response Combinations

The response to an enrollment add, change or cancel request uses multiple elements in order to convey the complete message. Different values apply depending upon the type of request, as well as the status of the response. The following table identifies these parts and what values/combinations are appropriate for the most basic business situations, and what they mean. Note – rows in this table relate to a specific business function used in a specific mode – i.e. in production send, or in test receive – and within the constraints established by the identifiers provided in TXN06 and TXN07, when present. These optional responses are not an exhaustive list of response combinations. Trading partners are free to use these or any combination of codes which support business needs.

Table 1.2 - Optional Response Combinations

Response Scenario

Requested Action (TXN01)

Response Transaction Type Code BTP05

Response TXN01

Response TXN05

Pended Request – action pending by the receiver of the request. Further responses are expected.

ALL

19 - Response - Further Updates to Follow

A4 - Pended

86 - Pended for Follow Up

Pended Request – action pending by another intermediary between the receiver and the payer for the request. Further responses are expected.

ALL

19 - Response - Further Updates to Follow

A4 - Pended

DC - Delivered to Another Carrier

Pended Request – action pended by payer, who is not the initial receiver of the request. Further responses are expected.

ALL

19 - Response - Further Updates to Follow

A4 - Pended

23 - Escalation

The request has been approved for production as described, effective on the date in TXN08.

ALL

18 - Response - No Further Updates to Follow

11 - Approve

8 – In Production Send

K - In Production Send and Receive

R – In Production Receive

The request has been approved for test as described, effective on the date in TXN08.

ALL

18 - Response - No Further Updates to Follow

11 - Approve

O - In Test/Send

P - In Test/Receive

Q - In Test/Send and Receive

The request has been rejected due to lack of necessary information. The information needed is identified in the text of N903 when N901=7G.

ALL

18 - Response - No Further Updates to Follow

21 – Disapprove

U - Reject

Inability to accept for processing due to the lack of required information

Pended Request – action pending by the receiver (who is not the payer). There is a problem as described in the Response Status that must be resolved by phone call to the receiver.

ALL

19 - Response - Further Updates to Follow

A4 - Pended

88 - Contact via Telephone Call

Pended Request – action pending by the payer. There is a problem as described in the Response Status that must be resolved by phone call to the payer.

ALL

19 - Response - Further Updates to Follow

A4 - Pended

CT - Contact Payer

The receiver is not currently able to support the request and is in development. Support is expected by the date in TXN08, and additional responses will be forth coming.

1 – ADD

2 - Change

19 - Response - Further Updates to Follow

A4 - Pended

L - In Development/Send

M - In Development/Receive

N - In Development/Send and Receive

The payer (who is not the receiver) is not currently able to support the request and is in development. Support is expected by the date in TXN08. No further action is expected. Resubmit after the date in TXN08.

1 – ADD

2 - Change

18 - Response - No Further Updates to Follow

21 - Disapprove

L - In Development/Send

M - In Development/Receive

N - In Development/Send and Receive

The action can't be completed by the receiver since the related transaction is not currently active between the sender and receiver. This only applies when the sender and receiver aren't the provider and the health plan.

2 - Change

3 - Delete

18 - Response - No Further Updates to Follow

21 - Disapprove

9 - Not Capable of Taking Action

The action can't be completed by the receiver since the related transaction is not currently active between the provider and the payer, and this request has been rejected by the payer.

2 - Change

3 - Delete

18 - Response - No Further Updates to Follow

21 - Disapprove

CL - Closed

The request has been rejected by the payer since there is no supporting business relationship between the provider and the payer – i.e. an institutional claim is being requested for a professional provider, or an EFT is being requested for a provider that doesn't get paid by the payer.

1 - ADD

18 - Response - No Further Updates to Follow

21 - Disapprove

58 - Not Justified

The payer rejects a request for addition of production services without the provider first running in test mode. Any specific test criteria are identified or linked to the N9 response status text.

1 - ADD

19 - Response - Further Updates to Follow

21 - Disapprove

CL - Closed

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 X12 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 is the first version of the Provider Enrollment for EDI Services Implementation Guide. No change summary is included.