Alluxi

FHIR integration for healthtech founders: a non-academic guide

Alluxi -

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.

Audience: founders and engineering leaders at early-stage healthtech companies (seed to Series B) who need to integrate with EHRs or other clinical systems via FHIR. Not aimed at researchers, standards committee members, or enterprise EHR teams who have different constraints.

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:

FHIR R4 (4.0.1)
The version mandated by US regulations. The most widely supported. If you support only one version, support this one. Vast majority of EHRs in 2026 expose R4.
FHIR R4B (4.3.0)
Maintenance release of R4. Most things are identical. A few resources got updates. Real-world adoption is partial.
FHIR R5 (5.0.0)
Latest major release. Better in many ways. Real-world adoption is still early. Build R4 today; plan for R5 in 2-3 years.
DSTU2 / STU3
Pre-R4 versions. Some smaller EHRs still expose them. Avoid if possible. If you must support, use a translation library rather than writing version-specific code.

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".

!
Vendor-specific quirks and missing data Epic returns slightly different data than Cerner, who returns slightly different data than Athena. Your code needs to handle each. Plan for 4-8 weeks per EHR after the initial integration to harden against real-world data.
!
App registration and certification Epic requires registration in the App Orchard or App Market. Cerner requires registration in code.cerner.com. Some integrations require certification reviews that take 8-16 weeks. Plan for this from day one.
!
Production tenant access Sandbox testing is straightforward. Production access at a real health system requires hospital-side IT setup, security review, contracts, and often a champion physician. Average time from "first conversation with hospital" to "in production" is 6-12 months.
!
HIPAA compliance and BAAs Every vendor whose service touches PHI needs a Business Associate Agreement with you. Plus your own SOC 2 Type II, HIPAA security policies, audit logging, encryption at rest and in transit. The compliance work easily exceeds the engineering work.
!
Identity matching "Same patient" across multiple sources is harder than it sounds. Names misspelled, DOB inconsistencies, multiple records in the same EHR. Patient matching algorithms are a discipline. For B2C apps, having the patient confirm their own identity simplifies most of this.
!
Versioning and updates FHIR specs evolve. EHRs update their implementations. Your code needs to track these changes. Budget 10-15% of original development cost per year for version maintenance.

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

✓
Pick the integration pattern SMART on FHIR launch, patient-mediated, bulk data, or B2B. Different paths require different scaffolding.
✓
Pick the FHIR version (R4) and implementation guide (US Core) Resist the temptation to support multiple versions early. Add later.
✓
Register a developer account at Epic, Cerner, or your target EHR You will need this to get sandbox credentials. The signup process can take days.
✓
Build against the sandbox first SMART Health IT sandbox, Epic sandbox, Cerner sandbox. Get the auth flow working end to end before talking to anyone about production.
✓
Pick a FHIR client library and a server library Choose one for the language your team knows best. Do not write FHIR code from scratch.
✓
Set up HIPAA-compliant infrastructure from day one Encryption, audit logs, BAAs with vendors, access controls. Retrofitting compliance is brutal.

The reality

FHIR integration is not particularly hard at the protocol level. The hardness is everywhere else: vendor-specific behavior, certification cycles, hospital-side IT processes, HIPAA compliance, identity matching, ongoing version drift.

For an early-stage healthtech company, plan 4-6 months from "we want to integrate with Epic" to "we are in production at one health system". Plan 12-18 months to be in production at five health systems. Budget 30-40% of engineering time on integration and compliance for the first two years.

If you want a working session to plan your specific FHIR integration, we have built integrations across the patterns described above and can shorten the learning curve by months. Book a free consultation at Alluxi.