01The problem, plainly
Any competent engineer can wrap a FHIR API in an MCP server in a weekend, and AI-assisted coding makes the client code nearly free. What still takes clinical-AI teams six to twelve months is the part AI can't shortcut:
- EMR vendor approvalKey registration and the OAuth quirks of every EPIC and Cerner instance.
- Security reviewProving to a hospital that your agent can't read the wrong patient, the wrong tenant, or write anything it shouldn't.
- Multi-tenant isolationProvable, not promised.
- Token economicsGetting a 200,000-token patient chart into a context window without truncating it or going broke.
- Notes search that stays homeFree-text notes made searchable without PHI leaving the hospital's own infrastructure.
- Clinician trustShowing how an answer was scoped, what was read, and what was blocked.
None of that is anyone's product. It's the same work, for every team, every time. That's the whole reason Kartha exists.
02The MCP server is the easy 5%
A FHIR API gets you a demo. Getting an agent to a live EMR takes enterprise-grade security know-how that goes well beyond the API — everything a health system requires before an agent touches a patient chart:
- Who may call the tools?Verified identity and tenancy on every request — attributable to a real person, not a service account.
- Which EMR does a call reach?Routing that no caller input — and no LLM output — can redirect to another tenant.
- What can the agent never do?Enforced limits on writes, patient scope, and time bounds. Not conventions — mechanisms.
- How does a 200K-token chart fit?Selective, economical retrieval — not full-chart dumps into a context window.
- How do notes become searchable?Semantic search over free text, without PHI ever leaving the building.
- Why should a clinician trust it?Visible receipts — how every answer was scoped, sourced, and constrained.
Kartha's answer to each of these is the platform: how it solves them, and what it's built on.