Track 04 · Multi-agent & integrationLesson 11 of 11
FHIR and electronic prior authorisation
Read and write healthcare data in the standard the hospital side actually sends.
- Specialisation · Healthcare
- 35 min read
- 75 min hands-on
- Pro
What you'll be able to do
01- Read a FHIR R4 bundle: resources, references, coded elements and the profile it claims, and say what "valid" means at each layer.
- Explain what the federal prior-authorisation rule requires of payers and when (as of October 2026), and what it leaves to the payer's own design.
- Place the three Da Vinci guides (CRD, DTR, PAS) and the X12 278 transaction in one request's journey, and say why both standards will run side by side for years.
- Build an intake that validates a request, maps it onto the operational model, checks the documents the policy lists and answers with a status, without ever approving or denying.
- Plan the EHR side honestly: vendor app programmes, sandboxes, SMART launch, terminology licences and minimum-necessary PHI.
Before you start
- The operational model: objects, links and actions: objects and actions as the only write path. Here a request becomes an object with a few intake actions.
- Approval gates and bounded autonomy: action tiers, envelopes and why approve or deny is never an agent action.
- Finding and masking personal data: finding and masking PHI.
- SaaS connectors and auth flows: OAuth flows and tokens; SMART App Launch builds on them.
- Python at the level of reading a few hundred lines. The worked example runs offline.
Starting here? This lesson is the healthcare elective's anchor. Two words used throughout: the payer is the health plan that decides coverage (Carevia); the provider is the hospital or practice that orders the service and asks for authorisation. A revenue-cycle team is the provider's staff who get services authorised, coded and paid.
The short version
Prior authorisation is a payer saying yes, no or "send more" before a service happens. Most of the work is administrative: the request arrives incomplete, someone phones, someone faxes a note, and only then does a nurse review it. FHIR is what the hospital side now sends: small typed resources (Patient, Coverage, ServiceRequest, DocumentReference, Claim) linked by references and shipped in a bundle. A US federal rule requires payers in the federal programmes to decide faster from 2026 and to offer a FHIR prior-authorisation API from 2027 (as of October 2026). The HL7 Da Vinci guides describe the flow: discover whether authorisation is needed (CRD), gather the documentation (DTR), submit the request (PAS). The X12 278 is still the HIPAA standard, so both arrive at the same intake for years.
The FDE builds that intake: it checks a request is well formed, maps it onto the operational model, checks the policy's documents are attached and tells the office where the request stands. It doesn't decide coverage.
- Valid has layers. Base FHIR, a profile such as US Core or PAS, and your own intake contract each say different things.
- A code means nothing without its system.
72148under the CPT system URL is a lumbar MRI; under a misspelt URL it's a string. - Complete is not approved. Intake checks documents are present; a nurse or physician decides whether they meet the policy.
- Both standards, one model. FHIR and X12 requests land in the same object with the same actions and the same audit trail.
- Minimum necessary. Copy into the operational model what the decision and the audit need, and leave clinical notes where they are.
Pro lesson
The rest of this lesson is in Pro.
The mental model, worked example, field note, failure table, exercise and self-check, with the voice tutor.
- Every stage and specialisation, in full
- Every lab and every role project
- Halden weeks 2–10, on your record
- Every drill, live in the playground
- All solutions, plus the server judge
- Lab Assistant and every Teach with AI