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 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. 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.
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.
What Good Looks Like
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.
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.
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.
It handles the messy middle. The team can work with an interface engine and HL7 v2, not just clean FHIR endpoints.
The certification path is proven. The vendor program requirements are understood and planned for, not discovered after launch.
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
- Healthcare AI development: the full map
- AI medical scribe: speech to SOAP notes to EHR
- HIPAA-compliant AI architecture
- AI revenue cycle management
- AI agents for healthcare: reducing admin burden
- Our 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.
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.