275 Transaction Set Listing

006020X316 Additional Information to Support a Health Care Services Review
Usage
Repeats

ISA - INTERCHANGE CONTROL HEADER

X12 Name:
Interchange Control Header
X12 Purpose:
To start and identify an interchange of zero or more functional groups and interchange-related control segments
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
  1. All positions within each of the data elements must be filled.
  2. For compliant implementations under this implementation guide, ISA13, the interchange Control Number, must be a positive unsigned number. Therefore, the ISA segment can be considered a fixed record length segment.
  3. The first element separator defines the element separator to be used through the entire interchange.
  4. The ISA segment terminator defines the segment terminator used throughout the entire interchange.
  5. Spaces in the example interchanges are represented by "." for clarity.
TR3 Example:
ISA✱00✱..........✱01✱SECRET....✱ZZ✱SUBMITTERS.ID..✱ZZ✱RECEIVERS.ID...✱030101✱1253✱^✱00602✱000000905✱0✱T✱:~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
I01
Authorization Information Qualifier
M 1
ID
2
Code identifying the type of information in the Authorization Information
CODE
DEFINITION
00
No Authorization Information Present (No Meaningful Information in I02)
03
Additional Data Identification
Required
2
I02
Authorization Information
M 1
AN
10
Information used for additional identification or authorization of the interchange sender or the data in the interchange; the type of information is set by the Authorization Information Qualifier (I01)
Required
3
I03
Security Information Qualifier
M 1
ID
2
Code identifying the type of information in the Security Information
CODE
DEFINITION
00
No Security Information Present (No Meaningful Information in I04)
01
Password
Required
4
I04
Security Information
M 1
AN
10
This is used for identifying the security information about the interchange sender or the data in the interchange; the type of information is set by the Security Information Qualifier (I03)
Required
5
I05
Interchange ID Qualifier
M 1
ID
2
Code indicating the system/method of code structure used to designate the sender or receiver ID element being qualified
This ID qualifies the Sender in ISA06.
CODE
DEFINITION
01
Duns (Dun & Bradstreet)
14
Duns Plus Suffix
20
Health Industry Number (HIN)
CODE SOURCE: 121: Health Industry Number
27
Carrier Identification Number as assigned by 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
M 1
ID
5
Code specifying the version number of the interchange control segments
CODE
DEFINITION
00602
Standards Approved for Publication by ASC X12 Procedures Review Board through October 2009
Required
13
I12
Interchange Control Number
M 1
N
9
A control number assigned by the interchange sender
  1. The Interchange Control Number, ISA13, must be identical to the associated Interchange Trailer IEA02.
  2. Must be a positive unsigned number and must be identical to the value in IEA02.
Required
14
I13
Acknowledgment Requested
M 1
ID
1
Code indicating sender's request for an interchange acknowledgment
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
1
Interchange Acknowledgment Requested (TA1)
Required
15
I14
Interchange Usage Indicator
M 1
ID
1
Code indicating whether data enclosed by this interchange envelope is test, production or information
CODE
DEFINITION
P
Production Data
T
Test Data
Required
16
I15
Component Element Separator
M 1
Type is not applicable; the component element separator is a delimiter and not a data element; this field provides the delimiter used to separate component data elements within a composite data structure; this value must be different than the data element separator and the segment terminator

GS*PI - 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✱006020X315~
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
PI
Patient Information (275)
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
006020X316
Additional Information to Support a Health Care Services Review

ST*275 - 275 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
FHIR Mapping:
The data elements in this segment are not defined in the PAS Bundle profile because the values are hardcoded or derived.
Implement with version: STU 1.0.0
TR3 Example:
ST✱275✱1234✱006020X316~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
143
Transaction Set Identifier Code
M 1
ID
3
Code uniquely identifying a Transaction Set
SEMANTIC: The transaction set identifier (ST01) is used by the translation routines of the interchange partners to select the appropriate transaction set definition (e.g., 810 selects the Invoice Transaction Set).
FHIR Mapping: '275'
Implement with version: STU 1.0.0
Use this code to identify the transaction set ID for the transaction set that will follow the ST segment. Each X12 standard has a transaction set identifier code that is unique to that transaction set.
CODE
DEFINITION
275
Patient Information
Required
2
329
Transaction Set Control Number
M 1
AN
4/9
Identifying control number that must be unique within the transaction set functional group assigned by the originator for a transaction set
The Transaction Set Control Numbers in ST02 and SE02 must be identical and must be a numeric value. The number (i.e. numeric value) is assigned by the originator and must be unique within a functional group (GS-GE). For example, start with the numeric value 0001 and increment from there. The Transaction Set Control Number also aids in error resolution research.
Required
3
1705
Implementation Convention Reference
O 1
AN
1/35
Reference assigned to identify Implementation Convention
SEMANTIC: The implementation convention reference (ST03) is used by the translation routines of the interchange partners to select the appropriate implementation convention to match the transaction set definition. When used, this implementation convention reference takes precedence over the implementation reference specified in the GS08.
FHIR Mapping: '006020X316'
Implement with version: STU 1.0.0
INDUSTRY NAME: Implementation Convention Reference Identifier
This field contains the same value as GS08. Some translator products strip off the ISA and GS segments prior to application (ST-SE) processing. Providing the information from the GS08 at this level will ensure that the appropriate application mapping is utilized at translation time.
CODE
DEFINITION
006020X316
Additional Information to Support a Health Care Services Review

BGN - BEGINNING SEGMENT

X12 Name:
Beginning Segment
X12 Purpose:
To indicate the beginning of a transaction set
X12 Syntax:
C0504
If BGN05 is present, then BGN04 is required.
Segment Usage:
Required
Segment Repeat:
1
FHIR Mapping:
The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
TR3 Example:
BGN✱11✱123456✱20111001✱0632~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
353
Transaction Set Purpose Code
M 1
ID
2
Code identifying purpose of transaction set
FHIR Mapping: '22'
Information Copy for 278 Health Care Services Review Notification
Implement with version: STU 1.0.0
CODE
DEFINITION
02
Add
Use when submitting an unsolicited attachment.
11
Response
Use when submitting this 275 in response to a 278 Health Care Services Review Response that contains a request for additional information.
22
Information Copy
Use when submitting an unsolicited attachment for a 278 Health Care Services Review Notification.
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: BGN02 is the transaction set reference number.
FHIR Mapping: Bundle.identifier.value
Implement with version: STU 1.0.0
INDUSTRY NAME: Transaction Set Reference Number
  1. The originator of the transaction set assigns the unique reference number in BGN02 and the date of creation in BGN03.
  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: BGN03 is the transaction set date.
FHIR Mapping: Bundle.timestamp
Extract the date portion of the Bundle.timestamp to populate BGN03
Implement with version: STU 1.0.0
INDUSTRY NAME: Transaction Set Creation Date
Required
4
337
Time
X 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: BGN04 is the transaction set time.
FHIR Mapping: Bundle.timestamp
Extract the date portion of the Bundle.timestamp to populate BGN04
Implement with version: STU 1.0.0
SEGMENT SYNTAX: C0504
INDUSTRY NAME: Transaction Set Creation Time
Not Used
5
623
Time Code
O 1
ID
2
Not Used
6
127
Reference Identification
O 1
AN
1/80
Not Used
7
640
Transaction Type Code
O 1
ID
2
Not Used
8
306
Action Code
O 1
ID
1/2
Not Used
9
786
Security Level Code
O 1
ID
2

NM1*ACV - INFORMATION SOURCE NAME

X12 Name:
Individual or Organizational Name
X12 Purpose:
To supply the full name of an individual or organizational entity
X12 Syntax:
  1. P0809
    If either NM108 or NM109 is present, then the other is required.
  2. C1110
    If NM111 is present, then NM110 is required.
  3. C1203
    If NM112 is present, then NM103 is required.
X12 Set Notes:
NOTE: Loop NM1 identifies a single patient; it also identifies other entities or individuals which include the requester, responder or other organizations.
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
  1. Use this NM1 loop to identify the source of the additional information, that is, the creator and sender of the 275.
  2. When BGN01 = 02 or 22, this NM1 loop identifies the person or organization that initiated providing this patient information.
FHIR Mapping:
Claim.provider => Organization
The Claim.provider will point to a Organization in the Bundle. Locate the Organization pointed at in the Claim and use that Organization for all of the fields in the 2010B Loop
Implement with version: STU 1.0.0
TR3 Example:
NM1✱ACV✱2✱HOLLY HILLS HOSPITAL✱✱✱✱✱XX✱1234567089✱67✱FA~
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
FHIR Mapping: 'ACV'
Implement with version: STU 1.0.0
CODE
DEFINITION
ACV
Information Source
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code qualifying the type of entity
SEMANTIC: NM102 qualifies NM103.
FHIR Mapping: '2'
Implement with version: STU 1.0.0
CODE
DEFINITION
1
Person
2
Non-Person Entity
Required
3
1035
Name Last or Organization Name
X 1
AN
1/60
Individual last name or organizational name
FHIR Mapping: Organization.name
Implement with version: STU 1.0.0
SEGMENT SYNTAX: C1203
INDUSTRY NAME: Information Source Last or Organization Name
Situational
4
1036
Name First
O 1
AN
1/35
Individual first name
FHIR Mapping: no value - not populated from FHIR Bundle
Implement with version: STU 1.0.0
SITUATIONAL RULE: Required when the person has a first name. If not required by this implementation guide, do not send.
INDUSTRY NAME: Information Source First Name
Situational
5
1037
Name Middle
O 1
AN
1/25
Individual middle name or initial
FHIR Mapping: no value - not populated from FHIR Bundle
Implement with version: STU 1.0.0
SITUATIONAL RULE: Required when the middle name or initial of the person is needed to identify the individual. If not required by this implementation guide, do not send.
INDUSTRY NAME: Information Source Middle Name
Not Used
6
1038
Name Prefix
O 1
AN
1/10
Situational
7
1039
Name Suffix
O 1
AN
1/10
Suffix to individual name
FHIR Mapping: no value - not populated from FHIR Bundle
Implement with version: STU 1.0.0
SITUATIONAL RULE: Required when the name suffix is needed to identify the individual. If not required by this implementation guide, do not send.
INDUSTRY NAME: Information Source Name Suffix
Required
8
66
Identification Code Qualifier
X 1
ID
1/2
Code designating the system/method of code structure used for Identification Code (67)
FHIR Mapping: 'XX'
Implement with version: STU 1.0.0
SEGMENT SYNTAX: P0809
CODE
DEFINITION
24
Employer's Identification Number
34
Social Security Number
46
Electronic Transmitter Identification Number (ETIN)
PI
Payor Identification
Use when UMO is a payer and XV is not used.
XV
Centers for Medicare and Medicaid Services PlanID
Use when reporting Health Plan ID (HPID) or Other Entity Identifier (OEID).
CODE SOURCE: 540: Centers for Medicare and Medicaid Services PlanID
XX
Centers for Medicare and Medicaid Services National Provider Identifier
CODE SOURCE: 537: Centers for Medicare & Medicaid Services National Provider Identifier
Required
9
67
Identification Code
X 1
AN
2/80
Code identifying a party or other code
FHIR Mapping: Organization.identifier[0].value
Implement with version: STU 1.0.0
SEGMENT SYNTAX: P0809
INDUSTRY NAME: Information Source Identifier
Required
10
706
Entity Relationship Code
X 1
ID
2
Code describing entity relationship
COMMENT: NM110 and NM111 further define the type of entity in NM101.
FHIR Mapping: '67'
Implement with version: STU 1.0.0
SEGMENT SYNTAX: C1110
CODE
DEFINITION
67
Self
Required
11
98
Entity Identifier Code
O 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
FHIR Mapping: '1P'
Implement with version: STU 1.0.0
SEGMENT SYNTAX: C1110
CODE
DEFINITION
1P
Provider
2B
Third-Party Administrator
36
Employer
FA
Facility
PR
Payer
X3
Utilization Management Organization
Not Used
12
1035
Name Last or Organization Name
O 1
AN
1/60

PER*IC - INFORMATION SOURCE 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 Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when BGN01=02 or BGN01=22 and the name of the individual to contact is different than the name within the prior name segment (i.e., NM1). Required when BGN01 = 11 and the information source wants to direct further contacts to a designated site. If not required by this implementation guide, do not send.
TR3 Notes:
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-".
FHIR Mapping:
The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
TR3 Example:
PER✱IC✱MEDICAL RECORDS DEPARTMENT✱TE✱5342242525~
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
FHIR Mapping: 'IC'
Implement with version: STU 1.0.0
CODE
DEFINITION
IC
Information Contact
Required
2
93
Name
O 1
AN
1/60
Free-form name
FHIR Mapping: Organization.contact[0].name
Implement with version: STU 1.0.0
INDUSTRY NAME: Information Source Contact Name
Required
3
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
FHIR Mapping: Organization.contact[0].telecom[0].system
The value from the system attribute is translated as follows:
'phone' -> 'TE'
'fax' -> 'FX'
'email' -> 'EM'
'pager' -> 'TE'
'url' -> 'UR'
'sms' -> 'TE'
'other' -> cannot be translated
Implement with version: STU 1.0.0
SEGMENT SYNTAX: P0304
CODE
DEFINITION
EM
Electronic Mail
FX
Facsimile
TE
Telephone
Required
4
364
Communication Number
X 1
AN
1/256
Complete communications number including country or area code when applicable
FHIR Mapping: Organization.contact[0].telecom[0].value
If the value of system is 'phone', this value must be parsed to determine if an extension is present (see ITU-T E.123 for format of telephone values). If an extension is present, the remove the extension part of the phone number and place in PER06 and set PER05 to 'EX'
Implement with version: STU 1.0.0
SEGMENT SYNTAX: P0304
INDUSTRY NAME: Information Source Contact Communication Number
Situational
5
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
FHIR Mapping: Organization.contact[0].telecom[1].system | 'EX'
See PER04 if PER03 is 'TE' otherwise select the next telecom in contact[0] and translate the system as follows:
'phone' -> 'TE'
'fax' -> 'FX'
'email' -> 'EM'
'pager' -> 'TE'
'url' -> 'UR'
'sms' -> 'TE'
'other' -> cannot be translated
Implement with version: STU 1.0.0
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when an additional type of communications number is available. If not required by this implementation guide, do not send.
CODE
DEFINITION
EM
Electronic Mail
EX
Telephone Extension
FX
Facsimile
TE
Telephone
Situational
6
364
Communication Number
X 1
AN
1/256
Complete communications number including country or area code when applicable
FHIR Mapping: Organization.contact[0].telecom[1].value | extracted extension
If PER05 is set to 'EX' this will be the extract value for the extension from PER04
Otherwise this is refer to PER04 for rules on formatting
Implement with version: STU 1.0.0
SEGMENT SYNTAX: P0506
SITUATIONAL RULE: Required when an additional type of communications number is available. If not required by this implementation guide, do not send.
INDUSTRY NAME: Information Source Contact Communication Number
Situational
7
365
Communication Number Qualifier
X 1
ID
2
Code identifying the type of communication number
FHIR Mapping: Organization.contact[0].telecom[n].system | 'EX'
See PER06 if PER05 is 'TE' otherwise select the next telecom in contact[0] and translate the system as follows:
'phone' -> 'TE'
'fax' -> 'FX'
'email' -> 'EM'
'pager' -> 'TE'
'url' -> 'UR'
'sms' -> 'TE'
'other' -> cannot be translated
Implement with version: STU 1.0.0
SEGMENT SYNTAX: P0708
SITUATIONAL RULE: Required when an additional type of communications number is available. If not required by this implementation guide, do not send.
CODE
DEFINITION
EM
Electronic Mail
EX
Telephone Extension
FX
Facsimile
TE
Telephone
Situational
8
364
Communication Number
X 1
AN
1/256
Complete communications number including country or area code when applicable
FHIR Mapping: Organization.contact[0].telecom[n].value | extracted extension
If PER07 is set to 'EX' this will be the extract value for the extension from PER06
Otherwise this is refer to PER04 for rules on formatting
Implement with version: STU 1.0.0
SEGMENT SYNTAX: P0708
SITUATIONAL RULE: Required when an additional type of communications number is available. If not required by this implementation guide, do not send.
INDUSTRY NAME: Information Source Contact Communication Number
Not Used
9
443
Contact Inquiry Reference
O 1
AN
1/20

REF - INFORMATION SOURCE SECONDARY IDENTIFICATION

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when a secondary Identification number is necessary to identify the entity. The primary identification number should be reported in NM108/09 in this loop. If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.
TR3 Notes:
  1. If NPI is reported in NM109 of this loop then this REF segment is not used.
  2. If HPID or OEID is reported in NM109 of this loop then this REF segment is not used.
FHIR Mapping:
The data elements in this segment are not defined in the PAS Bundle profile.
Implement with version: STU 1.0.0
TR3 Example:
REF✱1J✱12345678~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
0B
State License Number
1A
Blue Cross Provider Number
1B
Blue Shield Provider Number
1C
Medicare Provider Number
1D
Medicaid Provider Number
1E
Dentist License Number
1G
Provider UPIN Number
1H
CHAMPUS Identification Number
1J
Facility ID Number
A6
Provider Identifier
B3
Preferred Provider Organization Number
BQ
Health Maintenance Organization Code Number
EI
Employer's Identification Number
FH
Clinic Number
G5
Provider Site Number
LU
Location Number
SY
Social Security Number
The Social Security Number may not be used for Medicare.
TJ
Federal Taxpayer's Identification Number
U3
Unique Supplier Identification Number (USIN)
X5
State Industrial Accident Provider 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 Secondary 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
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

NM1*40 - INFORMATION RECEIVER NAME

X12 Name:
Individual or Organizational Name
X12 Purpose:
To supply the full name of an individual or organizational entity
X12 Syntax:
  1. P0809
    If either NM108 or NM109 is present, then the other is required.
  2. C1110
    If NM111 is present, then NM110 is required.
  3. C1203
    If NM112 is present, then NM103 is required.
X12 Set Notes:
NOTE: Loop NM1 identifies a single patient; it also identifies other entities or individuals which include the requester, responder or other organizations.
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
Use this segment to identify the receiver of this 275 and supportive information. When BGN02 = 02 or 11 this is the UMO receiving the 275 supporting the 278 Health Care Services Review Request. When BGN02 = 22 it is the entity receiving the 278 Health Care Services Review Notification.
FHIR Mapping:
Claim.insurer => Organization
The Claim.insurer will point to a Organization in the Bundle. Locate the Organization pointed at in the Claim and use that Organization for all of the fields in the 2010A Loop
Implement with version: STU 1.0.0
TR3 Example:
NM1✱40✱2✱ABC UTILIZATION REVIEW COMPANY✱✱✱✱✱46✱123456789✱67✱X3~
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
FHIR Mapping: '40'
Implement with version: STU 1.0.0
CODE
DEFINITION
40
Receiver
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code qualifying the type of entity
SEMANTIC: NM102 qualifies NM103.
FHIR Mapping: '2'
Implement with version: STU 1.0.0
CODE
DEFINITION
1
Person
2
Non-Person Entity
Required
3
1035
Name Last or Organization Name
X 1
AN
1/60
Individual last name or organizational name
FHIR Mapping: Organization.name
Implement with version: STU 1.0.0
SEGMENT SYNTAX: C1203
INDUSTRY NAME: Information Receiver Last or Organization Name
Situational
4
1036
Name First
O 1
AN
1/35
Individual first name
FHIR Mapping: no value - not populated from FHIR Bundle
Implement with version: STU 1.0.0
SITUATIONAL RULE: Required when the person has a first name. If not required by this implementation guide, do not send.
INDUSTRY NAME: Information Receiver First Name
Situational
5
1037
Name Middle
O 1
AN
1/25
Individual middle name or initial
FHIR Mapping: no value - not populated from FHIR Bundle
Implement with version: STU 1.0.0
SITUATIONAL RULE: Required when the middle name or initial of the person is needed to identify the individual. If not required by this implementation guide, do not send.
INDUSTRY NAME: Information Receiver Middle Name
Not Used
6
1038
Name Prefix
O 1
AN
1/10
Situational
7
1039
Name Suffix
O 1
AN
1/10
Suffix to individual name
FHIR Mapping: no value - not populated from FHIR Bundle
Implement with version: STU 1.0.0
SITUATIONAL RULE: Required when the name suffix is needed to identify the individual. If not required by this implementation guide, do not send.
INDUSTRY NAME: Information Receiver Name Suffix
Required
8
66
Identification Code Qualifier
X 1
ID
1/2
Code designating the system/method of code structure used for Identification Code (67)
FHIR Mapping: Organization.identifier[0].type.coding[0].code
The value from the system attribute is translated as follows:
'46' -> '46'
'U' -> 'PI'
Implement with version: STU 1.1.0
SEGMENT SYNTAX: P0809
CODE
DEFINITION
24
Employer's Identification Number
34
Social Security Number
46
Electronic Transmitter Identification Number (ETIN)
PI
Payor Identification
Use when UMO is a payer and XV is not used.
XV
Centers for Medicare and Medicaid Services PlanID
Use when reporting Health Plan ID (HPID) or Other Entity Identifier (OEID).
CODE SOURCE: 540: Centers for Medicare and Medicaid Services PlanID
XX
Centers for Medicare and Medicaid Services National Provider Identifier
CODE SOURCE: 537: Centers for Medicare & Medicaid Services National Provider Identifier
Required
9
67
Identification Code
X 1
AN
2/80
Code identifying a party or other code
FHIR Mapping: Organization.identifier[0].value
Implement with version: STU 1.0.0
SEGMENT SYNTAX: P0809
INDUSTRY NAME: Information Receiver Identifier
Required
10
706
Entity Relationship Code
X 1
ID
2
Code describing entity relationship
COMMENT: NM110 and NM111 further define the type of entity in NM101.
FHIR Mapping: '67'
Implement with version: STU 1.0.0
SEGMENT SYNTAX: C1110
CODE
DEFINITION
67
Self
Required
11
98
Entity Identifier Code
O 1
ID
2/3
Code identifying an organizational entity, a physical location, property or an individual
FHIR Mapping: 'PR'
Implement with version: STU 1.0.0
SEGMENT SYNTAX: C1110
CODE
DEFINITION
1P
Provider
2B
Third-Party Administrator
36
Employer
FA
Facility
PR
Payer
X3
Utilization Management Organization
Not Used
12
1035
Name Last or Organization Name
O 1
AN
1/60

PER*IC - INFORMATION RECEIVER 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 Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the value in BGN01=11 and the Health Care Services Review 278 Response designates a specific contact for the return of the requested information. Required when the BGN01 = 02 or 22 and the specific contact is known to the source of the information. If not required by this implementation guide do not send.
FHIR Mapping:
The data elements in this segment are not defined in the PAS Bundle profile.
Implement with version: STU 1.0.0
TR3 Example:
PER✱IC✱MEDICAL REVIEW DEPARTMENT~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
366
Contact Function Code
M 1
ID
2
Code identifying the major duty or responsibility of the person or group named
CODE
DEFINITION
IC
Information Contact
Required
2
93
Name
O 1
AN
1/60
Free-form name
INDUSTRY NAME: Information Receiver Contact Name
Not Used
3
365
Communication Number Qualifier
X 1
ID
2
Not Used
4
364
Communication Number
X 1
AN
1/256
Not Used
5
365
Communication Number Qualifier
X 1
ID
2
Not Used
6
364
Communication Number
X 1
AN
1/256
Not Used
7
365
Communication Number Qualifier
X 1
ID
2
Not Used
8
364
Communication Number
X 1
AN
1/256
Not Used
9
443
Contact Inquiry Reference
O 1
AN
1/20

REF - INFORMATION RECEIVER SECONDARY IDENTIFICATION

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when a secondary Identification number is necessary to identify the entity. The primary identification number should be reported in NM108/09 in this loop. If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.
TR3 Notes:
  1. If NPI is reported in NM109 of this loop then this REF segment is not used.
  2. If HPID or OEID is reported in NM109 of this loop then this REF segment is not used.
FHIR Mapping:
The data elements in this segment are not defined in the PAS Bundle profile.
Implement with version: STU 1.0.0
TR3 Example:
REF✱TJ✱565656565~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
0B
State License Number
1A
Blue Cross Provider Number
1B
Blue Shield Provider Number
1C
Medicare Provider Number
1D
Medicaid Provider Number
1E
Dentist License Number
1G
Provider UPIN Number
1H
CHAMPUS Identification Number
1J
Facility ID Number
A6
Provider Identifier
B3
Preferred Provider Organization Number
BQ
Health Maintenance Organization Code Number
EI
Employer's Identification Number
FH
Clinic Number
G5
Provider Site Number
LU
Location Number
SY
Social Security Number
The Social Security Number may not be used for Medicare.
TJ
Federal Taxpayer's Identification Number
U3
Unique Supplier Identification Number (USIN)
X5
State Industrial Accident Provider 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: Information Receiver Secondary Identification
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
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

NM1 - PATIENT NAME

X12 Name:
Individual or Organizational Name
X12 Purpose:
To supply the full name of an individual or organizational entity
X12 Syntax:
  1. P0809
    If either NM108 or NM109 is present, then the other is required.
  2. C1110
    If NM111 is present, then NM110 is required.
  3. C1203
    If NM112 is present, then NM103 is required.
X12 Set Notes:
NOTE: Loop NM1 identifies a single patient; it also identifies other entities or individuals which include the requester, responder or other organizations.
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
  1. Use this segment to identify the patient as identified in the 278 Health Care Services Review associated with this 275 attachment.
  2. If the subscriber is the patient, use NM101 = "IL". If the dependent is the patient, use NM101 = "QC".
FHIR Mapping:
Claim.patient => Patient
Locate the Patient Resource in the Bundle referenced in the Claim.patient attribute. Use the Patient Resource for all of the segments of the 2010D Loop
Implement with version: STU 1.0.0
TR3 Example:
NM1✱IL✱1✱SMITH✱JOHN✱H✱✱✱MI✱111222333A~
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
FHIR Mapping: see note
If Claim.insurance[0].coverage has Coverage.relationship.coding[0].code equal 'self' then insert 'IL'
Otherwise insert 'QC'
Implement with version: STU 1.0.0
CODE
DEFINITION
IL
Insured or Subscriber
Use if the subscriber is the patient.
QC
Patient
Use if the dependent is the patient.
Required
2
1065
Entity Type Qualifier
M 1
ID
1
Code qualifying the type of entity
SEMANTIC: NM102 qualifies NM103.
FHIR Mapping: '1'
Implement with version: STU 1.0.0
CODE
DEFINITION
1
Person
Required
3
1035
Name Last or Organization Name
X 1
AN
1/60
Individual last name or organizational name
FHIR Mapping: Patient.name[0].family
Implement with version: STU 1.0.0
SEGMENT SYNTAX: C1203
INDUSTRY NAME: Patient Last Name
Situational
4
1036
Name First
O 1
AN
1/35
Individual first name
FHIR Mapping: Patient.name[0].given[0]
Implement with version: STU 1.0.0
SITUATIONAL RULE: Required when the person has a first name. If not required by this implementation guide, do not send.
INDUSTRY NAME: Patient First Name
Situational
5
1037
Name Middle
O 1
AN
1/25
Individual middle name or initial
FHIR Mapping: Patient.name[0].given[1]
Implement with version: STU 1.0.0
SITUATIONAL RULE: Required when the middle name or initial of the person is needed to identify the individual. If not required by this implementation guide, do not send.
INDUSTRY NAME: Patient Middle Name or Initial
Not Used
6
1038
Name Prefix
O 1
AN
1/10
Situational
7
1039
Name Suffix
O 1
AN
1/10
Suffix to individual name
FHIR Mapping: Patient.name[0].suffix
Implement with version: STU 1.0.0
SITUATIONAL RULE: Required when the name suffix is needed to identify the individual. If not required by this implementation guide, do not send.
INDUSTRY NAME: Patient Name Suffix
Required
8
66
Identification Code Qualifier
X 1
ID
1/2
Code designating the system/method of code structure used for Identification Code (67)
FHIR Mapping: 'MI'
Implement with version: STU 1.1.0
SEGMENT SYNTAX: P0809
CODE
DEFINITION
II
Standard Unique Health Identifier for each Individual in the United States
The value "II" when used in this data element, shall be defined as "HIPAA Individual Identifier" if this identifier has been adopted. Under the Health Insurance Portability and Accountability Act of 1996, the Secretary of Health and Human Services must adopt a standard individual identifier for use in this transaction.
MI
Member Identification Number
The code MI is intended to be the subscriber's identification number as assigned by the payer. Payers use different terminology to convey the same number. Use MI - Member Identification Number to convey the following terms: Insured's ID, Subscriber's ID, Health Insurance Claim Number (HIC), etc.
Required
9
67
Identification Code
X 1
AN
2/80
Code identifying a party or other code
FHIR Mapping: Patient.identifier[0].value
Implement with version: STU 1.0.0
SEGMENT SYNTAX: P0809
INDUSTRY NAME: Patient Primary Identifier
Not Used
10
706
Entity Relationship Code
X 1
ID
2
Not Used
11
98
Entity Identifier Code
O 1
ID
2/3
Not Used
12
1035
Name Last or Organization Name
O 1
AN
1/60

REF*EJ - PATIENT ACCOUNT NUMBER

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the REF segment with the Patient Account Number is supplied in the associated 278 transaction. If not required by this implementation guide, do not send.
FHIR Mapping:
The data elements in this segment are not defined in the PAS Bundle profile.
Implement with version: STU 1.0.0
TR3 Example:
REF✱EJ✱PT12345~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
EJ
Patient Account 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: Patient Account Number
  1. The maximum number of characters to be supported for this qualifier is "20". Characters beyond the maximum are not required to be stored or returned by the receiving system.
  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
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

REF*2I - PATIENT EVENT TRACE NUMBER

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the Patient Event Tracking Number appears in the TRN segment of the associated 278. If not required by this implementation guide, do not send.
TR3 Notes:
  1. In the unsolicited 275, this is the trace number assigned by the information source in the 2000E Loop of the 278.
  2. In the solicited 275, this may be the number provided in the original 278 Request, or a TRN added by the UMO in the 278 Response.
FHIR Mapping:
The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
TR3 Example:
REF✱2I✱20022431100~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
FHIR Mapping: '2I'
Implement with version: STU 1.0.0
CODE
DEFINITION
2I
Tracking 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
FHIR Mapping: Claim.identifier[0].value
Implement with version: STU 1.0.0
SEGMENT SYNTAX: R0203
INDUSTRY NAME: Patient Event Tracking Number
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
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

LX - ASSIGNED NUMBER

X12 Name:
Transaction Set Line Number
X12 Purpose:
To reference a line number in a transaction set
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
  1. Within the LX, LX01 is the sequence number of the LX Loop. It is required that the LX01 sequence number start at 1 and increment by 1.
  2. The LX segment begins the detailed additional information loop. This loop occurs
    • once for each response to each request for additional information (each LOINC<190> and/or each Attachment Control Number) contained in the Health Care Services Review Response or
    • once for each type of additional information associated with the unsolicited 278 Health Care Services Review Request or
    • once for each type of additional information associated with the 278 Health Care Services Review Notification.
FHIR Mapping:
The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
TR3 Example:
LX✱1~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
554
Assigned Number
M 1
N
1/6
Number assigned for differentiation within a transaction set
FHIR Mapping: '1'
Implement with version: STU 1.0.0

TRN - ATTACHMENT CONTROL TRACE NUMBER

X12 Name:
Trace
X12 Purpose:
To uniquely identify a transaction to an application
X12 Set Notes:
NOTE: The TRN segment in Loop LX identifies a previously sent transaction set. The LX loop provides supporting or additional information for that item when TRN is used.
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
  1. If this 275 is sent in response to the UMO's request for additional information, enter the TRN with the Attachment Control Number assigned by the UMO. This is the number that appears in PWK06 of the associated PWK segment in the Health Care Services Review Response.
  2. If this 275 is sent as an unsolicited attachment for a 278 Health Care Services Review Request or Notification, enter the TRN with the Attachment Control Number that appears in PWK06 of the 278 Health Care Services Review Request or Notification.
FHIR Mapping:
The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
TR3 Example:
TRN✱2✱1234567~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
481
Trace Type Code
M 1
ID
1/2
Code identifying which transaction is being referenced
FHIR Mapping: '1'
Implement with version: STU 1.0.0
CODE
DEFINITION
1
Current Transaction Trace Numbers
Use when sending an unsolicited 275 in support of a 278.
2
Referenced Transaction Trace Numbers
Use when responding to a 278 Response requesting additional information.
Required
2
127
Reference Identification
M 1
AN
1/80
Reference information as defined for a particular Transaction Set or as specified by the Reference Identification Qualifier
SEMANTIC: TRN02 provides unique identification for the transaction.
FHIR Mapping: Claim.identifier[0].value
Implement with version: STU 1.0.0
INDUSTRY NAME: Attachment Control Number
  1. When BGN01 = 11, this number is the Attachment Control Number assigned by the UMO.
  2. When BGN01 = 02 or 22, this number is the Attachment Control Number that the provider assigned.
  3. 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
509
Originating Company Identifier
O 1
AN
10
Not Used
4
127
Reference Identification
O 1
AN
1/80

STC - STATUS INFORMATION

X12 Name:
Status Information
X12 Purpose:
To report the status, required action, and paid information of a claim or service line
X12 Set Notes:
NOTE: The STC segment in LX loop identifies the status and action requested in a prior transaction when the response is provided in this transaction.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the value in BGN01 is 11 (Response). If not required by this implementation guide, do not send.
TR3 Notes:
This segment must be used to return the question that originally was sent in the request for additional information.
TR3 Example:
  1. STC✱R4:19002-5::LOI~
  2. The data elements in this segment are not defined in the PAS Bundle profile.Implement with version: STU 1.0.0
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
C043
Health Care Claim Status
M 1
Used to convey status of the entire claim or a specific service line
X12 COMPOSITE SEMANTIC NOTES:
  1. C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
  2. C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
  3. C043-03 identifies the entity associated with the Health Care Claim Status Code.
  4. C043-04 is used to identify the Code Source referenced in C043-02.
This data element contains the values found in the Patient Event level or Service level in the 278 Response containing the request for additional information.
Required
1-1
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Category Code
For this implementation, the value must be a Category Code beginning with R.
Required
1-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Additional Information Request Code
This will be the LOINC® Code that defines the additional information that was requested.
Not Used
1-3
98
Entity Identifier Code
O 1
ID
2/3
Required
1-4
1270
Code List Qualifier Code
O 1
ID
1/3
Code identifying a specific industry code list
CODE
DEFINITION
LOI
Logical Observation Identifier Names and Codes (LOINC) Codes
CODE SOURCE: 663: Logical Observation Identifier Names and Codes (LOINC)
Not Used
2
373
Date
O 1
DT
8
Not Used
3
306
Action Code
O 1
ID
1/2
Not Used
4
782
Monetary Amount
O 1
R
1/18
Not Used
5
782
Monetary Amount
O 1
R
1/18
Not Used
6
373
Date
O 1
DT
8
Not Used
7
591
Payment Method Code
O 1
ID
3
Not Used
8
373
Date
O 1
DT
8
Not Used
9
429
Check Number
O 1
AN
1/16
Situational
10
C043
Health Care Claim Status
O 1
Used to convey status of the entire claim or a specific service line
X12 COMPOSITE SEMANTIC NOTES:
  1. C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
  2. C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
  3. C043-03 identifies the entity associated with the Health Care Claim Status Code.
  4. C043-04 is used to identify the Code Source referenced in C043-02.
SITUATIONAL RULE: Required when the the 278 Response contains a LOINC<190> Code Modifier. If not required by this implementation guide, do not send.
Required
10-1
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Category Code
For this implementation, the value must be a Category Code beginning with R.
Required
10-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Additional Information Request Modifier
This will be the LOINC® Code that further specifies the request for information.
Not Used
10-3
98
Entity Identifier Code
O 1
ID
2/3
Required
10-4
1270
Code List Qualifier Code
O 1
ID
1/3
Code identifying a specific industry code list
CODE
DEFINITION
LOI
Logical Observation Identifier Names and Codes (LOINC) Codes
CODE SOURCE: 663: Logical Observation Identifier Names and Codes (LOINC)
Situational
11
C043
Health Care Claim Status
O 1
Used to convey status of the entire claim or a specific service line
X12 COMPOSITE SEMANTIC NOTES:
  1. C043-01 (Claim Status Category Codes, Code Source 507) is used to specify the logical groupings of codes used in C043-02.
  2. C043-02 is used to identify the status of an entire claim or a service line. Code Source 508 is referenced unless qualified by C043-04.
  3. C043-03 identifies the entity associated with the Health Care Claim Status Code.
  4. C043-04 is used to identify the Code Source referenced in C043-02.
SITUATIONAL RULE: Required when the 278 contains an additional LOINC<190> Code Modifier. If not required by this implementation guide, do not send.
Required
11-1
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Health Care Claim Status Category Code
For this implementation, the value must be a Category Code beginning with R.
Required
11-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
INDUSTRY NAME: Additional Information Request Modifier
This will be the LOINC® Code that further specifies the request for information.
Not Used
11-3
98
Entity Identifier Code
O 1
ID
2/3
Required
11-4
1270
Code List Qualifier Code
O 1
ID
1/3
Code identifying a specific industry code list
CODE
DEFINITION
LOI
Logical Observation Identifier Names and Codes (LOINC) Codes
CODE SOURCE: 663: Logical Observation Identifier Names and Codes (LOINC)
Not Used
12
933
Free-form Message Text
O 1
AN
1/264

REF - SERVICE TRACE NUMBER

X12 Name:
Reference Information
X12 Purpose:
To specify identifying information
X12 Syntax:
R0203
At least one of REF02 or REF03 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the additional information pertains to specific services, procedures, or treatments originally referenced in the 278 and the 278 contains a Service Trace Number in the associated Service loop. If not required by this implementation guide, do not send.
FHIR Mapping:
The data elements in this segment are not defined in the PAS Bundle profile.
Implement with version: STU 1.0.0
TR3 Example:
REF✱6R✱54321~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
128
Reference Identification Qualifier
M 1
ID
2/3
Code qualifying the Reference Identification
CODE
DEFINITION
6R
Provider Control Number
Used when BGN01 equals 02 or 22.
FJ
Line Item Control Number
Used when BGN01 equals 11 and the Service Trace Number assigned by the UMO (where TRN01 =2) is sent in the 278 Health Care Services Review Response.
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: Service Trace Number
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
352
Description
X 1
AN
1/80
Not Used
4
C040
Reference Identifier
O 1

HI - HEALTH CARE INFORMATION CODES

X12 Name:
Health Care Information Codes
X12 Purpose:
To supply information related to the delivery of health care
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
2
Situational Rule:
Required when a diagnosis is specifically related to the attachment information being sent. If not required by this implementation guide, do not send.
TR3 Notes:
Do not transmit the decimal point for ICD codes. The decimal point is implied.
FHIR Mapping:
The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
TR3 Example:
HI✱ABK:H25032✱ABF:I10✱ABF:R9431✱ABF:H59312~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
C022
Health Care Code Information
M 1
To send health care codes and their associated dates, amounts and quantities
X12 COMPOSITE SYNTAX NOTES:
  1. P0304
    If either C02203 or C02204 is present, then the other is required.
  2. E0809
    Only one of C02208 or C02209 may be present.
X12 COMPOSITE SEMANTIC NOTES:
  1. C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
  2. If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
  3. C022-03 is the date format that will appear in C022-04.
  4. C022-07 qualifies C022-01.
  5. C022-08 represents the ending value in a range of codes.
  6. C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
X12 COMPOSITE COMMENTS: C022-09 would only need to be reported when C022-02 is a Diagnosis Code and range of diagnosis codes were NOT given in C022-08.
The diagnosis listed in this element is assumed to be the principal diagnosis.
Required
1-1
1270
Code List Qualifier Code
M 1
ID
1/3
Code identifying a specific industry code list
FHIR Mapping: See note
Use the values from Claim.diagnosis[0] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
INDUSTRY NAME: Diagnosis Type Code
CODE
DEFINITION
AAA
SNOMED, Systematized Nomenclature of Medicine
CODE SOURCE: 662: SNOMED, Systematized Nomenclature of Medicine
ABF
International Classification of Diseases Clinical Modification (ICD-10-CM) Diagnosis
The ICD-10 code set and corresponding qualifier can only be used: On or after the mandated HIPAA implementation date or, when the Secretary grants an exception to use the code set as a pilot project as allowed under the law.
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
ABJ
International Classification of Diseases Clinical Modification (ICD-10-CM) Admitting Diagnosis
The ICD-10 code set and corresponding qualifier can only be used: On or after the mandated HIPAA implementation date or, when the Secretary grants an exception to use the code set as a pilot project as allowed under the law.
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
ABK
International Classification of Diseases Clinical Modification (ICD-10-CM) Principal Diagnosis
The ICD-10 code set and corresponding qualifier can only be used: On or after the mandated HIPAA implementation date or, when the Secretary grants an exception to use the code set as a pilot project as allowed under the law.
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
APR
International Classification of Diseases Clinical Modification (ICD-10-CM) Patient's Reason for Visit
The ICD-10 code set and corresponding qualifier can only be used: On or after the mandated HIPAA implementation date or, when the Secretary grants an exception to use the code set as a pilot project as allowed under the law.
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
BF
International Classification of Diseases Clinical Modification (ICD-9-CM) Diagnosis
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
BJ
International Classification of Diseases Clinical Modification (ICD-9-CM) Admitting Diagnosis
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
BK
International Classification of Diseases Clinical Modification (ICD-9-CM) Principal Diagnosis
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
DR
Diagnosis Related Group (DRG)
CODE SOURCE: 229: Diagnosis Related Group Number (DRG)
PR
International Classification of Diseases Clinical Modification (ICD-9-CM) Patient's Reason for Visit
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
Required
1-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
FHIR Mapping: Claim.diagnosis[0].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
INDUSTRY NAME: Diagnosis Code
Not Used
1-3
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
1-4
1251
Date Time Period
X 1
AN
1/35
Not Used
1-5
782
Monetary Amount
O 1
R
1/18
Not Used
1-6
380
Quantity
O 1
R
1/15
Not Used
1-7
799
Version Identifier
O 1
AN
1/30
Not Used
1-8
1271
Industry Code
X 1
AN
1/30
Not Used
1-9
1271
Industry Code
X 1
AN
1/30
Situational
2
C022
Health Care Code Information
O 1
To send health care codes and their associated dates, amounts and quantities
X12 COMPOSITE SYNTAX NOTES:
  1. P0304
    If either C02203 or C02204 is present, then the other is required.
  2. E0809
    Only one of C02208 or C02209 may be present.
X12 COMPOSITE SEMANTIC NOTES:
  1. C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
  2. If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
  3. C022-03 is the date format that will appear in C022-04.
  4. C022-07 qualifies C022-01.
  5. C022-08 represents the ending value in a range of codes.
  6. C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
X12 COMPOSITE COMMENTS: C022-09 would only need to be reported when C022-02 is a Diagnosis Code and range of diagnosis codes were NOT given in C022-08.
SITUATIONAL RULE: Required when it is necessary to report additional diagnosis codes.
Required
2-1
1270
Code List Qualifier Code
M 1
ID
1/3
Code identifying a specific industry code list
FHIR Mapping: See note
Use the values from Claim.diagnosis[1] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
CODE
DEFINITION
ABF
International Classification of Diseases Clinical Modification (ICD-10-CM) Diagnosis
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
ABJ
International Classification of Diseases Clinical Modification (ICD-10-CM) Admitting Diagnosis
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
ABN
International Classification of Diseases Clinical Modification (ICD-10-CM) External Cause of Injury Code
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
BF
International Classification of Diseases Clinical Modification (ICD-9-CM) Diagnosis
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
BJ
International Classification of Diseases Clinical Modification (ICD-9-CM) Admitting Diagnosis
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
BN
International Classification of Diseases Clinical Modification (ICD-9-CM) External Cause of Injury Code (E-codes)
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
TQ
Systemized Nomenclature of Dentistry (SNODENT)
CODE SOURCE: 135: American Dental Association
Required
2-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
FHIR Mapping: Claim.diagnosis[1].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
Not Used
2-3
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
2-4
1251
Date Time Period
X 1
AN
1/35
Not Used
2-5
782
Monetary Amount
O 1
R
1/18
Not Used
2-6
380
Quantity
O 1
R
1/15
Not Used
2-7
799
Version Identifier
O 1
AN
1/30
Not Used
2-8
1271
Industry Code
X 1
AN
1/30
Not Used
2-9
1271
Industry Code
X 1
AN
1/30
Situational
3
C022
Health Care Code Information
O 1
To send health care codes and their associated dates, amounts and quantities
X12 COMPOSITE SYNTAX NOTES:
  1. P0304
    If either C02203 or C02204 is present, then the other is required.
  2. E0809
    Only one of C02208 or C02209 may be present.
X12 COMPOSITE SEMANTIC NOTES:
  1. C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
  2. If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
  3. C022-03 is the date format that will appear in C022-04.
  4. C022-07 qualifies C022-01.
  5. C022-08 represents the ending value in a range of codes.
  6. C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
X12 COMPOSITE COMMENTS: C022-09 would only need to be reported when C022-02 is a Diagnosis Code and range of diagnosis codes were NOT given in C022-08.
SITUATIONAL RULE: Required when it is necessary to report additional diagnosis codes.
Required
3-1
1270
Code List Qualifier Code
M 1
ID
1/3
Code identifying a specific industry code list
FHIR Mapping: See note
Use the values from Claim.diagnosis[2] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
CODE
DEFINITION
ABF
International Classification of Diseases Clinical Modification (ICD-10-CM) Diagnosis
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
ABN
International Classification of Diseases Clinical Modification (ICD-10-CM) External Cause of Injury Code
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
BF
International Classification of Diseases Clinical Modification (ICD-9-CM) Diagnosis
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
BN
International Classification of Diseases Clinical Modification (ICD-9-CM) External Cause of Injury Code (E-codes)
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
TQ
Systemized Nomenclature of Dentistry (SNODENT)
CODE SOURCE: 135: American Dental Association
Required
3-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
FHIR Mapping: Claim.diagnosis[2].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
Not Used
3-3
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
3-4
1251
Date Time Period
X 1
AN
1/35
Not Used
3-5
782
Monetary Amount
O 1
R
1/18
Not Used
3-6
380
Quantity
O 1
R
1/15
Not Used
3-7
799
Version Identifier
O 1
AN
1/30
Not Used
3-8
1271
Industry Code
X 1
AN
1/30
Not Used
3-9
1271
Industry Code
X 1
AN
1/30
Situational
4
C022
Health Care Code Information
O 1
To send health care codes and their associated dates, amounts and quantities
X12 COMPOSITE SYNTAX NOTES:
  1. P0304
    If either C02203 or C02204 is present, then the other is required.
  2. E0809
    Only one of C02208 or C02209 may be present.
X12 COMPOSITE SEMANTIC NOTES:
  1. C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
  2. If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
  3. C022-03 is the date format that will appear in C022-04.
  4. C022-07 qualifies C022-01.
  5. C022-08 represents the ending value in a range of codes.
  6. C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
X12 COMPOSITE COMMENTS: C022-09 would only need to be reported when C022-02 is a Diagnosis Code and range of diagnosis codes were NOT given in C022-08.
SITUATIONAL RULE: Required when it is necessary to report additional diagnosis codes.
Required
4-1
1270
Code List Qualifier Code
M 1
ID
1/3
Code identifying a specific industry code list
FHIR Mapping: See note
Use the values from Claim.diagnosis[3] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
CODE
DEFINITION
ABF
International Classification of Diseases Clinical Modification (ICD-10-CM) Diagnosis
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
ABN
International Classification of Diseases Clinical Modification (ICD-10-CM) External Cause of Injury Code
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
BF
International Classification of Diseases Clinical Modification (ICD-9-CM) Diagnosis
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
BN
International Classification of Diseases Clinical Modification (ICD-9-CM) External Cause of Injury Code (E-codes)
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
TQ
Systemized Nomenclature of Dentistry (SNODENT)
CODE SOURCE: 135: American Dental Association
Required
4-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
FHIR Mapping: Claim.diagnosis[3].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
Not Used
4-3
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
4-4
1251
Date Time Period
X 1
AN
1/35
Not Used
4-5
782
Monetary Amount
O 1
R
1/18
Not Used
4-6
380
Quantity
O 1
R
1/15
Not Used
4-7
799
Version Identifier
O 1
AN
1/30
Not Used
4-8
1271
Industry Code
X 1
AN
1/30
Not Used
4-9
1271
Industry Code
X 1
AN
1/30
Situational
5
C022
Health Care Code Information
O 1
To send health care codes and their associated dates, amounts and quantities
X12 COMPOSITE SYNTAX NOTES:
  1. P0304
    If either C02203 or C02204 is present, then the other is required.
  2. E0809
    Only one of C02208 or C02209 may be present.
X12 COMPOSITE SEMANTIC NOTES:
  1. C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
  2. If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
  3. C022-03 is the date format that will appear in C022-04.
  4. C022-07 qualifies C022-01.
  5. C022-08 represents the ending value in a range of codes.
  6. C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
X12 COMPOSITE COMMENTS: C022-09 would only need to be reported when C022-02 is a Diagnosis Code and range of diagnosis codes were NOT given in C022-08.
SITUATIONAL RULE: Required when it is necessary to report additional diagnosis codes.
Required
5-1
1270
Code List Qualifier Code
M 1
ID
1/3
Code identifying a specific industry code list
FHIR Mapping: See note
Use the values from Claim.diagnosis[4] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
CODE
DEFINITION
ABF
International Classification of Diseases Clinical Modification (ICD-10-CM) Diagnosis
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
ABN
International Classification of Diseases Clinical Modification (ICD-10-CM) External Cause of Injury Code
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
BF
International Classification of Diseases Clinical Modification (ICD-9-CM) Diagnosis
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
BN
International Classification of Diseases Clinical Modification (ICD-9-CM) External Cause of Injury Code (E-codes)
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
TQ
Systemized Nomenclature of Dentistry (SNODENT)
CODE SOURCE: 135: American Dental Association
Required
5-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
FHIR Mapping: Claim.diagnosis[4].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
Not Used
5-3
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
5-4
1251
Date Time Period
X 1
AN
1/35
Not Used
5-5
782
Monetary Amount
O 1
R
1/18
Not Used
5-6
380
Quantity
O 1
R
1/15
Not Used
5-7
799
Version Identifier
O 1
AN
1/30
Not Used
5-8
1271
Industry Code
X 1
AN
1/30
Not Used
5-9
1271
Industry Code
X 1
AN
1/30
Situational
6
C022
Health Care Code Information
O 1
To send health care codes and their associated dates, amounts and quantities
X12 COMPOSITE SYNTAX NOTES:
  1. P0304
    If either C02203 or C02204 is present, then the other is required.
  2. E0809
    Only one of C02208 or C02209 may be present.
X12 COMPOSITE SEMANTIC NOTES:
  1. C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
  2. If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
  3. C022-03 is the date format that will appear in C022-04.
  4. C022-07 qualifies C022-01.
  5. C022-08 represents the ending value in a range of codes.
  6. C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
X12 COMPOSITE COMMENTS: C022-09 would only need to be reported when C022-02 is a Diagnosis Code and range of diagnosis codes were NOT given in C022-08.
SITUATIONAL RULE: Required when it is necessary to report additional diagnosis codes.
Required
6-1
1270
Code List Qualifier Code
M 1
ID
1/3
Code identifying a specific industry code list
FHIR Mapping: See note
Use the values from Claim.diagnosis[5] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
CODE
DEFINITION
ABF
International Classification of Diseases Clinical Modification (ICD-10-CM) Diagnosis
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
ABN
International Classification of Diseases Clinical Modification (ICD-10-CM) External Cause of Injury Code
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
BF
International Classification of Diseases Clinical Modification (ICD-9-CM) Diagnosis
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
BN
International Classification of Diseases Clinical Modification (ICD-9-CM) External Cause of Injury Code (E-codes)
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
TQ
Systemized Nomenclature of Dentistry (SNODENT)
CODE SOURCE: 135: American Dental Association
Required
6-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
FHIR Mapping: Claim.diagnosis[5].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
Not Used
6-3
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
6-4
1251
Date Time Period
X 1
AN
1/35
Not Used
6-5
782
Monetary Amount
O 1
R
1/18
Not Used
6-6
380
Quantity
O 1
R
1/15
Not Used
6-7
799
Version Identifier
O 1
AN
1/30
Not Used
6-8
1271
Industry Code
X 1
AN
1/30
Not Used
6-9
1271
Industry Code
X 1
AN
1/30
Situational
7
C022
Health Care Code Information
O 1
To send health care codes and their associated dates, amounts and quantities
X12 COMPOSITE SYNTAX NOTES:
  1. P0304
    If either C02203 or C02204 is present, then the other is required.
  2. E0809
    Only one of C02208 or C02209 may be present.
X12 COMPOSITE SEMANTIC NOTES:
  1. C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
  2. If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
  3. C022-03 is the date format that will appear in C022-04.
  4. C022-07 qualifies C022-01.
  5. C022-08 represents the ending value in a range of codes.
  6. C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
X12 COMPOSITE COMMENTS: C022-09 would only need to be reported when C022-02 is a Diagnosis Code and range of diagnosis codes were NOT given in C022-08.
SITUATIONAL RULE: Required when it is necessary to report additional diagnosis codes.
Required
7-1
1270
Code List Qualifier Code
M 1
ID
1/3
Code identifying a specific industry code list
FHIR Mapping: See note
Use the values from Claim.diagnosis[6] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
CODE
DEFINITION
ABF
International Classification of Diseases Clinical Modification (ICD-10-CM) Diagnosis
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
ABN
International Classification of Diseases Clinical Modification (ICD-10-CM) External Cause of Injury Code
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
BF
International Classification of Diseases Clinical Modification (ICD-9-CM) Diagnosis
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
BN
International Classification of Diseases Clinical Modification (ICD-9-CM) External Cause of Injury Code (E-codes)
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
TQ
Systemized Nomenclature of Dentistry (SNODENT)
CODE SOURCE: 135: American Dental Association
Required
7-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
FHIR Mapping: Claim.diagnosis[6].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
Not Used
7-3
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
7-4
1251
Date Time Period
X 1
AN
1/35
Not Used
7-5
782
Monetary Amount
O 1
R
1/18
Not Used
7-6
380
Quantity
O 1
R
1/15
Not Used
7-7
799
Version Identifier
O 1
AN
1/30
Not Used
7-8
1271
Industry Code
X 1
AN
1/30
Not Used
7-9
1271
Industry Code
X 1
AN
1/30
Situational
8
C022
Health Care Code Information
O 1
To send health care codes and their associated dates, amounts and quantities
X12 COMPOSITE SYNTAX NOTES:
  1. P0304
    If either C02203 or C02204 is present, then the other is required.
  2. E0809
    Only one of C02208 or C02209 may be present.
X12 COMPOSITE SEMANTIC NOTES:
  1. C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
  2. If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
  3. C022-03 is the date format that will appear in C022-04.
  4. C022-07 qualifies C022-01.
  5. C022-08 represents the ending value in a range of codes.
  6. C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
X12 COMPOSITE COMMENTS: C022-09 would only need to be reported when C022-02 is a Diagnosis Code and range of diagnosis codes were NOT given in C022-08.
SITUATIONAL RULE: Required when it is necessary to report additional diagnosis codes.
Required
8-1
1270
Code List Qualifier Code
M 1
ID
1/3
Code identifying a specific industry code list
FHIR Mapping: See note
Use the values from Claim.diagnosis[7] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
CODE
DEFINITION
ABF
International Classification of Diseases Clinical Modification (ICD-10-CM) Diagnosis
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
ABN
International Classification of Diseases Clinical Modification (ICD-10-CM) External Cause of Injury Code
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
BF
International Classification of Diseases Clinical Modification (ICD-9-CM) Diagnosis
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
BN
International Classification of Diseases Clinical Modification (ICD-9-CM) External Cause of Injury Code (E-codes)
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
TQ
Systemized Nomenclature of Dentistry (SNODENT)
CODE SOURCE: 135: American Dental Association
Required
8-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
FHIR Mapping: Claim.diagnosis[7].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
Not Used
8-3
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
8-4
1251
Date Time Period
X 1
AN
1/35
Not Used
8-5
782
Monetary Amount
O 1
R
1/18
Not Used
8-6
380
Quantity
O 1
R
1/15
Not Used
8-7
799
Version Identifier
O 1
AN
1/30
Not Used
8-8
1271
Industry Code
X 1
AN
1/30
Not Used
8-9
1271
Industry Code
X 1
AN
1/30
Situational
9
C022
Health Care Code Information
O 1
To send health care codes and their associated dates, amounts and quantities
X12 COMPOSITE SYNTAX NOTES:
  1. P0304
    If either C02203 or C02204 is present, then the other is required.
  2. E0809
    Only one of C02208 or C02209 may be present.
X12 COMPOSITE SEMANTIC NOTES:
  1. C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
  2. If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
  3. C022-03 is the date format that will appear in C022-04.
  4. C022-07 qualifies C022-01.
  5. C022-08 represents the ending value in a range of codes.
  6. C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
X12 COMPOSITE COMMENTS: C022-09 would only need to be reported when C022-02 is a Diagnosis Code and range of diagnosis codes were NOT given in C022-08.
SITUATIONAL RULE: Required when it is necessary to report additional diagnosis codes.
Required
9-1
1270
Code List Qualifier Code
M 1
ID
1/3
Code identifying a specific industry code list
FHIR Mapping: See note
Use the values from Claim.diagnosis[8] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
CODE
DEFINITION
ABF
International Classification of Diseases Clinical Modification (ICD-10-CM) Diagnosis
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
ABN
International Classification of Diseases Clinical Modification (ICD-10-CM) External Cause of Injury Code
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
BF
International Classification of Diseases Clinical Modification (ICD-9-CM) Diagnosis
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
BN
International Classification of Diseases Clinical Modification (ICD-9-CM) External Cause of Injury Code (E-codes)
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
TQ
Systemized Nomenclature of Dentistry (SNODENT)
CODE SOURCE: 135: American Dental Association
Required
9-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
FHIR Mapping: Claim.diagnosis[8].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
Not Used
9-3
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
9-4
1251
Date Time Period
X 1
AN
1/35
Not Used
9-5
782
Monetary Amount
O 1
R
1/18
Not Used
9-6
380
Quantity
O 1
R
1/15
Not Used
9-7
799
Version Identifier
O 1
AN
1/30
Not Used
9-8
1271
Industry Code
X 1
AN
1/30
Not Used
9-9
1271
Industry Code
X 1
AN
1/30
Situational
10
C022
Health Care Code Information
O 1
To send health care codes and their associated dates, amounts and quantities
X12 COMPOSITE SYNTAX NOTES:
  1. P0304
    If either C02203 or C02204 is present, then the other is required.
  2. E0809
    Only one of C02208 or C02209 may be present.
X12 COMPOSITE SEMANTIC NOTES:
  1. C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
  2. If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
  3. C022-03 is the date format that will appear in C022-04.
  4. C022-07 qualifies C022-01.
  5. C022-08 represents the ending value in a range of codes.
  6. C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
X12 COMPOSITE COMMENTS: C022-09 would only need to be reported when C022-02 is a Diagnosis Code and range of diagnosis codes were NOT given in C022-08.
SITUATIONAL RULE: Required when it is necessary to report additional diagnosis codes.
Required
10-1
1270
Code List Qualifier Code
M 1
ID
1/3
Code identifying a specific industry code list
FHIR Mapping: See note
Use the values from Claim.diagnosis[9] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
CODE
DEFINITION
ABF
International Classification of Diseases Clinical Modification (ICD-10-CM) Diagnosis
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
ABN
International Classification of Diseases Clinical Modification (ICD-10-CM) External Cause of Injury Code
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
BF
International Classification of Diseases Clinical Modification (ICD-9-CM) Diagnosis
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
BN
International Classification of Diseases Clinical Modification (ICD-9-CM) External Cause of Injury Code (E-codes)
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
TQ
Systemized Nomenclature of Dentistry (SNODENT)
CODE SOURCE: 135: American Dental Association
Required
10-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
FHIR Mapping: Claim.diagnosis[9].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
Not Used
10-3
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
10-4
1251
Date Time Period
X 1
AN
1/35
Not Used
10-5
782
Monetary Amount
O 1
R
1/18
Not Used
10-6
380
Quantity
O 1
R
1/15
Not Used
10-7
799
Version Identifier
O 1
AN
1/30
Not Used
10-8
1271
Industry Code
X 1
AN
1/30
Not Used
10-9
1271
Industry Code
X 1
AN
1/30
Situational
11
C022
Health Care Code Information
O 1
To send health care codes and their associated dates, amounts and quantities
X12 COMPOSITE SYNTAX NOTES:
  1. P0304
    If either C02203 or C02204 is present, then the other is required.
  2. E0809
    Only one of C02208 or C02209 may be present.
X12 COMPOSITE SEMANTIC NOTES:
  1. C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
  2. If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
  3. C022-03 is the date format that will appear in C022-04.
  4. C022-07 qualifies C022-01.
  5. C022-08 represents the ending value in a range of codes.
  6. C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
X12 COMPOSITE COMMENTS: C022-09 would only need to be reported when C022-02 is a Diagnosis Code and range of diagnosis codes were NOT given in C022-08.
SITUATIONAL RULE: Required when it is necessary to report additional diagnosis codes.
Required
11-1
1270
Code List Qualifier Code
M 1
ID
1/3
Code identifying a specific industry code list
FHIR Mapping: See note
Use the values from Claim.diagnosis[10] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
CODE
DEFINITION
ABF
International Classification of Diseases Clinical Modification (ICD-10-CM) Diagnosis
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
ABN
International Classification of Diseases Clinical Modification (ICD-10-CM) External Cause of Injury Code
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
BF
International Classification of Diseases Clinical Modification (ICD-9-CM) Diagnosis
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
BN
International Classification of Diseases Clinical Modification (ICD-9-CM) External Cause of Injury Code (E-codes)
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
TQ
Systemized Nomenclature of Dentistry (SNODENT)
CODE SOURCE: 135: American Dental Association
Required
11-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
FHIR Mapping: Claim.diagnosis[10].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
Not Used
11-3
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
11-4
1251
Date Time Period
X 1
AN
1/35
Not Used
11-5
782
Monetary Amount
O 1
R
1/18
Not Used
11-6
380
Quantity
O 1
R
1/15
Not Used
11-7
799
Version Identifier
O 1
AN
1/30
Not Used
11-8
1271
Industry Code
X 1
AN
1/30
Not Used
11-9
1271
Industry Code
X 1
AN
1/30
Situational
12
C022
Health Care Code Information
O 1
To send health care codes and their associated dates, amounts and quantities
X12 COMPOSITE SYNTAX NOTES:
  1. P0304
    If either C02203 or C02204 is present, then the other is required.
  2. E0809
    Only one of C02208 or C02209 may be present.
X12 COMPOSITE SEMANTIC NOTES:
  1. C022-01 qualifies C022-02, C022-04, C022-05, C022-06 and C022-08.
  2. If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
  3. C022-03 is the date format that will appear in C022-04.
  4. C022-07 qualifies C022-01.
  5. C022-08 represents the ending value in a range of codes.
  6. C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
X12 COMPOSITE COMMENTS: C022-09 would only need to be reported when C022-02 is a Diagnosis Code and range of diagnosis codes were NOT given in C022-08.
SITUATIONAL RULE: Required when it is necessary to report additional diagnosis codes.
Required
12-1
1270
Code List Qualifier Code
M 1
ID
1/3
Code identifying a specific industry code list
FHIR Mapping: See note
Use the values from Claim.diagnosis[11] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
CODE
DEFINITION
ABF
International Classification of Diseases Clinical Modification (ICD-10-CM) Diagnosis
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
ABN
International Classification of Diseases Clinical Modification (ICD-10-CM) External Cause of Injury Code
CODE SOURCE: 897: International Classification of Diseases, 10th Revision, Clinical Modification (ICD-10-CM)
BF
International Classification of Diseases Clinical Modification (ICD-9-CM) Diagnosis
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
BN
International Classification of Diseases Clinical Modification (ICD-9-CM) External Cause of Injury Code (E-codes)
CODE SOURCE: 131: International Classification of Diseases, 9th Revision, Clinical Modification (ICD-9-CM)
TQ
Systemized Nomenclature of Dentistry (SNODENT)
CODE SOURCE: 135: American Dental Association
Required
12-2
1271
Industry Code
M 1
AN
1/30
Code indicating a code from a specific industry code list
FHIR Mapping: Claim.diagnosis[11].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
Not Used
12-3
1250
Date Time Period Format Qualifier
X 1
ID
2/3
Not Used
12-4
1251
Date Time Period
X 1
AN
1/35
Not Used
12-5
782
Monetary Amount
O 1
R
1/18
Not Used
12-6
380
Quantity
O 1
R
1/15
Not Used
12-7
799
Version Identifier
O 1
AN
1/30
Not Used
12-8
1271
Industry Code
X 1
AN
1/30
Not Used
12-9
1271
Industry Code
X 1
AN
1/30

SVC - SERVICE INFORMATION

X12 Name:
Service Information
X12 Purpose:
To supply payment and control information to a provider for a particular service
Loop:
Loop Usage:
Required
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the additional information is about a service line. If not required by this implementation guide, do not send.
FHIR Mapping:
The data elements in this segment are not defined in the PAS Bundle profile.
Implement with version: STU 1.0.0
TR3 Example:
SVC✱HC:99212:25✱100~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
C003
Composite Medical Procedure Identifier
M 1
To identify a medical procedure by its standardized codes and applicable modifiers
SEMANTIC: SVC01 is the medical procedure upon which adjudication is based.
COMMENT: For Medicare Part A claims, SVC01 would be the Healthcare Common Procedure Coding System (HCPCS) Code (see code source 130) and SVC04 would be the Revenue Code (see code source 132).
X12 COMPOSITE SEMANTIC NOTES:
  1. C003-01 qualifies C003-02 and C003-08.
  2. If C003-08 is used, then C003-02 represents the beginning value in the range in which the code occurs.
  3. C003-03 modifies the value in C003-02 and C003-08.
  4. C003-04 modifies the value in C003-02 and C003-08.
  5. C003-05 modifies the value in C003-02 and C003-08.
  6. C003-06 modifies the value in C003-02 and C003-08.
  7. C003-07 is the description of the procedure identified in C003-02.
  8. C003-08 represents the ending value in the range in which the code occurs.
  9. C003-09 modifies the value in C003-02 and C003-08.
  10. C003-10 modifies the value in C003-02 and C003-08.
  11. C003-11 modifies the value in C003-02 and C003-08.
  12. C003-12 modifies the value in C003-02 and C003-08.
Required
1-1
235
Product/Service ID Qualifier
M 1
ID
2
Code identifying the type/source of the descriptive number used in Product/Service ID (234)
INDUSTRY NAME: Product or Service ID Qualifier
CODE
DEFINITION
AD
American Dental Association Codes
CODE SOURCE: 135: American Dental Association
ER
Jurisdiction Specific Procedure and Supply Codes
This code set is not allowed for use under HIPAA at the time of this writing. The qualifier can only be used:
If a new rule names the Jurisdiction Specific Procedure and Supply Codes as an allowable code set under HIPAA,
OR
The Secretary grants an exception to use the code set as a pilot project as allowed under the law,
OR
For claims which are not covered under HIPAA.
CODE SOURCE: 576: Workers Compensation Specific Procedure and Supply Codes
HC
Healthcare Common Procedure Coding System (HCPCS) Codes
Because the AMA's CPT codes are also level 1 HCPCS codes, they are reported under HC. HCPCS consists of codes from multiple sources including AMA's CPT codes and ADA's CDT codes.
CODE SOURCE: 130: Healthcare Common Procedure Coding System
HP
Health Insurance Prospective Payment System (HIPPS) Skilled Nursing Facility Rate Code
CODE SOURCE: 716: Health Insurance Prospective Payment System (HIPPS) Rate Code for Skilled Nursing Facilities
N4
National Drug Code in 5-4-2 Format
CODE SOURCE: 240: National Drug Code by Format
NU
National Uniform Billing Committee (NUBC) UB92 Codes
This code is the NUBC Revenue Code.
CODE SOURCE: 132: National Uniform Billing Committee (NUBC) Codes
WK
Advanced Billing Concepts (ABC) Codes
At the time of this writing, this code set has been approved by the Secretary of HHS as a pilot project allowed under HIPAA law.
The qualifier may only be used in transactions covered under HIPAA:
By parties registered in the pilot project and their trading partners,
OR
If a new rule names the Complementary, Alternative, or Holistic Procedure Codes as an allowable code set under HIPAA,
OR
For claims which are not covered under HIPAA.
CODE SOURCE: 843: Advanced Billing Concepts (ABC) Codes
Required
1-2
234
Product/Service ID
M 1
AN
1/80
Identifying number for a product or service
INDUSTRY NAME: Product or Service ID
If the value in SVC01-01 is "NU", then this element is an NUBC Revenue Code. If the Revenue Code is present in SVC01-02, then SVC04 is not used.
Situational
1-3
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required when modifiers have been applied to the procedure code reported in SVC01-02. If not required by this implementation guide, do not send.
Situational
1-4
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required when modifiers have been applied to the procedure code reported in SVC01-02. If not required by this implementation guide, do not send.
Situational
1-5
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required when modifiers have been applied to the procedure code reported in SVC01-02. If not required by this implementation guide, do not send.
Situational
1-6
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required when modifiers have been applied to the procedure code reported in SVC01-02. If not required by this implementation guide, do not send.
Not Used
1-7
352
Description
O 1
AN
1/80
Not Used
1-8
234
Product/Service ID
O 1
AN
1/80
Situational
1-9
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required when modifiers have been applied to the procedure code reported in SVC01-02. If not required by this implementation guide, do not send.
Situational
1-10
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required when modifiers have been applied to the procedure code reported in SVC01-02. If not required by this implementation guide, do not send.
Situational
1-11
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required when modifiers have been applied to the procedure code reported in SVC01-02. If not required by this implementation guide, do not send.
Situational
1-12
1339
Procedure Modifier
O 1
AN
2
This identifies special circumstances related to the performance of the service, as defined by trading partners
SITUATIONAL RULE: Required when modifiers have been applied to the procedure code reported in SVC01-02. If not required by this implementation guide, do not send.
Required
2
782
Monetary Amount
M 1
R
1/18
Monetary amount
SEMANTIC: SVC02 is the submitted service charge.
Not Used
3
782
Monetary Amount
O 1
R
1/18
Situational
4
234
Product/Service ID
O 1
AN
1/80
Identifying number for a product or service
SEMANTIC: SVC04 is the National Uniform Billing Committee Revenue Code.
SITUATIONAL RULE: Required on institutional claims to report a NUBC revenue code when a HCPCS or HIPPS code is reported in the SVC01-02. If not required by this implementation guide, do not send.
INDUSTRY NAME: Product or Service ID
Not Used
5
380
Quantity
O 1
R
1/15
Not Used
6
C003
Composite Medical Procedure Identifier
O 1
Not Used
7
380
Quantity
O 1
R
1/15

DTP*368 - ADDITIONAL INFORMATION SUBMITTED DATE

X12 Name:
Date or Time or Period
X12 Purpose:
To specify any or all of a date, a time, or a time period
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
FHIR Mapping:
The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
TR3 Example:
DTP✱368✱D8✱20111024~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
374
Date/Time Qualifier
M 1
ID
3
Code specifying type of date or time, or both date and time
FHIR Mapping: '368'
Implement with version: STU 1.0.0
INDUSTRY NAME: Date Time Qualifier
CODE
DEFINITION
368
Submittal
Date information is submitted.
Required
2
1250
Date Time Period Format Qualifier
M 1
ID
2/3
Code indicating the date format, time format, or date and time format
SEMANTIC: DTP02 is the date or time or period format that will appear in DTP03.
FHIR Mapping: 'D8'
Implement with version: STU 1.0.0
CODE
DEFINITION
D8
Date Expressed in Format CCYYMMDD
Required
3
1251
Date Time Period
M 1
AN
1/35
Expression of a date, a time, or range of dates, times or dates and times
FHIR Mapping: Bundle.timestamp
Implement with version: STU 1.0.0
INDUSTRY NAME: Additional Information Submission Date

CAT*AE - FORMAT AND VERSION IDENTIFIER

X12 Name:
Category of Patient Information Service
X12 Purpose:
To specify categories of patient information service
X12 Syntax:
  1. C0302
    If CAT03 is present, then CAT02 is required.
  2. P0405
    If either CAT04 or CAT05 is present, then the other is required.
  3. C0605
    If CAT06 is present, then CAT05 is required.
  4. C0704
    If CAT07 is present, then CAT04 is required.
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
FHIR Mapping:
The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
TR3 Example:
CAT✱AE✱HL~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
755
Report Type Code
O 1
ID
2
Code indicating the title or contents of a document, report or supporting item
FHIR Mapping: 'AE'
Implement with version: STU 1.0.0
INDUSTRY NAME: Attachment Report Type Code
Description of information that will be coming in the BDS segment.
CODE
DEFINITION
AE
Attachment
Required
2
756
Report Transmission Code
X 1
ID
1/2
Code defining timing, transmission method or format by which reports are to be sent
FHIR Mapping: 'HL'
Implement with version: STU 1.0.0
SEGMENT SYNTAX: C0302
INDUSTRY NAME: Attachment Information Format Code
Code specifying the format of the attachment information sent in BDS03. It is up to mutual agreement among trading partners what CAT02 value is used for attachment information not yet adopted or for a business process not addressed under HIPAA.
CODE
DEFINITION
HL
Health Industry Level 7 Interface Standards (HL/7) Format
Format of the content in BDS03 is codified and contains HL7 header and body structure as defined by HL7.
CODE SOURCE: 464: Health Industry Level 7 (HL7)
IA
Electronic Image
Format of the content in BDS03 is an image or scanned image (jpeg, tiff, pdf, etc) and does not contain HL7 components.
MB
Binary Image
Format of the content in BDS03 is not codified but contains the HL7 header and the `body' is an non-XML formatted content, such as an image or scanned image (jpeg, tiff, pdf, etc).
TX
Text
Format of the content in BDS03 is not codified but contains the HL7 header and the `body' is in XML format.
Situational
3
799
Version Identifier
O 1
AN
1/30
Revision level of a particular format, program, technique or algorithm
FHIR Mapping: no value - not populated for this use case
Implement with version: STU 1.0.0
SEGMENT SYNTAX: C0302
SITUATIONAL RULE: Required when it is necessary to further qualify CAT02 to distinguish between multiple HL7 attachment versions. If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.
INDUSTRY NAME: Version Identification Code
Not Used
4
1270
Code List Qualifier Code
X 1
ID
1/3
Not Used
5
1271
Industry Code
X 1
AN
1/30
Not Used
6
1271
Industry Code
O 1
AN
1/30
Not Used
7
799
Version Identifier
O 1
AN
1/30

OOI - ASSOCIATED OBJECT TYPE IDENTIFICATION

X12 Name:
Associated Object Type Identification
X12 Purpose:
To identify attributes and status related to the object
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
FHIR Mapping:
The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
TR3 Example:
OOI✱1✱47✱ATTACHMENT~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
1694
Object Identification Group
M 1
AN
1/2
To link related object identifications
FHIR Mapping: '1'
Implement with version: STU 1.0.0
For this implementation, the value for this data element is "1".
Required
2
1691
Object Type Qualifier
M 1
ID
1/3
Code identifying type of object
SEMANTIC: Object type qualifier (data element 1691) defines the object attribute (either data element 1692 or 1693), instructing the receiving system on how to process and route the object.
FHIR Mapping: '47'
Implement with version: STU 1.0.0
CODE
DEFINITION
47
External Standard Requirement
Required
3
1692
Object Attribute Identification
M 1
AN
1/256
Identification of the attribute applying to the object type
FHIR Mapping: 'ATTACHMENT'
Implement with version: STU 1.0.0
The value "ATTACHMENT" is required.
Not Used
4
1693
Controlling Agency
O 1
ID
1/3

BDS - BINARY DATA SEGMENT

X12 Name:
Binary Data Structure
X12 Purpose:
To transfer binary data in a single data segment, convey a critical filter for transmission and allow identification of the end of the data segment through a count; there is no identification of the internal structure of the binary data in this segment
Loop:
Loop Usage:
Required
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
  1. It is recommended that the contents of the BDS not exceed 64 megabytes. When for example, a BDS must be split due to size limitations, the 2000A loop must be repeated.
  2. Please refer to the HL7 standard for an example of the attachment content. The BDS segment is used to hold the additional information. It allows for the use of the HL7 standard using the 275 transaction as the envelope.
FHIR Mapping:
The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
TR3 Example:
BDS✱ASC✱3117✱......~The BDS segment in this example does not display the HL7 attachment. Please refer to the HL7 specifications for an example of the attachment. For purposes of this example the attachment is represented by ......
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
1570
Filter ID Code
M 1
ID
3
Code specifying the type of filter used to convert data code values
FHIR Mapping: 'B64'
Implement with version: STU 1.0.0
This represents the encoding format of the data in the BDS.
CODE
DEFINITION
ASC
ASCII Filter
ASC stands for American Standard Code for Information Interchange (ASCII).
B64
Base 64
Required
2
784
Length of Binary Data
M 1
N
1/15
The length in integral octets of the binary data
SEMANTIC: BDS02 is the length of the data in BDS03 after application of the filter indicated by BDS01. For example; a 1000 byte binary file that has been filtered using Base 64 encoding (value 'B64' in BDS01) will have a value of 1336 in the BDS02.
FHIR Mapping: see note
Calculate the size of the entire Bundle submission and use that value for the BDS02
Implement with version: STU 1.0.0
  1. Senders must ensure that the count in BDS02 is equal to the byte count of the contents of the BDS03.
  2. It has been noted that line constraints, transfer protocols, zip programs or conversion processes may insert additional control characters such as line feeds, carriage returns or other specific characters into a transaction. If this occurs in BDS03, the sender's stated count in BDS02 may no longer be equal to the received contents of the data in BDS03 but in no case should it be less than the count indicated in BDS02.
Required
3
785
Binary Data
M 1
1/(1E+15)-1
A string of octets which can assume any binary pattern from hexadecimal 00 to FF. Note: The maximum length is dependent upon the maximum data value that can be entered in DE 784, which value is 999,999,999,999,999.
FHIR Mapping: Bundle
Place the entire contents of the Bundle submission in the BDS03
Implement with version: STU 1.0.0
It is recommended that BDS03 not exceed 64 megabytes. The segment terminator used in the 275 transaction must not be used within the data content of the BDS03.

SE - 275 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
FHIR Mapping:
The data elements in this segment are not defined in the PAS Bundle profile.
Implement with version: STU 1.0.0
TR3 Example:
SE✱17✱1234~
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
Each BDS segment, independent of content, counts as one segment only.
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~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
97
Number of Transaction Sets Included
M 1
N
1/6
Total number of transaction sets included in the functional group or interchange (transmission) group terminated by the trailer containing this data element
Required
2
28
Group Control Number
M 1
N
1/9
Assigned number originated and maintained by the sender
SEMANTIC: The data interchange control number GE02 in this trailer must be identical to the same data element in the associated functional group header, GS06.

IEA - INTERCHANGE CONTROL TRAILER

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

275 Additional Information to Support a Health Care Services Review (006020X316)

AUGUST 2021

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

All rights reserved.

Abstract

The Additional Information to Support a Health Care Claim or Encounter Implementation Guide describes the use of the ASC X12 Patient Information (275) transaction set for the following business usage:

  • To assist those who send additional supporting information or who receive additional supporting information to a health care claim services review.

Preface

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

Trading partners define their specific transport requirements separately. Neither ASC X12 standards nor TR3s define transport requirements.

1.1 Implementation Purpose and Scope

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

The purpose of this implementation guide is to provide standardized data requirements and content to all users of ASC X12 Additional Information to Support a Health Care Services Review (275) Transaction Set that focuses on the use of the 275 to send additional information about a healthcare service review. It provides a detailed explanation of the transaction set by defining uniform data content, identifying valid code tables, and specifying values applicable for the business use of the 275.

This implementation guide describes a solution that includes the encapsulation of a Health Level Seven International (HL7) Standard (www.HL7.org) within the 275 transaction to support the exchange of clinical data. HL7 is an ANSI Accredited Standards Development Organization (SDO) whose domain is clinical and administrative data. See sections 1.4 and 1.7.4 for additional details.

This implementation guide is designed to assist those who send or receive additional information in support of a healthcare service review using the 275 format.

Entities that use this implementation of the 275 include insurance companies, utilization management organizations (UMO), third party administrators (TPA), managed care service organizations (HMO), state and federal agencies and their contractors, plan purchasers, and any other entity that processes a healthcare service review. Other business partners affiliated with the 275 include consulting services, vendors of systems software, EDI translators, and EDI network intermediaries such as automated clearinghouses (ACH), value added networks (VAN), and telecommunications services.

1.2 Version Information

This implementation guide is based on the October 2009 ASC X12 standards, referred to as Version 6, Release 2, Sub-release 0 (006020).

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

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

  • PI   Patient Information (275)

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 if the transaction was not transmitted back to the sender of the original transaction. This implementation guide does not set specific response time parameters for these activities.

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

This implementation guide was based on requirements for batch mode. Willing trading partners may use batch or real-time mode.

1.3.2 Other Usage Limitations

There are other usage limitations.

The 275 transaction structure does not allow submission of additional information in support of more than one request for health care services review. A separate Transaction Set Header/Trailer (ST/SE) must be sent for each request for review. The 275 can support multiple sets of information for a single request for review. See Loop 2110A BDS Segment and the LX Segment at Loop 2000A for additional details.

This implementation guide ONLY addresses using the 275 to support a health care services review or notification. A separate implementation guide was developed for the 275 Additional Information to Support a Health Care Claim or Encounter.

A trading partner agreement may be used to define time parameters for the submission of the solicited 275 and the unsolicited 275 when not sent in the same interchange (ISA/IEA) as the 278. The 275 must be received by the processing entity within the specified time frame or the request will proceed through the review process without the needed information. The ultimate disposition of the service review can include, but is not limited to, approval, rejection, or denial.

As a result of the potential impact on transmission and processing times and storage capacity, trading partners may find it necessary to establish size limitations for the BDS Segment. It is recommended that the content of the BDS not exceed 64 megabytes.

1.4 Business Usage

The 275 transaction set is intended to meet the particular needs of the health care industry to send additional information about a health care service review either when a) responding to a request for additional information or b) submitting an original 278 Health Care Services Review Request or Response. This 275 is also used in support of a 278 Health Care Services Notification.

This 275 is used to convey additional information to support the following business flows:

  • solicited response to a 278 Health Care Services Review Response from a UMO requesting additional information or a paper request for additional information. See Figure 1.1.
  • unsolicited additional information to support a 278 Health Care Services Review Request submitted in the same interchange envelope as the associated 278 or within a separate interchange. See Figures 1.2 and 1.3.
  • unsolicited additional information to support a 278 Health Care Services Review Notification with patient information for exchange of information between health care entities. It may be submitted in the same interchange envelope as the associated 278 or within a separate interchange. See Figures 1.4 and 1.5.

This 275 is used to send specific information to supplement an initial healthcare service review (unsolicited) or to provide requested (solicited) information for a service review. In either case, the additional information is required for the approval process to be completed.

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 Solicited Response to a Health Care Services Review Request for Additional Information

When a medical or utilization review is performed during the healthcare service review additional information may be needed. The UMO (see Section 1.5 - Business Terminology for definition) then requests specific information to supplement or support the provider’s request for authorization of the services under review. The UMO request for additional information may be service specific or apply to the entire request. The 278 Health Care Services Review Response is used to transmit the request for additional information. The provider uses the 275 to respond to the 278 request (Figure 1.1).

In order to facilitate the adjudication of the 278 Health Care Services Review Request, the UMO may negotiate with providers or include as part of their Trading Partner Agreement a specified time period in which the provider may respond to the request for additional information. The 275 response must be received by the UMO within the specified time frame or the request will proceed through the review process without the needed information. The ultimate disposition of the service review can include, but is not limited to, approval, rejection, or denial.

1.4.3 Unsolicited Additional Information to Support a 278 Healthcare Service Review

When it is known at the time of the request that additional information is required by the UMO in order to complete the healthcare service review, the provider may submit an unsolicited 275. If done at the same time as the 278, the 275 may be sent within the same interchange (ISA/IEA) as the initial 278 (Figure 1.2). This situation requires separate GS/GE Functional Groups for the 278 and the 275. It may also be sent in a separate interchange (Figure 1.3). The unsolicited 275 eliminates the need for the UMO to request additional information via the 278 Health Care Services Review Response. A trading partner agreement may be used to define time parameters for the submission of the unsolicited 275 when not sent in the same interchange (ISA/IEA) as the 278. See Chapter 3, Examples.

1.4.4 Unsolicited Additional Information to Support a 278 Health Care Services Review Notification

This transaction is used to move information between health care entities to enable referral or transfer of care, support continuity of care and facilitate third party and subrogation processes. A 278 Health Care Services Review Notification provides for the exchange of information provider to provider, UMO to provider, UMO to payer, payer to payer, payer to TPL entity, etc. Exchanged information includes data such as notification of a review or service outcome, documentation of services provided, supporting information for a specialty referral and acknowledgment/error reporting.

1.4.5.1 Health Care Services Review Request and Response

Figure 1.1 - Solicited 275 EDI Transaction Flow illustrates the path of information related to the solicited business flow for the 275 Additional Information to Support a Health Care Services Review.

Figure 1.1 - Solicited 275 EDI Transaction Flow

Solicited 275 EDI Transaction Flow

Arrow 1
This represents the submission of the 278 Health Care Services Review Request from the provider to the UMO. In this business model the 275 attachment, with the appropriate imbedded HL7 attachment information, is not sent at the same time as the review request.

Arrow 2
After the request is received, the UMO may require additional information to complete the health care services review. The UMO then solicits this information by sending the 278 Health Care Services Review Response identifying the information needed.

Arrow 3
The provider responds to the request for additional information by sending to the UMO the 275 with the appropriate imbedded HL7 attachment information.

Arrow 4
The 278 Health Care Services Review Response is sent to the provider when the review process is completed.

Figure 1.2 - Unsolicited 275 EDI Transaction Flow - 278 and 275 in Same Interchange illustrates the path of information related to the unsolicited business flow for the 275 when the 278 and the 275 are sent in the same interchange.

Figure 1.2 - Unsolicited 275 EDI Transaction Flow - 278 and 275 in Same Interchange

Unsolicited 275 EDI Transaction Flow - 278 and 275 in Same Interchange

Arrow 1
This represents the submission of the 278 Health Care Services Review Request from the provider to the UMO. In this business model the 275 with the appropriate imbedded HL7 attachment information, is sent at the same time as the review request within the same data interchange (ISA/IEA) as the associated 278. Each transaction set is contained within its own Functional Group (GS/GE) within the interchange.

Arrow 2
The 278 Health Care Services Review Response is sent to the provider when the UMO has completed the review process.

Figure 1.3 - Unsolicited 275 EDI Transaction Flow - 278 and 275 in Different Interchange illustrates the path of information related to the unsolicited business flow for the 275 when the 278 and the 275 are sent in a separate interchange.

Figure 1.3 - Unsolicited 275 EDI Transaction Flow - 278 and 275 in Different Interchange

Unsolicited 275 EDI Transaction Flow - 278 and 275 in Different Interchange

Arrow 1
This represents the submission of the 278 Health Care Services Review Request from the provider to the UMO.

Arrow 2
In this business model the 275 with the appropriate imbedded HL7 attachment information, is sent in a separate data interchange (ISA/IEA) than the associated 278.

Arrow 3
The 278 Health Care Services Review Response is sent to the provider when the UMO has completed the review process.

1.4.5.2 Health Care Services Review Notification

Figure 1.4 - Unsolicited 275 EDI Transaction Flow - 278 Notification and 275 in Same Interchange illustrates the path of information related to the business flow for the 275 when the 278 and the 275 are sent in the same interchange.

Figure 1.4 - Unsolicited 275 EDI Transaction Flow - 278 Notification and 275 in Same Interchange

Unsolicited 275 EDI Transaction Flow - 278 Notification and 275 in Same Interchange

Arrow 1
This represents the submission of the 278 Health Care Services Review Notification from the Information Source to the Information Receiver. In this business model the 275 attachment, with the appropriate imbedded HL7 attachment information containing the additional information, is sent at the same time as the notification within the same data interchange (ISA/IEA) as the associated 278. Each transaction set is contained within its own Functional Group (GS/GE) within the interchange.

Arrow 2
The 278 Health Care Services Review Notification Acknowledgement/Error is sent to the Information Source when the Information Receiver acknowledges receipt.

Figure 1.5 - Unsolicited 275 EDI Transaction Flow - 278 Notification and 275 in Separate Interchange illustrates the path of information related to the business flow for the 275 when the 278 and the 275 are sent in separate interchanges.

Figure 1.5 - Unsolicited 275 EDI Transaction Flow - 278 Notification and 275 in Separate Interchange

Unsolicited 275 EDI Transaction Flow - 278 Notification and 275 in Separate Interchange

Arrow 1
This represents the submission of the 278 Health Care Services Review Notification from the Information Source to the Information Receiver.

Arrow 2
In this business model the 275 attachment, with the appropriate imbedded HL7 attachment information, is sent in a separate data interchange (ISA/IEA) than the associated 278; however, it is sent unsolicited.

Arrow 3
The 278 Health Care Services Review Notification Acknowledgment/Error is sent to the Information Source when the Information Receiver acknowledges receipt.

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.

For convenience, the Wordbook definitions for the following business terms, which are used in this implementation guide, are listed below.

Logical Observation Identifier Names and Codes (LOINC®) Code List
LOINC® codes provide a standard set of universal names and codes for identifying individual laboratory and clinical results as well as other clinical information. LOINC® codes are maintained by Regenstrief Institute, Inc.

The dash "-" character displayed in the LOINC® code (e.g., 18657-7) is part of the code.
Note: Therefore the dash"-" character must not be used as a delimiter

Patient event
Patient event in this guide refers to the service or group of services associated with a single episode of care. Examples include the following:

  • Admission to a facility for treatment related to a specific patient condition or diagnosis or related group of diagnoses
  • Referral to a specialty provider for consultation or testing to determine a specific diagnosis and appropriate treatment
  • Services administered during a patient visit such as chiropractic treatment delivered in a single patient visit. The same treatment can be approved for a series of visits.

Utilization Management Organization (UMO)
UMO refers to insurance companies, health maintenance organizations, preferred provider organizations, health care purchasers, professional review organizations, third-party administrators, other providers, and other utilization review entities that receive and respond to health care service review requests and inquiries. The UMO may or may not be the organization that makes the medical decision. The UMO might have a relationship with a payer that calls for the payer to make a decision or store information on completed referrals and certifications. It is the role of the UMO to forward that request or inquiry to the payer, receive the response from the payer, and then return the response to the requester. From the requester’s perspective, the exchange of information is between the requester and the UMO.

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 ASC X12 Technical Report Type 2, Acknowledgment Reference Model provides guidance on several control structures and transaction set standards intended to augment EDI auditing and control systems.

1.7 Related Transactions

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

TheASC X12 278 Health Care Services Review - Request for Review and Response, and the ASCX12 278 Health Care Services Review - Notification. Reference to specific versions of the 278 implementation standard is intentionally omitted to enable use of this transaction with any version of the 278.

In addition to the ASC X12 transactions listed above, the HL7 format standard is related to the 275.

1.7.1 The Health Care Services Review Response (278)

When a service request fails to complete the UMO's review, the UMO can respond with a 278 Health Care Services Review Response containing a request for additional information. Data from the original request is returned to the provider to facilitate locating the supporting information. The reason for the additional information is to aid in medical necessity decisions regarding the service requested.

1.7.2 Health Care Services Review Request (278)

When a request needs additional information to complete the review process, the provider can send an unsolicited 275 Additional Information to Support a Health Care Services Review in support of the 278 Health Care Services Review Request.

1.7.3 Health Care Services Review Notification (278)

The provider or information source can also send additional information in conjunction with a 278 Health Care Services Review Notification. For example, in a notification of discharge, the provider may need to attach information on the condition of the patient at the time of discharge; or a specialist may provide health care services outcome to the referring provider.

1.7.4 Health Level Seven (HL7)

The ANSI approved HL7 standard is used to convey the attachment content and is embedded in the 275. Relevant information can be found on the HL7 web site (www.HL7.org).

1.7.5 Application Advice (824)

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

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

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

The "Application Reporting for Insurance" Implementation Guide is available for insurance industry use. It is recommended that the 824 transaction be used to acknowledge the 275 with the embedded HL7 attachment information. The 824 transaction provides the ability to acknowledge multiple standards.

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 ASC X12 implementation guide requirements if the transaction satisfies all format and content rules and constraints specified in the applicable ASC X12 standards and the implementation guide (also known as a TR3) itself.

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

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

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

ASC 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 State and Federal Regulations

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

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

1.10 Data Overview

This section introduces the structure of the 275 and describes the positioning of the business data within that structure. Familiarity with ASC X12 nomenclature, segments, data elements, hierarchical levels, and looping structures is recommended. For a review, see X12.6 and Appendix C, EDI Control Directory.

This implementation guide assumes the use of the ASCII format. If a format other than ASCII is used, then the appropriate conversions must be applied wherever ASCII is explicitly required. The contents of the BDS segment must be encoded as text.

1.10.1 Data Needs for Business Purpose

When a request for additional information is made, the UMO supplies the parameters that assist the provider in locating the documents needed for the healthcare service review. These parameters are frequently the Patient Account Number, Patient Event Tracking Number, Diagnosis Code and Procedure Code or Revenue Code. The provider is the source of this information. If the information is found on the original 278 Health Care Services Review Request, the UMO returns those data elements in the 278 Health Care Services Review Response that contains the UMO's request for additional information.

If at the time of submitting the request for review, the provider determines that additional information is needed for completion of the review, an unsolicited 275 may be sent. In this usage the provider supplies the parameters to enable the UMO to match the supporting information to the 278 request for review.

When the Additional Information is submitted in the 275, it will either be related to the entire health care services review or to a specific revenue line or service line.

The following presents the developers' view of which segments are returned for patient event and service level information.

 
Loop ID

Segment
ID

 
Segment Name

 
Business Purpose

1000C Patient Name

NM1

Patient Name

Name of Patient

 

REF

Patient Account Number

Provider's Patient Account Number

2000A Assigned Number

LX

Assigned Number

A sequence number that starts at 1 and is incremented by 1 when the loop is repeated.

 

TRN

Attachment Reference Identifier

Identifier assigned by the UMO or Provider to uniquely identify this attachment.

 

STC

Status Information

Echo back the HI segment LOINC® information that specified the attachment information to provide.

 

HI

Health Care Information Codes

Patient event diagnosis the additional information supports. Use only if the additional information pertains to a specific diagnosis.

 

SVC

Service Information

Specific Revenue Code or Procedure Code with the additional information supports

 

REF

Service Trace Number

The number assigned by the provider to uniquely identify this service request when multiple services are requested.

2100A Date Additional Information Submitted

DTP

Date Additional Information Was Submitted

The 275 Submittal Date. Needed in order to use the BDS Segment

 

CAT

Category of Patient Information Service

Used to identify the type of information that will be in the BDS

2110A Associated Object Type ID

OOI

Associated Object Type Identification

Security Level of Data. Needed in order to use BDS Segment

 

BDS

Binary Data

HL7 Standard format (ASCII); Electronic Image; Binary Image- PDF, RTF or image objects (BASE 64 encoded within the MIME package); or Text (ASCII).

1.10.2 Transaction Identification and Purpose

The Transaction Set Header Segment (ST) identifies the transaction set by using 275 as the data value for the transaction set identifier code data element, ST01. The originator of the transaction set assigns the unique control number ST02 which is shown here as 1001. In this example, the originator is the provider. ST03 carries the same value that is populated in GS08 which is the Implementation Version Identifier. For this 275 transaction the identifier is 006020X316.

The Beginning Segment (BGN) indicates the transaction use. The Transaction Set Purpose Code value of "11" in the BGN01 indicates that this 275 is a response to a 278 Request for Additional Information Response. A value of "02" indicates that this is an unsolicited 275 with additional information for a 278 Healthcare Service Review. A value of "22" indicates that the information is in support of the 278 Health Care Services Review Notification. The originator of the transaction set assigns the unique reference number in BGN02 and the date of creation in BGN03. The Functional Group Header Segment (GS) provides additional identification of the business purpose of multi-functional transaction sets. See Appendix C, EDI Control Directory, for a detailed description of the elements in the GS segment. See Appendix B, Nomenclature, for descriptions of data element separators (e.g., *) and segment terminators (e.g., ~).

1.10.3 NM1 Loop Participants Identification Structure

The Loop ID: 1000 is repeated to define the participants involved in the transaction. The participants identified in the 275 are generally the information source, information receiver, and patient. The implementation guide specifies the participants in the subsequent loops within the transaction set and refers to these participants, respectively, in the following order and terms:

  • Information Source — This identifies the person or organization that owns/provides this patient information.
  • Information Receiver — This is the person or organization that is in receipt of this additional information.
  • Patient — This is the person receiving the services. The additional information supports the health care service review related to these services.

Loops 1000A, 1000B and 1000C contain the segments and data elements that describe the participants.

Loop 1000A - Information Source

Loop 1000B - Information Receiver

Loop 1000C - Patient

Patient REF Segment at the NM1 Level
The Patient Event Tracking Number in this REF is assigned by the provider and is the primary link between this 275 and itsassociated 278. The TRN enables the provider to link all transactions associated with this patient event. The REF segment can be repeated a maximum of two times at the Patient NM1 loop level for this implementation. The provider's patient account number, and the patient event tracking number are found in the REF segment. The Patient Account number is a supplemental identifier for the provider's use.

1.11 External References in this Guide

This implementation guide describes the intersection of X12 and Da Vinci data elements, so the information can be used consistently across implementations, regardless of syntax. Section 1.11, the FHIR mapping information provided in Section 2, and Appendix F are not part of the X12 EDI Standard or TR3 but are provided as a courtesy for organizations who are implementing multiple syntaxes.

1.11.1 The Da Vinci Project

Da Vinci is a private sector initiative, that addresses the needs of the Value Based Care Community by leveraging the Health Level 7 (HL7) Fast Healthcare Interoperability Resources (FHIR) platform. FHIR is an HL7 standard for exchanging healthcare information electronically. Da Vinci, an HL7 accelerator, and X12, an accredited Standards Developing Organization (SDO) have collaborated to produce materials to assist implementers in producing consistent electronic messaging.

Within this implementation guide are mapping instructions intended to inform implementers of the data relationships between the Da Vinci implementation guide and the X12 EDI Standard. These instructions delineate how the content maps between the FHIR exchange and the associated X12 segments and elements. The mapping appears in context in Section 2 of this implementation guide and as a standalone appendix.

1.11.1.1 The Da Vinci Prior Authorization Support Implementation Guide

The Da Vinci Project has developed a FHIR Implementation Guide titled Da Vinci Prior Authorization Support Implementation Guide (PAS). PAS provides a format to be used for creating a FHIR based message that contains the data necessary to create two X12 005010278 transactions and the X12 006020275. They are:

  • The 278 Health Care Services Review – Inquiry and Response
  • The 278 Health Care Services Review – Request and Response
  • The 275 Additional Information to Support a Health Care Services Review

X12 publishes detailed mappings specifically for use with the FHIR resource profiles contained within the Da Vinci PAS Implementation Guide for use by the industry. If subsequent changes are made to the Da Vinci PAS associated revisions may be applied to these mappings.

1.11.1.2 FHIR Resource Naming

FHIR naming methodology differs from the naming methodology of X12. To understand the mapping instructions provided an implementer must understand the following. A Bundle is the item exchanged between trading partners. The bundle contains a collection of resources that are composed of a set of structured data items as described by the name. One resource can be used for a variety of business purposes. The resource that includes the information needed for prior authorization and referrals (inquiry and request) is called Claim. ClaimResponse is the name of the resource used for a response to a prior authorization or referral inquiry or request.

1.11.1.3 FHIR Mapping Legend

The following conventions consistently describe the process of converting X12 messages from and to PAS compliant FHIR Resources.

  • The symbol '->' is used to show the translation of one value into another (code translation). This symbol should be read as 'becomes' or 'translates to'.
  • The symbol '=>' is used to follow the linkage from one FHIR resource to a related resource. This linkage traversal mechanism within a FHIR Bundle is described in the core FHIR Specification (v4.0.1) Section 2.36.4.1 Resolving References in Bundles. This symbol should be read as 'following reference to' or 'traversing reference'.
  • The symbol '|' is used when there are either multiple sources for the mapping or multiple destinations for the mapping. Mapping rules describe how to choose between the multiple sources or destinations. For example, a provider referenced on the Claim resource may be either a Practitioner resource or an Organization resource.
  • Single quotes "'" surround values that appear in codes and strings. These are fixed values (hard coded).
  • The values of true and false are not surrounded by single quotes as these are symbolic and the actual value used in implementations is dependent on technology (true may be 'T' or 't' or 'Y' or true).
  • Square brackets: '[' and ']'. Many of the elements in FHIR resources are arrays. An individual item from an array is indicated by a value enclosed in square brackets. For consistency, all array access is defined with a '0' base. So '[0]' is the first item in the array, '[1]' is the second item and '[n]' is an undetermined item within the array.
  • "out of scope": based on feedback to the Da Vinci Project PAS implementations will not include this information.
  • "no value - not populated from FHIR <resource-name>: there is no value in an attribute of the incoming FHIR Resource that can be used to populate the associated X12 attribute.
  • "no value - not populated for this use case": based on the use cases supported by PAS, this attribute is not expected to contain a value because the situation rule does not apply.
  • "not used on FHIR ClaimResponse": the outgoing FHIR ClaimResponse does not have an associated X12 element.
  • "cannot be populated into ClaimResponse at this time": there is a pending change request on the Da Vinci PAS FHIR profiles that will allow this attribute to be provided later.

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 ASC X12 standards are generic. For example, multiple trading communities use the same PER segment to specify administrative communication contacts. Each community decides which elements to use and which code values in those elements are applicable.

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

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

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 ASC X12 Examples website at http://examples.x12.org. The ASC X12 Examples website provides convenient access to examples of ASC X12 transaction transmissions, including the data stream and a description of the associated scenario.

Appendix A. External Code Sources

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://products.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 ASC 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 ASC 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 ASC X12 standard supports usage of exponential notation, this guide prohibits that usage.

Appendix D. Change Summary

This Implementation Guide (006020X316) defines the X12 requirements for the Additional Information to Support a Health Care Services Review. It is based on version/release/subrelease 006020 of the ASC X12 standards.

Appendix F. FHIR PAS Bundle to X12 275

This implementation guide describes the intersection of X12 and Da Vinci data elements, so the information can be used consistently across implementations, regardless of syntax. Section 1.11, the FHIR mapping information provided in Section 2, and Appendix F are not part of the X12 EDI Standard or TR3 but are provided as a courtesy for organizations who are implementing multiple syntaxes.

These instructions delineate how the data maps between the FHIR Claim elements and the associated X12 275 Bundle segments and elements.

Please review the information in Section 1.11 of this Implementation Guide for background and details on the mapping legend.

Segment - Loop Field Mapping/Notes Usage
ST The data elements in this segment are not defined in the PAS Bundle profile because the values are hardcoded or derived.
Implement with version: STU 1.0.0
R
ST01 '275'
Implement with version: STU 1.0.0
R
ST03 '006020X316'
Implement with version: STU 1.0.0
R
BGN The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
R
BGN01 '22'
Information Copy for 278 Health Care Services Review Notification
Implement with version: STU 1.0.0
R
BGN02 Bundle.identifier.value
Implement with version: STU 1.0.0
R
BGN03 Bundle.timestamp
Extract the date portion of the Bundle.timestamp to populate BGN03
Implement with version: STU 1.0.0
R
BGN04 Bundle.timestamp
Extract the date portion of the Bundle.timestamp to populate BGN04
Implement with version: STU 1.0.0
R
NM1 - 1000A Claim.provider => Organization
The Claim.provider will point to a Organization in the Bundle. Locate the Organization pointed at in the Claim and use that Organization for all of the fields in the 2010B Loop
Implement with version: STU 1.0.0
R
NM101 'ACV'
Implement with version: STU 1.0.0
R
NM102 '2'
Implement with version: STU 1.0.0
R
NM103 Organization.name
Implement with version: STU 1.0.0
R
NM104 no value - not populated from FHIR Bundle
Implement with version: STU 1.0.0
S
NM105 no value - not populated from FHIR Bundle
Implement with version: STU 1.0.0
S
NM107 no value - not populated from FHIR Bundle
Implement with version: STU 1.0.0
S
NM108 'XX'
Implement with version: STU 1.0.0
R
NM109 Organization.identifier[0].value
Implement with version: STU 1.0.0
R
NM110 '67'
Implement with version: STU 1.0.0
R
NM111 '1P'
Implement with version: STU 1.0.0
R
PER - 1000A The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
S
PER01 'IC'
Implement with version: STU 1.0.0
R
PER02 Organization.contact[0].name
Implement with version: STU 1.0.0
R
PER03 Organization.contact[0].telecom[0].system
The value from the system attribute is translated as follows:
'phone' -> 'TE'
'fax' -> 'FX'
'email' -> 'EM'
'pager' -> 'TE'
'url' -> 'UR'
'sms' -> 'TE'
'other' -> cannot be translated
Implement with version: STU 1.0.0
R
PER04 Organization.contact[0].telecom[0].value
If the value of system is 'phone', this value must be parsed to determine if an extension is present (see ITU-T E.123 for format of telephone values). If an extension is present, the remove the extension part of the phone number and place in PER06 and set PER05 to 'EX'
Implement with version: STU 1.0.0
R
PER05 Organization.contact[0].telecom[1].system | 'EX'
See PER04 if PER03 is 'TE' otherwise select the next telecom in contact[0] and translate the system as follows:
'phone' -> 'TE'
'fax' -> 'FX'
'email' -> 'EM'
'pager' -> 'TE'
'url' -> 'UR'
'sms' -> 'TE'
'other' -> cannot be translated
Implement with version: STU 1.0.0
S
PER06 Organization.contact[0].telecom[1].value | extracted extension
If PER05 is set to 'EX' this will be the extract value for the extension from PER04
Otherwise this is refer to PER04 for rules on formatting
Implement with version: STU 1.0.0
S
PER07 Organization.contact[0].telecom[n].system | 'EX'
See PER06 if PER05 is 'TE' otherwise select the next telecom in contact[0] and translate the system as follows:
'phone' -> 'TE'
'fax' -> 'FX'
'email' -> 'EM'
'pager' -> 'TE'
'url' -> 'UR'
'sms' -> 'TE'
'other' -> cannot be translated
Implement with version: STU 1.0.0
S
PER08 Organization.contact[0].telecom[n].value | extracted extension
If PER07 is set to 'EX' this will be the extract value for the extension from PER06
Otherwise this is refer to PER04 for rules on formatting
Implement with version: STU 1.0.0
S
REF - 1000A The data elements in this segment are not defined in the PAS Bundle profile.
Implement with version: STU 1.0.0
S
NM1 - 1000B Claim.insurer => Organization
The Claim.insurer will point to a Organization in the Bundle. Locate the Organization pointed at in the Claim and use that Organization for all of the fields in the 2010A Loop
Implement with version: STU 1.0.0
R
NM101 '40'
Implement with version: STU 1.0.0
R
NM102 '2'
Implement with version: STU 1.0.0
R
NM103 Organization.name
Implement with version: STU 1.0.0
R
NM104 no value - not populated from FHIR Bundle
Implement with version: STU 1.0.0
S
NM105 no value - not populated from FHIR Bundle
Implement with version: STU 1.0.0
S
NM107 no value - not populated from FHIR Bundle
Implement with version: STU 1.0.0
S
NM108 Organization.identifier[0].type.coding[0].code
Implement with version: STU 1.0.0
R
NM109 Organization.identifier[0].value
Implement with version: STU 1.0.0
R
NM110 '67'
Implement with version: STU 1.0.0
R
NM111 'PR'
Implement with version: STU 1.0.0
R
PER - 1000B The data elements in this segment are not defined in the PAS Bundle profile.
Implement with version: STU 1.0.0
S
REF - 1000B The data elements in this segment are not defined in the PAS Bundle profile.
Implement with version: STU 1.0.0
S
NM1 - 1000C Claim.patient => Patient
Locate the Patient Resource in the Bundle referenced in the Claim.patient attribute. Use the Patient Resource for all of the segments of the 2010D Loop
Implement with version: STU 1.0.0
R
NM101 see note
If Claim.insurance[0].coverage has Coverage.relationship.coding[0].code equal 'self' then insert 'IL'
Otherwise insert 'QC'
Implement with version: STU 1.0.0
R
NM102 '1'
Implement with version: STU 1.0.0
R
NM103 Patient.name[0].family
Implement with version: STU 1.0.0
R
NM104 Patient.name[0].given[0]
Implement with version: STU 1.0.0
S
NM105 Patient.name[0].given[1]
Implement with version: STU 1.0.0
S
NM107 Patient.name[0].suffix
Implement with version: STU 1.0.0
S
NM108 Patient.identifier[0].type.coding[0].code
Implement with version: STU 1.0.0
R
NM109 Patient.identifier[0].value
Implement with version: STU 1.0.0
R
REF - 1000C The data elements in this segment are not defined in the PAS Bundle profile.
Implement with version: STU 1.0.0
S
REF - 1000C The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
S
REF01 '2I'
Implement with version: STU 1.0.0
R
REF02 Claim.identifier[0].value
Implement with version: STU 1.0.0
R
LX - 2000A The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
R
LX01 '1'
Implement with version: STU 1.0.0
R
TRN - 2000A The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
R
TRN01 '2'
Implement with version: STU 1.0.0
R
TRN02 Claim.identifier[0].value
Implement with version: STU 1.0.0
R
STC - 2000A The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
S
STC01-01 no value - not populated when BGN01 = '22'
Implement with version: STU 1.0.0
R
STC01-02 no value - not populated when BGN01 = '22'
Implement with version: STU 1.0.0
R
STC01-04 no value - not populated when BGN01 = '22'
Implement with version: STU 1.0.0
R
STC10-01 no value - not populated for this use case
Implement with version: STU 1.0.0
R
STC10-02 no value - not populated for this use case
Implement with version: STU 1.0.0
R
STC10-04 no value - not populated for this use case
Implement with version: STU 1.0.0
R
STC11-01 no value - not populated for this use case
Implement with version: STU 1.0.0
R
STC11-02 no value - not populated for this use case
Implement with version: STU 1.0.0
R
STC11-04 no value - not populated for this use case
Implement with version: STU 1.0.0
R
REF - 2000A The data elements in this segment are not defined in the PAS Bundle profile.
Implement with version: STU 1.0.0
S
HI - 2000A The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
S
HI01-01 See note
Use the values from Claim.diagnosis[0] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
R
HI01-02 Claim.diagnosis[0].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
R
HI02-01 See note
Use the values from Claim.diagnosis[1] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
R
HI02-02 Claim.diagnosis[1].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
R
HI03-01 See note
Use the values from Claim.diagnosis[2] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
R
HI03-02 Claim.diagnosis[2].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
R
HI04-01 See note
Use the values from Claim.diagnosis[3] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
R
HI04-02 Claim.diagnosis[3].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
R
HI05-01 See note
Use the values from Claim.diagnosis[4] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
R
HI05-02 Claim.diagnosis[4].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
R
HI06-01 See note
Use the values from Claim.diagnosis[5] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
R
HI06-02 Claim.diagnosis[5].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
R
HI07-01 See note
Use the values from Claim.diagnosis[6] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
R
HI07-02 Claim.diagnosis[6].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
R
HI08-01 See note
Use the values from Claim.diagnosis[7] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
R
HI08-02 Claim.diagnosis[7].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
R
HI09-01 See note
Use the values from Claim.diagnosis[8] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
R
HI09-02 Claim.diagnosis[8].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
R
HI10-01 See note
Use the values from Claim.diagnosis[9] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
R
HI10-02 Claim.diagnosis[9].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
R
HI11-01 See note
Use the values from Claim.diagnosis[10] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
R
HI11-02 Claim.diagnosis[10].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
R
HI12-01 See note
Use the values from Claim.diagnosis[11] in the mapping table DiagnosisTypeCodeMapping to determine this value.
Implement with version: STU 1.0.0
R
HI12-02 Claim.diagnosis[11].diagnosisCodeableConcept.coding[0].code
Implement with version: STU 1.0.0
R
SVC - 2000A The data elements in this segment are not defined in the PAS Bundle profile.
Implement with version: STU 1.0.0
S
DTP - 2100A The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
R
DTP01 '368'
Implement with version: STU 1.0.0
R
DTP02 'D8'
Implement with version: STU 1.0.0
R
DTP03 Bundle.timestamp
Implement with version: STU 1.0.0
R
CAT - 2100A The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
R
CAT01 'AE'
Implement with version: STU 1.0.0
R
CAT02 'HL'
Implement with version: STU 1.0.0
R
CAT03 no value - not populated for this use case
Implement with version: STU 1.0.0
S
OOI - 2110A The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
R
OOI01 '1'
Implement with version: STU 1.0.0
R
OOI02 '47'
Implement with version: STU 1.0.0
R
OOI03 'ATTACHMENT'
Implement with version: STU 1.0.0
R
BDS - 2110A The data elements in this segment are defined in the PAS Bundle profile, see the FHIR Mapping instructions for each data element below.
Implement with version: STU 1.0.0
R
BDS01 'B64'
Implement with version: STU 1.0.0
R
BDS02 see note
Calculate the size of the entire Bundle submission and use that value for the BDS02
Implement with version: STU 1.0.0
R
BDS03 Bundle
Place the entire contents of the Bundle submission in the BDS03
Implement with version: STU 1.0.0
R
SE The data elements in this segment are not defined in the PAS Bundle profile.
Implement with version: STU 1.0.0
R