MCP in the hospital: connecting AI to a legacy HMIS without replacing it

You connect AI agents to a legacy HMIS by putting a Model Context Protocol (MCP) server in front of it: a small service your team controls that exposes a short list of named, permissioned read and write operations over your existing HL7 v2 feeds and vendor APIs, and logs every call. The HMIS stays where it is. The agent never touches the database, the interface engine keeps doing its job, and the MCP server becomes the one audited door through which any model, today's or next year's, reaches patient data. It is also how domain superintelligence (SI), a system built to work at expert level inside one bounded workflow, reaches your records: logged, scoped, and with a named person accountable for every write.

The HMIS is staying, so design for that

Most hospital CIOs have already decided. The HMIS is ten or fifteen years old, it runs billing and admissions, and nobody is replacing it for an AI pilot. Given the estate you have, what should the connection between an agent and your HMIS actually look like?

Nextdot's position on this is interoperability over displacement. We build adaptable integration, MCP servers and open APIs, that connect to legacy and open HMIS alike. A vendor whose AI only works after you migrate to their platform is selling you a migration, with the AI as the sweetener.

What MCP is, in hospital terms

MCP is an open protocol for connecting AI applications to data and tools. It was introduced in November 2024 (Source: Anthropic, 25 November 2024) and in December 2025 it became a founding project of the Agentic AI Foundation under the Linux Foundation, with OpenAI and Block among the co-founders (Source: Linux Foundation press release, 9 December 2025). For a hospital buyer, that means the interface you build is tied to no single model vendor's roadmap.

The specification defines three things a server can offer (Source: MCP specification, 2025-11-25). Resources are context and data the model can read. Tools are functions the model can execute. Prompts are templated workflows. In a hospital, a resource might be today's OPD roster for one department. A tool might be "hold appointment slot". A prompt might be the structured template a discharge-summary agent must fill.

The part that CIOs miss is the sentence in the specification that says MCP "cannot enforce these security principles at the protocol level." The protocol gives you a shape. Consent, access control and data protection are things the implementer builds. So the useful question is what your server should expose and what it should refuse.

What the server should expose, and what it should refuse

A good hospital MCP server is narrow and boring. It exposes named operations that map to a clinical or operational task, and each one returns the minimum data that task needs.

Compare two designs. The first exposes a generic "query patient database" tool that accepts free text and returns whatever it finds. The second exposes "get next available slot for consultant X on date Y" and "get visit summary for encounter Z, demographics excluded". The first is a data-exfiltration interface with a model attached. The second is an interface a security review can read, test and sign off.

Four rules for scoping one:

1. One tool per task. If a tool's description needs the word "or", split it.
2. Minimum fields out. A booking agent needs a slot and a consultant name. It does not need the patient's diagnosis history, so the server never returns it.
3. Identity resolved inside the server. The agent should never reconcile three patient IDs across HMIS, LIS and billing. The server does that once, deterministically, and returns one answer or an explicit "ambiguous" that routes to a human.
4. Stale data declared. Where the source is an HL7 v2 ADT feed that lags, the server returns the timestamp of the last message it saw, so the agent and the log both know how fresh the answer was.

Read paths and write paths are different projects

Treat reads and writes as separate builds with separate sign-offs.

A read path returns data from a replica, a feed or a vendor API. The worst case is disclosure: the wrong data to the wrong caller. That risk is serious under DPDP 2023, and it is controlled with scopes, field minimisation and logging.

A write path changes the record of truth. A held slot, an updated contact number, a draft note pushed into the HMIS inbox. The worst case is a wrong record that a clinician or a billing clerk then trusts. Every write tool should carry three properties: it writes to the narrowest target available (a draft queue or a pending status where the HMIS has one), it is idempotent so a retried call does not double-book, and it records who or what approved it. Anything that touches clinical content writes as a draft for human review, never as a signed entry. That follows directly from how Nextdot allocates liability: clinical judgment sits with the clinician, and the system's job is to keep the review step in the path of every clinical write.

Start with reads. Most early value comes from an agent that sees the right data at the right moment. Writes come after the logs show how the read path behaves in production.

Permissions: the specification gives you the lock, you still cut the keys

MCP authorization is optional in the specification. Where a server runs over HTTP, the specification bases authorization on OAuth 2.1, requires servers to reject tokens issued for any other audience, and explicitly forbids passing a client's token through to downstream APIs (Source: MCP specification, 2025-11-25, Authorization). Those are the right defaults. None of them tells you which agent should see which ward.

That mapping is yours. In practice it means a separate scope for each agent role (an inbound call agent, a scribe, a coding assistant), read and write scopes kept apart, and a credential for the server's own connection to the HMIS that lives in your environment and never in the model's context. Your DBA should be able to revoke that credential in one step.

Hosts must obtain explicit consent before invoking tools, per the specification's security principles. In a hospital that translates into your human-review step: the configured point at which a person approves what the agent proposes.

The audit log is the deliverable

The MCP server is the natural place to hold the audit trail, because every model call to your data passes through it.

On every Nextdot deployment, observability is standard: audit logs, versioned models and prompts, and human override capture. At the integration layer, each call should record the agent, the model version, the prompt version, the tool, the parameters, the rows returned, the latency, and what the human did next. When something goes wrong, that record is what lets you say which failure class it belongs to: the model's output, the retrieval pulling the wrong record, or a site running outside the intended use. Without it, liability becomes an argument.

Two honest caveats. Formal evaluation against clinician-labelled ground truth does not yet run on every Nextdot account; extending it is a current engineering priority. And logging costs latency. On our inbound voice agents, data fetch is one of the two sources of latency we see in production, so a server that logs synchronously on every call has to be designed for that budget from day one.

Ask any incumbent AI vendor in your hospital to show you the last thirty overrides. There is almost never an answer. An MCP layer you own gives you one.

Domain superintelligence (SI) and why the integration layer outlasts every model

Models turn over every few months. Your HMIS turns over every decade or so. The MCP server sits between those two clocks, and that is why it is the part worth owning.

This matters more as systems get more capable. The domain SI systems Nextdot builds are designed to work at expert level inside one bounded workflow, and each one should reach patient data only through a layer that decides what it can read, what it can write and who reviewed it. More capability leaves liability, DPDP obligations and the duty to reconstruct a decision exactly where they were. A more capable model on the far side of a well-scoped MCP server is still an auditable system. The same model with a database login is a liability that nobody can reconstruct.

The practical consequence: when you swap models, the server, its scopes, its tests and its logs stay put. Changing models becomes a configuration change followed by a regression run against your own cases. The integration work, which "Your Integration Layer Decides Whether AI Works" argued decides whether hospital AI works at all, is spent once.

How to start

Pick one workflow with a clear owner on your side. Build one read-only MCP server over the feed it needs, define its tools in writing before any code, pass security review, and run it with full logging for a few weeks. Then decide whether it earns a write path. A team that has done this before raises scopes, identity resolution and log retention in the first meeting. A team that talks mainly about the model has not done it yet.

Frequently asked questions