GFE → AEOB module map
These are the 13 pieces we need to get a patient from "what will this cost?" to a real Good Faith Estimate and Advanced EOB. Each one can be claimed by an HTE member and built in the open. Where Da Vinci PCT already has a profile, we build on it.
Pick a difficulty tier to see which modules it needs
Tiers line up with the adoption classes in the working definitions: single-party GFE, convened GFE, and AEOB.
Module register 5 of 13 claimed
Click a box in the diagram to jump to its row. Once the repo is up, claims will live in GitHub issues. Until then, reply in the workgroup thread with the module ID you want to own.
0 · Cross-cutting
Every module builds on theseDirectory & endpoints
Know who each provider and plan is and where to send things.
Provider NPI/TIN/taxonomy, plan → network mapping, payer and provider FHIR/X12 endpoints.
plans tableStatus & audit trail
See where any estimate is at every step, and keep a record.
One state model (requested → priced → convened → submitted → adjudicated → delivered), a correlation ID that follows the GFE into the AEOB, notifications.
Conformance & sandbox
Prove each module works and count real adoption.
Synthetic patients, plans and providers; reference servers; tests against PCT profiles; a classifier that labels output as single GFE, convened GFE, AEOB, or partial.
1 · Request
Turn a question into a structured estimate requestTrigger & intake
Start an estimate from any app: scheduling, an order, a patient request, a call center, or a member asking their plan.
Normalizes every entry point into one GFE Information Bundle: patient, coverage, service, diagnosis, date.
Service packages
Name the service in plain language and list everything that usually comes with it.
Claim-shaped templates: roles (facility, surgeon, anesthesia, pathology), codes, revenue codes, modifiers, quantities. Tells M5 who to convene.
service_components2 · Provider side → GFE
What the provider expects to chargeProvider pricing
Fill in what this provider expects to charge for its own lines.
Cash/self-pay rate, gross charge, or contracted rate from a swappable price source: internal systems, hospital MRFs, TiC.
PriceSource, $gfe-estimate, Task/$gfe-contributeConvening & coordination
Gather every provider's piece into one estimate for the whole episode.
Convening provider finds co-providers from the package, sends Contributor Tasks, tracks replies and timeouts, assembles the packet, flags missing pieces.
$gfe-retrieve; draft in STU2)GFE packet & patient copy
Produce the compliant GFE and a copy the patient can read.
GFE Packet with diagnosis codes, disclaimers and NSA fields; human-readable version. A self-pay GFE is finished here.
3 · Payer side → AEOB
What the plan will pay and the member will oweSubmission & routing
Send the finished estimate to the patient's plan as a pre-claim.
FHIR $gfe-submit or an X12 837 predetermination through a clearinghouse; acknowledgements; an X12↔FHIR bridge.
$gfe-submit, X12 837Allowed amount & network
Look up whether the provider is in network and what the plan will allow for each line.
Contracted rate per line; for out-of-network, list in-network alternatives as the NSA requires.
Benefits & accumulators
Know this member's coverage today: deductible met, copays, coinsurance, what needs prior auth.
Open benefits layer from plan or clearinghouse data so the payer doesn't have to build it. Reuses, but does not redo, the Real-Time Benefits pledge.
Adjudication & AEOB
Work out who pays what before care, and issue the AEOB.
Apply benefits to allowed amounts line by line: plan pays, member owes, accumulator position, PA flags. Builds the AEOB Bundle for the plan to stand behind.
4 · Patient
Delivery and comparisonPatient experience SDK
Show the patient a clear estimate and let them compare providers.
Retrieve GFE/AEOB, render in plain language, compare across providers and services, consent and sharing. The common rails every member app builds on.
Who does what in adjudication (M8 to M10)
A starting point for discussion. The plan is still on the hook for the AEOB, but most of the work behind it can run outside the payer if the inputs are open.
| Function | Payer must own | A tech company can do (as delegate or independently) |
|---|---|---|
| Network status & allowed amount | Contract of record; resolving disputes about which rate applies | Look up network and contracted rate from TiC files and the provider's own contract data (Serif-style lookup) |
| Member benefits & accumulators | Source of truth for plan design and deductible/OOP position | Pull 270/271 through a clearinghouse, parse plan documents, and normalize cost-share rules (Nirvana-style benefits layer) |
| Adjudication math | Signing off on the result as the plan's prospective determination | Run the line-by-line calculation with open, testable rules and hand back a draft AEOB |
| Medical management | Stating which services need prior auth, step therapy or review | Display the flags; PA workflows themselves stay in the ePA pledge |
| Delivery to the member | The NSA obligation to furnish the AEOB | Route, render, and let the patient compare in an app |
| True-up after care | Final claim and 835 | Reconcile estimate vs. final to score accuracy (feeds M12) |
Suggested build order
M3, M0, M1. Packages, directory and status unblock everything else, and none of them need a payer at the table.
M2, M4, M6, M11. Gets Tier 1 working end to end, starting from Serif's pricing code.
M7 to M10. Gets us to Tier 3. We need at least one payer (or delegate) willing to take a submitted GFE.
M5. Convening is the hardest coordination problem, and HHS still isn't enforcing it.