Add AI to an Existing EHR

Every healthcare IT architect eventually meets the system.

Nobody likes it. Nobody remembers exactly when it was installed. Its original vendor may or may not still exist. The documentation is a PDF last edited during the first Obama administration.

And the clinic absolutely cannot replace it.

Welcome to healthcare.

Now management wants an AI agent, a medical scribe, chart preparation, call analytics or some other modern capability — and somebody assumes the first step is a two-year EHR replacement.

Usually it isn't.

A large part of healthcare AI integration is building a safe layer around systems that were never designed for the workflow we want today.

"No API" is annoying. It is not automatically fatal.

Modern vendors love APIs. Legacy healthcare systems sometimes prefer more archaeological forms of communication.

But "no public REST API" does not necessarily mean "no integration path." The system may already expose:

• FHIR resources;
• HL7 v2 messages;
• a vendor-specific API;
• direct or replicated database access;
• scheduled CSV/XML exports;
• shared folders;
• interface-engine feeds;
• reporting endpoints;
• an import mechanism;
• or, in the least elegant cases, only its user interface.

The important thing is not ideological purity.

The important thing is finding the safest and most maintainable way to move the required information.

The integration paths we look for, in order

I roughly prefer the options in this order:

1. Supported vendor API. Best case: documented, authenticated, stable and covered by the vendor's support model.

2. Standards-based interface. FHIR, HL7, DICOM or another established healthcare protocol where it actually covers the workflow.

3. Existing integration infrastructure. Interface engine, integration database, event bus or another layer the organization already uses.

4. Controlled database/file integration. Sometimes the reliable option is reading a replica, importing exports or exchanging files. Not glamorous. Often perfectly effective.

5. RPA/UI automation. Last resort for workflows where the source system exposes nothing better and the operational importance allows it.

The best technical answer is not always the newest one.

If an old laboratory system exports a stable CSV every five minutes, I would rather consume the stable CSV than build a fragile screen robot because "agents are the future."

Reading from the EHR is easier than writing back

This distinction matters enormously.

An AI assistant that reads the record and prepares a physician summary can often be isolated from the core transaction flow.

An agent that creates appointments, changes medical data or writes documentation back into the EHR now needs stronger controls.

For write operations I want:

• explicit resource/patient identifiers;
• schema validation;
• business-rule validation;
• authorization independent of the model;
• concurrency/version checks where relevant;
• idempotency or duplicate protection for retry-prone operations;
• clear success/failure responses;
• auditability.

A model can decide that the user wants an appointment.

It should not be the component that decides whether a malformed booking transaction is valid.

Why healthcare integrations become difficult

The technical connection is only part of the problem. You also need to understand what the data means operationally.

A field called status = 3 is not particularly useful unless somebody knows that it means "patient arrived but has not completed payment." A patient may appear twice because two departments created separate records. An appointment may be technically cancelled but still need clinical follow-up.

Healthcare workflows accumulate these details over years.

This is why successful integration needs both technical work and domain understanding. Otherwise the systems exchange data beautifully while the actual process remains wrong.

There is another common problem: the EHR is not the whole clinic.

The workflow may also depend on CRM, telephony, billing, laboratory data, WhatsApp, payer portals, spreadsheets and a shared folder whose existence nobody mentioned during discovery.

AI needs the operational story, not just one database.

Where the AI layer should sit

I normally prefer to keep the AI layer logically separate from the EHR.

The EHR remains the system of record.

The AI application can:

1. retrieve only the data required for the task;
2. normalize or assemble context;
3. reason, classify, summarize or choose an approved next action;
4. call narrow integration tools;
5. validate the result;
6. write back only what belongs in the source system.

This architecture has several advantages.

You can change models without changing the EHR. You can test the AI in shadow mode. You can keep permissions explicit. You can add new workflows without forcing every AI concept into the source system's data model.

FHIR can be particularly useful as a standardized integration substrate; see FHIR for AI. For narrative data, a hybrid retrieval layer may also use RAG.

Sometimes the bridge is ugly

I have no religious objection to ugly integrations.

If a 15-year-old laboratory system can only export CSV files every five minutes, we can work with CSV files. If the only realistic integration with a legacy desktop application is controlled RPA, that can be considered too.

The question is whether the method is stable enough, secure enough and appropriate for the importance of the workflow.

You do not use a fragile screen automation to control a life-critical medical process if a better integration path exists.

But you also do not tell a clinic to replace a $2 million system because somebody on the development team thinks CSV is aesthetically offensive.

Engineering involves compromise.

Healthcare IT involves considerably more of it.

Security and auditability still matter

Building around a legacy system does not mean abandoning basic controls.

The integration layer should use appropriate authentication, access restrictions, logging and traceability. If data is transformed, the path should be understandable. If an automated action changes something in the source system, it should be possible to know what happened and why.

Especially when AI is involved.

For PHI-heavy architectures, see Can LLMs Handle PHI?. For action boundaries, see Healthcare AI Guardrails.

When replacement does make sense

Sometimes the old system genuinely has to go.

If it blocks critical workflows, creates unacceptable security risk, cannot scale or requires so much integration glue that maintaining the bridge becomes more expensive than replacement, migration may be the correct decision.

But we do not start with:

"Throw everything away and buy a new platform."

Healthcare organizations have existing processes, training, data and investments. The new system has to justify the disruption.

Until then, integration is often the smarter option.

Nobody raises a Series A because they successfully synchronized patient IDs between two databases.

But this is the infrastructure that lets everything else work — AI agents, analytics, patient communication, scribes and workflow automation all become much more useful once they can see and act on the information trapped inside existing systems.

So if the core system cannot be replaced, fine.

We connect to it.

And if it really refuses to cooperate, we build a safe bridge around it.