X12 5010 and FHIR R4, natively.
Payers and clearinghouses speak X12; EHRs and apps speak FHIR. Revora keeps one record and speaks both, so nothing is re-keyed and nothing is lost in translation.
Every transaction a practice exchanges with payers.
Delimiters are read from each partner's ISA header, control numbers are unique per trading partner, and test or production usage is set per connection.
| Transaction | Implementation guide | Direction | What Revora does with it |
|---|---|---|---|
| 270 / 271 | 005010X279A1 | Out / in | Eligibility at booking, before the visit and at check-in; benefits parsed into copay, deductible, coinsurance and out-of-pocket |
| 837P | 005010X222A1 | Out | Built from the signed note or a FHIR Claim, validated, then sent; corrected claims as frequency 7 with REF*F8 |
| 999 | 005010X231A1 | In | Syntax acceptance or rejection, tied to the exact interchange and claim |
| 277CA | 005010X214 | In | Claim-level acceptance with the payer claim number, or rejection with STC category, status and entity |
| 276 / 277 | 005010X212 | Out / in | Automatic status checks for claims the payer has not decided |
| 835 | 005010X221A1 | In | Balanced line by line, auto-posted, compared with the contract; reversals handled |
Every interchange is validated before it is sent (envelopes and counts, plus the guide rules that matter: dates, NPI check digits, ICD-10 format, diagnosis pointers, claim totals, 835 balancing) and stored verbatim in the EDI log.
The same records as FHIR resources.
For EHRs, patient apps, partner marketplaces and payers that have moved to FHIR.
| Resource | Interactions | Notes |
|---|---|---|
| Patient, Practitioner, Organization | read, search | US Core-shaped; NPI and tax ID identifiers |
| Coverage | read, search | Member ID, plan class, subscriber relationship |
| Schedule, Slot, Appointment | read, search, create | Published calendars and booking for partner apps |
| Encounter, Condition | read, search | ICD-10-CM encounter diagnoses |
| CoverageEligibilityRequest / Response | create, read | Runs a real-time 270/271 under the hood |
| Claim | read, search, $submit | use = claim sends an 837P; use = preauthorization runs prior authorization |
| ClaimResponse, ExplanationOfBenefit | read, search | From the 277CA and 835, with CARC/RARC reasons and adjudication amounts |
| Patient/$everything | operation | The patient's record as a Bundle |
FHIR R4 (4.0.1), application/fhir+json, OperationOutcome on errors, CapabilityStatement at /fhir/metadata. Resources are validated against the FHIR structure definitions.
Two calls to get started.
Authenticate with a bearer token; every request is written to the audit log.
# Check eligibility over FHIR: Revora sends the 270 and returns the 271 as a CoverageEligibilityResponse
curl -X POST https://your-practice.revora.health/fhir/CoverageEligibilityRequest \
-H "Authorization: Bearer $TOKEN" -H "Content-Type: application/fhir+json" \
-d '{"resourceType":"CoverageEligibilityRequest","status":"active","purpose":["benefits"],
"patient":{"reference":"Patient/pt-0042"},"created":"2026-10-14","insurer":{"reference":"Organization/py-apex"}}'
# Submit a claim: scrubbed, auto-fixed, sent as an 837P; the ClaimResponse carries the 277CA result
curl -X POST https://your-practice.revora.health/fhir/Claim/\$submit -H "Authorization: Bearer $TOKEN" -d @claim.json
Connecting your trading partners.
Most practices are live in two to three weeks.
1. Enrollment
We file EDI and ERA enrollment with each payer and your clearinghouse, and set your submitter ID.
2. Test
Interchanges go out with usage T until each partner confirms them; the interop console shows every one.
3. Production
Switch to P per partner. History, rules and work queues carry over unchanged.
Send us a sample file.
Paste any 837, 835 or 271 into the interop console and see it validated and converted to FHIR.