837 Transaction Set Listing
008020X300 Post-adjudicated Claims Data Reporting: Dental- Loop 1000A - SUBMITTER NAMERequired1
- Loop 1000B - RECEIVER NAMERequired1
- Loop 2000A - BILLING PROVIDER HIERARCHICAL LEVELRequired>1
- Loop 2010AA - BILLING PROVIDER NAMERequired1
- Loop 2000B - SUBSCRIBER HIERARCHICAL LEVELRequired>1
- Loop 2010BA - SUBSCRIBER NAMERequired1
- Loop 2010BB - DATA RECEIVERRequired1
- Loop 2000C - PATIENT HIERARCHICAL LEVELSituational>1
- Loop 2010CA - PATIENT NAMERequired1
- Loop 2300 - CLAIM INFORMATIONRequired100
- Loop 2310A - REFERRING PROVIDER NAMESituational2
- Loop 2310B - RENDERING PROVIDER NAMESituational1
- Loop 2310C - SERVICE FACILITY LOCATION NAMERequired1
- Loop 2310D - ASSISTANT SURGEON NAMESituational1
- Loop 2310E - SUPERVISING PROVIDER NAMESituational1
- Loop 2320A - SUBSCRIBER INFORMATIONRequired1
- Loop 2330A - PAYER NAMERequired1
- Loop 2320B - OTHER PAYER SUBSCRIBER INFORMATIONSituational9
- Loop 2330BA - OTHER PAYER NAMERequired1
- Loop 2330BB - OTHER PAYER SUBSCRIBER NAMERequired1
- Loop 2330BC - OTHER PAYER PATIENT NAMESituational1
- Loop 2400 - SERVICE LINE NUMBERRequired50
- Loop 2420A - RENDERING PROVIDER NAMESituational1
- Loop 2420B - ASSISTANT SURGEON NAMESituational1
- Loop 2420C - SUPERVISING PROVIDER NAMESituational1
- Loop 2430 - LINE ADJUDICATION INFORMATIONSituational25
ISA - INTERCHANGE CONTROL HEADER
- 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.
- The first element separator defines the element separator to be used through the entire interchange.
- Spaces in the example interchanges are represented by "." for clarity.
- The ISA segment terminator defines the segment terminator used throughout the entire interchange.
- All positions within each of the data elements must be filled.
- The Interchange Control Number, ISA13, must be identical to the associated Interchange Trailer IEA02.
- Must be a positive unsigned number and must be identical to the value in IEA02.
GS*HC - FUNCTIONAL GROUP HEADER
ST*837 - TRANSACTION SET HEADER
- This element must be populated with the guide identifier named in Section 1.2.
- This field contains the same value as GS08. Some translator products strip off the ISA and GS segments prior to application (ST-SE) processing. Providing the information from the GS08 at this level will ensure that the appropriate application mapping is used at translation time.
BHT*0019 - BEGINNING OF HIERARCHICAL TRANSACTION
- The inventory file number of the transmission assigned by the submitter's system. This number operates as a batch control 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.
NM1*41 - SUBMITTER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
PER*IC - SUBMITTER EDI CONTACT INFORMATION
- P0304
If either PER03 or PER04 is present, then the other is required. - P0506
If either PER05 or PER06 is present, then the other is required. - P0708
If either PER07 or PER08 is present, then the other is required.
- 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-".
- The contact information in this segment identifies the person in the submitter organization who deals with data transmission issues. If data transmission problems arise, this is the person to contact in the submitter organization.
- There are 2 repetitions of the PER segment to allow for six possible combinations of communication numbers including extensions.
NM1*40 - RECEIVER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
HL - BILLING PROVIDER HIERARCHICAL LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
PRV*BI - BILLING PROVIDER SPECIALTY INFORMATION
If either PRV02 or PRV03 is present, then the other is required.
If not required by this implementation guide, do not send.
CUR*85 - FOREIGN CURRENCY INFORMATION
- C0807
If CUR08 is present, then CUR07 is required. - C0907
If CUR09 is present, then CUR07 is required. - L101112
If CUR10 is present, then at least one of CUR11 or CUR12 are required. - C1110
If CUR11 is present, then CUR10 is required. - C1210
If CUR12 is present, then CUR10 is required. - L131415
If CUR13 is present, then at least one of CUR14 or CUR15 are required. - C1413
If CUR14 is present, then CUR13 is required. - C1513
If CUR15 is present, then CUR13 is required. - L161718
If CUR16 is present, then at least one of CUR17 or CUR18 are required. - C1716
If CUR17 is present, then CUR16 is required. - C1816
If CUR18 is present, then CUR16 is required. - L192021
If CUR19 is present, then at least one of CUR20 or CUR21 are required. - C2019
If CUR20 is present, then CUR19 is required. - C2119
If CUR21 is present, then CUR19 is required.
NM1*85 - BILLING PROVIDER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
- The Billing Provider may be an individual only when the health care provider performing services is an independent, unincorporated entity. In these cases, the Billing Provider is the individual whose social security number is used for 1099 purposes. That individual's NPI is reported in NM109, and the individual's Tax Identification Number must be reported in the REF segment of this loop. The individual's NPI must be reported when the individual provider is eligible for an NPI.
- When the individual or the organization is not a health care provider and, thus, not eligible to receive an NPI (For example, personal care services, carpenters, etc), the Billing Provider should be the legal entity. However, willing trading partners may agree upon varying definitions. Proprietary identifiers necessary for the receiver to identify the entity are to be reported in the Loop ID-2010BB REF, Billing Provider Secondary Identification segment.
- The information provided in this segment is intended to be representative of the information as known to the payer's system.
N3 - BILLING PROVIDER ADDRESS
N4 - BILLING PROVIDER CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
REF - BILLING PROVIDER TAX IDENTIFICATION
At least one of REF02 or REF03 is required.
For example, "001122333" would be valid, while sending "001-12-2333" or "00-1122333" would be invalid.
REF*0B - BILLING PROVIDER LICENSE INFORMATION
At least one of REF02 or REF03 is required.
If not required by this implementation guide, do not send.
REF - BILLING PROVIDER SECONDARY IDENTIFICATION
At least one of REF02 or REF03 is required.
If not required by this implementation guide, do not send.
HL - SUBSCRIBER HIERARCHICAL LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
- The claim (Loop ID-2300) can be used when HL04 has no subordinate levels (HL04 = 0) or when HL04 has subordinate levels indicated (HL04 = 1).
- In the first case (HL04 = 0), the subscriber is the patient and there are no dependent claims.
- The second case (HL04 = 1) happens when claims for one or more dependents of the subscriber are being sent under the same billing provider HL (for example, a spouse and son are both treated by the same provider). In that case, the subscriber HL04 = 1 because there is at least one dependent to this subscriber. The dependent HL (spouse) would then be sent followed by the Loop ID-2300 for the spouse. The next HL would be the dependent HL for the son followed by the Loop ID-2300 for the son.
- In order to send claims for the subscriber and one or more dependents, the Subscriber HL, with Relationship Code SBR02=18 (Self), would be followed by the Subscriber's Loop ID-2300 for the Subscriber's claims. Then the Subscriber HL would be repeated, followed by one or more Patient HL loops for the dependents, with the proper Relationship Code in PAT01, each followed by their respective Loop ID-2300 for each dependent's claims.
SBR*N - SUBSCRIBER INFORMATION
NM1*IL - SUBSCRIBER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
- In worker's compensation or other property and casualty claims, the "subscriber" may be a non-person entity (for example, the employer). However, this varies by state.
- When submitting to an All Payer Claims Database or Health Benefit Exchange, this is the Subscriber as defined within the payers enrollment files. When submitting Medicare or Medicaid encounters, the patient is always the subscriber.
This data element is used only to indicate generation or patronymic.
N3 - SUBSCRIBER ADDRESS
N4 - SUBSCRIBER CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
DMG*D8 - SUBSCRIBER DEMOGRAPHIC INFORMATION
- P0102
If either DMG01 or DMG02 is present, then the other is required. - P1011
If either DMG10 or DMG11 is present, then the other is required. - C1105
If DMG11 is present, then DMG05 is required.
REF*SY - SUBSCRIBER SOCIAL SECURITY NUMBER
At least one of REF02 or REF03 is required.
The entity identified as the data receiver in Loop ID 2010BB is an All Payer Claims Database or Health Insurance Exchange.
AND
The social security number is allowed to be used for this purpose under applicable law or regulation.
AND
The social security number is available in the payer's system.
If not required by this implementation guide, do not send.
REF*Y4 - PROPERTY AND CASUALTY CLAIM NUMBER
At least one of REF02 or REF03 is required.
If not required by this implementation guide, do not send.
REF - SUBSCRIBER SECONDARY IDENTIFICATION
At least one of REF02 or REF03 is required.
AND
The data is available in the payer's system.
If not required by this implementation guide, then do not send.
NM1*ZD - DATA RECEIVER
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
HL - PATIENT HIERARCHICAL LEVEL
- The HL segment is used to identify levels of detail information using a hierarchical structure, such as relating line-item data to shipment data, and packaging data to line-item data.
- The HL segment defines a top-down/left-right ordered structure.
- The information reported in this loop describes the patient as known by the payer's system.
- When submitting Medicare and/or Medicaid encounters, the patient is always the subscriber and the Patient HL in Loop 2000C is not used.
- There are no HLs subordinate to the Patient HL.
PAT - PATIENT INFORMATION
- P0506
If either PAT05 or PAT06 is present, then the other is required. - P0708
If either PAT07 or PAT08 is present, then the other is required.
NM1*QC - PATIENT NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
N3 - PATIENT ADDRESS
N4 - PATIENT CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
DMG*D8 - PATIENT DEMOGRAPHIC INFORMATION
- P0102
If either DMG01 or DMG02 is present, then the other is required. - P1011
If either DMG10 or DMG11 is present, then the other is required. - C1105
If DMG11 is present, then DMG05 is required.
REF*SY - PATIENT SOCIAL SECURITY NUMBER
At least one of REF02 or REF03 is required.
The entity identified as the data receiver in Loop ID 2010BB is an All Payer Claims Database or Health Insurance Exchange.
AND
The social security number is allowed to be used for this purpose under applicable law or regulation.
AND
The social security number is available in the payer's system.
If not required by this implementation guide, do not send.
REF*Y4 - PROPERTY AND CASUALTY CLAIM NUMBER
At least one of REF02 or REF03 is required.
If not required by this implementation guide, do not send.
REF - PATIENT SECONDARY IDENTIFICATION
At least one of REF02 or REF03 is required.
AND
The data is available in the payer's system.
If not required by this implementation guide, then do not send.
CLM - CLAIM INFORMATION
- The Total Claim Charge Amount must be greater than or equal to zero.
- The total claim charge amount must balance to the sum of all service line charge amounts reported in the Dental Service (SV3) segments for this claim.
- This amount represents the sum of the line charge amounts included in this portion of the claim.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- C023-01 does not contain the last position of the Uniform Bill Type Code (the Claim Frequency Code).
- C023-02 qualifies C023-01.
DTP*439 - ACCIDENT DATE
If not required by this implementation guide, do not send.
DTP*452 - APPLIANCE PLACEMENT DATE
If not required by this implementation guide, do not send.
- Dates in Loop ID-2300 apply to all service lines within Loop ID-2400 unless a DTP segment occurs in Loop ID-2400 with the same value in DTP01. In that case, the DTP in Loop ID-2400 overrides the DTP in Loop ID-2300 for that service line only.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
DTP*472 - SERVICE DATE
If not required by this implementation guide, do not send.
- Dates in Loop ID-2300 apply to all service lines within Loop ID-2400 unless a DTP segment occurs in Loop ID-2400 with the same value in DTP01. In that case, the DTP in Loop ID-2400 overrides the DTP in Loop ID-2300 for that service line only.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
DN1 - ORTHODONTIC TOTAL MONTHS OF TREATMENT
If not required by this implementation guide, do not send.
- When reporting this segment, at least one of DN101, DN102 or DN104 must be present.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
- DN1✱36✱27~
- DN1✱✱✱✱Y~
DN2 - TOOTH STATUS
If either DN204 or DN205 is present, then the other is required.
If not required by this implementation guide, do not send.
- The Universal National Tooth Designation System must be used to identify tooth numbers for this element. See Code Source 135: American Dental Association.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
CN1 - CONTRACT INFORMATION
If not required by this implementation guide, do not send.
AMT*F5 - PATIENT AMOUNT PAID
If not required by this implementation guide, do not send.
- Patient Amount Paid refers to the sum of all amounts paid on the claim by the patient or his or her representative(s).
- If, for whatever reason, the data is not stored within the payer's system, do not use.
REF*9F - REFERRAL NUMBER
At least one of REF02 or REF03 is required.
If not required by this implementation guide, do not send.
- Numbers at this position apply to the entire claim unless they are overridden in the REF segment in Loop ID-2400. A reference identification is considered to be overridden if the value in REF01 is the same in both the Loop ID-2300 REF segment and the Loop ID-2400 REF segment. In that case, the Loop ID-2400 REF applies only to that specific line.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
REF*G1 - PRIOR AUTHORIZATION
At least one of REF02 or REF03 is required.
If not required by this implementation guide, do not send.
- Numbers at this position apply to the entire claim unless they are overridden in the REF segment in Loop ID-2400. A reference identification is considered to be overridden if the value in REF01 is the same in both the Loop ID-2300 REF segment and the Loop ID-2400 REF segment. In that case, the Loop ID-2400 REF applies only to that specific line.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
REF*D9 - CLAIM IDENTIFIER FOR TRANSMISSION INTERMEDIARIES
At least one of REF02 or REF03 is required.
This segment is used only when the payer is submitting this transaction to the Data Receiver through an intermediary that assigns their own unique claim number.
- The value carried in this element is limited to a maximum of 20 positions.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
K3 - FILE INFORMATION
If not required by this implementation guide, do not send.
- The K3 segment is expected to be used only when necessary to meet the unexpected data requirement of a legislative authority. Before this segment can be used:
- The X12N Health Care Claim workgroup must conclude there is no other available option in the implementation guide to meet the emergency legislative requirement.
- The requestor must submit a proposal for approval accompanied by the relevant business documentation to the X12N Health Care Claim workgroup chairs and receive approval for the request.
Upon review of the request, X12N will issue an approval or denial decision to the requesting entity. Approved usage(s) of the K3 segment will be reviewed by the X12N Health Care Claim workgroup to develop a permanent change to include the business case in future transaction implementations. - Only when all of the requirements above have been met, may the regulatory agency require the temporary use of the K3 segment.
- X12N will submit the necessary data maintenance and refer the request to the appropriate data content committee(s).
- If, for whatever reason, the data is not stored within the payer's system, do not use.
HI - HEALTH CARE DIAGNOSIS CODE
If not required by this implementation guide, do not send.
- Do not transmit the decimal point for ICD codes. The decimal point is implied.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
If a new rule names the SNODENT codes as an allowable code set under HIPAA,
OR
the Secretary of Health and Human Services grants an exception to use the code set as a pilot project.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
If a new rule names the SNODENT codes as an allowable code set under HIPAA,
OR
the Secretary of Health and Human Services grants an exception to use the code set as a pilot project.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
If a new rule names the SNODENT codes as an allowable code set under HIPAA,
OR
the Secretary of Health and Human Services grants an exception to use the code set as a pilot project.
- P0304
If either C02203 or C02204 is present, then the other is required. - E0809
Only one of C02208 or C02209 may be present.
- C022-01 qualifies C022-02, C022-04, C022-05, C022-06, C022-08 and C022-10.
- If C022-08 is used, then C022-02 represents the beginning value in a range of codes.
- C022-03 is the date format that will appear in C022-04.
- C022-07 qualifies C022-01.
- C022-08 represents the ending value in a range of codes.
- C022-09 is a value from Code Source 959 for the Present on Admission Indicator.
- C022-10 is the attribute of the code in C022-02 from the same code list.
If a new rule names the SNODENT codes as an allowable code set under HIPAA,
OR
the Secretary of Health and Human Services grants an exception to use the code set as a pilot project.
NM1 - REFERRING PROVIDER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
If not required by this implementation guide, do not send.
- When there is only one referral on the claim, use code "DN - Referring Provider". When more than one referral exists and there is a requirement to report the additional referral, use code DN in the first iteration of this loop to indicate the referral received by the rendering provider on this claim. Use code "P3 - Primary Care Provider" in the second iteration of the loop to indicate the initial referral from the primary care provider or whatever provider wrote the initial referral for this patient's episode of care being billed/reported in this transaction.
- When reporting the provider who ordered services such as diagnostic and lab, use the 2310A loop at the claim level.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
PRV*RF - REFERRING PROVIDER SPECIALTY INFORMATION
If either PRV02 or PRV03 is present, then the other is required.
If not required by this implementation guide, do not send.
REF - REFERRING PROVIDER SECONDARY IDENTIFICATION
At least one of REF02 or REF03 is required.
If not required by this implementation guide, do not send.
- The REF segment in Loop ID-2310 applies to the entire claim unless overridden on the service line level by the presence of a REF segment with the same value in REF01.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
NM1*82 - RENDERING PROVIDER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.
- Information in Loop ID-2310 applies to the entire claim unless overridden on a service line by the presence of Loop ID-2420 with the same value in NM101.
- Used for all types of rendering providers including laboratories. The Rendering Provider is the person or company (laboratory or other facility) who rendered the care. In the case where a substitute provider (locum tenens) was used, enter that provider's information here.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
PRV*PE - RENDERING PROVIDER SPECIALTY INFORMATION
If either PRV02 or PRV03 is present, then the other is required.
If not required by this implementation guide, do not send.
- The PRV segment in Loop ID-2310 applies to the entire claim unless overridden on the service line level by the presence of a PRV segment with the same value in PRV01.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
REF - RENDERING PROVIDER SECONDARY IDENTIFICATION
At least one of REF02 or REF03 is required.
If not required by this implementation guide, do not send.
- The REF segment in Loop ID-2310 applies to the entire claim unless overridden on the service line level by the presence of a REF segment with the same value in REF01.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
NM1*77 - SERVICE FACILITY LOCATION NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
- Information in Loop ID-2310 applies to the entire claim unless overridden on a service line by the presence of Loop ID-2420 with the same value in NM101.
- This is the Service Location as reported on the originally submitted claim from the provider. If the Service Location loop was not used on the original claim, use the address information reported in Loop 2010AA of the provider's claim.
N3 - SERVICE FACILITY LOCATION ADDRESS
N4 - SERVICE FACILITY LOCATION CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
REF - SERVICE FACILITY LOCATION SECONDARY IDENTIFICATION
At least one of REF02 or REF03 is required.
If not required by this implementation guide, do not send.
NM1*DD - ASSISTANT SURGEON NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
If not required by this implementation guide, do not send.
- Information in Loop ID-2310 applies to the entire claim unless overridden on a service line by the presence of Loop ID-2420 with the same value in NM101.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
This data element is used only to indicate generation or patronymic.
PRV*AS - ASSISTANT SURGEON SPECIALTY INFORMATION
If either PRV02 or PRV03 is present, then the other is required.
If not required by this implementation guide, do not send.
- Information in Loop ID-2310 applies to the entire claim unless overridden on a service line by the presence of Loop ID-2420 with the same value in NM101.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
REF - ASSISTANT SURGEON SECONDARY IDENTIFICATION
At least one of REF02 or REF03 is required.
If not required by this implementation guide, do not send.
NM1*DQ - SUPERVISING PROVIDER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
If not required by this implementation guide, do not send.
- Information in Loop ID-2310 applies to the entire claim unless overridden on a service line by the presence of Loop ID-2420 with the same value in NM101.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
REF - SUPERVISING PROVIDER SECONDARY IDENTIFICATION
At least one of REF02 or REF03 is required.
If not required by this implementation guide, do not send.
SBR*R - SUBSCRIBER INFORMATION
Loop ID-2320A and its subordinate 2330 and 2430 loops convey information demonstrating how this claim was adjudicated by the submitting payer.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
- This is not the number uniquely identifying the subscriber. The unique subscriber number is submitted in Loop ID-2010BA.
CAS - CLAIM LEVEL ADJUSTMENTS
- L050607
If CAS05 is present, then at least one of CAS06 or CAS07 are required. - C0605
If CAS06 is present, then CAS05 is required. - C0705
If CAS07 is present, then CAS05 is required. - L080910
If CAS08 is present, then at least one of CAS09 or CAS10 are required. - C0908
If CAS09 is present, then CAS08 is required. - C1008
If CAS10 is present, then CAS08 is required. - L111213
If CAS11 is present, then at least one of CAS12 or CAS13 are required. - C1211
If CAS12 is present, then CAS11 is required. - C1311
If CAS13 is present, then CAS11 is required. - L141516
If CAS14 is present, then at least one of CAS15 or CAS16 are required. - C1514
If CAS15 is present, then CAS14 is required. - C1614
If CAS16 is present, then CAS14 is required. - L171819
If CAS17 is present, then at least one of CAS18 or CAS19 are required. - C1817
If CAS18 is present, then CAS17 is required. - C1917
If CAS19 is present, then CAS17 is required.
- Only one Group Code is allowed per CAS. If it is necessary to send more than one Group Code at the claim level, repeat the CAS segment.
- A single CAS segment contains six repetitions of the "adjustment trio" composed of adjustment reason code, adjustment amount, and adjustment quantity. These six adjustment trios are used to report up to six adjustments related to a particular Claim Adjustment Group Code (CAS01). The first non-zero adjustment is reported in the first adjustment trio (CAS02-CAS04). If there is a second non-zero adjustment, it is reported in the second adjustment trio (CAS05-CAS07), and so on through the sixth adjustment trio (CAS17-CAS19).
- Codes and amounts must be reported the same as if creating the 835 to send to the provider.
- CAS✱PR✱1✱7.93~
- CAS✱OA✱93✱15.06~
AMT*D - COORDINATION OF BENEFITS (COB) PAYER PAID AMOUNT
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- It is acceptable to show "0" as the amount paid.
OI - PAYER CLAIM ADJUSTMENT/VOID INDICATOR
MOA - OUTPATIENT ADJUDICATION INFORMATION
NM1*PR - PAYER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
DTP*573 - CLAIM CHECK OR REMITTANCE DATE
REF - OTHER PAYER SECONDARY IDENTIFIER
At least one of REF02 or REF03 is required.
AND
The data is available in the payer's system.
If not required by this implementation guide, then do not send.
For example, "001122333" would be valid, while sending "001-12-2333" or "00-1122333" would be invalid.
REF*F8 - PAYER CLAIM CONTROL NUMBER
At least one of REF02 or REF03 is required.
REF*BP - PAYER PREVIOUS CLAIM CONTROL NUMBER
At least one of REF02 or REF03 is required.
REF*PHC - METHOD OF CLAIM/ENCOUNTER SUBMISSION
At least one of REF02 or REF03 is required.
If not required by this implementation guide, do not send.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
- The information reported in this element must reflect the method in which this claim was received by the submitting payer. Codes reported in REF02 must be one of the following:
C - Crossover
Use when the claim was automatically crossed over from one payer to another.
D - Direct Data Entry
Use when the claim was manually entered through a DDE terminal or web portal.
E - Electronic Submission
Use when the claim was electronically submitted through a transmission or via upload by web portal.
O - Other
Use when the claim was submitted in a different format other than DDE, web portal, electronic or paper.
P - Paper
Use when the claim was submitted via paper, including paper claims put through an OCR process by the payer.
REF*CE - IN PLAN NETWORK INDICATOR
At least one of REF02 or REF03 is required.
SBR - OTHER PAYER SUBSCRIBER INFORMATION
- All information contained in Loop ID-2320B applies only to the payer identified in Loop ID-2330BA. It is specific only to that payer. If information for an additional payer is necessary, repeat Loop ID-2320B with its respective 2330 Loops.
- Loop ID-2320B and its subordinate 2330 and 2430 loops convey information demonstrating how this claim was adjudicated by the payers who have previously adjudicated the claim.
- This loop is not to be provided for payers who have not adjudicated the claim. For example, the provider submitted claim includes payer information that is subsequent to the payer submitting this transaction.
- The payer and adjudication information related to this iteration of Loop ID-2320B and 2430 represents processing performed prior to the adjudication of this claim by the submitting payer and the Other Payer information is to be reported as received from the provider.
- Within a given claim, the various values for the Payer Responsibility Sequence Number Code (other than value "U") may occur no more than once.
- When sending Line Adjudication Information for this payer, the identifier sent in SVD01 (Payer Responsibility Sequence Code) of Loop ID-2430 (Line Adjudication Information) must match this value when used.
- This is not the number uniquely identifying the subscriber. The unique subscriber number is submitted in Loop ID-2330BB NM109 for this iteration of Loop ID-2320B.
- Refer to Appendix B.1.1.2.1 Maximum Length of Data Element 127 Reference Identification for more information about this data element length.
CAS - CLAIM LEVEL ADJUSTMENTS
- L050607
If CAS05 is present, then at least one of CAS06 or CAS07 are required. - C0605
If CAS06 is present, then CAS05 is required. - C0705
If CAS07 is present, then CAS05 is required. - L080910
If CAS08 is present, then at least one of CAS09 or CAS10 are required. - C0908
If CAS09 is present, then CAS08 is required. - C1008
If CAS10 is present, then CAS08 is required. - L111213
If CAS11 is present, then at least one of CAS12 or CAS13 are required. - C1211
If CAS12 is present, then CAS11 is required. - C1311
If CAS13 is present, then CAS11 is required. - L141516
If CAS14 is present, then at least one of CAS15 or CAS16 are required. - C1514
If CAS15 is present, then CAS14 is required. - C1614
If CAS16 is present, then CAS14 is required. - L171819
If CAS17 is present, then at least one of CAS18 or CAS19 are required. - C1817
If CAS18 is present, then CAS17 is required. - C1917
If CAS19 is present, then CAS17 is required.
- Submitters must use this CAS segment to report prior payers' claim level adjustments that cause the amount paid to differ from the amount originally charged.
- Only one Group Code is allowed per CAS. If it is necessary to send more than one Group Code at the claim level, repeat the CAS segment.
- A single CAS segment contains six repetitions of the "adjustment trio" composed of adjustment reason code, adjustment amount, and adjustment quantity. These six adjustment trios are used to report up to six adjustments related to a particular Claim Adjustment Group Code (CAS01). The first non-zero adjustment is reported in the first adjustment trio (CAS02-CAS04). If there is a second non-zero adjustment, it is reported in the second adjustment trio (CAS05-CAS07), and so on through the sixth adjustment trio (CAS17-CAS19).
- When the CAS information for the prior payer listed in Loop ID-2330BA in this instance of Loop ID-2320B was reported on the claim, the codes and associated amounts must be reported as received.
- When the prior payer in Loop ID-2330BA of this instance of Loop ID-2320B is the same as the submitting payer, and the Coordination of Benefits (COB) was performed without submission from the provider, CAS segments are to be populated as remitted to the provider on the 835.
- CAS✱PR✱1✱7.93~
- CAS✱OA✱93✱15.06~
AMT*D - COORDINATION OF BENEFITS (COB) PAYER PAID AMOUNT
- It is acceptable to show "0" as the amount paid.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
AMT*EAF - REMAINING PATIENT LIABILITY
If not required by this implementation guide, do not send.
MOA - OUTPATIENT ADJUDICATION INFORMATION
NM1*PR - OTHER PAYER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
DTP*573 - CLAIM CHECK OR REMITTANCE DATE
REF - OTHER PAYER SECONDARY IDENTIFIER
At least one of REF02 or REF03 is required.
AND
The data is available in the payer's system.
If not required by this implementation guide, then do not send.
For example, "001122333" would be valid, while sending "001-12-2333" or "00-1122333" would be invalid.
NM1*IL - OTHER PAYER SUBSCRIBER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
N3 - OTHER PAYER SUBSCRIBER ADDRESS
If not required by this implementation guide, do not send.
N4 - OTHER PAYER SUBSCRIBER CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
If not required by this implementation guide, do not send.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
REF*SY - OTHER PAYER SUBSCRIBER SOCIAL SECURITY NUMBER
At least one of REF02 or REF03 is required.
The social security number is allowed to be used for this purpose under applicable law or regulation.
AND
The social security number is available in the payer's system.
If not required by this implementation guide, do not send.
NM1*QC - OTHER PAYER PATIENT NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
N3 - OTHER PAYER PATIENT ADDRESS
If not required by this implementation guide, do not send.
N4 - OTHER PAYER PATIENT CITY, STATE, ZIP CODE
- E0207
Only one of N402 or N407 may be present. - E0308
Only one of N403 or N408 may be present. - C0605
If N406 is present, then N405 is required. - C0704
If N407 is present, then N404 is required.
If not required by this implementation guide, do not send.
- CODE SOURCE 51: ZIP Code
- CODE SOURCE 932: Universal Postal Codes
REF*SY - OTHER PAYER PATIENT SOCIAL SECURITY NUMBER
At least one of REF02 or REF03 is required.
The social security number is allowed to be used for this purpose under applicable law or regulation.
AND
The social security number is available in the payer's system.
If not required by this implementation guide, do not send.
LX - SERVICE LINE NUMBER
- The LX functions as a line counter.
- The Service Line LX segment must begin with one and is incremented by one for each additional service line of a claim.
- LX01 is used to indicate bundling in SVD06 in the Line Item Adjudication loop. See Section 1.4.2.4 for more information on bundling and section 1.4.2.6 for more information on unbundling.
SV3 - DENTAL SERVICE
- C003-01 qualifies C003-02 and C003-08.
- If C003-08 is used, then C003-02 represents the beginning value in the range in which the code occurs.
- C003-03 modifies the value in C003-02 and C003-08.
- C003-04 modifies the value in C003-02 and C003-08.
- C003-05 modifies the value in C003-02 and C003-08.
- C003-06 modifies the value in C003-02 and C003-08.
- C003-07 is the description of the procedure identified in C003-02.
- C003-08 represents the ending value in the range in which the code occurs.
- C003-09 modifies the value in C003-02 and C003-08.
- C003-10 modifies the value in C003-02 and C003-08.
- C003-11 modifies the value in C003-02 and C003-08.
- C003-12 modifies the value in C003-02 and C003-08.
- This is the total charge amount for this service line. The amount is inclusive of the provider's base charge and any applicable tax amounts reported within this line's AMT segments.
- Zero "0" is an acceptable value for this element.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- Do not use this element for reporting of individual teeth. If it is necessary to report one or more individual teeth, use the Tooth Information (TOO) segment in this loop.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
- Number of procedures
- If, for whatever reason, the data is not stored within the payer's system, do not use.
TOO*JP - TOOTH INFORMATION
If either TOO01 or TOO02 is present, then the other is required.
If not required by this implementation guide, do not send.
- See Appendix A for code source 135: American Dental Association Codes.
- This element may only be used to report individual teeth. It may not be used to report areas of the oral cavity such as quadrants or sextants. Areas of the oral cavity must be reported in one or more of the components of SV304.
DTP*472 - SERVICE DATE
If not required by this implementation guide, do not send.
- Do not use this DTP segment when submitting a Treatment Start Date, Treatment Completion Date or both.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
DTP - PRIOR PLACEMENT DATE
If not required by this implementation guide, do not send.
DTP*452 - APPLIANCE PLACEMENT DATE
If not required by this implementation guide, do not send.
DTP*446 - REPLACEMENT DATE
If not required by this implementation guide, do not send.
DTP*196 - TREATMENT START DATE
If not required by this implementation guide, do not send.
- When the Treatment Start Date is used, the Date of Service must not be used.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
DTP*198 - TREATMENT COMPLETION DATE
If not required by this implementation guide, do not send.
- When the Treatment Completion Date is used, the Date of Service must not be used.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
CN1 - CONTRACT INFORMATION
If not required by this implementation guide, do not send.
REF*G1 - PRIOR AUTHORIZATION
At least one of REF02 or REF03 is required.
If not required by this implementation guide, do not send.
REF*9F - REFERRAL NUMBER
At least one of REF02 or REF03 is required.
If not required by this implementation guide, do not send.
K3 - FILE INFORMATION
If not required by this implementation guide, do not send.
- The K3 segment is expected to be used only when necessary to meet the unexpected data requirement of a legislative authority. Before this segment can be used:
- The X12N Health Care Claim workgroup must conclude there is no other available option in the implementation guide to meet the emergency legislative requirement.
- The requestor must submit a proposal for approval accompanied by the relevant business documentation to the X12N Health Care Claim workgroup chairs and receive approval for the request.
Upon review of the request, X12N will issue an approval or denial decision to the requesting entity. Approved usage(s) of the K3 segment will be reviewed by the X12N Health Care Claim workgroup to develop a permanent change to include the business case in future transaction implementations. - Only when all of the requirements above have been met, may the regulatory agency require the temporary use of the K3 segment.
- X12N will submit the necessary data maintenance and refer the request to the appropriate data content committee(s).
- If, for whatever reason, the data is not stored within the payer's system, do not use.
NM1*82 - RENDERING PROVIDER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
OR
Required when Loop ID-2310B Rendering Provider is not used AND this particular line item has different Rendering Provider information than that which is carried in Loop ID-2010AA Billing Provider.
If not required by this implementation guide, may be provided at the sender's discretion, but cannot be required by the receiver.
- Used for all types of rendering providers including laboratories. The Rendering Provider is the person or company (laboratory or other facility) who rendered the care. In the case where a substitute provider (locum tenens) was used, enter that provider's information here.
- If, for whatever reason, the data is not stored within the payer's system, do not use.
PRV*PE - RENDERING PROVIDER SPECIALTY INFORMATION
If either PRV02 or PRV03 is present, then the other is required.
If not required by this implementation guide, do not send.
REF - RENDERING PROVIDER SECONDARY IDENTIFICATION
At least one of REF02 or REF03 is required.
If not required by this implementation guide, do not send.
NM1*DD - ASSISTANT SURGEON NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
If not required by this implementation guide, do not send.
PRV*AS - ASSISTANT SURGEON SPECIALTY INFORMATION
If either PRV02 or PRV03 is present, then the other is required.
If not required by this implementation guide, do not send.
REF - ASSISTANT SURGEON SECONDARY IDENTIFICATION
At least one of REF02 or REF03 is required.
If not required by this implementation guide, do not send.
NM1*DQ - SUPERVISING PROVIDER NAME
- P0809
If either NM108 or NM109 is present, then the other is required. - C1110
If NM111 is present, then NM110 is required. - C1203
If NM112 is present, then NM103 is required.
If not required by this implementation guide, do not send.
REF - SUPERVISING PROVIDER SECONDARY IDENTIFICATION
At least one of REF02 or REF03 is required.
If not required by this implementation guide, do not send.
SVD*R - LINE ADJUDICATION INFORMATION
OR
Required when the related Loop ID 2320 SBR06 = 1; and the data was present on the provider submitted claim.
If not required by this implementation guide, do not send.
When SVD01 matches the SBR01 in Loop ID-2320A, the payer and adjudication information related to this iteration of Loop ID-2320A and 2430 represents the adjudication results of the submitting payer.
- Zero "0" is an acceptable value for this element.
- Refer to Appendix B.1.1.2.2 Maximum Length of Data Element 782 Monetary Amount for more information about this data element length.
- C003-01 qualifies C003-02 and C003-08.
- If C003-08 is used, then C003-02 represents the beginning value in the range in which the code occurs.
- C003-03 modifies the value in C003-02 and C003-08.
- C003-04 modifies the value in C003-02 and C003-08.
- C003-05 modifies the value in C003-02 and C003-08.
- C003-06 modifies the value in C003-02 and C003-08.
- C003-07 is the description of the procedure identified in C003-02.
- C003-08 represents the ending value in the range in which the code occurs.
- C003-09 modifies the value in C003-02 and C003-08.
- C003-10 modifies the value in C003-02 and C003-08.
- C003-11 modifies the value in C003-02 and C003-08.
- C003-12 modifies the value in C003-02 and C003-08.
A modifier must be from code source 135 (American Dental Association) found in the `Code on Dental Procedures and Nomenclature'.
A modifier must be from code source 135 (American Dental Association) found in the `Code on Dental Procedures and Nomenclature'.
A modifier must be from code source 135 (American Dental Association) found in the `Code on Dental Procedures and Nomenclature'.
A modifier must be from code source 135 (American Dental Association) found in the `Code on Dental Procedures and Nomenclature'.
- The maximum length for this field is 8 digits excluding the decimal. When a decimal is used, the maximum number of digits allowed to the right of the decimal is three.
- When SVD01 matches the SBR01 in Loop ID-2320A, this is the number of paid units which would have been sent on the remittance advice. When paid units are not present on the remittance advice, the value must be one.
When SVD01 matches the SBR01 in Loop ID-2320B, this is the number of paid units as reported on the submitted claim. When paid units are not present on the submitted claim, the value must be one.
CAS - LINE ADJUSTMENT
- L050607
If CAS05 is present, then at least one of CAS06 or CAS07 are required. - C0605
If CAS06 is present, then CAS05 is required. - C0705
If CAS07 is present, then CAS05 is required. - L080910
If CAS08 is present, then at least one of CAS09 or CAS10 are required. - C0908
If CAS09 is present, then CAS08 is required. - C1008
If CAS10 is present, then CAS08 is required. - L111213
If CAS11 is present, then at least one of CAS12 or CAS13 are required. - C1211
If CAS12 is present, then CAS11 is required. - C1311
If CAS13 is present, then CAS11 is required. - L141516
If CAS14 is present, then at least one of CAS15 or CAS16 are required. - C1514
If CAS15 is present, then CAS14 is required. - C1614
If CAS16 is present, then CAS14 is required. - L171819
If CAS17 is present, then at least one of CAS18 or CAS19 are required. - C1817
If CAS18 is present, then CAS17 is required. - C1917
If CAS19 is present, then CAS17 is required.
- CAS✱PR✱1✱7.93~
- CAS✱OA✱93✱15.06~
DTP*573 - LINE CHECK OR REMITTANCE DATE
AMT*EAF - REMAINING PATIENT LIABILITY
If not required by this implementation guide, do not send.
SE - TRANSACTION SET TRAILER
GE - FUNCTIONAL GROUP TRAILER
IEA - INTERCHANGE CONTROL TRAILER
| | 837 Post-adjudicated Claims Data Reporting: Dental (008020X300)FEBRUARY 2022 Copyright © 2008-22, X12 Incorporated, Format © 2008-22 Washington Publishing Company. Exclusively published by the Washington Publishing Company. No part of this publication may be distributed, posted, reproduced, stored in a retrieval system, or transmitted in any form or by any means without the prior written permission of the copyright owner. All rights reserved. Abstract The Post-Adjudicated Claims Data Reporting: Dental Implementation Guide describes the use of the X12 Health Care Claim (837) transaction set for reporting health care dental service post-adjudicated data:
|
PrefaceX12 standards are developed to identify the broadest data requirements for a transaction set. Type 3 Technical Reports (TR3), also known as implementation guides, define the explicit data requirements for a specific business purpose. Trading partners who implement according to the instructions in this TR3 can exchange data consistently with multiple trading partners. As X12 does not define transport requirements, trading partners define their specific transport requirements separately. |
1.1 Implementation Purpose and ScopeFor 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 define the transaction set used to exchange post-adjudicated claims data. The entities involved in this exchange include payers and organizations that receive post-adjudicated claim data. This exchange may be performed directly or via transmission intermediaries, such as clearinghouses and value added networks. For further clarification on definitions of the participants, see X12 Wordbook for definitions. This is the technical report document for the X12N 837 Health Care Claims (837) transaction for dental post-adjudicated data reporting. This document provides a definitive statement of what trading partners must be able to support in this implementation of the 837. |
1.2 Version InformationThis implementation guide is based on the October 2020 X12 standards, referred to as Version 8, Release 2 (008020). The unique Version/Release/Industry Identifier Code for transaction sets that are defined by this implementation guide is 008020X300. The two-character Functional Identifier Code for the transaction set included in this implementation guide:
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 UsageThere are multiple methods available for sending and receiving business transactions electronically. Two common modes for EDI transactions are batch and real-time. Batch - In a batch mode the sender does not remain connected while the receiver processes the transactions. Processing is usually completed according to a set schedule. If there is an associated business response transaction (such as a 271 Response to a 270 Request for Eligibility), the receiver creates the response transaction and stores it for future delivery or transmits the response transaction back to the sender of the original transaction. The sender of the original transmission reconnects at a later time and picks up the response transaction. Note: The sender of the original transmission may not always be the entity that picks up the response transaction at a later time (e.g. Provider submitting through a clearinghouse.) Real-Time - In real-time mode the sender remains connected while the receiver processes the transactions and returns a response transaction to the sender. This implementation guide does not set specific response time parameters for implementers. This implementation guide was based on requirements for batch mode. Willing trading partners may use batch or real-time mode. |
1.3.2 Other Usage LimitationsWhen processing in batch mode, receiving trading partners may have system limitations which control the size of the transmission they can receive. Some submitters may have the capability and the desire to transmit large 837 transactions with thousands of claims contained in them. This implementation guide limits the size of the transaction (ST-SE envelope) to a maximum of 5000 CLM segments. Willing trading partners can agree to higher limits. There is no recommended limit to the number of ST-SE transactions within a GS-GE or ISA-IEA. When a claim is processed in real-time, only one CLM per ISA/IEA is allowed and must be responded to in a single communication session. |
1.4 Business UsageThis transaction set is used by trading partners to exchange post-adjudicated claims data. Trading partners include:
For purposes of this standard, the payer is an entity that pays claims or administers the insurance product, benefit, or both. For example, a payer may be an insurance company, health maintenance organization (HMO), government agency (Medicare, Medicaid, TRICARE, etc.) or an entity such as a third party administrator (TPA), or third party organization (TPO) that may be contracted by one of those groups. A regulatory agency is an entity responsible, by law or rule, for administering and monitoring a statutory benefits program or a specific segment of the health care/insurance industry. The transaction defined by this implementation guide is intended to originate with the payer to report encounter or post-adjudicated claim data to:
|
1.4.1 Health Care Transaction FlowEach 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 Data Changed By AdjudicationPayer adjudication practices may result in altered representations of claim data. This section describes a few of those possible scenarios and how to represent that data in a way that allows the receiver to understand what transpired. The examples follow the claim from the originating provider, through adjudication to the 835 transaction, and then show how the adjudicated data is presented in the data reporting transaction. Only the noteworthy segments are shown in the examples. |
1.4.2.1 Typical adjudication Claim and Line adjudicated as submitted.
|
1.4.2.2 Adjudicated procedure different than submitted Adjudicated procedure is different than the submitted procedure.
|
1.4.2.3 Adjudicated Line Split Adjudicated procedure is different than the submitted procedure.
|
1.4.2.4 Bundled Lines Submitted lines combined into a single line for processing and pricing.
|
1.4.2.5 Split Claims Submitted lines split into multiple claims for processing.
|
1.4.2.6 Unbundled Lines Submitted lines split into multiple lines for processing and pricing.
|
1.4.3 Subscriber / Patient InformationThe structure of this implementation guide is different from a "normal" provider submitted claim in that, as an entity, the Data Receiver does not always assign subscriber or patient identifier of their own. With the exception of Medicare and Medicaid encounters, the desire of the receiver is to retain the subscriber/patient relationship as known to the submitting entity. Header Level Subscriber/Patient Information (Loops 2010BA and 2010CA) Since the Data Receiver is not serving in the role of a payer, things like the Payer Responsibility Sequence Code (SBR01) and others are not applicable. Where able, these elements have been changed to Not Used. If the element is defined as Mandatory in the standard (SBR01 for example), a default has been defined. In the case of submissions to Medicare and Medicaid agencies, the Subscriber identified in loop 2010BA is the patient and therefore the patient loop is never used. Submitting Payer (Loop-ID 2320A) Coordination of Benefits Submission (Loop-ID 2320B) |
1.4.4 Provider Taxonomy Code ReportingProvider Taxonomy Codes describe provider type, classification, and area of specialization and are maintained by the National Uniform Claims Committee. For use in post-adjudication reporting, the taxonomy reported is determined by the payer's adjudication process. When the payer does not use taxonomies in their processing, the taxonomy may not be included in the transaction. |
1.4.5 BalancingIn order to ensure internal claim integrity, amounts reported in the 837 MUST balance at two different levels — the claim and the service line. |
1.4.5.1 Claim LevelThere are two different ways the claim information must balance. They are as follows. 1) Claim Charge Amounts 2) Claim Payment Amounts For a given other payer that has service line adjudication data, the sum of all line level payment amounts for that other payer (Loop ID-2430 SVD02 Service Line Paid Amount where Loop ID-2430 SVD01 Payer Responsibility Sequence Code = Loop-ID-2320B SBR01 Other Payer Responsibility Sequence Code) less any claim level adjustment amounts (Loop ID-2320B CAS adjustments) must balance to the claim level payment amount (Loop ID-2320B AMT02 Payer Paid Amount). Expressed as a calculation for a given other payer that has service line adjudication date: {Loop ID-2320B AMT02 Payer Paid Amount} = {sum of Loop ID-2430 SVD02 Service Line Paid Amounts} minus {sum of Loop ID-2320B CAS adjustment amounts}. Line Level Payment Amounts Adjustment Calculations Claim Level Payment Amount Example:
|
1.4.5.2 Service LineService line balancing applies independently for each Payer's Line Adjudication Information loop, Loop ID-2430. In order to balance, the sum of all service line adjustments and the service line payment within a Payer's 2430 Line Adjudication Information loop must balance to the Line Item Charge Amount for that service line. When a single service line has multiple 2430 loops for the same Payer, balancing logic must be modified. In the case of 2430 loops from two benefit plans from the same Payer, each SVD loop must balance independently as described above. Whereas, in the case of a single payer's adjudication unbundling services resulting in multiple 2430 loops, one for each unbundled service, the payments and adjustments for all such loops for that Payer must be summed together to balance to the Line Item Charge. The balancing calculation for each 2430 loop (other than the exceptions listed above) is as follows: {Sum of all Loop-ID 2430 CAS Adjustment Amounts}, Example:
|
1.5 Business TerminologyTo ensure consistent use of terms, definitions, and acronyms across X12 products, X12 maintains the Wordbook, a comprehensive corporate glossary. The included terms are either proprietary to X12, cite definitions published by another authority, or represent common terms and definitions that are relevant to X12's work. The terms and definitions defined in the Wordbook are used in X12 work products when applicable, without modification or revision. The Wordbook can be referenced online at wordbook.x12.org. |
1.6 Transaction AcknowledgmentsThe purpose of transaction acknowledgments is to report to the sender whether the transaction being acknowledged was accepted or rejected. The X12 Technical Report Type 2, Acknowledgment Reference Model provides guidance on several control structures and transaction set standards intended to augment EDI auditing and control systems. |
1.7 Related TransactionsThere are one or more transactions related to the transactions described in this implementation guide. |
1.7.1 Health Care Claim Payment/Advice (835)Information in the Health Care Claim Payment/Advice (835) transaction is generated by the payer's adjudication system. Some of the information reported in the 835 must be included in the Post-Adjudicated Claims Data Reporting 837. |
1.8 Trading Partner AgreementsTrading 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 ComplianceThere 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 RequirementsA transaction complies with X12 implementation guide requirements if the transaction satisfies all format and content rules and constraints specified in the applicable X12 standards and the implementation guide (also known as a TR3) itself. Should additional clarification of an X12 implementation guide requirement be desired, two options are available.
X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that are not TR3-compliant based on its own business process. A receiver may specify its business rules in a trading partner agreement or companion document. As stated in §1.8, these documents do not override TR3 requirements, nor change how transaction compliance with this TR3 is determined. |
1.9.2 Transaction Compliance with State and Federal RegulationsThis implementation guide has been developed for use as an insurance industry implementation guide. At the time of publication it has not been adopted as a state or federal standard. Should this implementation guide be adopted as a standard, the adopting authority will establish compliance dates for its use by impacted entities. X12 is not the authority for determining compliance with regulatory requirements that might further constrain implementation guide requirements. Questions of compliance for regulatory requirements should be directed to the governing authority. X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that do not comply with applicable regulatory requirements as specified by the applicable regulation(s) or governing authority. |
1.9.3 Transaction Compliance with Contractual RequirementsX12 is not the authority for determining compliance with contractual requirements that might further constrain implementation guide requirements. Questions of compliance for contractual requirements should be directed to the contracting entity. X12 does not specify the business rules that the receiving entity must use to decide when to accept or reject a transaction. The receiver will handle transactions that do not comply with contractual requirements as specified by the applicable contract or contracting entity. |
2.1 Presentation ExamplesThe 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 Figure 2.2 - Transaction Set Key - Standard Figure 2.3 - Segment Key - Implementation Figure 2.4 - Segment Key - Diagram Figure 2.5 - Segment Key - Element Summary |
2.2.1 Industry UsageIndustry 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).
|
2.2.1.1 Determining Transaction Compliance with Industry Usage RequirementsA 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.
|
2.2.2 LoopsLoop requirements depend on the context or location of the loop within the transaction. See Appendix B for more information on loops.
|
3. ExamplesBusiness scenario examples for use of this transaction can be found on the X12 Examples website at http://examples.x12.org. The X12 Examples website provides convenient access to examples of X12 transaction transmissions, including the data stream and a description of the associated scenario. |
| Â | ||||
Appendix A. External Code SourcesPrior to this publication, X12 TR3s contained a subset of the overall Code Source Directory, formerly known as Appendix A of X12.3. External code lists are not part of the X12 standard and are provided for information purposes only. The full listing is available in Glass, X12's On-Line viewer. Read more about Glass here: https://glasshelp.x12.org/. Where an external code source is referenced in this publication, the implementer is required to use only the codes from that list. Codes must be reported as listed in the code source (e.g. with leading zeroes). Implementers must follow the instructions for code use that are supplied by the code set owner. | ||||
| Â | ||||
B.1.1 X12 Referenced and Related StandardsThis 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:
The following guideline is useful to interpret, understand, and use this technical report:
The following reference model is useful to interpret, understand, and use this technical report:
All of the documents above are available online using links to X12's Online Viewer. | ||||
| Â | ||||
B.1.1.1 Transmission Control SchematicRefer 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 | ||||
| Â | ||||
B.1.1.2 Constraints applicable to the suite of TR3sRefer to X12.6 - Application Control Structure, Section 3.2.8 - Minimums/Maximums. Data element minimum and maximum lengths are set by the X12 standard. This implementation guide may further restrict minimum and maximum lengths within the bounds set by the standard. Such restrictions may occur implicitly by virtue of the allowed qualifier for the data element, or they may be stated explicitly in a note attached to the element or in the general limitations below. | ||||
| Â | ||||
B.1.1.2.1 Maximum Length of Data Element 127 Reference IdentificationThe current X12 standard allows a maximum length greater than 50 characters for data element 127. For implementations governed by this implementation guide, unless another value is specified in an attached note, the maximum length of each occurrence of this data element is constrained to 50 characters. | ||||
| Â | ||||
B.1.1.2.2 Maximum Length of Data Element 782 Monetary AmountFor 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
| ||||
| Â | ||||
B.1.1.3 DecimalWhile the X12 standard supports usage of exponential notation, this guide prohibits that usage. | ||||
Appendix D. Change SummaryThis Implementation Guide (008020X300) defines the X12 requirements for the Post-adjudicated Claims Data Reporting: Dental. It is based on version/release/subrelease 008020 of the X12 standards. |