HIPAA makes you legal. FDA clearance makes you sellable to clinicians. Neither gets you into a hospital. This guide covers the integration standards, vendor marketplaces, and procurement realities that decide whether a healthcare AI product ships into real clinical environments — or sits on a shelf with a great demo.
Most healthcare AI startups treat the path to a hospital deployment as a two-stage gate: get HIPAA right, get FDA clearance if you need it, then go sell. That model is missing a step that, in our experience, kills more healthcare AI products than either compliance pillar. That step is EHR integration — the technical and commercial work of getting your software to read from and write into the electronic health record system that the clinician already lives inside.
A clinician who has to leave Epic, log into your portal, copy a patient identifier across, run your model, then transcribe a result back into the chart is a clinician who will not use your product after the pilot ends. A hospital IT department that cannot answer "what data does this tool see, where does the output land, and what is its audit trail" will not sign your contract regardless of how good the underlying model is. And a procurement committee that asks "are you in the Epic Showroom or do you integrate via Redox?" expects a real answer — not a roadmap slide.
This guide is written for healthcare AI founders, CTOs, and engineering leads who have understood that EHR integration is the gap between a demo and a deployment, and who need a practical map of the standards, the vendors, the marketplaces, and the procurement choreography that decide whether your product ships into clinical use.
Hospitals do not buy point tools. They buy things that fit into the system their clinicians are already using thirty hours a week. A surgical scheduling AI that lives at a separate URL is a worse product than a slightly less capable model that surfaces inside the EHR's existing scheduling view. A radiology triage model that writes its prediction into the worklist is deployable; one that emails a PDF report is a research project.
This is not a preference. It is an operational reality driven by three constraints.
The marginal cost of switching contexts during a clinical encounter is enormous. Studies of EHR-driven physician burnout consistently identify each additional system, login, and copy-paste step as a measurable contributor to dissatisfaction and error. An AI tool that adds steps will be silently dropped after the pilot regardless of its accuracy on benchmark data. Integration is what removes those steps.
Any output that informs a clinical decision must be traceable: which patient, which encounter, which inputs, which model version, at what time. Hospitals expect that trail to exist inside the EHR's audit log, not in a vendor system that the compliance officer cannot access without a separate request. If your inference cannot be re-constructed from EHR audit data alone, your procurement review will stall.
Increasingly, AI outputs that influence billable activity — diagnostic image interpretation, risk stratification, clinical documentation — must be discoverable in the chart for coding, billing, and downstream payer audit. Outputs that exist only in a vendor portal cannot anchor a CPT code or support a denial appeal. Integration into the chart is what makes the output billable.
The US acute care EHR market is concentrated. According to KLAS Research's annual market share reports, the picture by hospital beds is roughly as follows, and has been directionally stable for several years.
Epic dominates large health systems and academic medical centres. By hospital beds, it has been near 40 per cent and growing. Epic's developer programme — previously called App Orchard, rebranded to Showroom and Vendor Services — is the canonical path for third-party software to integrate with Epic deployments. Membership tiers determine API access, support, and what your customers see when they look for you in Epic's directory. Application fees, annual fees, and revenue share apply.
Epic's FHIR endpoints expose much of USCDI v3 and a growing set of write APIs. Some functionality — particularly anything that writes to flowsheets, orders, or notes in a way that bypasses standard FHIR resources — requires participation in Vendor Services and, in some cases, a direct working relationship with Epic's interoperability team.
Oracle Health, formed after Oracle's 2022 acquisition of Cerner, holds the next-largest share of the acute care market. Its developer programme — Oracle Health Marketplace — provides access to FHIR APIs, SMART on FHIR app hosting, and CDS Hooks support. Cerner has been an early and significant contributor to the FHIR standard, and its API coverage in some areas is broader than Epic's, though commercial dynamics post-acquisition continue to shift.
Meditech serves a significant share of community hospitals. Its Expanse platform supports FHIR and SMART on FHIR, and Meditech maintains a partner programme for third-party integration. Coverage of advanced FHIR resources lags Epic and Oracle Health, but the population of Meditech sites is large enough that for many segments — rural and community hospitals especially — Meditech support is not optional.
The ambulatory and small-practice market is more fragmented. Athenahealth's Marketplace programme is well-developed and approachable; eClinicalWorks, NextGen, and Veradigm (the rebrand of Allscripts) each maintain partner programmes of varying maturity. For ambulatory AI products, these vendors are often more strategically important than Epic.
The choice of which two or three EHRs to support first is a commercial decision that drives every subsequent technical decision: which FHIR resources you must implement, which authentication flows you must support, whether you need an HL7 v2 interface engine in your stack, what your sandbox testing looks like, and what your enterprise sales cycle will demand of you. Founders who choose their target EHRs after building their architecture rebuild their architecture.
Healthcare interoperability is not a single standard. It is a stack of overlapping standards with different histories, different roles, and different levels of vendor support. A working integration almost always uses several of them.
HL7 v2 is a pipe-delimited messaging standard that has been the workhorse of US hospital integration since the early 1990s. Despite its age, it remains the most common interface format inside hospitals — admit-discharge-transfer (ADT) feeds, lab results (ORU), orders (ORM), pharmacy, billing, and many other workflows still run over HL7 v2 messages routed through interface engines like Mirth Connect, Rhapsody, Cloverleaf, or Corepoint.
If your product needs near-real-time event streams — for example, you want to know when a patient is admitted, or when a lab result is finalised — HL7 v2 via an interface engine is often the only viable path. FHIR Subscriptions are improving this, but production deployments of FHIR-based event streams remain the exception, not the norm.
FHIR (Fast Healthcare Interoperability Resources) R4 is the HL7 standard that the modern EHR API ecosystem is built on. It defines resources — Patient, Encounter, Observation, Condition, MedicationRequest, DocumentReference, and so on — exposed via REST APIs with JSON or XML payloads. FHIR R4 is the version that the ONC has anchored its certification requirements on. R5 exists, but R4 is what every production EHR API supports and what every integration in 2026 is being built against.
FHIR is approachable for engineering teams used to modern web APIs. It is also deceptively complex once you move beyond the simplest reads: profiles, extensions, contained resources, versioning, conditional updates, and search parameter quirks vary by implementer. The standard is generous; the implementations are opinionated.
The United States Core Data for Interoperability (USCDI) is the minimum data set that ONC-certified EHRs must make available via FHIR. USCDI v3 and v4 expand coverage to include data classes such as social determinants of health, advance directives, and a growing set of clinical concepts. If your product only needs data that is in USCDI, you can plan around what every certified EHR must expose. If you need anything outside USCDI — historical free-text notes, imaging metadata, certain flowsheet variables — you are negotiating per-vendor.
Consolidated Clinical Document Architecture (C-CDA) is the XML-based document format used for clinical summary exchange — continuity of care documents, discharge summaries, referral notes. C-CDA matters less for greenfield API integration but remains central to document exchange via Carequality, CommonWell, and TEFCA's QHIN network. If your product consumes or produces summary documents, C-CDA is unavoidable.
SMART on FHIR is the framework that lets a third-party application launch from inside the EHR with the appropriate patient and encounter context already established, using OAuth 2.0 for authorisation. A clinician opens a chart, clicks your app from a panel inside the EHR, and your application loads inside an iframe or new tab with a FHIR token scoped to that patient. This is the canonical pattern for embedding a clinician-facing AI tool into existing chart workflows without writing custom integration code per hospital.
SMART on FHIR also defines the backend services flow that lets server-to-server applications obtain bulk or population data without a clinician in the loop — relevant for population health, analytics, and training data pipelines.
CDS Hooks is a complementary specification for clinical decision support that fires at well-defined moments in the EHR — when a clinician opens a chart, signs an order, begins a medication review. The EHR calls your endpoint, you return cards (suggestions, alerts, app launch links), and the EHR renders them inline. For AI products whose value is delivered as a recommendation at a decision point, CDS Hooks is often the right surface.
The FHIR Bulk Data Access specification (often called $export) defines how to request and receive large-scale extracts of resources for entire patient populations or groups, returned as NDJSON files. This is the primary path for population health AI, model training on retrospective data, and analytics workloads. The ONC's HTI-1 rule requires certified EHRs to support bulk FHIR for population access, which has been the single biggest unlock for AI startups doing retrospective work since 2024.
If your AI product touches medical imaging, the standards stack expands to include DICOM for the image objects and metadata, and IHE profiles (XDS-I, IOCM, AIR) for cross-enterprise image exchange. Integration with PACS and radiology information systems is its own subdomain with its own vendors (Sectra, GE, Philips, Fujifilm) and is rarely covered by general EHR integration efforts.
The integration pattern is determined by the clinical workflow, not the other way around. Pick the pattern that matches what the clinician needs to see and do, then implement it against the standards above.
Use when: Your product is a tool a clinician opens during patient care — a risk score, a documentation assistant, a decision support tool, a specialist consultation interface. The clinician launches your app from inside the chart; you get patient context and a scoped FHIR token; you render an interface; you optionally write structured data back via FHIR.
This is the most common pattern for clinician-facing AI in 2026 and the one with the broadest cross-vendor support.
Use when: Your value is a contextual recommendation surfaced at a specific clinical action — opening a chart for a patient with a particular condition, signing an order for a medication with a known interaction, beginning a discharge process. You expose an endpoint; the EHR calls you at the configured hook; you return cards.
CDS Hooks is lower-latency and lower-friction for the clinician than launching a separate app, but the interaction surface is narrower. Adoption is broad on Epic and Oracle Health, more limited elsewhere.
Use when: You need a real-time stream of clinical events — every admission, every lab result, every medication order — for population monitoring, alerting, or asynchronous AI inference. You stand up a listener; the hospital's interface engine sends you HL7 v2 messages over MLLP or HTTPS; you parse and act.
This pattern is essential for population health, real-time risk monitoring, and any workflow where you need to act on events the clinician has not yet looked at. Implementation cost is higher because every hospital's HL7 feed is configured slightly differently — message types, segments populated, identifiers used, vocabulary localisations.
Use when: You are training a model, building cohort analytics, or running batch inference on a population. Bulk FHIR $export is the modern path. Some health systems still expose research data via a Clarity (Epic) or HealtheIntent (Oracle Health) data warehouse mirror — typically governed by a research data use agreement, not a commercial contract.
Use when: Your output needs to land in the chart as a structured artifact — a DocumentReference, an Observation, a flowsheet row, a draft order, a problem list entry. Standard FHIR write resources cover much of the surface; some destinations (Epic flowsheets, certain order types, draft notes) require vendor-specific APIs available only to programme members.
Use when: Your application is patient-facing or operates outside the clinician workflow — a patient portal companion, a care navigation app, an administrative tool. You read patient-authorised FHIR data using the SMART on FHIR patient launch flow and never write back. This is the pattern most third-party patient apps use under the ONC's patient access requirements.
Several federal rules have meaningfully shifted the integration landscape in the last few years. They are worth understanding because they are now the strongest commercial lever a small vendor has against a reluctant IT department.
The ONC's Information Blocking Rule, finalised under the 21st Century Cures Act, prohibits actors — including EHR vendors and healthcare providers — from engaging in practices that interfere with the access, exchange, or use of electronic health information. Refusing or unreasonably delaying API access to data a patient or their authorised app has requested is presumptively information blocking, with disincentives (and, for vendors, civil monetary penalties) attached.
For startups, this rule is the reason a hospital cannot simply say "no" when a patient or partner requests data through your application using a certified API. It does not eliminate friction, but it puts the friction on a clock.
The HTI-1 final rule, effective in stages from 2024, updates ONC certification criteria around USCDI v3, decision support intervention transparency, and bulk FHIR support. Certified EHRs are required to expose USCDI v3 via FHIR R4 and to support bulk export. The practical effect: the data your application needs is, by regulation, available at every certified site.
TEFCA (the Trusted Exchange Framework and Common Agreement) establishes a national framework for exchanging health data through a network of Qualified Health Information Networks (QHINs). For startups, TEFCA is interesting primarily as a route to cross-organisational data — connecting to patients' records at sites you are not directly integrated with. Direct QHIN participation is heavyweight for most startups; aggregators that participate in TEFCA on your behalf are a more practical entry point.
These rules together mean that, in 2026, a new healthcare AI vendor with the right credentials and the right architecture has a legally backed path to the data it needs at any certified hospital. This is a very different environment from a decade ago, when integration was almost entirely a matter of bilateral negotiation.
For most startups, building direct integrations against three to five EHR vendors is a 12 to 24 month engineering investment that does not differentiate the product. Integration aggregators offer a unified API that fans out to the underlying EHRs and networks.
Redox normalises HL7 v2, FHIR, and proprietary APIs across many EHRs into a single JSON API. It is a mature product with broad hospital connectivity. The tradeoff is contract structure (per-customer connection model), data fidelity (the abstraction can lose vendor-specific nuance), and latency (an extra hop in event-driven workflows).
Particle Health focuses on patient-centric record retrieval across networks like Carequality and CommonWell. Strong fit for products that need historical records on a patient, less so for embedded clinical workflows inside a specific EHR.
Health Gorilla operates a designated QHIN under TEFCA and provides APIs for clinical data access across networks. Useful for products that need national-scale data retrieval without bilateral integration work.
Metriport is an open-source-leaning option focused on medical record retrieval and FHIR conversion. Attractive for early-stage startups due to pricing and transparency; less suitable for write-heavy or real-time use cases.
1upHealth provides a FHIR platform with bulk FHIR ingestion, patient access APIs, and a strong analytics orientation. Particularly relevant for products doing population analytics or model training on aggregated data.
The decision is rarely binary. A pragmatic split is to build directly against your most strategic EHR — usually Epic, given its market share and the differentiation available from deeper integration — and use an aggregator for the long tail. For a research or population-health product, an aggregator-first stack is often correct from day one. For a clinician-facing decision support tool whose value depends on tight, low-latency embedding in the chart, direct integration on at least the primary target is usually unavoidable.
The integration patterns above apply to any healthcare software. AI products carry a handful of additional concerns that frequently surface only during procurement review or — worse — after deployment.
If your product sends EHR-derived data to a large language model, that prompt contains Protected Health Information. Every assumption about HIPAA, BAAs, and vendor coverage that applies to your application database applies equally to your LLM provider, your prompt logging system, your observability stack, and any caching layer that retains prompt content. We covered the underlying compliance picture in our guide to HIPAA-compliant AI development; the integration-specific point is that the FHIR data you successfully fetched does not become non-PHI when you serialise it into a prompt.
For any AI output that informs clinical action, you should be able to reconstruct, after the fact, exactly which FHIR resources were read, at what version, from which endpoint, and what model version produced the output. This means storing references — not just values — and capturing the FHIR resource versionId and lastUpdated at the time of inference. Hospitals reviewing an adverse outcome will ask for this trail. Plan for it from the first integration sprint.
Writing AI output into the chart changes its legal status. A draft note written into the EHR becomes part of the medical record once a clinician signs it; until then, its discoverability and audit treatment depend on vendor configuration. Writing structured Observations creates downstream consumers (other clinicians, reporting systems, payers) who will treat your output as a clinical fact unless it is clearly tagged. Use the FHIR derivedFrom, method, and provenance resources to make clear that the data is AI-generated and unsigned.
If your AI output drives clinical action — diagnosis, treatment selection, risk stratification used in care decisions — the integration design and the FDA pathway intersect. Whether your output is a recommendation requiring clinician sign-off or a determination acted on automatically affects both the regulatory classification and the integration surface. Our guide to building 510(k)-ready software covers the regulatory side; the integration consequence is that anything written automatically into the chart will be examined by the FDA reviewer as part of your indications for use.
Health systems increasingly ask, during procurement, for subgroup performance data — accuracy and calibration across age, sex, race, language, and payer. ONC's HTI-1 rule formalises a related transparency requirement for Predictive Decision Support Interventions ("DSI source attributes"). Your integration scope should include emitting and exposing the metadata the rule requires. If you cannot produce this evidence on demand, expect the procurement cycle to extend.
SMART on FHIR launches and CDS Hooks calls have implicit user-facing latency budgets. An app launch that takes more than a few seconds to render its first useful state will be perceived as broken. A CDS Hooks endpoint that takes longer than the EHR's timeout (commonly 2 to 5 seconds) will be marked unavailable. For LLM-backed features, this often forces a hybrid architecture: a small, fast model for the synchronous response, with the heavier model running asynchronously and updating the chart later through a separate write.
Specific numbers vary by product surface, target EHRs, and team experience, but the shape of the work is consistent. The figures below describe what we have typically seen for a clinician-facing AI product integrating with Epic as primary and one or two additional EHRs.
Team comes up to speed on FHIR R4, SMART on FHIR, and the relevant EHR developer documentation. Sandbox accounts are obtained — Epic's developer sandbox, Oracle Health's code console, SMART Health IT's reference servers. A first read-only SMART launch works end-to-end against a test patient. Internal architecture decisions land: where the FHIR client lives, how tokens are cached, how multi-tenant configuration is stored.
Engagement with a design partner hospital. Their IT team registers your app, scopes are negotiated, security review begins (HITRUST, SOC 2 Type II, and security questionnaires are typically required). First read-and-display flow works against their production endpoint with a test patient. Bidirectional flow — your write-back — is the harder half and often slips here.
Vendor programme applications submitted (Epic Showroom or Vendor Services, Oracle Health Marketplace, Athenahealth Marketplace). Fees paid; technical reviews completed. Listing goes live. Second and third design partner hospitals onboard in parallel, exposing per-site configuration variability. HL7 v2 inbound feed work begins for products that need real-time events.
Second EHR brought online (Oracle Health or Meditech, typically). Aggregator partnership evaluated for long-tail vendors. Production operations mature: monitoring per-endpoint health, handling token refresh failures, alerting on FHIR API regressions, capturing audit data correctly.
Beyond the engineering build, the meaningful line items are vendor programme fees (Epic Vendor Services membership and per-app fees, Oracle Health Marketplace fees, and similar elsewhere), security certifications (HITRUST and SOC 2 Type II together often run into the low-to-mid six figures for a startup), aggregator subscription costs if used, and the ongoing cost of customer-specific integration work that does not generalise — a line item most early-stage budgets underestimate.
Architecture choices made in ignorance of the target EHRs are almost always wrong. The shape of your data model, the format of your write-backs, and the way you handle multi-tenant configuration all depend on what the target EHR exposes and how. Pick your first two EHRs in the first sprint.
Aggregators reduce per-vendor implementation work but do not eliminate the per-customer onboarding work. Every hospital still has to authorise your app, configure their feed, sign a BAA, and pass a security review. The aggregator collapses the API surface; it does not collapse the procurement process.
Two hospitals on the same EHR version will expose different code sets, different available extensions, different documented and undocumented quirks. Production EHR integration is never a single implementation that ships unchanged. Expect a configuration layer per site and budget accordingly.
This appears in every healthcare AI integration review and remains the most common compliance failure we see. The FHIR data you successfully retrieved through a properly scoped SMART token is still PHI. Any LLM provider that processes that data needs a BAA, and the specific service tier you are using needs to be covered under that BAA. Consumer endpoints — ChatGPT.com, the Claude consumer app — are never covered.
If you cannot produce, on demand, a complete record of which inputs produced a given output and which model version was used, you cannot pass a hospital's security review and you cannot defend a clinical outcome review. This must be designed in from the first integration, not added later.
Epic Vendor Services is most useful when you have a customer who wants to deploy you. Joining cold, before a hospital is ready to onboard you, burns money and time. The pattern that works: secure a committed design partner first, then enter the vendor programme with their support and a concrete deployment plan.
We build production AI software for regulated industries, and EHR integration is one of the engineering disciplines we run for healthcare clients alongside the FDA, HIPAA, and clinical workflow work. For founders early in this journey, the most useful starting points are usually a target-EHR strategy session, an architecture review focused on integration surface, and an evidence-readiness review covering provenance, audit, and the documentation a hospital security team will request. Our work spans healthcare software development, HIPAA-aligned engineering, and AI development, and our team has shipped against Epic, Oracle Health, Athenahealth, and aggregator stacks in production.
If you want to talk through where you are and what the next milestone should look like, get in touch.
For read-only access using standard SMART on FHIR patient and clinician launches against USCDI data, the certified public FHIR endpoints are sufficient and no programme membership is required. For deeper integration — additional FHIR resources beyond USCDI, write-back into flowsheets or notes, or visibility in Epic's directory to support customer discovery — programme membership is effectively required. Most clinician-facing AI products end up needing it within a year of launch.
For greenfield clinician-facing apps using SMART on FHIR launches and CDS Hooks, you can often avoid HL7 v2 in the short term. The moment you need a real-time event stream — admissions, lab results, medication orders — HL7 v2 via the hospital's interface engine is still typically the production path. Plan to learn it before your first event-driven feature.
Only if the scope of your authorisation and your BAA with the covered entity explicitly permits secondary use. Many SMART launches authorise data for treatment purposes only; training is a separate use that often requires a different agreement, frequently with de-identification or limited data set terms. Population data accessed via Bulk FHIR under a research or analytics agreement is the more typical training-data path.
If your AI output drives clinical decisions, FDA classification is determined by your indications for use and the level of clinician oversight in the workflow. The integration design — particularly whether output is presented for clinician review or written automatically into the record — directly shapes that classification. Our 510(k)-readiness guide covers the regulatory side in detail.
Partially. FHIR is genuinely international and is the foundation of national interoperability programmes in the UK (NHS), Canada (the Pan-Canadian Interoperability Roadmap), Australia, and much of the EU. SMART on FHIR is widely adopted. Country-specific profiles, terminology bindings, and certification regimes vary substantially — UK NHS-specific profiles, Canada's pan-Canadian profiles, and the EU's evolving European Health Data Space all differ from US Core. The architecture transfers; the specifics do not.
For most clinician-facing products: a SMART on FHIR EHR launch that reads a defined slice of USCDI for the launched patient, runs your model, and presents the output in your app. No write-back, no event feed, no marketplace listing. This can ship in eight to twelve weeks against a cooperative design partner and is usually enough to validate the workflow and unlock the next round of work.
Last updated: May 2026
Get expert guidance on implementing AI solutions that actually work. Our team will help you design, build, and deploy custom automation tailored to your business needs.
As businesses move toward fully cashless operations, ACH payments offer a low-cost, reliable backbone for transactions. This guide covers what ACH is, how it fits into a cashless strategy, compliance requirements, and how to evaluate whether ACH is right for your business.
Learn how to build AI agents that can actually take actions, not just answer questions. Includes real architecture patterns, code examples, and lessons from building 30+ production AI agents.
Discover how AI automation development is transforming businesses—improving efficiency, reducing costs, and driving growth across manufacturing, healthcare, finance, and retail.