274 Transaction Set Listing

006020X290 Acknowledgment For Health Care Insurance
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✱:~
ISA
✱
1
I01
Author Info
Qualifier
M 1
ID
2
✱
2
I02
Author
Information
M 1
AN
10
✱
3
I03
Security
Info Qual
M 1
ID
2
✱
4
I04
Security
Information
M 1
AN
10
✱
5
I05
Interchange
ID Qual
M 1
ID
2
✱
6
I06
Interchange
Sender ID
M 1
AN
15
✱
7
I05
Interchange
ID Qual
M 1
ID
2
✱
8
I07
Interchange
Receiver ID
M 1
AN
15
✱
9
I08
Interchange
Date
M 1
DT
6
✱
10
I09
Interchange
Time
M 1
TM
4
✱
11
I65
Repetition
Separator
M 1
✱
12
I11
Inter Ctrl
Version Num
M 1
ID
5
✱
13
I12
Inter Ctrl
Number
M 1
N
9
✱
14
I13
Ack
Requested
M 1
ID
1
✱
15
I14
Usage
Indicator
M 1
ID
1
✱
16
I15
Component
Elem Sepera
M 1
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
I01
Authorization Information Qualifier
M 1
ID
2
Code identifying the type of information in the Authorization Information
CODE
DEFINITION
00
No Authorization Information Present (No Meaningful Information in I02)
03
Additional Data Identification
Required
2
I02
Authorization Information
M 1
AN
10
Information used for additional identification or authorization of the interchange sender or the data in the interchange; the type of information is set by the Authorization Information Qualifier (I01)
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*FA - 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✱006020X290~
GS
✱
1
479
Functional
ID Code
M 1
ID
2
✱
2
142
Application
Send's Code
M 1
AN
2/15
✱
3
124
Application
Rec's Code
M 1
AN
2/15
✱
4
373
Date
M 1
DT
8
✱
5
337
Time
M 1
TM
4/8
✱
6
28
Group Ctrl
Number
M 1
N
1/9
✱
7
455
Responsible
Agency Code
M 1
ID
1/2
✱
8
480
Ver/Release
ID Code
M 1
AN
1/12
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
479
Functional Identifier Code
M 1
ID
2
Code identifying a group of application related transaction sets
This is the 2-character Functional Identifier Code assigned to each transaction set by X12. The specific code for a transaction set defined by this implementation guide is presented in Section 1.2, Version Information.
CODE
DEFINITION
FA
Functional or Implementation Acknowledgment Transaction Sets (997, 999)
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
006020X290
Acknowledgment For Health Care Insurance

ST*999 - TRANSACTION SET HEADER

X12 Name:
Transaction Set Header
X12 Purpose:
To indicate the start of a transaction set and to assign a control number
X12 Set Notes:
  1. NOTE: Neither the 997 nor the 999 Acknowledgment shall be acknowledged, thereby preventing an endless cycle of acknowledgments of acknowledgments. Nor shall a Implementation Acknowledgment be sent to report errors in a previous Implementation Acknowledgment.
  2. NOTE: There is only one Implementation Acknowledgment Transaction Set per acknowledged functional group.
  3. NOTE: Only one acknowledgement can be sent for each functional group. The acknowledgment can be either a single Transaction Set 997 or a single Transaction Set 999 as mutually agreed upon by the trading partners. Different Functional Groups may have different acknowledgements, e.g. some Functional Groups, within the same interchange, may be acknowledged with the 997 and others with the 999.
Segment Usage:
Required
Segment Repeat:
1
TR3 Notes:
When acknowledging a healthcare implementation guide (TR3) based transaction, only a single transaction set 999 can be used. When acknowledging a healthcare implementation guide (TR3) based transaction, the transaction set 997 must not be used.
TR3 Example:
ST✱999✱0001✱006020X290~
ST
✱
1
143
TS ID
Code
M 1
ID
3
✱
2
329
TS Control
Number
M 1
AN
4/9
✱
3
1705
Imple Conv
Reference
O 1
AN
1/35
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
143
Transaction Set Identifier Code
M 1
ID
3
Code uniquely identifying a Transaction Set
SEMANTIC: The transaction set identifier (ST01) is used by the translation routines of the interchange partners to select the appropriate transaction set definition (e.g., 810 selects the Invoice Transaction Set).
CODE
DEFINITION
999
Implementation Acknowledgment
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. The number is assigned by the originator and must be unique within a functional group (GS-GE). For example, start with the number 0001 and increment from there. The 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.
This field contains the same value as data element GS08. This value is always 006020X290 when this implementation guide is used. Some translator products strip off the ISA and GS segments prior to application processing. Providing the information from GS08 at this level will help ensure the appropriate application mapping is utilized at translation time.
CODE
DEFINITION
006020X290
Acknowledgment For Health Care Insurance

AK1 - FUNCTIONAL GROUP RESPONSE HEADER

X12 Name:
Functional Group Response Header
X12 Purpose:
To start acknowledgment of a functional group
X12 Set Notes:
  1. NOTE: AK1 is used to respond to the functional group header and to start the acknowledgment for a functional group. There shall be one AK1 segment for the functional group that is being acknowledged.
  2. NOTE: The Implementation Acknowledgement is generated at the point of translation, intended for the originator (not any intermediate parties).
  3. NOTE: The Functional Group Header Segment (GS) is used to start the envelope for the Implementation Acknowledgment Transaction Sets. In preparing the functional group of acknowledgments, the application sender's code and the application receiver's code, taken from the functional group being acknowledged, are exchanged; therefore, one acknowledgment functional group responds to only those functional groups from one application receiver's code to one application sender's code.
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
AK1✱HC✱0001✱006020X259~
AK1
✱
1
479
Functional
ID Code
M 1
ID
2
✱
2
28
Group Ctrl
Number
M 1
N
1/9
✱
3
480
Ver/Release
ID Code
O 1
AN
1/12
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
479
Functional Identifier Code
M 1
ID
2
Code identifying a group of application related transaction sets
SEMANTIC: AK101 is the functional ID found in the GS segment (GS01) in the functional group being acknowledged.
Use the value in GS01 from the functional group to which this 999 transaction set is responding.
Required
2
28
Group Control Number
M 1
N
1/9
Assigned number originated and maintained by the sender
SEMANTIC: AK102 is the functional group control number found in the GS segment in the functional group being acknowledged.
Use the value in GS06 from the functional group to which this 999 transaction set is responding.
Required
3
480
Version / Release / Industry Identifier Code
O 1
AN
1/12
Code indicating the version, release, subrelease, and industry identifier of the EDI standard being used, including the GS and GE segments; if code in DE455 in GS segment is X, then in DE 480 positions 1-3 are the version number; positions 4-6 are the release and subrelease, level of the version; and positions 7-12 are the industry or trade association identifiers (optionally assigned by user); if code in DE455 in GS segment is T, then other formats are allowed
SEMANTIC: AK103 is the version release industry identifier code in the GS segment (GS08) in the functional group being acknowledged.
INDUSTRY NAME: Version, Release, or Industry Identifier Code
Use the value in GS08 from the functional group to which this 999 transaction set is responding.
CODE SOURCE 881: Version / Release / Industry Identifier Code

AK2 - TRANSACTION SET RESPONSE HEADER

X12 Name:
Transaction Set Response Header
X12 Purpose:
To start acknowledgment of a single transaction set
X12 Set Notes:
NOTE: AK2 is used to start the acknowledgment of a transaction set within the received functional group. The AK2 segments shall appear in the same order as the transaction sets in the functional group that has been received and is being acknowledged.
Loop:
Loop AK2 - TRANSACTION SET RESPONSE HEADER
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required when an error is present in a transaction set contained in the functional group to which this 999 transaction set is responding. If not required by this implementation guide, may be provided at the sender's discretion but cannot be required by the receiver.
TR3 Notes:
While it is not required that an AK2 loop be included for each transaction set received, it is required that an AK2 loop be included for each transaction set that contains an error. When AK2 loops are included in this transaction set, they must be in the same order as received in the functional group to which this 999 is responding.
TR3 Example:
AK2✱837✱0001✱006020X259~
AK2
✱
1
143
TS ID
Code
M 1
ID
3
✱
2
329
TS Control
Number
M 1
AN
4/9
✱
3
1705
Imple Conv
Reference
O 1
AN
1/35
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
143
Transaction Set Identifier Code
M 1
ID
3
Code uniquely identifying a Transaction Set
SEMANTIC: AK201 is the transaction set ID found in the ST segment (ST01) in the transaction set being acknowledged.
Use the value in ST01 from the transaction set to which this 999 transaction set is responding.
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
SEMANTIC: AK202 is the transaction set control number found in the ST segment in the transaction set being acknowledged.
Use the value in ST02 from the transaction set to which this 999 transaction set is responding.
Situational
3
1705
Implementation Convention Reference
O 1
AN
1/35
Reference assigned to identify Implementation Convention
SEMANTIC: AK203 is the implementation convention reference, if any, found in the ST segment (ST03) in the transaction set being acknowledged.
SITUATIONAL RULE: Required when the ST03 value is available in the transaction set to which this 999 transaction set is responding. If not required by this implementation guide, do not send.
When used, this is the value in ST03 from the transaction set to which this 999 transaction set is responding.

IK3 - ERROR IDENTIFICATION

X12 Name:
Implementation Data Segment Note
X12 Purpose:
To report implementation errors in a data segment and identify the location of the data segment
X12 Set Notes:
COMMENT: The data segments of this standard are used to report the results of the syntactical analysis of the functional groups of transaction sets; they report the extent to which the syntax complies with the standards or proper subsets of transaction sets and functional groups as expressed in compliant implementation guides. They do not report on the semantic meaning of the transaction sets (for example, on the ability of the receiver to comply with the request of the sender).
Loop:
Loop IK3 - ERROR IDENTIFICATION
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required when an error is present in the transaction set identified in this AK2 loop and the location of the data segment containing the error can be identified by the submitter of this 999. If not required by this implementation guideline, do not send.
TR3 Example:
IK3✱DMG✱31✱2000✱8~
IK3
✱
1
721
Segment ID
Code
M 1
ID
2/3
✱
2
719
Segment Pos
in TS
M 1
N
1/10
✱
3
447
Loop ID
Code
O 1
AN
1/4
✱
4
620
Imple Seg
Syn Er Code
O 1
ID
1/3
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
721
Segment ID Code
M 1
ID
2/3
Code defining the segment ID of the data segment in error (See Appendix A - Number 77)
CODE SOURCE 77: X12 Directories
Required
2
719
Segment Position in Transaction Set
M 1
N
1/10
The numerical count position of this data segment from the start of the transaction set: the transaction set header is count position 1
The value to use in IK302 is the numerical count position of this data segment, relative to the transaction set instance (not the transaction set diagram), from the start of the transaction set. The transaction set header (i.e. ST) is count position 1.
Situational
3
447
Loop Identifier Code
O 1
AN
1/4
The loop ID number given on the transaction set diagram is the value for this data element in segments LS and LE
SITUATIONAL RULE: Required when the data segment containing the error is within an LS loop and the LS01 value is known by the submitter of this 999, or when the data segment containing the error is within another type of loop and the loop identifier value from the transaction set diagram is known by the submitter of this 999. If not required by this implementation guide, do not send.
Only the first four characters of the loop identifier must be used.
Required
4
620
Implementation Segment Syntax Error Code
O 1
ID
1/3
Code indicating implementation error found based on the syntax editing of a segment
CODE
DEFINITION
1
Unrecognized segment ID
2
Unexpected segment
3
Required Segment Missing
4
Loop Occurs Over Maximum Times
5
Segment Exceeds Maximum Use
6
Segment Not in Defined Transaction Set
7
Segment Not in Proper Sequence
8
Segment Has Data Element Errors
I4
Implementation "Not Used" Segment Present
I6
Implementation Dependent Segment Missing
I7
Implementation Loop Occurs Under Minimum Times
I8
Implementation Segment Below Minimum Use
I9
Implementation Dependent "Not Used" Segment Present

CTX - SEGMENT CONTEXT

X12 Name:
Context
X12 Purpose:
Describes an event context in terms of the application or implementation contexts in force at the time the event occurred and the position in the EDI stream at which that context was activated
Loop:
Loop IK3 - ERROR IDENTIFICATION
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
9
Situational Rule:
Required when the error identified in this IK3 loop was triggered by a situational requirement of the implementation guide and the error occurs at the segment level. If not required by this implementation guide, do not send.
TR3 Notes:
The CTX segment is used to identify the data that triggered the situational requirement.
TR3 Example:
CTX✱SITUATIONAL TRIGGER✱CLM✱43✱✱5:3~CTX✱SITUATIONAL TRIGGER✱CLM✱43✱✱2✱782~
CTX
✱
1
C998
Context
Identificat
M 10
✱
2
721
Segment ID
Code
O 1
ID
2/3
✱
3
719
Segment Pos
in TS
O 1
N
1/10
✱
4
447
Loop ID
Code
O 1
AN
1/4
✱
5
C030
Position
in Segment
O 1
✱
6
C999
Reference
in Segment
O 1
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
C998
Context Identification
M 10
Holds information to identify a context
Required
1-1
9999
Context Name
M 1
AN
1/35
Holds the name or 'tag' of a context
Always contains the value "SITUATIONAL TRIGGER".
Not Used
1-2
9998
Context Reference
O 1
AN
1/35
Required
2
721
Segment ID Code
O 1
ID
2/3
Code defining the segment ID of the data segment in error (See Appendix A - Number 77)
CODE SOURCE 77: X12 Directories
Required
3
719
Segment Position in Transaction Set
O 1
N
1/10
The numerical count position of this data segment from the start of the transaction set: the transaction set header is count position 1
Situational
4
447
Loop Identifier Code
O 1
AN
1/4
The loop ID number given on the transaction set diagram is the value for this data element in segments LS and LE
SITUATIONAL RULE: Required when the data segment containing the situational requirement is within an LS loop and the LS01 value is known by the submitter of this 999, or when the data segment containing the situational requirement is within another type of loop and the loop identifier value from the transaction set diagram is known by the submitter of this 999. If not required by this implementation guide, do not send.
Only the first four characters of the loop identifier must be used.
Situational
5
C030
Position in Segment
O 1
Code indicating the relative position of the simple data element or composite data structure in error within a segment, count beginning with 1 for the position immediately following the segment ID; additionally indicating the relative position of a repeating structure in error, count beginning with 1 for the position immediately following the preceding element separator; additionally indicating the relative position of a component of a composite data structure in error, count beginning with 1 for the position following the preceding element or repetition separator
SITUATIONAL RULE: Required when the situational requirement relates to an element. If not required by this implementation guide, do not send.
Required
5-1
722
Element Position in Segment
M 1
N
1/2
This is used to indicate the relative position of a simple data element, or the relative position of a composite data structure with the relative position of the component within the composite data structure, in error; in the data segment the count starts with 1 for the simple data element or composite data structure immediately following the segment ID
Situational
5-2
1528
Component Data Element Position in Composite
O 1
N
1/2
To identify the component data element position within the composite that is in error
SITUATIONAL RULE: Required when the situational requirement relates to a component data element within a composite data structure. If not required by this implementation guide, do not send.
Situational
5-3
1686
Repeating Data Element Position
O 1
N
1/4
To identify the specific repetition of a data element that is in error
SITUATIONAL RULE: Required when the situational requirement relates to a repeating data element. If not required by this implementation guide, do not send.
Situational
6
C999
Reference in Segment
O 1
To hold the reference number of a data element and optionally a component data element within a composite
X12 COMPOSITE SEMANTIC NOTES:
  1. This element holds the reference number of the simple or composite element at segment level.
  2. This element holds the reference number of the simple element within a composite.
SITUATIONAL RULE: Required when CTX05 is used and the data element reference number of the data element identified in CTX05-01 is known by the submitter of the 999, and it is NOT a composite data element. If not required by this implementation guide, do not send.
Required
6-1
725
Data Element Reference Number
M 1
N
1/4
Reference number used to locate the data element in the Data Element Dictionary
INDUSTRY NAME: Context Data Element Reference Number
CODE SOURCE 77: X12 Directories
Not Used
6-2
725
Data Element Reference Number
O 1
N
1/4

CTX - BUSINESS UNIT IDENTIFIER

X12 Name:
Context
X12 Purpose:
Describes an event context in terms of the application or implementation contexts in force at the time the event occurred and the position in the EDI stream at which that context was activated
Loop:
Loop IK3 - ERROR IDENTIFICATION
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
1
Situational Rule:
Required when the error reported in this IK3 loop is within a business unit and the business unit identifier is known by the submitter of the 999. If not required by this implementation guide, do not send.
TR3 Example:
CTX✱CLM01:123456789~
CTX
✱
1
C998
Context
Identificat
M 10
✱
2
721
Segment ID
Code
O 1
ID
2/3
✱
3
719
Segment Pos
in TS
O 1
N
1/10
✱
4
447
Loop ID
Code
O 1
AN
1/4
✱
5
C030
Position
in Segment
O 1
✱
6
C999
Reference
in Segment
O 1
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
C998
Context Identification
M 10
Holds information to identify a context
Required
1-1
9999
Context Name
M 1
AN
1/35
Holds the name or 'tag' of a context
This contains one of the following values, depending on the value in AK201:
TRN02 269 business unit identifier
TRN02 270 business unit identifier
TRN02 271 business unit identifier
NM109 274 business unit identifier
PATIENT NAME NM109 275 business unit identifier
TRN02 276 business unit identifier
TRN02 277 business unit identifier
SUBSCRIBER NAME NM109 278 business unit identifier
ENT01 820 business unit identifier
SUBSCRIBER NUMBER REF02 834 business unit identifier
TRN02 835 business unit identifier
CLM01 837 business unit identifier
Required
1-2
9998
Context Reference
O 1
AN
1/35
Holds a reference to or for a context
  1. This contains the value from the business unit identifier specified in CTX01-01.
  2. When the below identified data elements are used and exceed a length of 35 characters, truncate and use the first 35 characters.
    See PDF for table.
Not Used
2
721
Segment ID Code
O 1
ID
2/3
Not Used
3
719
Segment Position in Transaction Set
O 1
N
1/10
Not Used
4
447
Loop Identifier Code
O 1
AN
1/4
Not Used
5
C030
Position in Segment
O 1
Not Used
6
C999
Reference in Segment
O 1

IK4 - IMPLEMENTATION DATA ELEMENT NOTE

X12 Name:
Implementation Data Element Note
X12 Purpose:
To report implementation errors in a data element or composite data structure and identify the location of the data element
Loop:
Loop IK4 - IMPLEMENTATION DATA ELEMENT NOTE
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
Situational Rule:
Required when the error in the segment described in the IK3 segment applies to a data element and the location of the data element containing the error can be identified by the submitter of the 999. If not required by this implementation guideline, do not send.
TR3 Example:
IK4✱1:3✱98✱1✱0002~
IK4
✱
1
C030
Position
in Segment
M 1
✱
2
725
Data Elemnt
Ref Number
O 1
N
1/4
✱
3
621
Imple Data
Syn Er Code
M 1
ID
1/3
✱
4
724
Copy of Bad
Data Elemnt
O 1
AN
1/99
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
C030
Position in Segment
M 1
Code indicating the relative position of the simple data element or composite data structure in error within a segment, count beginning with 1 for the position immediately following the segment ID; additionally indicating the relative position of a repeating structure in error, count beginning with 1 for the position immediately following the preceding element separator; additionally indicating the relative position of a component of a composite data structure in error, count beginning with 1 for the position following the preceding element or repetition separator
Required
1-1
722
Element Position in Segment
M 1
N
1/2
This is used to indicate the relative position of a simple data element, or the relative position of a composite data structure with the relative position of the component within the composite data structure, in error; in the data segment the count starts with 1 for the simple data element or composite data structure immediately following the segment ID
Situational
1-2
1528
Component Data Element Position in Composite
O 1
N
1/2
To identify the component data element position within the composite that is in error
SITUATIONAL RULE: Required when the error described in this segment relates to a component data element within a composite data structure. If not required by this implementation guide, do not send.
Situational
1-3
1686
Repeating Data Element Position
O 1
N
1/4
To identify the specific repetition of a data element that is in error
SITUATIONAL RULE: Required when the error described in this segment relates to a repeating data element. If not required by this implementation guide, do not send.
Situational
2
725
Data Element Reference Number
O 1
N
1/4
Reference number used to locate the data element in the Data Element Dictionary
SITUATIONAL RULE: Required when the data element reference number for the data in error is known, and it is NOT a composite data element. If not required by this implementation guide, do not send.
CODE SOURCE 77: X12 Directories
Required
3
621
Implementation Data Element Syntax Error Code
M 1
ID
1/3
Code indicating the implementation error found after syntax edits of a data element
CODE
DEFINITION
1
Required Data Element Missing
2
Conditional Required Data Element Missing
3
Too Many Data Elements
4
Data Element Too Short
5
Data Element Too Long
6
Invalid Character In Data Element
7
Invalid Code Value
8
Invalid Date
9
Invalid Time
10
Exclusion Condition Violated
12
Too Many Repetitions
13
Too Many Components
I10
Implementation "Not Used" Data Element Present
I11
Implementation Too Few Repetitions
I12
Implementation Pattern Match Failure
I13
Implementation Dependent "Not Used" Data Element Present
I6
Code Value Not Used in Implementation
I9
Implementation Dependent Data Element Missing
Situational
4
724
Copy of Bad Data Element
O 1
AN
1/99
This is a copy of the data element in error
SITUATIONAL RULE: Required unless invalid characters are present, data is missing, or the data is from a binary data element. If not required by this implementation guide, do not send.

CTX - ELEMENT CONTEXT

X12 Name:
Context
X12 Purpose:
Describes an event context in terms of the application or implementation contexts in force at the time the event occurred and the position in the EDI stream at which that context was activated
X12 Set Notes:
NOTE: The CTX Segment shall be used to disambiguate a reported error that is dependent on context.
Loop:
Loop IK4 - IMPLEMENTATION DATA ELEMENT NOTE
Loop Usage:
Situational
Segment Usage:
Situational
Segment Repeat:
10
Situational Rule:
Required when the error identified in this IK4 loop was triggered by a situational requirement of the implementation guide and the error occurs at the element level. If not required by this implementation guide, do not send.
TR3 Notes:
The CTX segment is used to identify the data that triggered the situational requirement.
TR3 Example:
CTX✱SITUATIONAL TRIGGER✱CLM✱43✱✱5:3~CTX✱SITUATIONAL TRIGGER✱CLM✱43✱✱2✱782~
CTX
✱
1
C998
Context
Identificat
M 10
✱
2
721
Segment ID
Code
O 1
ID
2/3
✱
3
719
Segment Pos
in TS
O 1
N
1/10
✱
4
447
Loop ID
Code
O 1
AN
1/4
✱
5
C030
Position
in Segment
O 1
✱
6
C999
Reference
in Segment
O 1
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
C998
Context Identification
M 10
Holds information to identify a context
Required
1-1
9999
Context Name
M 1
AN
1/35
Holds the name or 'tag' of a context
Always contains the value "SITUATIONAL TRIGGER".
Not Used
1-2
9998
Context Reference
O 1
AN
1/35
Required
2
721
Segment ID Code
O 1
ID
2/3
Code defining the segment ID of the data segment in error (See Appendix A - Number 77)
CODE SOURCE 77: X12 Directories
Required
3
719
Segment Position in Transaction Set
O 1
N
1/10
The numerical count position of this data segment from the start of the transaction set: the transaction set header is count position 1
Situational
4
447
Loop Identifier Code
O 1
AN
1/4
The loop ID number given on the transaction set diagram is the value for this data element in segments LS and LE
SITUATIONAL RULE: Required when the data segment containing the situational requirement is within an LS loop and the LS01 value is known by the submitter of this 999, or when the data segment containing the situational requirement is within another type of loop and the loop identifier value from the transaction set diagram is known by the submitter of this 999. If not required by this implementation guide, do not send.
Only the first four characters of the loop identifier must be used.
Required
5
C030
Position in Segment
O 1
Code indicating the relative position of the simple data element or composite data structure in error within a segment, count beginning with 1 for the position immediately following the segment ID; additionally indicating the relative position of a repeating structure in error, count beginning with 1 for the position immediately following the preceding element separator; additionally indicating the relative position of a component of a composite data structure in error, count beginning with 1 for the position following the preceding element or repetition separator
Required
5-1
722
Element Position in Segment
M 1
N
1/2
This is used to indicate the relative position of a simple data element, or the relative position of a composite data structure with the relative position of the component within the composite data structure, in error; in the data segment the count starts with 1 for the simple data element or composite data structure immediately following the segment ID
Situational
5-2
1528
Component Data Element Position in Composite
O 1
N
1/2
To identify the component data element position within the composite that is in error
SITUATIONAL RULE: Required when the situational requirement relates to a component data element within a composite data structure. If not required by this implementation guide, do not send.
Situational
5-3
1686
Repeating Data Element Position
O 1
N
1/4
To identify the specific repetition of a data element that is in error
SITUATIONAL RULE: Required when the situational requirement relates to a repeating data element. If not required by this implementation guide, do not send.
Situational
6
C999
Reference in Segment
O 1
To hold the reference number of a data element and optionally a component data element within a composite
X12 COMPOSITE SEMANTIC NOTES:
  1. This element holds the reference number of the simple or composite element at segment level.
  2. This element holds the reference number of the simple element within a composite.
SITUATIONAL RULE: Required when CTX05 is used and the data element reference number of the data element identified in CTX05-01 is known by the submitter of the 999, and it is NOT a composite data element. If not required by this implementation guide, do not send.
Required
6-1
725
Data Element Reference Number
M 1
N
1/4
Reference number used to locate the data element in the Data Element Dictionary
CODE SOURCE 77: X12 Directories
Not Used
6-2
725
Data Element Reference Number
O 1
N
1/4

IK5 - TRANSACTION SET RESPONSE TRAILER

X12 Name:
Implementation Transaction Set Response Trailer
X12 Purpose:
To acknowledge acceptance or rejection and report implementation errors in a transaction set
X12 Set Notes:
NOTE: If any implementation guide errors have been reported in IK3 or IK4, then code I5 shall be reported in the IK5 Segment.
Loop:
Loop AK2 - TRANSACTION SET RESPONSE HEADER
Loop Usage:
Situational
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
IK5✱R✱5~
IK5
✱
1
717
TS Ack
Code
M 1
ID
1
✱
2
618
Imple TS
Syn Er Code
O 1
ID
1/3
✱
3
618
Imple TS
Syn Er Code
O 1
ID
1/3
✱
4
618
Imple TS
Syn Er Code
O 1
ID
1/3
✱
5
618
Imple TS
Syn Er Code
O 1
ID
1/3
✱
6
618
Imple TS
Syn Er Code
O 1
ID
1/3
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
717
Transaction Set Acknowledgment Code
M 1
ID
1
Code indicating accept or reject condition based on the syntax editing of the transaction set
CODE
DEFINITION
A
Accepted
E
Accepted But Errors Were Noted
The transaction set indicated in this AK2 loop contained errors, but was forwarded for further processing.
M
Rejected, Message Authentication Code (MAC) Failed
R
Rejected
The transaction set indicated in this AK2 loop contained errors, and was NOT forwarded for further processing. It will need to be corrected and resubmitted.
W
Rejected, Assurance Failed Validity Tests
X
Rejected, Content After Decryption Could Not Be Analyzed
Situational
2
618
Implementation Transaction Set Syntax Error Code
O 1
ID
1/3
Code indicating implementation error found based on the syntax editing of a transaction set
SITUATIONAL RULE: Required when IK501 = E or R. If not required by this implementation guide, do not send.
CODE
DEFINITION
1
Transaction Set Not Supported
2
Transaction Set Trailer Missing
3
Transaction Set Control Number in Header and Trailer Do Not Match
4
Number of Included Segments Does Not Match Actual Count
5
One or More Segments in Error
6
Missing or Invalid Transaction Set Identifier
7
Missing or Invalid Transaction Set Control Number
8
Authentication Key Name Unknown
9
Encryption Key Name Unknown
10
Requested Service (Authentication or Encrypted) Not Available
11
Unknown Security Recipient
12
Incorrect Message Length (Encryption Only)
13
Message Authentication Code Failed
15
Unknown Security Originator
16
Syntax Error in Decrypted Text
17
Security Not Supported
18
Transaction Set not in Functional Group
19
Invalid Transaction Set Implementation Convention Reference
23
Transaction Set Control Number Not Unique within the Functional Group
24
S3E Security End Segment Missing for S3S Security Start Segment
25
S3S Security Start Segment Missing for S3E Security End Segment
26
S4E Security End Segment Missing for S4S Security Start Segment
27
S4S Security Start Segment Missing for S4E Security End Segment
I5
Implementation One or More Segments in Error
I6
Implementation Convention Not Supported
Situational
3
618
Implementation Transaction Set Syntax Error Code
O 1
ID
1/3
Code indicating implementation error found based on the syntax editing of a transaction set
SITUATIONAL RULE: Required when IK501 = E or R, and IK502 has been used, and there are additional error codes to report. If not required by this implementation guide, do not send.
CODE
DEFINITION
1
Transaction Set Not Supported
2
Transaction Set Trailer Missing
3
Transaction Set Control Number in Header and Trailer Do Not Match
4
Number of Included Segments Does Not Match Actual Count
5
One or More Segments in Error
6
Missing or Invalid Transaction Set Identifier
7
Missing or Invalid Transaction Set Control Number
8
Authentication Key Name Unknown
9
Encryption Key Name Unknown
10
Requested Service (Authentication or Encrypted) Not Available
11
Unknown Security Recipient
12
Incorrect Message Length (Encryption Only)
13
Message Authentication Code Failed
15
Unknown Security Originator
16
Syntax Error in Decrypted Text
17
Security Not Supported
18
Transaction Set not in Functional Group
19
Invalid Transaction Set Implementation Convention Reference
23
Transaction Set Control Number Not Unique within the Functional Group
24
S3E Security End Segment Missing for S3S Security Start Segment
25
S3S Security Start Segment Missing for S3E Security End Segment
26
S4E Security End Segment Missing for S4S Security Start Segment
27
S4S Security Start Segment Missing for S4E Security End Segment
I5
Implementation One or More Segments in Error
I6
Implementation Convention Not Supported
Situational
4
618
Implementation Transaction Set Syntax Error Code
O 1
ID
1/3
Code indicating implementation error found based on the syntax editing of a transaction set
SITUATIONAL RULE: Required when IK501 = E or R, and IK502 and IK503 have been used, and there are additional error codes to report. If not required by this implementation guide, do not send.
CODE
DEFINITION
1
Transaction Set Not Supported
2
Transaction Set Trailer Missing
3
Transaction Set Control Number in Header and Trailer Do Not Match
4
Number of Included Segments Does Not Match Actual Count
5
One or More Segments in Error
6
Missing or Invalid Transaction Set Identifier
7
Missing or Invalid Transaction Set Control Number
8
Authentication Key Name Unknown
9
Encryption Key Name Unknown
10
Requested Service (Authentication or Encrypted) Not Available
11
Unknown Security Recipient
12
Incorrect Message Length (Encryption Only)
13
Message Authentication Code Failed
15
Unknown Security Originator
16
Syntax Error in Decrypted Text
17
Security Not Supported
18
Transaction Set not in Functional Group
19
Invalid Transaction Set Implementation Convention Reference
23
Transaction Set Control Number Not Unique within the Functional Group
24
S3E Security End Segment Missing for S3S Security Start Segment
25
S3S Security Start Segment Missing for S3E Security End Segment
26
S4E Security End Segment Missing for S4S Security Start Segment
27
S4S Security Start Segment Missing for S4E Security End Segment
I5
Implementation One or More Segments in Error
I6
Implementation Convention Not Supported
Situational
5
618
Implementation Transaction Set Syntax Error Code
O 1
ID
1/3
Code indicating implementation error found based on the syntax editing of a transaction set
SITUATIONAL RULE: Required when IK501 = E or R, and IK502, IK503, and IK504 have been used, and there are additional error codes to report. If not required by this implementation guide, do not send.
CODE
DEFINITION
1
Transaction Set Not Supported
2
Transaction Set Trailer Missing
3
Transaction Set Control Number in Header and Trailer Do Not Match
4
Number of Included Segments Does Not Match Actual Count
5
One or More Segments in Error
6
Missing or Invalid Transaction Set Identifier
7
Missing or Invalid Transaction Set Control Number
8
Authentication Key Name Unknown
9
Encryption Key Name Unknown
10
Requested Service (Authentication or Encrypted) Not Available
11
Unknown Security Recipient
12
Incorrect Message Length (Encryption Only)
13
Message Authentication Code Failed
15
Unknown Security Originator
16
Syntax Error in Decrypted Text
17
Security Not Supported
18
Transaction Set not in Functional Group
19
Invalid Transaction Set Implementation Convention Reference
23
Transaction Set Control Number Not Unique within the Functional Group
24
S3E Security End Segment Missing for S3S Security Start Segment
25
S3S Security Start Segment Missing for S3E Security End Segment
26
S4E Security End Segment Missing for S4S Security Start Segment
27
S4S Security Start Segment Missing for S4E Security End Segment
I5
Implementation One or More Segments in Error
I6
Implementation Convention Not Supported
Situational
6
618
Implementation Transaction Set Syntax Error Code
O 1
ID
1/3
Code indicating implementation error found based on the syntax editing of a transaction set
SITUATIONAL RULE: Required when IK501 = E or R, and IK502, IK503, IK504, and IK505 have been used, and there are additional error codes to report. If not required by this implementation guide, do not send.
CODE
DEFINITION
1
Transaction Set Not Supported
2
Transaction Set Trailer Missing
3
Transaction Set Control Number in Header and Trailer Do Not Match
4
Number of Included Segments Does Not Match Actual Count
5
One or More Segments in Error
6
Missing or Invalid Transaction Set Identifier
7
Missing or Invalid Transaction Set Control Number
8
Authentication Key Name Unknown
9
Encryption Key Name Unknown
10
Requested Service (Authentication or Encrypted) Not Available
11
Unknown Security Recipient
12
Incorrect Message Length (Encryption Only)
13
Message Authentication Code Failed
15
Unknown Security Originator
16
Syntax Error in Decrypted Text
17
Security Not Supported
18
Transaction Set not in Functional Group
19
Invalid Transaction Set Implementation Convention Reference
23
Transaction Set Control Number Not Unique within the Functional Group
24
S3E Security End Segment Missing for S3S Security Start Segment
25
S3S Security Start Segment Missing for S3E Security End Segment
26
S4E Security End Segment Missing for S4S Security Start Segment
27
S4S Security Start Segment Missing for S4E Security End Segment
I5
Implementation One or More Segments in Error
I6
Implementation Convention Not Supported

AK9 - FUNCTIONAL GROUP RESPONSE TRAILER

X12 Name:
Functional Group Response Trailer
X12 Purpose:
To acknowledge acceptance or rejection of a functional group and report the number of included transaction sets from the original trailer, the accepted sets, and the received sets in this functional group
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
AK9✱R✱1✱1✱0~
AK9
✱
1
715
Funct Group
Ack Code
M 1
ID
1
✱
2
97
Number of
TS Included
M 1
N
1/6
✱
3
123
Number of
Received TS
M 1
N
1/6
✱
4
2
Number of
Accepted TS
M 1
N
1/6
✱
5
716
Funct Group
Error Code
O 1
ID
1/3
✱
6
716
Funct Group
Error Code
O 1
ID
1/3
✱
7
716
Funct Group
Error Code
O 1
ID
1/3
✱
8
716
Funct Group
Error Code
O 1
ID
1/3
✱
9
716
Funct Group
Error Code
O 1
ID
1/3
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
715
Functional Group Acknowledge Code
M 1
ID
1
Code indicating accept or reject condition based on the syntax editing of the functional group
COMMENT: If AK901 contains the value "A" or "E", then the transmitted functional group is accepted.
CODE
DEFINITION
A
Accepted
This code value can only be used if there are no AK2 loops or all IK501 values = `A'.
E
Accepted, But Errors Were Noted.
The functional group indicated in this 999 contained errors, but was forwarded for further processing.
M
Rejected, Message Authentication Code (MAC) Failed
P
Partially Accepted, At Least One Transaction Set Was Rejected
R
Rejected
The functional group indicated in this 999 contained errors, and was NOT forwarded for further processing. It will need to be corrected and resubmitted.
W
Rejected, Assurance Failed Validity Tests
X
Rejected, Content After Decryption Could Not Be Analyzed
Required
2
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
3
123
Number of Received Transaction Sets
M 1
N
1/6
Number of Transaction Sets received
Required
4
2
Number of Accepted Transaction Sets
M 1
N
1/6
Number of accepted Transaction Sets in a Functional Group
Situational
5
716
Functional Group Syntax Error Code
O 1
ID
1/3
Code indicating error found based on the syntax editing of the functional group header and/or trailer
SITUATIONAL RULE: Required when AK901 = E or R, and the error is at the functional group level. If not required by this implementation guide, do not send.
CODE
DEFINITION
1
Functional Group Not Supported
2
Functional Group Version Not Supported
3
Functional Group Trailer Missing
4
Group Control Number in the Functional Group Header and Trailer Do Not Agree
5
Number of Included Transaction Sets Does Not Match Actual Count
6
Group Control Number Violates Syntax
7
Invalid Application Sender's Code
8
Invalid Application Receiver's Code
9
Invalid Responsible Agency Code
10
Authentication Key Name Unknown
11
Encryption Key Name Unknown
12
Requested Service (Authentication or Encryption) Not Available
13
Unknown Security Recipient
14
Unknown Security Originator
15
Syntax Error in Decrypted Text
16
Security Not Supported
17
Incorrect Message Length (Encryption Only)
18
Message Authentication Code Failed
19
Functional Group Control Number not Unique within Interchange
23
S3E Security End Segment Missing for S3S Security Start Segment
24
S3S Security Start Segment Missing for S3E End Segment
25
S4E Security End Segment Missing for S4S Security Start Segment
26
S4S Security Start Segment Missing for S4E Security End Segment
30
Invalid Group Date
31
Invalid Group Time
Situational
6
716
Functional Group Syntax Error Code
O 1
ID
1/3
Code indicating error found based on the syntax editing of the functional group header and/or trailer
SITUATIONAL RULE: Required when AK901 = E or R, and AK905 has been used, and there are additional error codes to report. If not required by this implementation guide, do not send.
CODE
DEFINITION
1
Functional Group Not Supported
2
Functional Group Version Not Supported
3
Functional Group Trailer Missing
4
Group Control Number in the Functional Group Header and Trailer Do Not Agree
5
Number of Included Transaction Sets Does Not Match Actual Count
6
Group Control Number Violates Syntax
7
Invalid Application Sender's Code
8
Invalid Application Receiver's Code
9
Invalid Responsible Agency Code
10
Authentication Key Name Unknown
11
Encryption Key Name Unknown
12
Requested Service (Authentication or Encryption) Not Available
13
Unknown Security Recipient
14
Unknown Security Originator
15
Syntax Error in Decrypted Text
16
Security Not Supported
17
Incorrect Message Length (Encryption Only)
18
Message Authentication Code Failed
19
Functional Group Control Number not Unique within Interchange
23
S3E Security End Segment Missing for S3S Security Start Segment
24
S3S Security Start Segment Missing for S3E End Segment
25
S4E Security End Segment Missing for S4S Security Start Segment
26
S4S Security Start Segment Missing for S4E Security End Segment
30
Invalid Group Date
31
Invalid Group Time
Situational
7
716
Functional Group Syntax Error Code
O 1
ID
1/3
Code indicating error found based on the syntax editing of the functional group header and/or trailer
SITUATIONAL RULE: Required when AK901 = E or R, and AK905 and AK906 have been used, and there are additional error codes to report. If not required by this implementation guide, do not send.
CODE
DEFINITION
1
Functional Group Not Supported
2
Functional Group Version Not Supported
3
Functional Group Trailer Missing
4
Group Control Number in the Functional Group Header and Trailer Do Not Agree
5
Number of Included Transaction Sets Does Not Match Actual Count
6
Group Control Number Violates Syntax
7
Invalid Application Sender's Code
8
Invalid Application Receiver's Code
9
Invalid Responsible Agency Code
10
Authentication Key Name Unknown
11
Encryption Key Name Unknown
12
Requested Service (Authentication or Encryption) Not Available
13
Unknown Security Recipient
14
Unknown Security Originator
15
Syntax Error in Decrypted Text
16
Security Not Supported
17
Incorrect Message Length (Encryption Only)
18
Message Authentication Code Failed
19
Functional Group Control Number not Unique within Interchange
23
S3E Security End Segment Missing for S3S Security Start Segment
24
S3S Security Start Segment Missing for S3E End Segment
25
S4E Security End Segment Missing for S4S Security Start Segment
26
S4S Security Start Segment Missing for S4E Security End Segment
30
Invalid Group Date
31
Invalid Group Time
Situational
8
716
Functional Group Syntax Error Code
O 1
ID
1/3
Code indicating error found based on the syntax editing of the functional group header and/or trailer
SITUATIONAL RULE: Required when AK901 = E or R, and AK905, AK906, and AK907 have been used, and there are additional error codes to report. If not required by this implementation guide, do not send.
CODE
DEFINITION
1
Functional Group Not Supported
2
Functional Group Version Not Supported
3
Functional Group Trailer Missing
4
Group Control Number in the Functional Group Header and Trailer Do Not Agree
5
Number of Included Transaction Sets Does Not Match Actual Count
6
Group Control Number Violates Syntax
7
Invalid Application Sender's Code
8
Invalid Application Receiver's Code
9
Invalid Responsible Agency Code
10
Authentication Key Name Unknown
11
Encryption Key Name Unknown
12
Requested Service (Authentication or Encryption) Not Available
13
Unknown Security Recipient
14
Unknown Security Originator
15
Syntax Error in Decrypted Text
16
Security Not Supported
17
Incorrect Message Length (Encryption Only)
18
Message Authentication Code Failed
19
Functional Group Control Number not Unique within Interchange
23
S3E Security End Segment Missing for S3S Security Start Segment
24
S3S Security Start Segment Missing for S3E End Segment
25
S4E Security End Segment Missing for S4S Security Start Segment
26
S4S Security Start Segment Missing for S4E Security End Segment
30
Invalid Group Date
31
Invalid Group Time
Situational
9
716
Functional Group Syntax Error Code
O 1
ID
1/3
Code indicating error found based on the syntax editing of the functional group header and/or trailer
SITUATIONAL RULE: Required when AK901 = E or R, and AK905, AK906, AK907, and AK908 have been used, and there are additional error codes to report. If not required by this implementation guide, do not send.
CODE
DEFINITION
1
Functional Group Not Supported
2
Functional Group Version Not Supported
3
Functional Group Trailer Missing
4
Group Control Number in the Functional Group Header and Trailer Do Not Agree
5
Number of Included Transaction Sets Does Not Match Actual Count
6
Group Control Number Violates Syntax
7
Invalid Application Sender's Code
8
Invalid Application Receiver's Code
9
Invalid Responsible Agency Code
10
Authentication Key Name Unknown
11
Encryption Key Name Unknown
12
Requested Service (Authentication or Encryption) Not Available
13
Unknown Security Recipient
14
Unknown Security Originator
15
Syntax Error in Decrypted Text
16
Security Not Supported
17
Incorrect Message Length (Encryption Only)
18
Message Authentication Code Failed
19
Functional Group Control Number not Unique within Interchange
23
S3E Security End Segment Missing for S3S Security Start Segment
24
S3S Security Start Segment Missing for S3E End Segment
25
S4E Security End Segment Missing for S4S Security Start Segment
26
S4S Security Start Segment Missing for S4E Security End Segment
30
Invalid Group Date
31
Invalid Group Time

SE - TRANSACTION SET TRAILER

X12 Name:
Transaction Set Trailer
X12 Purpose:
To indicate the end of the transaction set and provide the count of the transmitted segments (including the beginning (ST) and ending (SE) segments)
X12 Comments:
SE is the last segment of each transaction set.
Segment Usage:
Required
Segment Repeat:
1
TR3 Example:
SE✱1230✱0001~
SE
✱
1
96
Number of
Inc Segs
M 1
N
1/10
✱
2
329
TS Control
Number
M 1
AN
4/9
~
USAGE
SEQ
D.E. NUM
NAME
ATTRIBUTES
Required
1
96
Number of Included Segments
M 1
N
1/10
Total number of segments included in a transaction set including ST and SE segments
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. The number is assigned by the originator and must be unique within a functional group (GS-GE). For example, start with the number 0001 and increment from there. The number also aids in error resolution research.

GE - FUNCTIONAL GROUP TRAILER

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

IEA - INTERCHANGE CONTROL TRAILER

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

999 Implementation Acknowledgment For Health Care Insurance (006020X290)

SEPTEMBER 2013

Copyright © 2008-2023, X12 Incorporated, Format © 2008-2023 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 purpose of this implementation guide is to provide standardized data content and structure to users of the ASC X12 999 transaction set for Health Care Insurance.

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

The purpose of this implementation guide is to provide standardized data content and structure to users of the ASC X12 999 transaction set for Health Care Insurance. This implementation guide is intended to enable a receiver of a functional group based on an X12 Implementation Guideline (TR3) related to Health Care Insurance business processes, to report syntactical errors as specified by that transaction's implementation guideline (TR3), or to acknowledge receipt of an error-free transaction set.

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 006020X290.

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

  • FA   Functional or Implementation Acknowledgment Transaction Sets (997, 999)

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.

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

The ASC X12 999 transaction set is designed to report conformance against an implementation guideline (TR3), including syntax and relational conditions, based on an ASC X12 standard.

The 999 is not limited to only IG errors. It can report standard syntax errors, as well as IG errors.

This 999 implementation guide can NOT be used for any application level validations.

The ASC X12 999 transaction set is designed to respond to one and only one functional group (i.e. GS/GE), but will respond to all transaction sets (i.e. ST/SE) within that functional group.

When acknowledging a healthcare implementation guide (TR3) based transaction, only a single transaction set 999 can be used. When acknowledging a healthcare implementation guide (TR3) based transaction, the transaction set 997 must not be used.

This ASC X12 999 Implementation Guideline must NOT be used to respond to any management transaction sets intended for acknowledgments, i.e. TS 997 and 999, or interchange control segments related to acknowledgments, i.e. TA1 and TA3.

1.4 Business Usage

This ASC X12 999 implementation guide (TR3) is intended to meet the needs of the Health Care industry.

  1. For a standard implementation guideline designed for reporting of syntactical and relational condition errors against a functional group based on an X12 Implementation Guideline,
  2. to report receipt of a functional group that fully complies with an implementation guideline.

For more information on the relationship between the 999 transaction set and other response transaction sets, refer to the ASC X12 document "X12 Acknowledgement Reference Model".

1.4.1 Health Care Transaction Flow

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

1.5 Business Terminology

Business Unit
A unique unit of work that will trigger or support a business process.

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.

Refer to appropriate TR3 and ASC X12 Technical Report Type 2, Acknowledgment Reference Model for real time usage.

1.7 Related Transactions

This ASC X12 999 Implementation Guide (TR3) is designed for responding to Health Care transactions based upon an Implementation Guide, including, but not limited to, the following TR3 documents and associated errata:

270 006020X280
271 006020X280
274 006020X206
275 006020X275
276 006020X267
277 006020X267
277 006020X268
277 006020X269
277 006020X270
278 006020X266
820 006020X284
824 006020X257
834 006020X283
835 006020X258
837 006020X259
837 006020X260
837 006020X261
837 006020X262

1.8 Trading Partner Agreements

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

1.9 HIPAA Role in Implementation Guides

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

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

1.10.1 Overall Data Architecture

NOTE
See X12.6 to review the transaction set structure, including descriptions of segments, data elements, levels and loops.

1.10.1.1 Response Process

The following sequence diagram (sd) shows how the 999 transaction set is used with other X12 response transactions.

Figure 1.1 - Sequence Diagram

Sequence Diagram

For more information on the relationship between the 999 transaction set and other response transaction sets, refer to the ASC X12 document "X12 Acknowledgement Reference Model".

2. Transaction Set

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

2.1 Presentation Examples

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

In this implementation guide, IMPLEMENTATION specifies the requirements for this implementation. X12 STANDARD is included as a reference only.

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

2.3 Transaction Set Listing

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

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

This section is included as a reference.

2.4 Segment Detail

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

This section is included as a reference.

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

This section specifies the implementation details of each data element.

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

Figure 2.1 - Transaction Set Key - Implementation

Transaction Set Key - Implementation

Figure 2.2 - Transaction Set Key - Standard

Transaction Set Key - Standard

Figure 2.3 - Segment Key - Implementation

Segment Key - Implementation

Figure 2.4 - Segment Key - Diagram

Segment Key - Diagram

Figure 2.5 - Segment Key - Element Summary

Segment Key - Element Summary

2.2.1 Industry Usage

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

Required  

This loop/segment/element must always be sent.

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

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

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

Not Used  

This element must never be sent.

Situational  

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

There are two forms of Situational Rules.

The first form is "Required when <explicit condition statement>. If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver."
The data qualified by such a situational rule cannot be required, 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.

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

2.2.1.1 Transaction Compliance Related to Industry Usage

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

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

This table specifies how an entity is to evaluate a transmitted transaction for compliance with industry usage. It is not intended to require or imply that the receiver must reject non-compliant transactions. The receiver will handle non-compliant transactions based on its business process and any applicable regulations.

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

 

Appendix A. External Code Sources

Appendix A is a listing of all external code sources referenced in this implementation guide.

  • Where an external code source is referenced, 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.

77 X12 Directories

SIMPLE DATA ELEMENT/CODE REFERENCES

721, 725

SOURCE

X12.3 Data Element Dictionary
X12.22 Segment Directory

AVAILABLE FROM

Data Interchange Standards Association, Inc. (DISA)
Suite 200
1800 Diagonal Road
Alexandria, VA 22314-2852

ABSTRACT

The data element dictionary contains the format and descriptions of data elements used to construct X12 segments. It also contains code lists associated with these data elements.The segment directory contains the format and definitions of the data segments used to construct X12 transaction sets.

121 Health Industry Number

SIMPLE DATA ELEMENT/CODE REFERENCES

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

SOURCE

Health Industry Number Database

AVAILABLE FROM

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

ABSTRACT

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

881 Version / Release / Industry Identifier Code

SIMPLE DATA ELEMENT/CODE REFERENCES

480

SOURCE

Data Interchange Standards Association

AVAILABLE FROM

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

ABSTRACT

Code indicating the version, release, sub-release, and industry identifier of the EDI standard being used, including the GS and GE segments; if code in DE455 in GS segment is X, then in DE 480 positions 1-3 are the version number; positions 4-6 are the release and sub-release, level of the version; and positions 7-12 are the industry or trade association identifiers (optionally assigned by user); if code in DE455 in GS segment is T, then other formats are allowed.

B.1.1 Interchange and Application Control Structures

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

B.1.1.1 Interchange Control Structure

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 Delimiters

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

Table B.1 - Delimiters

CHARACTER NAME DELIMITER
* Asterisk Data Element Separator
^ Caret Repetition Separator
: Colon Component Element Separator
~ Tilde Segment Terminator


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

B.1.1.3 Data Element Lengths

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.3.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.3.2 Maximum Length of Data Element 782 Monetary Amount

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

EXAMPLE

For implementations governed by HIPAA:

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

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

 

B.2 Object Descriptors

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

  1. Transaction Set
  2. Loop
  3. Segment
  4. Composite Data Element
  5. Component Data Element
  6. Simple Data Element

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

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

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

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

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

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

Appendix D. Change Summary

Place changes from previous versions here.

F.1 Administrative Gender

Source code list
 X12 DE 1068 - Gender Code
 owned by ASC X12
 Element Attributes: 1/1 ID

Target code list
 SNOMED
 owned by International Health Terminology Standard Development Organisation (IHTSDO)

X12 DE 1068 - Gender Code

SNOMED

F - Female

1086007 Female structure (body structure)

M - Male

10052007 Male structure (body structure)

U - Unknown

37791004 Indeterminate sex (body structure)