This guide covers 12 common HIPAA X12 messages and variants (the 837 has three variants, and the 278 has a request and a response). HIPAA also adopts other standards, such as NCPDP for pharmacy, so this is not an exhaustive regulatory list. This guide explains each one - when it's used, who sends it, and how to convert it to FHIR. Redix validates and converts the HIPAA 5010 transaction sets; FHIR conversion covers the 837, 835, 834, 270/271, 276/277, and 278 (the 820 is not mapped to FHIR).
The 12 Transaction Types at a Glance
| Transaction | Name | Direction | Purpose | Typical FHIR R4 counterpart |
|---|---|---|---|---|
837P |
Professional Claim | Provider → Payer | Physician/outpatient claims | Claim (professional) |
837I |
Institutional Claim | Provider → Payer | Hospital/facility claims | Claim (institutional) |
837D |
Dental Claim | Provider → Payer | Dental claims | Claim (oral) |
835 |
Remittance Advice | Payer → Provider | Payment explanation | ClaimResponse + PaymentReconciliation (Redix); ExplanationOfBenefit (alternative) |
834 |
Benefit Enrollment | Sponsor → Payer | Enroll/terminate members | Coverage |
820 |
Premium Payment | Sponsor → Payer | Premium payments | PaymentNotice |
270 |
Eligibility Inquiry | Provider → Payer | Check coverage | CoverageEligibilityRequest |
271 |
Eligibility Response | Payer → Provider | Coverage details | CoverageEligibilityResponse |
276 |
Claim Status Request | Provider → Payer | Check claim status | Mapping-specific status inquiry (Redix: Claim) |
277 |
Claim Status Response | Payer → Provider | Claim status details | ClaimResponse |
278 REQ |
Prior Auth Request | Provider → Payer | Request authorization | Claim (preauthorization) |
278 RES |
Prior Auth Response | Payer → Provider | Authorization decision | ClaimResponse |
Also covered: the 999 Implementation Acknowledgment, returned at the functional-group and transaction-set level where the implementation guide and trading-partner agreement call for it.
Claims Transactions (837 Family)
837P Professional Claim
Direction: Provider → Payer | FHIR: Claim (type: professional)
Purpose: Submit claims for physician offices, outpatient procedures, labs, DME, and ambulance services.
Key Segments: ISA/GS (headers), BHT (transaction start), NM1 (names), CLM (claim info), HI (diagnoses), SV1 (service lines)
Coding: CPT, HCPCS
837I Institutional Claim
Direction: Provider → Payer | FHIR: Claim (type: institutional)
Purpose: Submit claims for hospitals, inpatient stays, SNF, home health, and hospice.
Key Differences: Uses Revenue Codes, DRG for inpatient, Occurrence/Value Codes, SV2 segment instead of SV1.
Coding: revenue codes; CPT/HCPCS for outpatient services; ICD-10-PCS for inpatient procedures
837D Dental Claim
Direction: Provider → Payer | FHIR: Claim (type: oral)
Purpose: Submit claims for dental services including preventive, restorative, oral surgery, and orthodontics.
Key Differences: Uses CDT codes, includes Tooth Numbers and Surface Codes, Oral Cavity designations.
Coding: CDT (Current Dental Terminology)
Detailed claim form mapping guides: See our field-by-field conversion guides for 837P → CMS-1500, 837I → UB-04, and 837D → ADA J400. For converting claims to FHIR, see Convert HIPAA 837 Claims to FHIR R4.
Acknowledgment Transaction
999 Implementation Acknowledgment
Direction: Receiver → Sender
Purpose: Report whether a received functional group and its transaction sets passed implementation-guide validation. It is not a per-claim acknowledgment and not an adjudication result.
Key Segments: AK1 (functional group), AK2 (transaction set), IK3 (segment errors), IK4 (element errors), AK9 (response)
| AK9 Code | Meaning |
|---|---|
A | Accepted |
E | Accepted with errors |
R | Rejected |
Payment Transaction
835 Remittance Advice
Direction: Payer → Provider | FHIR: ClaimResponse and PaymentReconciliation in the Redix mapping (ExplanationOfBenefit is an alternative model)
Purpose: Explain how a claim was adjudicated - payment amounts, adjustments, denials, and patient responsibility.
Key Data: Claim payment amount, Adjustment reason codes (CARC/RARC), Deductible/copay/coinsurance, Contractual write-offs.
Enrollment Transactions
834 Benefit Enrollment
Direction: Sponsor → Payer | FHIR: Coverage
Purpose: Enroll, change, or terminate member coverage. Used for new hires, open enrollment, life events, terminations, COBRA.
Key Segments: INS (member detail), NM1 (names), DMG (demographics), HD (coverage), DTP (dates)
820 Premium Payment
Direction: Sponsor → Payer | FHIR: PaymentNotice
Purpose: Report premium payments including monthly remittance, payroll deductions, COBRA, and retiree premiums.
Eligibility Transactions
270 Eligibility Inquiry
Direction: Provider → Payer | FHIR: CoverageEligibilityRequest
Purpose: Request eligibility and benefit information - verify coverage, check benefits, confirm demographics.
271 Eligibility Response
Direction: Payer → Provider | FHIR: CoverageEligibilityResponse
Purpose: Respond with coverage status, effective dates, benefits by service type, deductibles, copays, prior auth requirements.
Claim Status Transactions
276 Claim Status Request
Direction: Provider → Payer
Purpose: Inquire about a previously submitted claim - was it received, is it processing, is it pending info, was it denied?
277 Claim Status Response
Direction: Payer → Provider | FHIR: ClaimResponse
Purpose: Return current claim status with category codes.
| Code Range | Meaning |
|---|---|
A1 | Acknowledgment: received |
A6, A7, A8 | Acknowledgment: rejected (for example, missing or invalid information) |
P1 | Pending: in process |
F1 | Finalized: payment |
R codes | Requests for additional information |
Examples only; some codes, such as F5, are deactivated. The full list is maintained by X12: claim status category codes. A 277 claim status response is different from the 277CA claim acknowledgment.
Prior Authorization Transactions
278 REQ Prior Authorization Request
Direction: Provider → Payer | FHIR: Claim (use: preauthorization)
Purpose: Request prior authorization for admissions, procedures, DME, specialty drugs, or behavioral health services.
CMS-0057-F: for organizations that keep X12 systems behind a FHIR prior authorization API, the 278 is the bridge. Redix converts the 278 to Da Vinci PAS resources (Claim and ClaimResponse), not just a generic FHIR Claim; tested synthetic 278 request output (June 2026 run) passed validation against the PAS 2.0.1 and 2.1.0 profiles.
Key segments: request: ISA/GS, BHT, UM (review information), HI (diagnoses), SV1/SV2 (services); response: HCR (the review decision).
278 RES Prior Authorization Response
Direction: Payer → Provider | FHIR: ClaimResponse
Purpose: Communicate the authorization decision.
| Code | Decision |
|---|---|
A1 | Certified in total |
A2 | Certified - partial |
A3 | Not certified (denied) |
A4 | Pended for review |
A6 | Modified |
Where Redix Fits
The "typical FHIR counterpart" column above is the usual target resource. Redix's own mapping can differ: for example, Redix converts the 835 to ClaimResponse and PaymentReconciliation, and does not map the 820 to FHIR.
| Capability | Transactions |
|---|---|
| Validation with 999 and TA1 | HIPAA 5010 transaction sets; balancing for 837, 835, and 820 |
| X12 to and from RMap | 270/271, 276/277, 278, 820, 834, 835, 837P/I/D |
| X12 to FHIR R4 | 837, 835, 834, 270/271, 276/277, 278 (837P, 837I, 835, and 278 in the live demo) |
| 278 to Da Vinci PAS | 278 request and response |
API Reference
| Transaction | Endpoint |
|---|---|
| Any (auto-detect, including 837D) | /api/v2/hipaa-to-fhir/convert |
| 837P | /api/v2/hipaa-to-fhir/837-professional |
| 837I | /api/v2/hipaa-to-fhir/837-institutional |
| 835 | /api/v2/hipaa-to-fhir/835-remittance |
| 834 | /api/v2/hipaa-to-fhir/834-enrollment |
| 270 / 271 | /api/v2/hipaa-to-fhir/270-eligibility / 271-eligibility |
| 276 / 277 | /api/v2/hipaa-to-fhir/276-claim-status / 277-claim-status |
| 278 Request | /api/v2/hipaa-to-fhir/278-request |
| 278 Response | /api/v2/hipaa-to-fhir/278-response |
Frequently Asked Questions
What are the 12 HIPAA X12 transaction types?
The 12 common HIPAA X12 messages and variants covered in this guide are: 837P (Professional Claim), 837I (Institutional Claim), 837D (Dental Claim), 835 (Remittance Advice), 834 (Benefit Enrollment), 820 (Premium Payment), 270 (Eligibility Inquiry), 271 (Eligibility Response), 276 (Claim Status Request), 277 (Claim Status Response), 278 Request (Prior Auth Request), and 278 Response (Prior Auth Response).
What is the difference between 837P, 837I, and 837D?
837P is for Professional claims (physician offices, outpatient) using CPT/HCPCS codes. 837I is for Institutional claims (hospitals and facilities) using revenue codes, with CPT/HCPCS for outpatient services and ICD-10-PCS for inpatient procedures. 837D is for Dental claims using CDT codes. They map to FHIR Claim types 'professional', 'institutional', and 'oral' respectively.
What is a 999 acknowledgment in HIPAA EDI?
The 999 Implementation Acknowledgment reports, at the functional-group and transaction-set level, whether received transactions passed implementation-guide validation, where the guide and trading-partner agreement call for it. It is not a per-claim acknowledgment or an adjudication result. Example AK9 codes include A (accepted), E (accepted with errors), and R (rejected).
What FHIR resource does an 835 remittance convert to?
In the Redix mapping, the 835 Remittance Advice converts to FHIR ClaimResponse and PaymentReconciliation resources, carrying payment amounts, adjustment reason codes, patient responsibility, and provider adjustments. Some implementations model adjudicated claims as ExplanationOfBenefit instead; the mapping is configurable.
What are the 278 prior authorization decision codes?
The 278 Response contains decision codes: A1 (Certified in total), A2 (Certified partial), A3 (Not certified/denied), A4 (Pended for review), and A6 (Modified). In Da Vinci PAS, the review decision is carried in the reviewAction extension; FHIR ClaimResponse.outcome describes processing state (for example complete or error), not approval or denial.
What are the 277 claim status category codes?
The 277 Claim Status Response carries claim status category codes. Examples: A1 (received), A6, A7, and A8 (acknowledgment rejections), P1 (pending, in process), F1 (finalized, payment), and R codes (requests for additional information). Some codes, such as F5, are deactivated. See the official X12 claim status category code list.