On this page
- What is HL7 FHIR?
- Why does FHIR matter for your healthcare app?
- Which U.S. rules require FHIR APIs in 2026?
- How do healthcare apps use FHIR?
- How to build a FHIR-enabled healthcare app: 7 steps
- What affects the cost and timeline of a FHIR project?
- Common myths about FHIR
- How do you choose a FHIR development partner?
- Summing up
- FAQ
Healthcare data is spread across EHRs, lab systems, payer databases, and patient devices. That fragmentation makes coordinated care hard and slows down every new digital health product. HL7 FHIR fixes the core problem by giving every system the same data format and the same web API rules.
For founders, product managers, and CTOs, FHIR is no longer optional. U.S. rules require FHIR APIs from certified EHRs and from most public-program payers. This blog covers what FHIR is, why it matters, the 2026 rules, real use cases, a 7-step build plan, costs, common myths, and how to pick a partner.
What is HL7 FHIR?
HL7 FHIR is a standard for exchanging health data electronically, published by HL7 International, the standards body behind earlier HL7 versions. FHIR describes health data as small, defined building blocks called resources. Apps request those resources through REST APIs, the same web technology used in banking and retail apps.
Grahame Grieve proposed FHIR to HL7 in 2011, and HL7 adopted it as a project that September. FHIR Release 4 (R4), finalised in late 2018 and published as version 4.0.1 in October 2019, was the first release with normative content, and U.S. certification rules still build on it. The full HL7 FHIR specification is free to read and use.
FHIR is an international standard, not a U.S. one. Hospitals, payers, device makers, and governments around the world use it. An app built on FHIR can therefore work across markets, with local profiles added on top.
How do FHIR resources work?
A FHIR resource is a standard data structure for one real-world concept, such as a patient, a lab result or a prescription. Each resource has defined fields, codes, and links to other resources. Common examples include:
- Patient, which holds demographics such as name, birth date, and identifiers.
- Observation, which holds lab results, vital signs, and device readings.
- AllergyIntolerance, which holds a patient’s allergies and reactions.
- MedicationRequest, which holds prescriptions and medication orders.
- Coverage, which holds a patient’s insurance details.
Apps work with resources through simple HTTP calls. A GET request reads data, such as a patient’s current medication list. A POST request writes data, such as a new blood pressure reading. Resources travel as JSON or XML, so any web or mobile developer can parse them.
Apps request only the resources they need, so they avoid moving whole records for every task. Implementation guides, such as US Core in the United States, add rules on top of the base resources so every system fills in the same fields the same way.
How is FHIR different from HL7 v2 and C-CDA?
FHIR exchanges small pieces of data through APIs, while HL7 v2 sends event messages and C-CDA sends whole documents. All three are still in use, and many apps touch more than one.
How HL7 FHIR compares with older HL7 standards
| Standard | Format | How Data Moves | Best For |
|---|---|---|---|
| HL7 v2 | Pipe-delimited text messages | Event messages over point-to-point interfaces | Lab results, admissions and other hospital event feeds |
| C-CDA | XML documents | Whole clinical documents | Care summaries at referral and discharge |
| HL7 FHIR | JSON or XML resources | REST API calls for specific data | Mobile apps, patient access and real-time integration |
Why does FHIR matter for your healthcare app?
FHIR matters because it cuts integration time, keeps your app aligned with U.S. law, and connects you to a large ecosystem of systems that already use the same standard. Those three benefits drive most build decisions.
Faster, cheaper integration
FHIR shortens integration because certified systems expose the same resources through the same API pattern. Instead of a custom interface for each EHR, your team builds one data mapping and adapts it per system. A well-planned FHIR integration solution reuses that mapping across every connection your app needs.
FHIR does not remove integration work. It replaces fragile point-to-point interfaces with reusable APIs, which lowers maintenance as you add partners, features, and markets.
Regulatory alignment
FHIR support keeps a U.S. healthcare app in line with federal rules on patient data access. Certified EHRs and most public-program payers must offer FHIR APIs, so building on FHIR from the start avoids costly retrofits later.
Broad vendor support
Major EHR vendors, including Epic, Oracle Health (formerly Cerner), MEDITECH, and athenahealth, offer FHIR APIs and developer programs. Amazon, Google, and Microsoft all sell managed FHIR services. SMART on FHIR, an open authorization framework, lets one third-party app launch inside many of these EHRs.
Better patient and clinician experience
FHIR improves care because it puts timely data in front of the people who need it. A clinician who sees a patient’s current medications, allergies, and recent labs in one place can avoid errors and repeat tests. Patients also gain control because FHIR-based apps let them view and share their own records from a phone.
Which U.S. rules require FHIR APIs in 2026?
Two federal bodies require FHIR APIs in the United States. ASTP/ONC (the Assistant Secretary for Technology Policy and Office of the National Coordinator for Health IT) sets rules for certified health IT. CMS (the Centers for Medicare & Medicaid Services) sets rules for payers in public programs. Any app that pulls data from these systems will meet FHIR.
Rules for certified EHRs
The 21st Century Cures Act of 2016 led to the ONC Cures Act Final Rule in 2020. That rule created a standardized FHIR API certification criterion known as (g)(10). After a pandemic-era extension, certified health IT developers had until December 31, 2022 to make FHIR R4–based (g)(10) APIs available to their customers.
The ASTP/ONC HTI-1 final rule raised the baseline to USCDI version 3 from January 1, 2026. USCDI, the United States Core Data for Interoperability, is the national list of data classes every certified system must exchange.
In FHIR terms, that baseline is the HL7 US Core Implementation Guide, version 6.1.0. HTI-1 also required SMART App Launch v2.0.0.
HTI-4, finalized in July 2025 and effective October 1, 2025, added FHIR-based certification criteria (g)(31)–(g)(33) for electronic prior authorization. HTI-5, finalized in October 2026, removed 14 of the 60 certification criteria (fewer than the 34 originally proposed) and left the HTI-4 criteria in place.
Rules for payers
CMS has enforced the FHIR Patient Access API requirement for Medicare Advantage, Medicaid, CHIP, and federal Marketplace plans since July 1, 2021. The CMS Interoperability and Prior Authorization final rule fact sheet explains how the rule extends this to four FHIR APIs: Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization.
Most of those API requirements apply from January 1, 2027, depending on payer type. Impacted payers also began reporting Patient Access API usage metrics to CMS in 2026.
Privacy and security rules still apply
FHIR defines how data moves, not who may see it. HIPAA applies to covered entities and their business associates, so a FHIR app built for a hospital or payer must meet HIPAA safeguards. A consumer app that a patient chooses may sit outside HIPAA but can still fall under the FTC Health Breach Notification Rule. Certifications such as HITRUST and SOC 2 are voluntary, but many buyers ask for them.
What about outside the United States?
FHIR also underpins national health data programs outside the United States. India’s Ayushman Bharat Digital Mission uses FHIR R4 profiles for health record exchange. Anyone building an ABDM-compliant healthcare app therefore works with FHIR from day one. NHS England publishes UK Core FHIR profiles for the same reason.
How do healthcare apps use FHIR?
Healthcare apps use FHIR in five main ways. They give patients their records, feed telehealth and monitoring tools, coordinate chronic care, automate payer workflows, and extend EHRs.
Patient access apps and personal health records
Patient access apps let people download and manage their own medical records. Apple Health Records, launched with iOS 11.3 in 2018, uses FHIR and SMART on FHIR to pull records from participating providers into the iPhone Health app.
Example: a large US diagnostics company with a non-FHIR database added a SMART on FHIR interface so patients could see lab results in Apple Health. According to a Smile Digital Health case study, the integration took under six months and used 25–33% fewer developers than a typical project of that kind.
Telehealth and remote patient monitoring
Telehealth and remote monitoring apps use FHIR to share clinical data before, during, and after a visit. A telemedicine platform can pull a patient’s medication list and recent vitals from the EHR before a video consultation. Teams planning that product can follow a step-by-step plan for how to build a telemedicine app.
Connected devices in the Internet of Medical Things, or IoMT, can send readings as FHIR Observation resources. Glucometers and blood pressure cuffs are common examples. Clinicians then review trends and get alerts when a reading leaves a safe range.
Chronic care and care coordination
Chronic care apps use FHIR to bring records from several providers into one shared view. A heart failure program can share daily weight and blood pressure readings with the primary care doctor and the cardiologist. Both teams then work from the same plan.
Payer workflows and prior authorization
Payers and providers use FHIR to check eligibility and submit prior authorizations without fax or phone calls. HL7’s Da Vinci project publishes implementation guides for these workflows, including Coverage Requirements Discovery, Documentation Templates and Rules, and Prior Authorization Support.
Example: according to a CapMinds case study, a large U.S. third-party administrator mapped fragmented eligibility and claims data into FHIR resources such as Coverage, CoverageEligibilityRequest, Claim and ClaimResponse, then built FHIR-based APIs for eligibility checks, pre-authorization and claims on top of them.
SMART on FHIR apps inside the EHR
SMART on FHIR apps run inside the clinician’s EHR screen and add tools the EHR lacks. A decision support app can read lab trends and vitals, then show a risk score or an alert. CDS Hooks, a related HL7 specification, lets the EHR call that app at the right moment, such as when a clinician signs an order.
How to build a FHIR-enabled healthcare app: 7 steps
Building a FHIR-enabled healthcare app takes seven steps. You define the data, pick standards, choose a server, set up authorization, handle legacy data, secure the app and test against real systems. FHIR work sits inside wider healthcare software development, so plan it alongside product, design and compliance.
1. Define the use case and the data you need
Defining the use case means listing the exact data your app must read and write. Map each item to a USCDI data class and a FHIR resource, and note which systems hold it. Decide early whether you only read data or also write it back, because write access is less common and takes longer to approve.
2. Choose the FHIR version and implementation guides
FHIR R4 is the right version for most new apps in 2026. In the United States, build to US Core 6.1.0, which matches USCDI v3. FHIR R5 is a trial-use release, and R6 is still in balloting. Add other guides only where your use case needs them:
- Da Vinci guides for payer and prior authorization workflows.
- Bulk FHIR for exporting data on large patient groups.
- SMART App Launch for app authorization.
3. Pick a FHIR server or managed service
A FHIR server stores resources and exposes the FHIR API. You can run your own or use a managed cloud service. The right choice depends on control, compliance needs and team skills.
Common FHIR server options
| Option | Type | Best For |
|---|---|---|
| HAPI FHIR | Open-source Java server | Teams that want full control or on-premises hosting |
| AWS HealthLake | Managed cloud service | Apps already on AWS that need health data analytics |
| Google Cloud Healthcare API | Managed cloud service | Teams on Google Cloud handling FHIR, HL7 v2 and DICOM |
| Azure Health Data Services | Managed cloud service | Organizations standardized on Microsoft Azure |
Check that any option supports R4, US Core profiles, search indexing for large data sets and audit logging. Managed services cut setup time but tie you to one cloud. Self-hosted servers give more control but need more DevOps effort.
4. Set up authorization with SMART on FHIR
SMART on FHIR is the standard way to authorize apps that use FHIR data. It builds on OAuth 2.0 for access tokens and OpenID Connect for user identity. Scopes define exactly which resources an app may read or write, and a user or administrator approves them.
Plan for both launch types. In an EHR launch, the app opens inside the EHR with the current patient selected. In a standalone launch, a patient or clinician opens the app directly and signs in.
5. Plan for legacy data
Most health systems still run HL7 v2 feeds, C-CDA documents and DICOM imaging alongside FHIR. An integration engine translates those formats into FHIR resources, so your app works with one data model. Budget time for terminology mapping too: LOINC for lab tests, SNOMED CT for clinical terms and RxNorm for medications.
6. Secure the app and document compliance
A FHIR app needs the same safeguards as any system that holds health data. Use HTTPS everywhere, encrypt stored data, apply role-based access and log every access. Sign business associate agreements with vendors that handle protected health information. Support patient rights too: when a patient revokes an app’s access, the app must stop pulling data at once.
7. Test conformance and every target system
Testing proves that your FHIR API and app behave as the standards expect. Inferno, the open-source testing tool from ASTP/ONC, checks conformance with US Core and SMART App Launch. After that, test in each EHR vendor’s developer sandbox, because two FHIR systems can still return data differently. HL7 FHIR Connectathons offer another chance to test against other implementers.
What affects the cost and timeline of a FHIR project?
The cost and timeline of a FHIR project depend mostly on how many systems you connect and whether you write data back. A read-only patient app connected to one EHR is a small project. A two-way clinical app across several EHRs and payers is a large one. The main cost drivers are:
- The number of target systems, because each EHR or payer needs its own setup, testing and approval, and initial integration can take several weeks of work per system.
- Write access, because vendors review apps that change records more strictly than read-only apps.
- Legacy data, because partners that still send HL7 v2 or C-CDA add mapping and transformation work.
- Compliance scope, because security reviews, audits and hosting controls affect both cost and schedule.
- Ongoing upgrades, because US Core and the regulations change on a regular cycle.
Plan maintenance from the start. Each new US Core release and EHR update can change what your app receives, so keep budget for regular conformance checks.
Common myths about FHIR
The most common myth about FHIR is that it works out of the box everywhere. FHIR simplifies interoperability, but real projects still need planning, testing and fallback options.
Myth: FHIR is plug-and-play everywhere
FHIR support varies widely between hospitals. ONC Data Brief No. 68 found that two in three U.S. hospitals used a FHIR API for patient app access in 2022. Among hospitals that let clinician apps read EHR data, nearly half used only standards-based APIs, and about one in three did so for writing data back. ASTP/ONC’s 2024 data (Data Brief No. 81, February 2026) put standards-based patient access at about seven in ten hospitals, higher at hospitals on a market-leading EHR than at others.
Myth: FHIR is only for large hospitals
FHIR scales from a single clinic to a national network because it runs on ordinary web technology. Adoption is the gap, not the standard. The same ONC data shows that small, rural and critical access hospitals use FHIR APIs at lower rates than large, system-affiliated ones. Factor that readiness into your rollout plan if you sell to community providers.
Myth: FHIR replaces every legacy standard
FHIR is the new front door, but older pipelines still run behind it. Lab instruments often output HL7 v2 messages, imaging runs on DICOM, and referrals still move as C-CDA documents. Expect to bridge these formats with middleware for years.
Myth: every EHR’s FHIR API behaves the same
Each health system configures its EHR differently, adds local extensions and limits which resources it exposes. FHIR’s flexibility is a strength, but it means no two APIs are identical. Build your app to handle missing fields, extra fields and different search behavior.
How do you choose a FHIR development partner?
The right FHIR development partner has shipped healthcare apps that connect to real EHRs and can show how it tests them. Use these checks during selection:
- Healthcare experience: the team knows clinical and payer workflows and code systems such as USCDI, LOINC and SNOMED CT.
- FHIR track record: the team can show live SMART on FHIR apps or FHIR integrations and explain how it tested them against real EHRs.
- Regulatory knowledge: the team understands HIPAA, the ASTP/ONC certification criteria and the CMS payer API rules.
- Open standards: the team builds on open standards rather than proprietary connectors that lock you in.
- Conformance testing: the team uses Inferno and vendor sandboxes and has a plan for new US Core releases.
PRO TIP: Start with a small pilot before a full build. A focused first release through mvp development services shows how a partner handles FHIR scope, testing, and EHR approvals before you commit to the full product.
Ailoitte is one option to consider. As a healthcare app development company, Ailoitte builds patient and clinician apps that connect to EHRs and payer systems through FHIR APIs. Compare it with two or three other partners against the checks above.
Summing up
HL7 FHIR is the standard way for healthcare apps to exchange patient data in 2026, and U.S. rules require it from certified EHRs and most public-program payers. Build to FHIR R4 and US Core 6.1.0, authorize with SMART on FHIR, plan for legacy data, and test against every target system. Treat FHIR as a strong foundation that still needs careful planning, not a plug-in that works on its own.
Sunil Kumar is CEO of Ailoitte, an AI-native engineering company building intelligent applications for startups and enterprises. He created the AI Velocity Pods model, delivering production-ready AI products 5× faster than traditional teams. Sunil writes about agentic AI, GenAI strategy, and outcome-based engineering.
About Ailoitte
