You're the PM on a healthcare project. Your engineers keep saying "we need a FHIR resource for that" or "that's not in the FHIR spec" and you're nodding along, pretending you know what they mean.
You don't need to write FHIR code. But you do need to understand what your engineers mean — well enough to scope, prioritize, and push back when they're hand-waving. This is the 10-minute version.
What FHIR actually is
FHIR (Fast Healthcare Interoperability Resources, pronounced "fire") is a standard for representing healthcare data — and a standard for the APIs that move it around. It's published by HL7, the same organization behind HL7v2 (the older standard) and CDA documents.
Three things to know:
- FHIR is RESTful — every resource has a URL, you GET/POST/PUT/DELETE it, just like any modern API. This makes it dramatically easier to work with than HL7v2.
- FHIR resources are JSON (or XML). Patient is a JSON object. Observation is a JSON object. Encounter is a JSON object. They reference each other by URL.
- FHIR R4 (Release 4) is the current production standard. If someone says "FHIR" without qualification, they probably mean R4.
Resources, references, bundles — the three things to know
Almost every conversation about FHIR comes back to these three concepts.
A resource is a structured piece of healthcare data. There are ~150 resource types defined in FHIR R4. The most common ones you'll talk about: Patient, Practitioner, Encounter, Observation, Condition, Procedure, MedicationRequest, AllergyIntolerance, DocumentReference, Organization.
A reference is how resources point at each other. An Observation has a reference to the Patient it belongs to (something like "Patient/12345"). An Encounter has a reference to the Patient and a reference to the Practitioner. Resources don't embed each other — they reference. This is critical for performance, and it's the source of most FHIR pain (you fetch a Patient, then you have to fetch all their Observations separately).
A bundle is a collection of resources returned together. When you search FHIR, you get back a Bundle of Patient resources. When you submit a batch of writes, you submit a Bundle. Bundles are how FHIR groups things.
The three operations PMs encounter
There are dozens of FHIR operations, but you'll mostly hear about three.
Read — fetch a specific resource by ID. "Get this patient's record." This is the easy one. Everyone's FHIR server supports read.
Write — create or update a resource. "Record this lab result." This is where most teams get stuck. Many FHIR servers — including big-name EHRs — are read-only or have severe write restrictions. If your project requires write-back into Epic, that's a different conversation than read.
Search — find resources matching criteria. "Get all observations of type 'blood pressure' for patients seen in the last 30 days." Search is where FHIR gets weirdly inconsistent: every FHIR server supports search differently, and the criteria available vary by implementation. Don't assume a search works until you've tested it on the actual server.
Where conformance matters
FHIR is a spec. Implementations vary wildly. Epic's FHIR is not Cerner's FHIR is not Athenahealth's FHIR — they all conform to the same spec at the surface, but they each define their own "profiles" and support different optional features.
Conformance is the formal way an implementation says "here's exactly what I support." A FHIR server publishes a CapabilityStatement — a machine-readable document listing every resource type, search parameter, and operation it supports.
When scoping FHIR work, make your engineers read the target server's CapabilityStatement before committing to a timeline. We've seen 3-month projects discover in week six that the target EHR doesn't support a search parameter the design depended on.
What "we have a FHIR integration" actually means
When a vendor says "we have a FHIR integration with Epic," the actual meaning varies wildly. Press for specifics:
- Read-only or read/write? Most are read-only.
- Which resources? "FHIR integration" might mean Patient + Observation only.
- Is it the patient-facing FHIR API (US Core, limited) or the bulk FHIR API (more resources, but requires different auth)?
- Bidirectional sync, or one-way?
- What's the auth model — SMART on FHIR (user-mediated) or system-to-system (back-channel)?
Until you have answers to these, you don't have a scoped FHIR integration. You have a marketing claim.
FHIR is a spec, not a product. Two compliant implementations can be wildly different to work with.
Red flags when scoping FHIR work
- "It's just a FHIR integration" — there is no "just" with FHIR. Demand specifics.
- "FHIR R3 or R4, doesn't matter" — it absolutely matters. R3 to R4 has breaking changes; you'll pick one and commit.
- "We'll add write support later" — write support is fundamentally different from read. Don't punt it.
- "Search will be fine" — until you've tested the specific search you need on the target server, assume it won't be.
- "It's HL7" — HL7 is the organization. They publish FHIR, HL7v2, and CDA. These are different standards. Ask which one.
The right questions to ask
Five questions that get you 90% of the way to a scoped FHIR conversation:
- Which FHIR version — R3, R4, or R5?
- Which resources — and is it the US Core profile, or full FHIR?
- Read-only, write-only, or bidirectional?
- What's the auth flow — SMART on FHIR, OAuth client credentials, or something custom?
- Has anyone on the team actually read the target server's CapabilityStatement?
If your engineers can answer all five, you have a scoped project. If they can't, get the answers before you commit to a date.