Cybersecurity: 24/7/365
Cybersecurity: 24/7/365
4MEDNET delivers managed IT, cybersecurity, HIPAA compliance, and AI automation solutions built exclusively for healthcare practices.
HL7 FHIR integration services: FHIR APIs, SMART on FHIR apps, FHIR servers, and HL7 v2 bridges for health-tech products and healthcare organizations.
FHIR is the reason connecting to an EHR is easier than it was five years ago. It is also why half the integration advice online is out of date.
We build FHIR integrations for health-tech products and healthcare organizations. Reading records, writing results back, launching inside the chart, and bridging to the HL7 v2 feeds still running underneath.
This page covers what FHIR is, how it differs from HL7 v2, what we build, and what it costs.
Hospitals on standards-based FHIR APIs (2024)
CMS deadline for four payer FHIR APIs
Typical FHIR project, discovery to go-live
FHIR stands for Fast Healthcare Interoperability Resources. The HL7 FHIR standard defines how health data moves over the web.
The core idea is the resource. A Patient, an Observation, a MedicationRequest — each is a self-contained object with a defined shape, retrievable at its own URL.
FHIR resources are the vocabulary. An integration is mostly a conversation about which resources move, in which direction, and how often.
The current production version is R4, with US Core profiles layering American requirements on top. Nearly all real work in the United States targets that pair.
In practice, yes. The FHIR standard defines a REST API over ordinary web services, returning JSON or XML.
If your team has used any modern web API, FHIR APIs will feel familiar. You GET a Patient by id, search Observations by date, and POST a DocumentReference.
That familiarity is the point. FHIR was designed so ordinary web developers could work with health data without first learning a bespoke messaging format.
What differs is the domain. The shapes are clinical, the vocabularies are coded, and the access control rules are stricter than most APIs your team has met.
Both are HL7 standards, which causes most of the confusion. HL7 v2 is the older messaging format, and it still moves the majority of hospital traffic.
HL7 v2 pushes pipe-delimited messages over a persistent connection whenever an event happens. Something arrives whether you asked for it or not.
FHIR pulls. You request the data you want, when you want it, over an ordinary HTTPS call. It also supports subscriptions when you need real-time updates.
The HL7 standard for v2 is better at high-volume event feeds like admissions. FHIR is better at querying a health record and at anything a web or mobile app needs.
Most healthcare data exchange projects end up using both. Treating the choice as either-or is the most common planning mistake we see.
Regulation drove FHIR adoption faster than any vendor could have.
The 21st Century Cures Act requires certified electronic health record systems to expose standardized FHIR APIs, and it prohibits information blocking.
CMS rules pushed the payer side too. A payer must now offer Patient Access and Provider Directory APIs built on FHIR, which is why payer integration became a live market.
TEFCA adds a national framework for exchange between networks. The direction is settled: FHIR is the interface to US health information.
For a product team that means the FHIR ecosystem is no longer optional. Buyers assume you speak it before they ask anything else.
Most engagements take one of five shapes.
Reading clinical data from an EHR: patient records, observations, medications, allergies, and documents, on demand or on a schedule.
Writing back: results, notes, and documents that land in the correct chart with the correct provenance.
A FHIR facade over systems that do not speak it, so your product sees one clean FHIR API instead of six legacy interfaces.
A FHIR server when you need to store and serve health data yourself, with the data management and access control that implies.
Bulk FHIR export for analytics and population work, where per-patient calls will never scale.
FHIR support varies more than the specification suggests. These are the platforms we work with most.
FHIR R4 and US Core, SMART launch, and the Vendor Services review path.
Ignite FHIR APIs, plus the HL7 v2 feeds still running alongside them.
FHIR APIs and the marketplace review process for ambulatory products.
Where a health system already runs it as the integration engine.
Open-source FHIR servers when you host and serve the data yourself.
Managed FHIR stores for analytics-heavy products.
Naming the version and profile early prevents most rework. Here is what we build against.
The production version nearly all US work targets today.
The American profile set that constrains R4 into practical interoperability.
App launch and authorization inside the EHR.
Population-scale export when per-patient calls will not scale.
Triggering guidance at the point of care inside the clinical workflow.
Still required alongside FHIR at almost every health system.
SMART on FHIR is the launch layer. It opens your application inside the EHR with the patient already in context and the clinician already authenticated.
That matters for adoption. An app a clinician must open separately and search by name does not get used during a visit.
We build SMART apps for provider-facing and patient-facing launches, including OAuth scopes, token handling, and the vendor review each platform requires.
Done well, it disappears into the clinical workflow. The clinician sees your feature where the work already happens.
Very few health systems are FHIR-only. Most run FHIR alongside an integration engine that has moved HL7 v2 messages for a decade.
We work both sides of that line. Usually that means mapping v2 segments into FHIR resources, or emitting v2 messages from a FHIR-native product.
Keeping identity consistent across the two is the hard part. The same patient carries different identifiers in each system, and reconciling them is real work.
Getting this right is what makes care coordination possible across systems that were never designed to agree.
Ranges below assume one target system. Multi-EHR work scales sub-linearly once the first integration is built properly.
Query patient data and clinical data from one EHR, including mapping and testing.
Read and write, including write-back provenance and vendor certification.
In-EHR launch with OAuth scopes, context handling, and platform review.
A FHIR API layer over existing systems, or a hosted FHIR server with full access control.
Version upgrades, profile changes, and monitoring as the ecosystem moves.
Every FHIR project follows the same arc. Timelines move with scope and with how fast the vendor reviews.
A straightforward read integration goes live in six to ten weeks. Bidirectional builds and SMART apps run three to six months.
Coverage gaps come first. A vendor may support R4 but not the exact resource you need, or support reads and not writes.
Profile mismatches come second. US Core sets expectations, but implementations vary enough that code written against one EHR needs adjusting for the next.
Performance is third. Per-patient FHIR calls are fine for a chart view and hopeless for population analytics, which is what Bulk FHIR exists for.
Vendor review queues remain the least predictable part of any timeline. We plan around them rather than promise through them.
FHIR endpoints expose health information, so access control carries the weight here.
We implement OAuth 2.0 with scoped tokens, so an application reads what it needs and nothing more. Scopes get reviewed rather than assumed.
Everything is encrypted in transit and at rest, every data access is logged, and a business associate agreement is signed before real patient data moves.
We also keep health data out of logs and error reports. It is the simplest control and the one most often missed.
Health-tech products need FHIR to sell. Buyers ask which EHRs you support before they evaluate a single feature.
Healthcare providers and health systems need it to connect tools they have already bought, and to stop paying for interfaces twice.
A payer needs it for the Patient Access and Provider Directory APIs that CMS now requires.
The common thread is patient care. Data that reaches the right place at the right time changes what a clinician can do in the room.
Teams that implement FHIR well decide three things before anyone writes code.
First, which FHIR data they actually need. Scope creep in the resource list is the quiet killer of integration timelines.
Second, whether data sharing runs one direction or both. Write-back is materially harder than read, and it changes the certification path.
Third, who owns the integration after go-live. Profiles and APIs keep moving, and an unowned interface degrades silently.
We work through those three in discovery, before the estimate, because each one moves the number.
Fast Healthcare Interoperability Resources. It is an HL7 standard for exchanging health data over ordinary web APIs.
Both come from HL7, the standards body, but they are different standards. HL7 v2 is the older message-based format and FHIR is the modern REST API. Most health systems run both.
Yes, in practice. FHIR defines a REST API over standard web services returning JSON. If your team knows web APIs, FHIR APIs will look familiar.
The 21st Century Cures Act requires certified EHRs to expose FHIR APIs, and CMS requires payers to do the same. FHIR is now the default interface to US health information.
A specification for launching an app inside the EHR with the patient in context and the clinician authenticated. It is how a product gets used during a visit instead of in a separate tab.
Yes, and it usually must. We map v2 segments to FHIR resources, or emit v2 from a FHIR-native product, keeping patient identity consistent across both.
A read-only integration runs $20,000 to $45,000. Bidirectional builds are $45,000 to $110,000. A SMART on FHIR app is $35,000 to $95,000, and a facade or FHIR server starts near $70,000.
Six to ten weeks for a straightforward read integration. Three to six months for bidirectional work or a SMART app, with vendor review the least predictable part.
Yes. Payer work is mostly Patient Access, Provider Directory, and prior-authorization APIs under the CMS rules, and it rests on the same FHIR foundations as provider integration.
Both ways. Some clients want us to build and hand over. Others want us to stand up the FHIR data layer and train their team to own it.
Bring us the systems you need to connect and what has to move between them. We'll come back with an interface plan, a timeline, and a fixed range — before anyone signs anything.
Book a scoping call or send us the details. If you also need the practice-side work, our managed IT and HIPAA compliance services cover it.
Managed IT, cybersecurity, HIPAA compliance, and AI automation for healthcare practices. We keep your technology secure so you can focus on patient care.
4MEDNET.COM - Copyright 2026. All rights reserved.