TL;DR: The AI model is rarely what stalls a healthcare AI project; the integration is. In a 2024 survey of US acute care hospitals, 48.8% of Epic hospitals had generative AI integrated into their EHR, versus 15.6% on Oracle and 14.3% on Meditech. For mid-market providers on older or less-extensible systems, the real budget line is plumbing, data cleanup and governance, not the model licence.
Internal Links
- healthcare organisations
- API development and integration
- custom software development
- EHR interoperability
- custom middleware
The number that should reframe your AI roadmap
A peer-reviewed analysis in JAMA Network Open of 2,174 non-federal US acute care hospitals found that 31.5% had generative AI integrated with their EHR, and a further 24.7% planned to within a year. Behind that average sits a stark split. Early adoption was 48.8% among Epic users, 15.6% among Oracle users and 14.3% among Meditech users. Major teaching hospitals were at 53.9%, nonteaching hospitals at 25.9%; multihospital system members at 38.5%, independents at 16.3%.
The pattern is not that some hospitals are smarter about AI. It is that when AI arrives as a feature of the EHR vendor's own platform, the integration cost is borne by the vendor and spread across thousands of customers. Everyone else pays it themselves, once, in custom work.
Federal data tells the same story for predictive AI. ASTP/ONC reported that about 71% of hospitals used EHR-integrated predictive AI in 2024, up from 66% in 2023, but adoption was 86% in health-system-affiliated hospitals against 37% in independents, with small, rural and critical access hospitals lagging.
For healthcare organisations outside the large-system, single-vendor club, the question is not "which AI tool" but "what does it cost to connect it safely to the system of record."
Where AI is delivering value today
The use cases with traction are the ones that sit close to existing workflows and have measurable outputs:
- Revenue-cycle and administrative automation. Per the ASTP data, hospitals using predictive AI for automated billing rose from 36% to 61% between 2023 and 2024, and for scheduling from 51% to 67%. These are bounded, auditable tasks.
- Ambient documentation. Multi-site studies of ambient AI scribes report reductions in documentation time and clinician EHR time, and some report modest increases in visit volume. Results vary by specialty and setting, and clinician review of every note remains essential.
- Risk identification for outpatients. Identifying high-risk outpatients was among the faster-growing predictive uses.
Where it is overhyped or premature
- Clinical treatment recommendations. In the same ASTP data, treatment-recommendation use plateaued (roughly a 2-point rise) and inpatient trajectory prediction was flat. Local validation, liability and clinician trust are the brakes, not model capability.
- Autonomous patient-facing agents. Hallucination in a clinical context is a patient-safety and regulatory issue, not a UX bug.
- "Plug-in" AI for non-extensible systems. Vendor demos assume clean, standards-based data access that many on-premise or heavily customised EHRs cannot offer.
Why "just use the API" understates the work
Most healthcare AI pilots start with a demo on exported or synthetic data. The demo works, the pilot is approved, and then the team discovers what production requires. EHR interoperability in a real hospital is rarely a single clean FHIR endpoint. It is typically a mix of HL7 v2 message feeds for admissions and results, vendor-specific APIs with rate limits and licence conditions, direct database reads for a few legacy modules, and scanned or free-text documents that never became structured data. Each source has its own identifiers, its own update cadence and its own failure modes.
That is why the integration layer, often built as custom middleware between the EHR, lab, pharmacy and billing systems, tends to outlive the first AI use case. The model may be replaced twice in three years; the normalised patient, encounter and order data feed is the durable asset. Teams that budget for it as infrastructure, rather than as a one-off project cost, get a much cheaper second and third use case.
Three failure patterns we see repeatedly
The insight that lives outside the workflow. A risk score on a separate dashboard competes with the clinician's attention and loses. If write-back or in-context display is not possible with your EHR, the use case needs to be re-scoped around what is possible, such as a worklist, a pre-visit summary or a billing queue.
The data feed nobody owns. When a field changes meaning after an EHR upgrade or a new coding practice, a model silently degrades. Someone must own data contracts between the source system and the AI service, with alerts when distributions shift.
The compliance review that arrives last. Privacy, consent and audit requirements should shape architecture on day one. In the US that means HIPAA obligations and business associate agreements; in India, the DPDP Act and ABDM norms. A HIPAA compliance checklist run at the design stage costs a fraction of re-architecting after a security review.
Build, buy or wait: a practical decision frame
If your EHR vendor ships a native feature for a generic need such as ambient documentation, buying or waiting is usually rational: the vendor carries the integration. If the use case depends on your own workflows, your own mix of systems or data the vendor does not expose, you will carry the integration either way, and owning it gives you leverage and portability. For many mid-sized providers, the answer is hybrid: adopt vendor-native features where they exist and invest in a thin, well-governed integration layer for everything else. Custom-built healthcare software is not a default recommendation, but targeted custom components around a commercial EHR often are.
The hidden cost stack of legacy EHR integration
| Cost layer | What actually happens | Mitigation |
|---|---|---|
| Interface access | Read/write access limited by vendor APIs, licensing fees or HL7 v2 interfaces with site-specific quirks | Integration layer / API gateway that normalises to FHIR where possible |
| Data quality | Free-text notes, inconsistent coding, duplicate patients, missing fields | Data profiling before model selection; fix the feed first |
| Write-back | Insight that cannot land inside the clinician's workflow is ignored | Design for in-workflow delivery, not a separate dashboard |
| Validation & monitoring | Models drift; hospitals that need local accuracy and bias checks need tooling for them | Governance owner, monitoring dashboards, rollback plan |
| Privacy & compliance | PHI handling, consent, audit trails (HIPAA in the US, DPDP Act and ABDM norms in India) | Data minimisation, de-identification, vendor BAAs/DPAs |
| Change management | Clinicians reject tools that add clicks | Clinical champions and a pilot on one ward or clinic |
One finding is worth sitting with: in the JAMA analysis, hospitals that did comprehensive evaluation of predictive models were 12.1 percentage points less likely to be early generative AI adopters. Rigour is slower; that is a feature, not a bug, but it should be planned for in timelines.
Is your organisation ready? A checklist
- Can you name the system of record for each data type the AI will need, and the interface (FHIR, HL7 v2, database, flat file) for each?
- Do you have documented, tested read access, and a path for write-back into the clinician's screen?
- Has someone profiled the data quality of the fields the use case depends on?
- Is there a named clinical owner and a governance process for local validation and monitoring?
- Have privacy, consent and audit requirements been mapped to the use case?
- Does the pilot target an administrative or documentation workflow before a clinical decision?
- Is the integration cost in the business case, not just the licence?
What to do in the next 90 days
Pick one administrative or documentation use case with a clear baseline metric. Inventory the systems and interfaces it touches. Profile the data quality of the fields it depends on. Stand up the minimum integration layer, with logging and access control, before selecting a model vendor. Define the clinical owner, the validation approach and the rollback trigger. Only then run the pilot, measuring against the baseline you captured first. This order feels slower than starting with a model demo; in practice it avoids the six-month stall that follows a pilot nobody can connect to production.
How Syslabs fits
For mid-market providers, the valuable work is usually unglamorous: an integration layer that exposes EHR and ancillary system data through clean APIs, data-quality pipelines, and custom workflow software that puts AI output where clinicians already work. That is where Syslabs focuses its API development and integration and custom software development work: making AI projects connect to the systems you already run, rather than assuming a rip-and-replace.
Sources
- Uptake of Generative AI Integrated With Electronic Health Records in US Hospitals, JAMA Network Open: https://jamanetwork.com/journals/jamanetworkopen/fullarticle/2842683
- ASTP Data Brief No. 80, Hospital Trends in the Use, Evaluation, and Governance of Predictive AI, 2023-2024: https://www.healthit.gov/sites/default/files/2025-09/hospital-trends-use-evaluation-and-governance-predictive-ai-2023-2024.pdf
- Healthcare IT News coverage of the ASTP findings: https://www.healthcareitnews.com/news/astp-finds-more-health-systems-are-adopting-predictive-ai
Next step
If you are weighing an AI project against an EHR that was not built for it, a 30-minute AI-readiness conversation can map your integration path and likely cost before you commit budget.