FHIR (Fast Healthcare Interoperability Resources) is HL7's web-native standard for exchanging health data through REST APIs using JSON, modeling records as discrete resources like Patient, Observation, and Encounter. For startups in 2026, FHIR R4 plus the USCDI data set is the practical foundation for interoperability: it lets your product read and write real clinical data across major EHRs, satisfy US API rules, and avoid building one-off integrations for every customer.
Why interoperability decides whether your product ships
Healthcare data is famously fragmented. A single patient's records can live across hospital EHRs, lab systems, pharmacies, payers, and consumer devices, each with its own format. If your product can't move data in and out of those systems, it stays a demo. Interoperability is what turns a prototype into something a clinic or health system can actually deploy.
For founders, this is both a technical and a commercial issue. Buyers ask how you connect to their EHR in the first sales call. Getting interoperability right early is a core part of any realistic healthtech startup roadmap, and getting it wrong is one of the most common and expensive healthtech MVP mistakes we see teams make. This guide covers the concepts: HL7 vs FHIR, FHIR resources, SMART on FHIR, and the USCDI/TEFCA landscape. For the hands-on connection work, see our companion guide on EHR integration for startups.
HL7 v2, CDA, and FHIR: what's actually different
HL7 is the standards body, not a single format. Over decades it has published several specifications, and you'll encounter more than one in production. Understanding which is which saves you from a lot of confusion when a hospital's integration team starts talking.
HL7 v2 messaging
HL7 v2 is the workhorse inside hospitals. It uses pipe-and-hat delimited messages (ADT for admissions, ORM/ORU for orders and results) flowing through interface engines like Mirth or Rhapsody. It's everywhere, but it's not web-friendly: you don't call a v2 endpoint with a browser. It assumes a point-to-point interface and a fair amount of site-specific customization.
CDA documents
Clinical Document Architecture (CDA) and its C-CDA variant package data as structured XML documents, like a discharge summary or care record. They're document-centric rather than data-centric, which makes pulling a single value (one lab result) clumsy compared to an API call.
FHIR
FHIR is the modern, web-native answer. It exposes data as RESTful resources you fetch over HTTPS, returns JSON or XML, and uses ordinary HTTP verbs. For a startup team that already knows REST and OAuth, FHIR feels familiar in a way v2 never will. The table below summarizes the practical tradeoffs.
| Standard | Format | Transport | Best for | Startup difficulty |
|---|---|---|---|---|
| HL7 v2 | Pipe-delimited messages | Interface engine / MLLP | Intra-hospital feeds (ADT, results) | High — needs an engine and mapping |
| C-CDA | Structured XML documents | File / Direct messaging | Document exchange (summaries) | Medium — verbose XML parsing |
| FHIR R4 | JSON / XML resources | REST over HTTPS | App integrations, patient & provider APIs | Low–Medium — familiar REST + OAuth |
The reality in 2026: you'll often consume FHIR at the edge while a hospital still runs v2 internally, with the EHR vendor translating between them. That's fine. Your job is to build against FHIR and let the established systems handle their legacy plumbing.
FHIR resources: the building blocks
FHIR organizes health data into resources, each a self-contained object with a defined structure and its own URL. Instead of one giant patient record, you work with many small, linked pieces. A clinical visit might touch a Patient resource, an Encounter, several Observation resources, a Condition, and a MedicationRequest, all referencing each other by ID.
Here are the resources most healthtech MVPs touch first:
- Patient — demographics and identifiers, the anchor most other resources reference.
- Observation — vitals, lab results, and measured data points; the most heavily used resource in practice.
- Condition — diagnoses and problems, usually coded with ICD-10 or SNOMED CT.
- MedicationRequest / MedicationStatement — prescriptions and what a patient is taking.
- Encounter — a visit or interaction that ties events together.
- DocumentReference — pointers to notes, PDFs, or images.
Each resource leans on standard code systems: LOINC for lab and observation codes, SNOMED CT for clinical terms, ICD-10 for diagnoses, RxNorm for medications, and CPT for procedures. Mapping your internal data to these vocabularies is unglamorous but essential. If your app generates a glucose reading, it should carry the right LOINC code and UCUM unit so the receiving system understands it without a human in the loop. This terminology work matters even more if you're feeding data into clinical decision support software, where a miscoded value can change a recommendation.
A note on FHIR versions
FHIR R4 is the default for 2026 integrations and the version named in US regulation. R5 exists and R6 work is ongoing, but most production EHR endpoints still speak R4 (often via the US Core profiles). Build for R4 unless a specific partner requires otherwise, and don't over-engineer for versions your customers aren't running.
SMART on FHIR: secure app launch
FHIR defines the data; SMART on FHIR defines how an outside app gets authorized to touch it. SMART layers OAuth 2.0 and OpenID Connect on top of FHIR, with standardized scopes (like patient/Observation.read) and launch contexts. The payoff is huge: instead of building bespoke authentication for every EHR vendor, you implement the SMART flow once and connect to many.
There are two common patterns. EHR launch happens when a clinician opens your app from inside the EHR and the launch context tells you which patient is in view. Standalone launch happens when a patient or user opens your app directly and authorizes access to their own records, including from patient-facing portals. Knowing which flow you need shapes your auth design and your onboarding UX.
SMART scopes also force you to think about minimum necessary access early, which aligns neatly with HIPAA. Requesting only the resources and operations you genuinely need is good security and good optics with hospital review boards. We dig deeper into safeguarding the data itself in building AI with patient data and how to make an app HIPAA compliant.
USCDI and TEFCA at a glance
Two US frameworks shape what data you exchange and how networks connect. They sound bureaucratic, but they translate into concrete product decisions.
USCDI
The United States Core Data for Interoperability (USCDI) is a standardized list of data classes and elements that certified health IT must support, things like patient demographics, allergies, medications, lab results, clinical notes, and more. USCDI defines what data should be available; FHIR (via US Core profiles) defines how it's represented. If your product handles a USCDI data class, mapping cleanly to the matching FHIR profile keeps you aligned with what EHRs already expose.
TEFCA
The Trusted Exchange Framework and Common Agreement (TEFCA) is a national network-of-networks model that lets participants exchange data through Qualified Health Information Networks (QHINs). For an early MVP you rarely connect to TEFCA directly, but it matters for your roadmap: as you scale, joining or partnering with a QHIN can unlock nationwide query-based exchange. Know it exists and design so you can plug in later.
Information blocking rules
US information-blocking regulations discourage practices that unreasonably interfere with access to electronic health information, and ONC certification requires standardized FHIR APIs. The practical effect for startups is positive: major EHRs are now obligated to expose FHIR endpoints, so the data you need is more reachable than it was a few years ago.
One honest caveat: this section is general information, not legal or regulatory advice. The specifics of USCDI versions, certification, and TEFCA participation change, and they interact with your particular use case. Treat this as orientation and bring in qualified healthcare counsel before you make compliance claims or sign agreements. SpeedMVPs builds HIPAA-ready, standards-based MVPs, but we'll always tell you where you need a lawyer rather than a developer.
Designing your product to be interoperable
Interoperability isn't a feature you bolt on at the end; it's an architecture decision. A few principles save you painful rework later.
Model your internal data against FHIR early
Even if you store data in your own schema, keep a clear mapping to FHIR resources from day one. When a customer asks for FHIR export or a SMART integration, you'll translate, not rebuild. Designing your domain model with Patient, Observation, and Encounter shapes in mind costs little upfront and pays off fast. This is one of the choices that belongs in your healthtech tech stack decisions.
Use the standard vocabularies
Store codes (LOINC, SNOMED, RxNorm, ICD-10) alongside human-readable labels. Free-text-only fields are interoperability dead ends. If you let users enter unstructured data, plan a coding step, whether manual mapping, a terminology service, or an LLM-assisted classifier with human review.
Separate the integration layer
Keep EHR and partner connections behind a clean adapter so vendor quirks don't leak into your core logic. Epic, Oracle Health, athenahealth, and others all have FHIR endpoints, but each has its own sandbox, registration process, and edge cases. A dedicated layer lets you add the next vendor without touching your product code, the practical heart of EHR integration for startups.
Plan for write-back carefully
Reading FHIR data is comparatively easy. Writing back into a clinical system (creating an order, updating a problem list) raises higher safety and permissioning bars and often requires extra vendor approval. Scope your MVP around what's achievable, and be explicit with customers about read vs write capabilities.
How this fits an MVP timeline and budget
Founders ask whether real FHIR interoperability is realistic for a first version. It can be, if you scope tightly. A focused MVP that reads a defined set of FHIR resources from one or two EHR sandboxes via SMART on FHIR is achievable in weeks, not quarters. The cost driver isn't FHIR itself; it's the breadth of integrations and whether you need write-back and multi-vendor support on day one.
The table below shows how scope shifts effort. Treat these as planning ranges, not quotes, and sanity-check your own numbers against our healthcare app development cost breakdown and the broader AI MVP cost guide.
| Interoperability scope | Typical MVP effort | Notes |
|---|---|---|
| Read-only, one EHR sandbox, SMART launch | Low | Great first milestone; proves the integration pattern |
| Read across 2–3 EHR vendors | Medium | Adapter layer plus per-vendor registration and testing |
| Read + limited write-back | Medium–High | Extra approvals, safety review, narrower vendor support |
| Network exchange (QHIN / TEFCA path) | High / later phase | Usually post-MVP; plan architecture so you can join later |
This is exactly the kind of scoping conversation that determines whether your build succeeds. Our guide on scoping an AI MVP before you build walks through the tradeoffs, and the broader healthtech MVP development pillar ties interoperability into the full picture of building a compliant health product.
Where SpeedMVPs fits
SpeedMVPs builds production-ready, HIPAA-ready AI MVPs in 2-3 weeks with fixed pricing and direct developer access. For interoperability work that means designing your data model around FHIR resources from the start, wiring SMART on FHIR auth, and connecting to the EHR sandboxes your first customers care about, without the multi-month timelines large agencies quote. When write-back, multi-vendor support, or TEFCA participation become relevant, we architect the MVP so those are additions, not rewrites. You work directly with the engineers building it, so the interoperability decisions get made by people who understand both the standard and your product goals.
Get interoperability right from the first sprint
FHIR, SMART on FHIR, and USCDI aren't optional nice-to-haves in modern healthtech; they're how your product earns the right to touch real patient data and integrate with the systems your customers already run. Scope the interoperability you need now, design for the interoperability you'll need later, and you avoid the costly rebuilds that sink so many health startups. If you're mapping out a FHIR-based product and want a partner who has shipped compliant, standards-based MVPs, book a free discovery call. You can also explore our AI MVP Development service or model a budget with the AI MVP Cost Calculator before you commit.
