What is FHIR?

A 30-second history

Healthcare interoperability has been an engineering problem for forty years. The standards body HL7 produced HL7 v2 in the late 1980s — a pipe-delimited message format that became the workhorse of hospital integrations and is still everywhere. In the 2000s, HL7 tried again with CDA, an XML document standard. Neither was friendly to web developers, and neither produced a standard for "let me launch an app inside an EHR."

FHIR was started in 2011 to fix that. The design goal was deliberately simple: make it look like a normal REST API. Resources are JSON. Endpoints follow REST conventions. Auth is OAuth 2.0. A web developer can read the FHIR spec on a Saturday and ship a working integration on a Monday.

FHIR R4 — the current normative version most EHRs support in production — was published in 2019. The 21st Century Cures Act in the US, and the ONC's interoperability rules that followed, made FHIR R4 the required interoperability surface for certified EHRs. That's why every Epic, Cerner / Oracle Health, Meditech, athenahealth, and eClinicalWorks instance now exposes a FHIR endpoint.

What's actually in FHIR

FHIR has three things stacked together: a data model (resources), an API (RESTful endpoints), and extensions for the long tail of variation between systems.

Resources

A FHIR resource is a structured representation of a clinical concept. There are about 150 resource types in R4, but in practice most production apps use a small subset. The ones you'll encounter constantly:

• Patient — demographics, identifiers, contact info.
• Encounter — a clinical visit. Has a start time, end time, location, and type.
• Observation — labs, vitals, assessment scores. Anything you measure or observe about the patient.
• Condition — a diagnosis or active clinical problem.
• MedicationRequest — an order for a medication.
• DocumentReference — a clinical note. The standard write target for ambient scribes and AI documentation.
• ServiceRequest — an order for a procedure, referral, or service.
• Practitioner — a clinician. Used to identify the launching user.

Each resource has a stable schema and a stable identifier. You can fetch one by ID: GET /Patient/12345. You can search: GET /Observation?patient=12345&category=vital-signs. You can create or update one with PUT/POST. It feels like every other REST API you've used.

The API

FHIR uses standard HTTP verbs, returns JSON (or XML if you really want), supports cursor-based paging, and uses OAuth 2.0 for authentication. There's nothing exotic about it from a developer ergonomics perspective. Every search returns a Bundle resource containing zero-or-more matching resources plus paging links.

Extensions and profiles

Real-world clinical data doesn't fit a global schema cleanly. FHIR's answer is extensions — a mechanism to add fields to any resource — and profiles — constraints and conventions for a specific use case. The most important profile family for US apps is US Core, which standardizes how things like vital signs, demographics, and lab results are represented across US EHRs.

US Core is the practical baseline. If your app is built against US Core profiles, it will work cleanly across most US-based Epic instances with minimal per-hospital adjustment.

FHIR vs the older HL7 standards

Hospitals still run plenty of HL7 v2 — for ADT messages, lab orders, and other message-driven workflows. HL7 v2 isn't going away tomorrow. But for new third-party apps that need to launch inside the EHR and read or write clinical data with patient context, FHIR is the answer. You will rarely build a new SMART on FHIR app on top of HL7 v2.

Where you'll see HL7 v2 in your life as a vendor: anything involving real-time event streams from hospital systems (e.g., "tell me when this patient is admitted") is often still HL7 v2 under the hood, even if it's wrapped in a more modern API by an integration platform like Redox or Mirth.

FHIR is necessary, not sufficient

FHIR gives you a clean API surface to build against. It does not give you a hospital deployment. To actually ship a FHIR-based app into Epic, you still need:

• SMART on FHIR for the launch and auth flow.
• HIPAA-compliant hosting + a BAA with each hospital.
• SOC 2 Type II evidence for the security review.
• An Epic Showroom listing — Epic's vendor marketplace.
• Maintenance when Epic ships breaking changes to the FHIR endpoints.

FHIR is the data layer. The runtime around it is the part that wins or loses hospital deals — and the part SoFaaS™ owns on your behalf.