EDI 837 Dental Healthcare Claim (837D)
What is the EDI 837 Dental Transaction Set?
The EDI 837 Healthcare Claim transaction set and format have been specified by HIPAA 5010 standards for the electronic exchange of healthcare claim information. HIPAA 5010 837 transaction sets used are: EDI 837 Q1 for professionals, EDI 837 Q2 for dental practices, and EDI 837 Q3 for institutions. Providers send the proper EDI 837 transaction set to payers. (See an example EDI 837 Q2 below.) This transaction set can be used to submit healthcare claim billing information, encounter information, or both.
The payer refers to a third party entity that pays claims or administers the insurance product or benefit or both. The payer may be an insurance company, Health Maintenance Organization (HMO), Preferred Provider Organization (PPO), government agency (Medicare, Medicaid, 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. Providers may send 837s directly to payers or via clearinghouses. The EDI 837 transaction set can also be used to transmit healthcare claims and billing payment information between payers with different payment responsibilities where coordination of benefits is required. It may also be used between payers and regulatory agencies.
Health insurers and other payers send their payments and coordination of benefits information back to providers via the EDI 835 Healthcare Claim Payment transaction set.
The claim information for a single care encounter between patient and provider basically includes: patient descriptors; the condition for which treatment was provided; services provided; cost(s) of said treatment.
The 837 Q2 Healthcare Claim: Dental transaction set can be used to submit healthcare claim billing information, encounter information, or both, from providers of healthcare services to payers, either directly or via intermediary billers and claims clearinghouses.
Read our X12 EDI case studies on the rapid Integration of EDI Transactions.
EDI 837 Dental Claim in Data Mapper
(Click to enlarge)
EDI 837 Workflow Example
(EDI 837 Workflow – Click to Enlarge)
Providers or third-party services send the EDI 837 Healthcare Claim to payers. The optional EDI 275 Additional Patient Information (Unsolicited) may also be sent with attachments. The payer or clearinghouse system returns an EDI 999 Implementation Acknowledgment to confirm receipt of the incoming EDI 837 Healthcare Claim. The payer may send an EDI 277 Claim Acknowledgement of all claims received in the payer’s pre-processing system.
An EDI 276 Claim Status Request is sent to verify the status of the claim. The EDI 277 Claim Status Response is sent by the payer. The payer may also send an EDI 277 Request for Additional Information. The EDI 275 Additional Information (Solicited) is sent in response and may include patient record attachments.
With aspects of the claim verified, the payer sends the EDI 277 Claim Pending Status Information. The EDI 835 Claim Payment/Advice is used to make payments to healthcare providers and/or provide Explanations of Benefits (EOBs). The EDI 835 is used to detail and track the payment to the claim.
EDI 837 Frequently Asked Questions
Pilotfish’s eiConsole Interface Engine can configure interfaces to parse EDI 835, EDI 837 or any other X12 EDI message and transform them into SQL inserts. Read more about X12 EDI Parsing.
Yes, the PilotFish Mapper in the eiConsole for X12 can map any X12 EDI transaction to any target transaction, resources such as FHIR and API’s. The Data Mapper can also connect and map directly to SQL database tables.
Absolutely. PilotFish expertly conducts SNIP validations, ensuring both integrity and compliance. For example, EDI 835 files that are generated from EDI 837 files. This meticulous validation process not only identifies errors but also presents the findings in a user-friendly XML format. Additionally, users have the flexibility to either generate detailed reports or opt for exceptions based on these validation outcomes.
Yes, PilotFish can do a lookup query with its software, which is optimized for routing an EDI 837 claims transaction set. The query determines the correct destination for each claim based on the patient’s insurance information. PilotFish can send an EDI 835 with information about the payment, adjustment, denial and other claim details.
Yes, PilotFish has customers that require splitting based on some level of validation. For instance, in an 837 file with multiple claims, PilotFish can separate the data into two files, allowing the valid file to continue processing if the other encounters issues.
Check out our EDI FAQ pages for more.
EDI 837 Q2 Format Example
Commercial Health Insurance
ASC X12 Version: 005010 | Transaction Set: 837 | TR3 ID: 005010X224
The patient is a different person than the subscriber. The payer is a commercial health insurance company.
Transmission Explanation
HEADER
| ST*837*3456*005010X224~ | ST TRANSACTION SET HEADER |
| BHT*0019*00*0123*20061123*1023*CH~ | BHT TRANSACTION SET HIERARCHY AND CONTROL INFORMATION |
1000A SUBMITTER
| NM1*41*2*PREMIER BILLING SERVICE*****46*TGJ23~ | NM1 SUBMITTER |
| PER*IC*JERRY*TE*7176149999~ | PER SUBMITTER EDI CONTACT INFORMATION |
1000B RECEIVER
| NM1*40*2*INSURANCE COMPANY XYZ*****46*66783JJT~ | NM1 RECEIVER |
2000A BILLING PROVIDER HL LOOP
| HL*1**20*1~ | HIERARCHAL LEVEL 1 |
2010AA BILLING PROVIDER
| NM1*85*2*DENTAL ASSOCIATES*****XX*1234567890~ | NM1 BILLING PROVIDER NAME |
| N3*234 SEAWAY ST~ | N3 BILLING PROVIDER ADDRESS |
| N4*MIAMI*FL*33111~ | N4 BILLING PROVIDER LOCATION |
| REF*EI*587654321~ | REF BILLING PROVIDER’S TAX IDENTIFICATION |
2000B SUBSCRIBER HL LOOP
| HL*2*1*22*1~ | HIERARCHAL LEVEL 2 |
| SBR*P********CI~ | SBR SUBSCRIBER INFORMATION |
2010BA SUBSCRIBER
| NM1*IL*1*SMITH*JANE****MI*111223333~ | NM1 SUBSCRIBER’S NAME |
2010BB SUBSCRIBER/PAYER
| NM1*PR*2*INSURANCE COMPANY XYZ*****PI*66783JJT~ | NM1 PAYER’S NAME |
2000C PATIENT’S HL LOOP
| HL*3*2*23*0~ | HIERARCHAL LEVEL 3 |
| PAT*19~ | PAT PATIENT INFORMATION |
2010CA PATIENT
| NM1*QC*1*SMITH*TED~ | NM1 PATIENT’S NAME |
| N3*236 N MAIN ST~ | N3 PATIENT’S ADDRESS |
| N4*MIAMI*FL*33413~ | N4 PATIENT’S CITY |
| DMG*D8*19920501*M~ | DMG PATIENT DEMOGRAPHIC INFORMATION |
2300 CLAIM
| CLM*26403774*150***11:B:1*Y*A*Y*I~ | CLM HEALTH CLAIM INFORMATION |
| DTP*472*D8*20061029~ | DTP DATE – SERVICE DATE |
| REF*D9*17312345600006351~ | REF VAN CLAIM NUMBER |
2310B RENDERING PROVIDER
| NM1*82*1*KILDARE*BEN****XX*9876543210~ | NM1 RENDERING PROVIDER’S NAME |
| PRV*PE*PXC*1223G0001X~ | PRV RENDERING PROVIDER INFORMATION |
2400 SERVICE LINE
| LX*1~ | LX SERVICE LINE NUMBER |
| SV3*AD:D2150*100****1~ | SV3 DENTAL SERVICE |
| TOO*JP*12*M:O~ | TOO TOOTH NUMBER/SURFACES |
2400 SERVICE LINE
| LX*2~ | LX SERVICE LINE NUMBER |
| SV3*AD:D1110*50****1~ | SV3 DENTAL SERVICE |
TRAILER
| SE*31*3456~ | SE TRANSACTION SET TRAILER |
Source
Accredited Standards Committee X12. ASC X12 Standard [Table Data]. Data Interchange Standards Association, Inc., Falls Church, VA. ASC X12 Examples
X12, chartered by the American National Standards Institute for more than 35 years, develops and maintains EDI standards and XML schemas.