FHIR integration for healthtech founders: a non-academic guide

FHIR (Fast Healthcare Interoperability Resources) is the data interoperability standard that healthtech founders are required to support whether they want to or not. Major US health systems and EHRs (Epic, Cerner, Athena, Meditech) expose FHIR APIs. Federal regulations (the 21st Century Cures Act, Information Blocking rule) made it harder for them to refuse access. If your product touches patient data, you are going to integrate with FHIR.

The standard documentation for FHIR is dense, comprehensive, and largely useless for someone trying to ship a product in the next 90 days. This guide is the version we wish we had when we built our first FHIR integration: what to do, what to skip, what will hurt later.

FHIR in practice: what it actually is

FHIR is two things in practice:

First, it is a data model. A set of "resources" that describe clinical concepts: Patient, Observation (lab results, vitals), Condition (diagnoses), MedicationRequest (prescriptions), Encounter (a visit), DocumentReference (clinical notes). Each resource is a JSON or XML structure with mostly-standard fields and lots of extensions.

Second, it is a REST API specification. You can GET /Patient/123 to retrieve a patient. You can search /Observation?patient=123&code=8480-6 to get blood pressure readings. You can POST /Appointment to create an appointment. The semantics are mostly RESTful with some specific conventions (Bundle resources, _include parameters, version negotiation).

The catch: every implementer of FHIR (Epic, Cerner, Athena, regional health systems) interprets the standard slightly differently. There are required fields that one EHR enforces strictly and another ignores. There are extensions one vendor uses that another does not understand. The standard tells you the shape of the resource; reality tells you what the specific EHR actually returns.

Which version of FHIR to support

Three versions matter in 2026:

Default decision: build to R4. Add a translation layer if you need to support older versions. Plan to evaluate R5 in 12-18 months.

US Core and the role of implementation guides

Pure FHIR is too flexible. The US Core Implementation Guide narrows it down to "what every certified US EHR must support". For most US healthtech use cases, US Core is the actual contract you are coding against, not raw FHIR.

US Core defines:

• Required fields for each resource (US Core Patient must have an identifier, name, gender, etc.)
• Required code systems for things like race, ethnicity, language
• Required search parameters (you can always search Patient by name, identifier, etc.)
• Specific extensions for US-specific data (race, ethnicity, birthsex)

If you are building for the US market, build to US Core compliance, not raw FHIR. Other implementation guides exist for specific use cases (CARIN Blue Button for payer data, Da Vinci for payer-provider exchange, IPS for international patient summary). Pick the one that matches your use case rather than trying to be universal.

The four integration patterns that actually ship

Pattern 1: SMART on FHIR (in-EHR app launch)

Your application launches inside the EHR's UI when a clinician clicks a button. The EHR provides OAuth2 authorization, the patient context (current patient ID), and access to the FHIR API for that patient.

This is the right pattern for clinical decision support tools that augment the EHR workflow. Clinician sees patient, clicks your app, your app shows risk score or recommendation based on patient data, clinician acts. Time to integration: 4-12 weeks for a single EHR.

Pattern 2: Bulk data export

The EHR exposes a bulk endpoint that returns all patients (or a filtered subset) as a stream of FHIR resources. Used for population health, analytics, claims processing.

Implemented as the FHIR Bulk Data Access (Flat FHIR) specification. The EHR exports NDJSON files; your system processes them. Time to integration: 6-16 weeks. Watch for performance issues with very large patient populations and rate limits set by the EHR.

Pattern 3: Patient-mediated access

The patient logs into your app, authorizes via OAuth, and your app pulls their data from one or more EHRs on their behalf. Powered by SMART App Launch (with patient as the authenticator instead of clinician) and the Cures Act-mandated Patient API.

This is the right pattern for direct-to-consumer healthtech, personal health records, care coordination. Time to integration: 8-20 weeks. The complexity is supporting many EHRs (each with quirks), not the protocol itself.

Pattern 4: Business-to-business with backend services

Your service exchanges data directly with another organization's FHIR server, authenticated via SMART Backend Services or mutual TLS. No user in the loop. Used for care coordination between providers, payer-provider exchange, lab results delivery.

Time to integration: 12-30 weeks per partner. Each B2B integration tends to require legal agreements, security reviews, and bilateral testing.

Where the real cost lives

The protocol-level work is the visible part. The expensive part is everything that happens after "we successfully called the API once".

Libraries and tools that save time

Do not write FHIR client code from scratch. Use one of:

• HAPI FHIR (Java): the most complete FHIR implementation. Use this for production servers and Java-based clients.
• fhir.js / fhir-kit-client (JavaScript/TypeScript): good clients for Node.js applications and browser-based SMART apps.
• fhir.resources (Python): Pydantic-based FHIR models. Solid choice for Python services.
• Firely .NET SDK (C#): well-maintained, used in many production systems.
• Aidbox / Medplum (server side): hosted FHIR servers if you do not want to operate one yourself. Worth the cost for early-stage teams.
• SMART on FHIR Sandbox: for development and testing without needing a real EHR connection.

Avoid building your own FHIR validator. The standard is too complex; use the official validator or an established library.

Week-one checklist for your first FHIR integration