Why healthcare needs
its own browser.

Spreadsheets needed Excel. Code needed an IDE. Design needed Figma. Healthcare operations have been running inside a browser tab for fifteen years, and that browser has been Chrome, which was built for the open web rather than for clinical workflows. The cost of that mismatch shows up in places that are easy to miss until you spend time inside an outpatient practice and start to see them everywhere: a coordinator keeping seven Athena tabs open at once, all labeled "Athenahealth," navigated by memory and muscle; a check-in workflow split across three windows because the EHR's UI never anticipated it; a clinician copy-pasting a patient identifier between tabs because the browser does not know they are working on the same person.

A purpose-built browser does not replace the EHR. It becomes the layer the EHR runs inside, observing the workflow as it unfolds, normalizing it across systems, surfacing context the EHR never bothered to expose, and mediating AI access under a single compliance posture.

A team takes a strong foundation model, fine-tunes it on a specific domain, wraps it in a vertical UI, and goes to market as the AI-native answer for some category of work. Legal research. Customer support. Clinical documentation. Sales enablement.

The pattern is structurally fragile in two ways.

The same pattern is now repeating across every operational category in healthcare. Every prior auth agent, RCM agent, referral management agent, and AI scribe is, structurally, an application-layer company. The question, for any AI vendor in healthcare, is whether the moat lives somewhere a foundation model cannot reach.

A principle has emerged from AI research over the last two years that does more to predict where AI will work than any of the louder debates about model size or training data. Whether the work in a given industry produces a verifiable signal at the end of every transaction is a better predictor of when AI will transform that industry than almost anything else.

A system trained against verified rewards self-corrects systematically. Each error generates a precise signal that feeds the next decision. A system trained against subjective feedback improves until it saturates the rater's ability to distinguish quality, and then plateaus.

Test-time compute sharpens this divergence. When a model spends more cycles while answering, it gets sharper in verifiable domains and more confidently wrong in non-verifiable ones. The same scaling axis that makes pricing more accurate makes a clinical recommendation more dangerous.

Most healthcare AI bets sit in non-verifiable territory.

The category where verification is structurally available in healthcare is the one nobody is talking about: the operational layer, which runs on standardized EDI transactions and produces a verifiable outcome on every claim. Pricing is the cleanest instance.

When a patient walks into a specialist's office for a colonoscopy, the practice needs to know, before the procedure, what the patient will owe. The answer depends on plan, accumulated deductible spend, the negotiated rate at the CPT code, modifiers, and coverage logic. The 835 closes the loop with a verdict decomposable into each.

Pricing is where we begin because it has the most immediately measurable ROI for the practice. Patient AR collects in roughly a day instead of a month. Patient yield moves from 60–75% to 90%+. Time spent on insurance checks drops by an order of magnitude. The protocol pays for itself before anything harder gets touched, which is what gets it deployed. The architecture pricing required (a verifier-grounded loop, a network of practices, browser-level workflow access) is the same architecture every other operational AI workload requires.

Pricing accuracy for a given payer-plan-procedure tuple improves with the number of independent observations. A single practice might see a particular Anthem PPO plan adjudicate a 45378 a few dozen times a year. A network of fifty practices on the same payer mix sees it thousands. This is a network effect that derives from the geometry of the data, not from the model layer. A foundation model with a million-token context window cannot replicate it, because the data does not exist in any one place to be ingested.

For an AI vendor in healthcare, the runtime is almost always the EHR's API surface, which the EHR vendor designed and controls. The signal an AI vendor can train on is the signal the EHR chose to expose. The actions the vendor can take are the actions the EHR's API supports. The integration timeline is the timeline the EHR's developer relations team is willing to commit to.

A browser sits between the user and whatever the EHR vendor renders. The DOM is what the EHR built its own UI against. The API is a subset of the same information shipped late and often incompletely. Instead of waiting for an EHR to expose a new endpoint, the browser observes the workflow directly. Instead of integrating against N different EHR APIs to reach N different practice cohorts, a single browser deployment normalizes across all of them.

The harder question is whether building a browser is a reasonable thing to do. It is, and the reason is that the browser stopped being a moonshot in 2008.

None of this is exotic. All of it ships in Chromium. All of it has been open source since 2008. Before Chromium, building a browser was a multi-thousand-engineer project. After Chromium, the rendering layer became infrastructure. We did not invent a new browser substrate. We chose the right one and we are building the parts no one has built yet.

We do not fork Blink. Reinventing a layout engine would consume engineering time for no commercial return. The desktop application shell is Electron, the same framework that ships Slack, VS Code, and Linear. What we build on top is the part that matters.

An API returns the schema the vendor designed: a set of fields, exposed at a set of endpoints, on a release cadence the vendor controls.

The DOM is the live state of the page the user is interacting with. Every field they have considered. Every dropdown they have opened. Every value they have changed. Every state transition the page has rendered. The DOM is the workflow itself. The API is a summary of the workflow shipped after the fact.

An EHR-published MCP server is the right interface for clean, structured queries against the vendor's schema. DOM observation is the right interface for live workflow context the EHR does not expose. The two are complements, not substitutes. We will ship an MCP server for our own platform and continue to invest heavily in DOM observation. Most agents that operate seriously inside healthcare will use both.

An agent built on a conventional architecture pays for inference on every interaction, in real time, against tokens that scale linearly with usage. An agent built on our browser inherits a different cost structure, because the browser sits in front of scheduling data and can pre-compute against tomorrow's appointment list overnight. Pre-visit eligibility classification, intake screening, prior authorization triage, and pricing inference for the next day's schedule all run as batched, asynchronous, low-priority workloads against tomorrow's patients, with results cached and surfaced instantly when the patient walks in. Inference at batched, off-peak rates against a cached schedule is a different unit economic regime from inference on the critical path of a live workflow.

Vetted agents register with the platform. Practices choose which agents are active and switch between them at runtime, paying through a single billing relationship. Agent vendors reach hundreds of practices through a single integration. The frontier labs continue to build the best models, and we continue to use them. The economic substance of the platform accrues at the layer that sits across all of the EHRs, all of the agents, and all of the practices.

The multi-process model that makes Chromium safe also makes it forgetful. Each origin runs in an isolated renderer process with its own memory space and its own access controls.

Healthcare workflows do not respect origin boundaries. A single check-in routinely spans the EHR, the clearinghouse portal, the practice management system, and at least one ancillary tool.

The clean answer is not to weaken process isolation. The harder answer involves a privileged context-passing layer inside the browser itself, mediated by the main process, with explicit consent surfaces and audit logging on every cross-origin transit. The implementation has to interact correctly with the agent runtime, the compliance layer, and the practice's existing identity infrastructure.

We are writing about it now because the engineers who would find this problem interesting are the engineers we want to be working with on it.