FHIR and EHR integration is where most healthcare AI products succeed or stall. Building a model that summarises a note or suggests a billing code is now the comparatively easy part. Getting that model to read a real patient's record from a hospital's electronic health record, and to put its output back where a clinician will actually see it, is the hard part, and it is the part teams most often underestimate.
The problem is that healthcare data does not flow through one clean API. Some of it moves through modern FHIR endpoints. A great deal still moves as HL7 v2 messages through interface engines built decades ago. Every value needs the right code system, and each EHR vendor runs its own partner and app program that can add weeks or months to a launch. Teams that discover this late end up with a finished product that cannot connect to the system it was built for.
This guide maps that plumbing in plain English. It covers what FHIR is and how its resources work, how SMART on FHIR lets apps launch inside the EHR, why HL7 v2 and interface engines still matter, the terminologies that give clinical data meaning, what vendor programs involve, why deep integration is a competitive moat, and realistic cost and timeline expectations.
The Demo Works. The Integration Is the Product.
It's easy to build a healthcare AI feature that looks finished. Feed it a sample note, watch it produce a tidy summary or a suggested code, and it demos beautifully. But the moment you try to put that feature in front of a real clinician, the same question arrives every time: where does the data come from, and where does the result go back to?
That question is the entire job. An AI feature that can't read a patient's actual record from the hospital's system, and can't write its output back into the workflow the clinician already uses, is a demo — not a product. The intelligence is the easy part. The plumbing that connects it to Epic, Cerner and the rest of the messy, standards-bound world of FHIR, HL7 and clinical data is where healthcare AI projects either become real or quietly stall.
This guide is the plain-English map of that plumbing. What the standards are and why they exist, what integrating with the major electronic health record (EHR) vendors actually involves, and why teams that can do this well hold a competitive advantage that's genuinely hard to copy. It's the engineering layer that sits underneath everything in our healthcare AI development work — the scribe, the coding tools, the prior-auth assistant all depend on getting it right.
FHIR: The Standard That Made Integration Bearable
FHIR — Fast Healthcare Interoperability Resources, pronounced "fire" — is the modern standard for exchanging clinical data, and it's the one to understand first because it's where the industry is heading. The official HL7 FHIR specification is the canonical reference for every resource type mentioned below.
The important thing about FHIR is that it works the way the rest of the software world already works: REST over HTTPS, with data represented as JSON (or XML). If you've ever consumed a web API, FHIR will feel familiar. You make a request to a URL, you get back a structured resource, you can create or update resources with standard HTTP verbs. That's a dramatic simplification compared with what came before, and it's the single biggest reason integration got more approachable over the last decade.
FHIR organises clinical information into resources — discrete, well-defined objects that map to real-world concepts. A Patient resource holds demographics. An Observation holds a lab result or a vital sign. Condition holds a diagnosis, MedicationRequest a prescription, Encounter a visit, DocumentReference a clinical note. Each resource has a defined structure, a stable identifier, and references that link it to others — an Observation points to the Patient it belongs to, and the Encounter it was recorded in.
For an AI system, this is exactly the shape you want. Instead of parsing a wall of free text to work out what medications a patient is on, you request their MedicationRequest resources and get structured, coded data back. Retrieval-augmented workflows that ground a model in the patient's real record — the backbone of trustworthy clinical AI — are built on precisely this kind of clean, addressable data.
The honest caveat: FHIR is a standard, not a guarantee of uniformity. Vendors implement different versions (R4 is the common baseline today), support different subsets of resources, and add their own extensions. "It speaks FHIR" is the start of a compatibility conversation, not the end of one.
SMART on FHIR: Launching Inside the EHR
Reading and writing data is half the story. The other half is where your software actually appears. Clinicians live inside their EHR all day; an AI tool that forces them into a separate browser tab, to log in again and search for the patient they already have open, will lose to friction no matter how good the model is.
SMART on FHIR is the standard that solves this, and its developer documentation is the best starting point for understanding the launch flow. It's a set of specifications — built on OAuth 2.0 for authorisation and FHIR for data — that lets a third-party app launch inside the EHR, in context. When a clinician opens your app from within a patient's chart, SMART passes it the security tokens and the context it needs, so your app knows which patient is loaded and can immediately pull the relevant record. No second login, no re-selecting the patient, no copy-pasting an ID.
That "launched in context with the patient already loaded" experience is what makes an embedded AI tool feel like part of the EHR rather than a bolt-on. It's the difference between a scribe that a clinician reaches for by reflex and one they forget exists. If you're building a workflow that clinicians use dozens of times a day — an AI medical scribe, a coding assistant, a prior-auth helper — SMART on FHIR is usually how it should reach them.
HL7 v2 and the Interface Engine: The World That's Actually Deployed
Here's the reality check. FHIR is the future and increasingly the present, but a very large amount of clinical data still moves the old way: HL7 version 2.
HL7 v2 is a messaging standard that predates modern web APIs by decades. Instead of JSON resources at REST endpoints, it uses pipe-and-hat delimited messages — dense strings of text divided by | and ^ characters — fired between systems as events happen. A patient gets admitted and an ADT (Admission, Discharge, Transfer) message goes out. A lab result comes back and an ORU message is sent. It's not pretty, and it's not self-describing the way FHIR is, but it is everywhere, and it works.
Most hospitals route these messages through an interface engine — software like Mirth Connect, Rhapsody or Cloverleaf that sits in the middle, receiving messages from one system, transforming them, and delivering them to another. For many integration projects, the practical path isn't a clean FHIR API at all; it's getting your system connected to the hospital's interface engine and learning to speak HL7 v2 for the feeds you need.
Any team claiming to do healthcare integration that only knows FHIR is telling you they've worked on greenfield projects, not with established hospitals. The ability to handle both — modern FHIR where it exists, HL7 v2 through an interface engine where it doesn't — is what separates people who've shipped in real clinical environments from people who've built demos.
The Terminologies: Speaking the Language of Clinical Data
Standards move the data; terminologies give it meaning. Clinical information is coded, and an AI system that produces or consumes clinical data has to use the right code systems or its output is unusable downstream. Four matter most.
| Standard | What it codes | Where it shows up |
|---|---|---|
| ICD-10 | Diagnoses and conditions | Billing, claims, the diagnosis on a patient's problem list |
| CPT | Procedures and services performed | Billing and reimbursement for what was actually done |
| SNOMED CT | Clinical terms and findings | Structured clinical documentation inside the EHR |
| LOINC | Lab tests and observations | Lab orders and results, so a "glucose" test means the same thing everywhere |
| DICOM | Medical imaging | X-rays, CT, MRI — the images and their metadata |
The distinctions matter in practice. ICD-10 and CPT are the language of billing — get them wrong and claims get denied, which is exactly the problem AI revenue cycle management exists to catch before submission. SNOMED CT is far richer and used for clinical meaning inside the record. LOINC makes lab data comparable across systems that might otherwise each call the same test something different. DICOM is its own world entirely — the standard for medical images and the metadata wrapped around them, relevant the moment your AI touches radiology.
A scribe that suggests a diagnosis needs to map it to a valid ICD-10 code. A coding tool has to reconcile CPT and ICD-10 correctly. None of this is optional polish; it's the difference between output a system can accept and output a human has to re-key by hand.
EHR Vendor Programs: The Timeline Cost Nobody Budgets For
Technically integrating with an EHR is one thing. Being allowed to is another — and it's where timelines quietly stretch.
The major EHR vendors run partner and app programs that govern how third-party software connects to their systems, particularly for anything installed at a customer site or listed in their app marketplace. Epic and Oracle Health (Cerner) both operate developer and partner programs of this kind; Athenahealth and others have their own API and marketplace arrangements. The specifics differ by vendor and change over time, so the honest advice is to treat the details as something to confirm directly with each vendor rather than assume.
What's consistent is the shape of the cost. Getting listed or approved typically involves registration, technical review, security and privacy attestations, and testing against the vendor's requirements — a process measured in weeks or months, not days. For patient-facing or lightweight read-only apps using standardised FHIR endpoints, the path is generally lighter. For deep, write-back, installed-at-the-hospital integrations, it's heavier and more involved.
The practical implication for planning: the integration certification is a real line item in your timeline, separate from the engineering. Teams that discover this late end up with a finished product that can't legally connect to the system it was built for. Prove the integration path — including the vendor program requirements — before you build everything on top of it. This is the same discipline that governs any AI agent handling sensitive systems and data; in healthcare, it simply has a vendor gate in front of it as well.
Benefits of FHIR and EHR Integration
AI grounded in the real patient record
An integrated system reads medications, diagnoses, labs, and notes directly from the EHR as structured resources instead of relying on whatever a user pastes in. That grounding is what makes clinical AI trustworthy: summaries reflect the actual chart, suggestions are based on current data, and the model is far less likely to fill gaps with plausible guesses. Without it, even an excellent model is working from an incomplete and possibly outdated picture.
Output that lands where clinicians already work
Write-back means a drafted note, a suggested code, or a flagged result appears inside the EHR workflow rather than in a separate tool. Clinicians do not have to copy, paste, or reconcile anything by hand. That removes the friction that usually kills adoption, and it reduces the transcription errors that creep in whenever people move data between systems manually.
Faster, lower-friction access through in-context launch
With SMART on FHIR, an app opens from the patient's chart already knowing who the patient is and holding the tokens it needs. There is no second login and no searching for the patient again. For tools used dozens of times a day, those saved seconds add up, and the experience feels like part of the EHR instead of a bolt-on. In-context launch also reduces the risk of a clinician acting on the wrong patient's information, because the app inherits the chart that is already open.
Clean, coded data downstream systems accept
Mapping output to ICD-10, CPT, SNOMED CT, and LOINC means billing systems, registries, and analytics tools can ingest it automatically. Correct codes prevent denied claims and avoid the cost of staff re-keying information. Coded data also makes results comparable across sites, which matters for any product that will run in more than one hospital.
A defensible position in the market
Integration work is slow, specialised, and specific to each vendor and site. Teams that build it well accumulate knowledge of quirks, interface engine patterns, and approval processes that competitors cannot copy by switching to a better model. Buyers often care more about whether a product will connect reliably than about marginal model quality, so integration depth becomes a reason to choose one product over another.
FHIR and EHR Integration Use Cases
Ambient documentation and medical scribes
Clinicians spend large parts of their day writing notes. A scribe captures the visit, drafts a structured note, and uses integration to pull context such as active problems and medications from the record. The draft is then written back for the clinician to review and sign. Without the read and write paths, the scribe produces text the clinician has to move into the chart manually, which erodes most of the time it was meant to save.
Coding and revenue cycle support
Coding errors lead to denied claims and rework. Tools that read encounter documentation and suggest ICD-10 and CPT codes depend on structured access to the visit record and on correct terminology mapping. Integrated suggestions can be reviewed inside the existing billing workflow, catching mismatches before claims are submitted rather than after they come back denied.
Prior authorisation assistance
Assembling the evidence for a prior authorisation request means hunting through diagnoses, prior treatments, and lab results. An integrated assistant pulls the relevant Condition, MedicationRequest, and Observation resources and drafts the supporting summary. Staff spend their time checking and submitting instead of searching, and requests go out with more complete documentation. Because the evidence comes straight from coded resources, it is easier to show reviewers exactly where each supporting fact was recorded in the chart.
Lab and results monitoring
Many result feeds still arrive as HL7 v2 ORU messages through an interface engine. A monitoring tool subscribed to those feeds can flag abnormal values, track trends against LOINC-coded history, and route alerts to the right care team. The integration path here is often the interface engine rather than a FHIR API, which is why teams need both skills.
Patient-facing apps and remote monitoring
Patient apps and remote monitoring platforms need demographics, appointments, and care plans, and they often need to send readings back to the care team. Standardised FHIR endpoints typically make lightweight, read-oriented patient apps the lighter integration path, while writing device readings back into the record requires deeper integration and vendor review. Planning which side of that line a product sits on shapes the whole timeline.
Why Deep Integration Is a Moat
Step back and the strategic point becomes clear. The AI is increasingly a commodity — the same foundation models are available to everyone. What isn't commoditised is the ability to make that AI work inside a specific hospital's Epic instance, pulling clean data through FHIR, falling back to HL7 v2 through the interface engine where needed, mapping to the right terminologies, and clearing the vendor's certification.
That work is hard, slow, and unglamorous, which is exactly why it's defensible. A competitor with a slightly better model but no integration story can't displace you, because the buyer's real fear isn't model quality — it's whether the thing will actually connect to their systems without breaking. A team known for clean, deep EHR integration wins enterprise deals on that reputation alone.
It's also compounding. The first integration is the hardest; the second EHR of the same vendor is easier, and the institutional knowledge of what each vendor's quirks are becomes an asset no demo can replicate. This is the moat that turns healthcare AI from a services business into a durable product one.
FHIR and EHR Integration Best Practices
A well-integrated healthcare AI system has these properties:
- It reads from the source of truth. The AI grounds its work in the patient's actual record via FHIR (or HL7 v2 where that's what's available), not a copy that drifts out of date. Cache only what you must, and know when cached data was last refreshed.
- It writes back into the workflow. Output lands where the clinician already works — drafted into the note, queued in the EHR — rather than in a separate tool they have to reconcile by hand. Write-back should always leave a clinician in control of what is signed.
- It launches in context. Where clinicians use it repeatedly, it's embedded via SMART on FHIR, with the patient already loaded and no second login.
- It uses the right codes. Diagnoses in ICD-10, procedures in CPT, clinical terms in SNOMED CT, labs in LOINC — mapped correctly so downstream systems accept the output. Test mappings against real examples, not just the happy path.
- It handles the messy middle. The team can work with an interface engine and HL7 v2, not just clean FHIR endpoints, and plans for the sites where modern APIs are not available.
- It checks each site's actual capabilities. FHIR version, supported resources, and vendor extensions are confirmed per deployment before features depend on them, since "it speaks FHIR" is only the start of the compatibility conversation.
- It requests only the data it needs. Scopes and feeds are limited to the resources the feature uses, which simplifies privacy review and reduces what is exposed if something goes wrong.
- The certification path is proven. The vendor program requirements are understood and planned for, not discovered after launch. Confirm current requirements directly with each vendor and put the review period on the project plan as its own line item.
Common FHIR and EHR Integration Mistakes
Building the AI before proving the data path
Teams often perfect the model on sample data and only then ask how it will reach real records. When the target system exposes the data differently, or not at all, much of the work has to be redone. Prove read access to the exact resources you need, against the systems your first customers use, before building features on top.
Assuming FHIR means uniformity
Vendors implement different versions, support different subsets of resources, and add their own extensions. A product tested against one sandbox can break on the next site. Treat each new EHR, and sometimes each new hospital, as a compatibility exercise with its own testing rather than a configuration change.
Ignoring HL7 v2 and interface engines
Teams that only know modern APIs discover that many established hospitals still deliver key data as HL7 v2 messages through an interface engine. Without a plan for that path, a product can only serve greenfield sites. Budget engineering time and expertise for message parsing, transformation, and working with each hospital's interface team.
Leaving vendor programs until the end
Partner and app program reviews, security attestations, and testing take weeks or months and run on the vendor's schedule. Discovering them after the product is built leaves a finished system that cannot connect. Start the conversation with each vendor early, and confirm current requirements directly rather than relying on old assumptions.
Treating terminology mapping as polish
Output with missing or incorrect codes is rejected by billing systems or has to be re-keyed by staff. Mapping to ICD-10, CPT, SNOMED CT, and LOINC is part of the core integration work, and it needs clinical or coding review, not just a lookup table assembled at the last minute. Code sets are updated periodically, so the mapping also needs an owner and a refresh schedule.
Questions to Ask
Before you commit to a build, ask your team directly:
"Which EHRs will this integrate with, and via FHIR or HL7 v2?" You want a specific answer per system, not "it supports standard healthcare formats."
"Have you gone through the vendor's partner or app program before?" Experience with the certification process is worth as much as the engineering skill.
"How does the AI's output get written back into the clinician's workflow?" If the answer is "the user copies it over," that's a friction problem that will sink adoption.
"How do you map to ICD-10, CPT and the other terminologies?" Vague answers here mean output that humans have to re-key.
"What's the plan for the messy hospitals that aren't on modern FHIR?" The interface-engine fallback is where real deployments live.
What It Costs and How Long It Takes
Integration is usually the single most time-consuming and least predictable part of a healthcare AI build, precisely because so much of it depends on the target system and the vendor's process. A clean, standards-based FHIR read against a modern endpoint can be quick. A deep, write-back integration with an established hospital — HL7 v2 feeds through an interface engine, terminology mapping, and vendor certification — is a multi-month effort before the AI on top of it even ships.
The honest caveat is that the certification timeline is largely outside your control. Vendor review queues and requirements move at their own pace, and no amount of engineering speed compresses them. Budget for that as a real dependency, and prove the integration path early — it's the riskiest assumption in the whole project, and the one worth de-risking first. That floor is also the barrier that keeps the work valuable: a team that can clear it commands better contracts because the buyer knows how much they've just been saved from.
Related guides
- What healthcare AI development actually involves
- AI medical scribe: speech to SOAP notes to EHR
- AI revenue cycle management
- AI agents for healthcare: reducing admin burden
- Our healthcare AI development services
We Build Integrations That Actually Connect
The hard, defensible part of healthcare AI isn't the model — it's making it read and write clinical data correctly inside the systems your clinicians already use. We build integrations that ground the AI in the real record via FHIR, handle HL7 v2 through the interface engine where that's the reality, map cleanly to ICD-10, CPT, SNOMED CT and LOINC, and plan the vendor certification path as a real part of the timeline rather than a surprise at the end.
Whether you're integrating a single workflow with one EHR or building toward a product that connects to many, we're happy to scope the integration honestly — including where the simpler path gets you most of the value.
Integration work like this underpins every build in our healthcare AI development practice — the scribe, the chatbot, the RPM platform, all of it.
Talk to us about your platform — no commitment, just a conversation.
Frequently Asked Questions
What is the difference between FHIR and HL7 v2?
Both are standards from the HL7 organisation for exchanging healthcare data, but they work very differently. HL7 v2 is an older messaging standard that sends dense, delimited text messages between systems as events happen — still enormously common in deployed hospital environments. FHIR is the modern approach: a REST-and-JSON API that represents clinical data as structured, addressable resources, working much like any web API a developer would recognise. FHIR is where the industry is heading, but HL7 v2 is where a great deal of clinical data still lives, so real integration work usually involves both.
What is SMART on FHIR and why does it matter for AI tools?
SMART on FHIR is a set of specifications, built on OAuth 2.0 and FHIR, that lets a third-party application launch inside an EHR in context. When a clinician opens your app from within a patient's chart, it receives the security tokens and knows which patient is loaded — no second login and no re-selecting the patient. For an AI tool used many times a day, this in-context launch is the difference between something clinicians reach for by reflex and something they forget exists. It removes the friction that otherwise kills adoption.
Do I have to go through Epic's or Cerner's certification to integrate?
For most meaningful integrations, yes — the major EHR vendors run partner and app programs that govern how third-party software connects, especially for anything installed at a customer site or listed in a marketplace. Epic and Oracle Health (Cerner) both operate programs of this kind, and the requirements and timelines differ by vendor and change over time, so confirm the specifics with each vendor directly. Lightweight, read-only apps using standardised FHIR endpoints generally face a lighter path than deep, write-back, installed integrations. Either way, treat the certification as a real line item in your timeline, not an afterthought.
Why can't we just use a foundation model and skip all this integration work?
Because the model is only useful if it can read the patient's real data and write its output somewhere the clinician will actually see it. A model that produces a beautiful summary from a pasted sample is a demo; a system that pulls the live record, grounds its work in it, and writes back into the EHR workflow is a product. The integration is what makes the AI clinically usable — and, not coincidentally, it's the part competitors find hardest to replicate, which is why it's worth doing properly.
What are ICD-10, CPT, SNOMED CT and LOINC, and why do they matter?
They're the coding systems that give clinical data meaning. ICD-10 codes diagnoses, CPT codes procedures and services, SNOMED CT covers clinical terms and findings, and LOINC standardises lab tests and results. An AI system that produces or consumes clinical data has to use the correct code system, or its output can't be accepted downstream — a suggested diagnosis needs a valid ICD-10 code, a billing tool needs correct CPT and ICD-10 pairings. Getting the terminology mapping right is the difference between output a system ingests automatically and output a human has to re-key by hand.
What is an interface engine and do we need one?
An interface engine is middleware — Mirth Connect, Rhapsody and Cloverleaf are common examples — that sits between hospital systems, receiving messages, transforming them, and routing them to their destination. Because so much clinical data still moves as HL7 v2 messages rather than through FHIR APIs, connecting to a hospital's interface engine is often the practical path to the data feeds you need. You may not run your own, but you'll almost certainly need to work with the hospital's, which is why the ability to handle HL7 v2 through an interface engine — not just clean FHIR — is a mark of a team that has shipped in real clinical environments.
How should a healthcare startup get started with EHR integration?
Start by naming the specific EHRs your first customers use and confirming, per system, whether you will connect through FHIR APIs or HL7 v2 feeds through an interface engine. Build a read-only FHIR prototype against a vendor sandbox to prove the data you need is actually available, then investigate the vendor's partner or app program requirements before building write-back features. Treat the integration path as the riskiest assumption in the project and de-risk it first, because model quality cannot rescue a product that cannot connect.
Conclusion
Healthcare AI does not fail because the model is weak. It fails because the product cannot reliably read the patient's real record or write its output back into the clinician's workflow. FHIR has made that work far more approachable, with REST endpoints and structured resources, but it sits alongside a large installed base of HL7 v2 messaging, interface engines, terminology mapping, and vendor approval programs.
The practical lessons: treat "it speaks FHIR" as the start of a compatibility conversation, since versions, resource coverage, and extensions vary. Plan for HL7 v2 through an interface engine where modern APIs are not available. Map diagnoses, procedures, and labs to the correct code systems so downstream systems accept the output. Use SMART on FHIR for tools clinicians open many times a day.
The biggest caveat is time. Vendor program review is largely outside your control and varies by vendor, so confirm current requirements directly with each one and build that into the plan from day one. Prove the integration path before building features on top of it.
If you are planning a product that needs to connect to EHRs, our FHIR and EHR integration services page explains how we scope this work honestly, including where a simpler path gets most of the value.