Healthcare & EDI Interop

The step that is usually missing

Healthcare integration tooling is good at moving X12 and FHIR between systems. It stops at the point where a person has to read the result. An 835 remittance is a wall of delimited segments; a FHIR Bundle is nested JSON. Someone downstream still needs a remittance summary, an appeal packet, a patient-facing statement, or a printable record for a chart.

That is the step we do. Every endpoint below is live today on the same REST API, the same X-API-Key header and the same token balance as the rest of the catalog — no separate product, no separate contract.

EDI / X12 — 6 endpoints

Healthcare transaction sets recognized today

IdentifyEdiDocument names the transaction, version, sender and receiver; the parse, validate and convert endpoints work on any X12 envelope, whichever transaction it carries.

Non-healthcare X12 works the same way — 850 purchase orders, 810 invoices and the rest of the supply-chain set parse, validate and render through the identical endpoints.

FHIR R4 — 6 endpoints

From wire format to a printable document

Both renderers emit styled HTML. Chaining that into ConvertHtmlToPdf gives you a PDF, so a whole interop-to-document path is two calls:

POST /api/FhirBundleToHtml   { "resource": { ...Bundle... }, "title": "Patient Summary" }
POST /api/ConvertHtmlToPdf   { "html": "<the HTML from step 1>", "returnBase64": true }

Swap step one for /api/ConvertX12ToHtml and the same two calls turn an 835 into a remittance report. Both can run as a single published webhook instead of two round trips.

Why this matters now

CMS-0057-F (Interoperability and Prior Authorization) puts dates on the calendar for impacted payers: prior-authorization decision timeframes have applied since January 1, 2026, and the four required FHIR APIs — Patient Access, Provider Access, Payer-to-Payer and Prior Authorization — are due January 1, 2027.

Read the rule carefully and the useful detail is that FHIR sits in front of X12 rather than replacing it. Prior authorization is explicitly designed to work in both directions between FHIR and the X12 278, and 837, 835, 270 and 271 stay X12-mandated. Organizations subject to the rule end up holding both formats at once, indefinitely, and still owe humans a readable document out of either.

Dates and scope are stated as CMS published them; confirm applicability for your own organization — the rule binds specific payer types, not everyone in healthcare.

What this is, and what it is not

Deliberately plain, because the alternative is a sales call that ends badly:

• This is a document layer, not a clearinghouse. We do not submit claims, hold payer connections, or route transactions.
• There is no X12↔FHIR mapping endpoint. Converting an 837 into a FHIR Claim is a different piece of work, and we have not built it.
• HL7 v2 is not supported. FHIR R4 only.
• We make no HIPAA certification or attestation claim. Compliance depends on your deployment, your agreements and your data handling — talk to us before putting real PHI through the hosted service.

If the missing piece for you is one of the above, say so. Whether anyone actually needs it is exactly what we are trying to find out, and a real requirement beats a guess.