X12 271 to FHIR Coverage
Convert an X12 271 eligibility response into a FHIR R4 Coverage resource — structured data instead of a raw EDI stream.
The workflow
The complete flow, exactly as it runs in the Workflow Builder. Scroll to explore, or use the zoom controls.
About this workflow
A payer's X12 271 eligibility response is dense, segment-based EDI text. This workflow converts it into a FHIR R4 Coverage resource — the shape an eligibility check takes once a modern system needs to reason about the result as structured data instead of parsing an EDI stream by hand.
The problem
Eligibility and benefits checks run over X12 270/271 transactions industry-wide, but EDI's segment-and-qualifier structure isn't something a typical application can consume directly. Turning a 271 response into something a patient portal or claims system can use usually means a dedicated EDI parser.
How it works
An Inject node carries a synthetic X12 271 message directly into a Mapper step. The mapping project pulls the subscriber's member ID and the payer's name from the message's NM1 loops and wires them into a FHIR Coverage resource; the resource's bookkeeping fields (resourceType, status) are set directly, since a bare 271 doesn't carry them on its own. A Debug node shows the finished Coverage resource.
Why it matters
It's an honest example: the mapping wires exactly what the source message actually contains, and states plainly where a 271 response stops short (no coverage date range in this template) rather than fabricating fields that aren't really there.
Who it's for
Teams building eligibility-check integrations who need the payer response as structured FHIR data, not raw EDI text.
How to build this workflow
Recreate it in the Workflow Builder by wiring these steps in order — or download it above and import it directly.
Step 1: Receive the Message
An Inject node carries the built-in synthetic payload straight into the flow.
Step 2: Run the Mapping
A Mapper step runs the saved mapping project, wiring the source fields into the target format directly — no parser needed, since the source is already structured.
Step 3: Confirm the Output
A Debug node shows the finished result, exactly as the mapping produced it.