01The problem
The Model Context Protocol is an open standard that lets an AI application discover another system’s tools and call them on a user’s behalf. It appeared in late 2024, and within a year the major AI platforms spoke it, so a physician’s ChatGPT or Claude can in principle plug into anything on the other end. In healthcare, almost nothing is on the other end.
That is not because the standard is hard. A minimal MCP server is a few hundred lines of code. It is because the server is only the last inch. Everything behind it, what a tool may return, on whose behalf, with what record of it, is where an EHR either has an answer or does not.
02What we saw
We compared what an AI needs from a record with what records offer. The interoperability rules of the last few years give a read-only view of one patient’s data through FHIR. Useful, but an AI asked who is due for a wellness visit needs a panel, a schedule and a rulebook, not one patient’s bundle. Actions such as booking, refilling and sending are not exposed at all, or only through vendor marketplaces with months of onboarding and a fee per connection.
Inside the vendors the picture was the same. Their own AI features reach the data through private paths that were never meant to be handed to an outside model carrying an outside user’s identity. The door they would need is not locked. It was never built.
03What you have to build
An MCP server a clinic can trust is five things, and the server itself is the smallest. First, typed tools: find a patient, read a result, draft a note, propose an order, book a slot, each with a schema a model can read and a response that carries only what the question needs. Second, delegated identity: the model acts as a named person through a per-user grant with scopes, and inherits exactly that person’s permissions, no more. Third, minimum necessary: the tool decides what to return, not the model, so a question about an A1c does not ship the whole chart. Fourth, an audit line per call, naming the user, the model, the tool and the reason, in the same log as every human action. Fifth, a human gate: anything that leaves the clinic, an order, a message, a claim, is a proposal until a person approves it.
We did not build these for MCP. We built them because our own agents needed them on day one. The receptionist, the fax agent and the billing agent call the same tools, under the same scopes, into the same log. The MCP server is that layer with a standard plug on the outside. That is the whole trick, and it is why it took weeks rather than years.
04Why the incumbents cannot follow quickly
A record built over twenty years for billing and documentation keeps its meaning in screens and workflows rather than in typed objects. There is no propose-an-order to expose; there is an order-entry form with four hundred rules living in its buttons. Turning that into a tool is a rewrite of the clinical core.
Identity is the second wall. Those systems authenticate a person at a keyboard. They have no notion of a model acting for a person with a narrower scope than the person, and no audit path that can name which model did what. Adding that means touching every access check in the product.
The third is economics. Integration is a revenue line for the large vendors, sold through marketplaces and paid per connection. An open protocol that turns a six-month integration into a ten-minute connection competes with that business. Companies rarely build the thing that undercuts their own margin, and when they do, they do it slowly.
An MCP server is not a feature. It is a receipt for how the record was built.
05What it makes possible
The obvious implication is choice. The clinic no longer buys an AI when it buys a record. It brings the model its people already use, switches when a better one arrives, and keeps every workflow, because the workflows live in the record’s tools rather than in a vendor’s chatbot.
The less obvious one is composition. Once the clinic’s tools are on a standard, anyone with permission can combine them. A practice manager wires a Monday-morning brief in Claude that pulls the prior-auth queue, the unconfirmed visits and the week’s denials. A physician keeps a private thread that knows her panel. None of that is a feature we shipped. It is what a standard interface produces on its own.
And it all runs under the clinic’s rules. Bring-your-own-model does not mean bring-your-own-risk: the scopes, the minimum-necessary responses and the human gate apply to a call from Claude exactly as they apply to a call from our receptionist. Patient data reaches an outside model only on a plan that carries the clinic’s business associate agreement with that provider.
06What changed
We are, as far as we can find, the only EHR that ships an MCP server today. We do not expect that to stay true forever, and we would rather it did not: a record any model can use safely is better for clinics than one vendor’s head start. But the gap is structural. The vendors that follow will have to rebuild their core around typed tools, delegated identity and an audit line per call, and that is the work we started with.