EMR WebMCP: LabLatch

Why I am building this

I am Dr. Sithira Ambepitiya, a doctor and the Head of AI at AIGP Health.

At AIGP Health, I work on Anzu, an agentic clinical platform built in Singapore. Anzu is HSA Class A approved, and we are building the wider system toward an agent-native EMR.

Working on Anzu has shown me what is possible when a new clinical system is designed around agents from day one. That is exciting, but a new EMR is obviously not the answer for everyone.

Most clinics cannot throw away the medical record they already use. Large health programs have years of data, workflows, training, and infrastructure tied to existing systems. Open source EMRs like OpenMRS are already being used by real clinics and large populations, especially in places where budgets, staff, and infrastructure are limited.

That is why I wanted to build this.

The real opportunity is not only creating new agent-native medical records. It is also making the systems people already depend on understandable and usable by agents.

The medical record already has most of the information a clinic needs. The painful part is the work around it. Someone still has to search through screens, open several charts, check whether an abnormal result was followed up, work out who owns the next step, and make sure nothing important has disappeared into a queue.

When people talk about medical AI, they often jump straight to diagnosis. I do not think an agent has to start there to be useful. There is a huge amount of repetitive operational work that pulls clinicians away from patients. It is structured enough for an agent to help with, but important enough that it needs proper safety boundaries.

What EMR WebMCP does

EMR WebMCP gives an existing medical record a small set of structured tools that an agent can understand and use.

Instead of handing the agent unrestricted browser control or a generic API key, the OpenMRS page exposes specific actions through WebMCP. The tools available at any moment depend on the current page, the logged-in user, their permissions, and what that OpenMRS installation supports.

A clinician can ask, "Prepare tomorrow's diabetes clinic. Show me unresolved abnormal results, missing follow-up, and overdue tasks."

The agent can find the appointments, assemble a focused brief for each patient, identify recorded gaps, prepare follow-up drafts, and take the clinician to the right native screen.

One workflow is called LabLatch. It finds abnormal results that do not have an active follow-up owner. It gathers the relevant context and prepares a task for review, so an important result does not quietly disappear into the record.

The important word is prepare. The agent does not make the final clinical action.

How it works

I did not want to fork OpenMRS or build a fake medical record just for a hackathon demo. The whole point is to show that an existing system can become agent accessible without being replaced.

The project is a TypeScript monorepo. A shared core defines the tool contracts, safety rules, result format, lifecycle, and privacy-aware telemetry. The OpenMRS adapter connects those contracts to O3, FHIR R4, REST data, routes, permissions, and native workspaces. Reusable workflow packages contain the clinic preparation and follow-up logic.

An O3 frontend module registers twelve bounded tools through document.modelContext.

Some tools read a limited amount of existing information. Some open a known screen. Some prepare a temporary draft inside the browser.

There is no tool for arbitrary REST calls, unrestricted FHIR queries, SQL, code execution, or free-form DOM manipulation.

The demo uses synthetic patients and a simulated clinic backlog. It does not need real patient data.

The safety boundary

The hardest part was not connecting an agent to an API. The hard part was deciding exactly what the agent should not be allowed to do.

I split every action into four classes: read, navigate, draft, and commit.

The agent can read, navigate, and draft. It cannot commit.

Before anything is written, OpenMRS shows the patient, the source evidence, the proposed action, the assignee, the priority, and the due date. The clinician can edit it, confirm it, or discard it. Only that visible confirmation creates a durable task.

The agent cannot prescribe, sign a note, discharge a patient, change clinical facts, contact a patient, or quietly mark work as complete.

It also cannot bypass the current user's permissions. There is no shared superuser token behind the demo.

What was difficult

The easy version would have been one generic tool that could call any EMR endpoint. It would look powerful, but it would miss the point of WebMCP and create a dangerous interface.

The better version required small tools with clear meanings, bounded inputs, predictable outputs, and visible confirmation points.

OpenMRS also spans frontend context, FHIR resources, REST metadata, routes, permissions, and task workspaces. Keeping those details inside one adapter while keeping the workflows reusable was a real architecture challenge.

I also had to treat stale screens, patient changes, duplicate follow-ups, expired drafts, authorization failures, and logout as normal safety cases, not rare edge cases.

What I am proud of

The part I am most proud of is not the number of tools. It is the boundary.

The agent can do enough preparation to make a real difference, while OpenMRS remains the system of record. The existing EMR still controls identity, permissions, clinical evidence, and the final write.

This is also what makes the idea larger than one OpenMRS demo. A different EMR can implement the same workflow contracts through its own adapter, using its own API, terminology, routes, and confirmation screens.

What I learned

WebMCP is much more interesting than simply turning a webpage into another API.

A good WebMCP surface lets an application explain what actions are meaningful, what data is needed, what the current user is allowed to do, and where a human decision is still required.

For healthcare, that is the difference between an agent that clicks faster and an agent that can actually fit into clinical work.

What comes next

OpenMRS is the first proof point. I am not claiming that EMR WebMCP already works with every medical record.

The next test is a second adapter that passes the same contracts without changing the workflow packages. After that, the same approach could support referrals, patient recall, documentation drafts, inventory, and discharge readiness.

I also want to compare the same tasks across normal manual use, ordinary browser automation, and WebMCP. The goal is to measure whether the structured agent path saves time while preserving the clinical safety gates.