An open health platform for AI to participate in clinical work.
AI needs access to the work of healthcare as well as its data. Reading a chart is one part of helping with care. Useful assistance also means contributing to a draft, preparing the next step, responding when information changes, and following a task through to completion. Each of those depends on what the clinical system lets other software do.
Breeze gives clinical applications and AI agents the same documented capabilities, under explicit permissions, with a record of who did what. Breeze EHR is one application on the platform, not the platform itself.
Five things software needs to take part in care.
Health data standards give an application a way to ask for access to a patient's information, including permission to write. How deeply it can take part still depends on what the clinical system exposes. Access to records does not by itself provide access to the work happening around them.
Context
The relevant record, its history, and where each fact came from.
Today: read the record, search it, and see every earlier version of it.
Participation
Structured drafts and collaborative edits where clinicians already work.
Today: shared editing of the visit note, and structured note sections captured at a stated point in the record's history.
Action
Defined clinical and administrative actions with checks, bounded authority, and human review where required.
Today: named actions for booking, tasks, referrals, medications, billing and notes. The platform owns the rules and makes the related changes together.
Feedback
Events and outcomes that let a caller follow work through to completion.
Today: live updates on a patient, a task or an appointment, delivered so that a screen or an agent never sees a half-applied change.
Accountability
A trace of what was read, proposed, approved and changed, including who or what acted and on whose behalf.
Today: every change names the clinician responsible for it, and every version is kept. A uniform record of reads and of agent actions is designed and in progress.
Decoupled by design, bound by one contract.
Every layer in the diagram above speaks the same standard language at its boundary, and the boundary a clinician's screen uses is the boundary an agent uses. That is what makes the platform open: a piece can be inspected, extended or replaced without rebuilding the rest.
The contract comes first. A written contract declares what the record looks like and which actions may be taken on it. The platform is assembled from that contract. An action that is declared but not implemented stops the platform from starting, rather than failing a caller later.
The core is reusable and open. The server at the center is open source, and storage sits behind it as an interchangeable piece. Two storage engines exist today; both keep the full history of the record.
The EHR is one application on the platform. Breeze EHR reads and writes through the same interface any partner application or agent uses. There is no private path, and nothing the EHR can do that the interface cannot.
Services are separable. Terminology, collaborative notes, connections to labs, pharmacies and hospitals, and search each stand behind their own boundary. Choose the AI provider, the terminology source or the connection you need; the rest of the platform does not change.
An agent is a caller, not a new layer.
An agent is not a privileged system with inside access. It uses the same platform a person does: the same services, the same actions, governed by the same permissions and the same accountability. There is no agent-only way to change the record and no agent-only exception to the rules.
An agent's authority is a strict subset of the authority of the human or service it acts for, and every exercise of that authority is recorded.The principle the agent surface is built to.
The same actions, the same rules. An agent does not receive a special catalogue of powers. It receives the published actions, each already bounded, documented and individually permitted, which is exactly what a safe tool should be. A general "do anything" capability is precisely what an agent never gets.
Described once, understood by everyone. Because every action is declared in the contract, the description a person reads, the one the clinical application is built from, and the one an agent is given are the same description. The clinical application is built from it today; handing agents that same description is the next step.
| What an agent can do | How | Status |
|---|---|---|
| Read the record and search it | The same way a clinician's screen does, limited by the agent's permissions and the patients it may see | implemented |
| Take a named action | Booking, tasks, referrals, medications, notes, with the platform's rules applied and the related changes made together | implemented |
| Ask what the record said at an earlier time | Every version of every record is kept | implemented |
| Follow a patient, task or appointment | Live updates as the record changes | implemented |
| Act for a person with less than their full authority | Bounded delegation: a subset of the person's permissions, patients and actions | direction |
| Receive its list of allowed actions automatically | Derived from the contract and filtered by what the agent is permitted to do | direction |
Every action is named, written down and enforced.
A useful integration needs the rules of the workflow, not only the shape of the record. A caller says what it wants done; the platform applies the rules and makes the related changes together, so no caller has to reimplement them and no caller can skip them.
For example, creating a referral
The caller says who the patient is, which specialty they are being referred to, and why. The platform sets the category, the time and the requesting clinician, allows the referral to begin only as a draft or as active, and, if the same request arrives twice, returns the referral it already created instead of making a second one. The clinician sees one referral, with the reasoning attached, ready to approve.
Scheduling
- Book
- Cancel
- Check in
- Mark no-show
- Release a slot
- Copy a day's schedule
Tasks
- Start
- Complete
- Reassign
- Reject
- Reopen
Orders and referrals
- Create a referral
- Convert to an order
- Complete
- Reconcile results
Medications
- Replace
- Stop
- Cancel
- Approve a renewal
Notes
- Capture a section
- Attest
- Use structured sections
Visits and billing
- Open a visit
- Change status
- Change attending
- Move location
- Send a claim
- Withdraw a claim
Terminology
- Expand a value set
- Validate a code
- Look up a code
- Search concepts
People
- Register a patient
- Request a demographic change
- Update demographics
- Add a related person
Each action is declared once. The same declaration drives the platform, the clinical application and, in time, an agent's understanding of what it may do. What a particular deployment exposes to outside software is stated for that deployment, not assumed from the list.
There is a time for language models, and a time for deterministic decision support.
A language model is the right tool when the work is open-ended: reading a long history, drafting a note, summarizing a conversation, answering a question nobody wrote a rule for. Some decision support has to be different. When a diagnosis is entered, the same suggestions must appear every time, for every clinician, with a reason that can be shown and a version that can be reviewed. That is a job for rules, not a model.
Breeze runs a deterministic rule engine alongside the record. Rules are written once, as data: when an encounter carries a diagnosis in this set, suggest this condition in the history; when this result comes back, suggest the follow-up. Thousands of rules are compiled together and evaluated in one pass per patient, and a change to the record re-evaluates only what it touches rather than starting over. The suggestions appear inline as the clinician writes in Breeze EHR, and they are the same suggestions on Monday as on Friday.
The two work together. A model can draft; rules keep watch. A rule's answer is reproducible, its reason is the rule itself, and its history is a version number. A model's answer goes to a person for review. Both read the same record under the same permissions, through the same interface as everything else on the platform.
The warmed performance profile
The engine warms once, then stays warm. On start it loads and compiles the practice's rule bundle, about half a minute, shared by every clinic served by that process. Bringing a clinic onto an already warm engine takes about two seconds. From then on the engine is incremental: it holds the rules' working state in memory and updates only the part a change touches.
Two properties matter as much as the numbers. Answers are consistent by construction: a reply never mixes data from two different moments in the record, because the engine only speaks once a moment is sealed. And the profile holds under load: across the measurement window the new engine's median stayed flat while the previous engine's nearly doubled as traffic grew. During a five-hour outage of the previous engine in August 2026 the new one kept answering, with suggestions identical to what the old engine had produced before and after. It now serves the clinical application, with the previous engine kept as a fallback while the changeover completes. Figures are from live traffic at one practice in August 2026.
A new rule editor in progress
Rules are only as useful as the people who can write them. The rule editor now in design lets a clinician author a rule the way they would say it: a sentence with blanks. When an encounter's diagnosis is in [a value set], in [this section], suggest [this item]. Each blank knows the clinical data model and offers only what makes sense there: a code offers an exact concept or membership in a value set, a measurement asks for a value and a unit, a choice asks for its branch before its comparison. Nothing is a free-text expression box.
The suggested item itself is authored with the same editors clinicians use during an encounter, so what a rule suggests looks exactly like what they would have entered by hand. Rules are named and owned by modules that compose and version; a practice can include another module's rules, replace one locally, or disable it, and every effective rule shows where it came from. Rules are searchable by what they read, what they suggest, and where the suggestion appears, so "how could fever be suggested in the history?" and "what gets suggested for otitis media?" are both one query. Adding a condition splits a rule into explicit cases, with and without, so nothing is narrowed silently. Drafts and published releases stay visibly distinct.
A record a model can read and a person can trust.
Legible data is structured data with its story attached: what it says in words, what it said before, and who changed it.
Plain language on the record. Records written through the platform carry a readable version generated from their structured content, so a model and a clinician read the same statement of the same fact.
History is kept, not overwritten. Every version of every record is retained. Ask what the record said at any past moment. The second storage engine also answers what was believed to be true for a period, which is the question a retrospective review or a corrected result actually asks.
Every change is attributed. A change on the clinical interface must name the clinician responsible for it. A device or service credential without one is refused; a patient's own session is the one exception. That rule is what makes acting on someone's behalf meaningful when agents arrive.
The trace below is the shape the accountability work is building toward: one line per read, draft, proposal, approval and applied change, each naming who or what acted and for whom.
An assistant helping with a visit.
Consider an assistant working alongside a clinician during a visit. Each step needs a supported interface and an explicit permission. The steps are in the order the work happens.
-
Read the relevant history
Problems, medications, prior results and the notes from the last two visits, limited to this patient and this clinician's authority.
Uses reading and searching the record, with its history. implemented
-
Contribute a draft to the note
An assessment section the clinician can accept, edit or discard, in the same document they are already writing in.
Uses the shared note and section capture. implemented
-
Prepare a referral for review
A cardiology referral created as a draft, with the reason and the note filled in, for the clinician to approve.
Uses the create-a-referral action, as a draft. implemented The review step that lets an agent propose without approving is direction.
-
Follow the result into the next task
When the referral is accepted or a result lands, the assistant sees it and moves the follow-up task along.
Uses live updates and the task actions. implemented
We are building toward that connected workflow. The interfaces for each step exist; complete agent workflows across them, with human review and attributable outcomes, remain to be demonstrated.
What runs today, and what is direction.
Three statements are kept distinct on this page: built, verified in a particular deployment, and available to outside developers. The table is the first. Which release you would build on, and what it exposes, is a conversation.
| Capability | Built | Direction |
|---|---|---|
| Clinical contract | The shape of the record and the actions allowed on it, declared in writing and loaded by the platform at startup. | Publishing the contract as a versioned package for outside developers. |
| Workflow actions | Booking, tasks, referrals, medication changes, billing, note sections, demographic change review, terminology. | A review step for agent proposals; delegation of individual actions. |
| Decision support | An incremental rule engine that keeps thousands of rules evaluated as the record changes, serving suggestions to the clinical application with the previous engine as a fallback. | The sentence-style rule editor; retiring the previous engine. |
| Live updates | Updates on a patient, task or appointment, delivered consistently. | Re-checking permissions on every update. |
| Collaborative notes | Shared editing with history and live updates; structured sections with a stated basis. | One permission path shared with the rest of the platform. |
| Permissions | Standard, scoped permissions on the clinical interface; a responsible clinician named on every non-patient change. | Bounded delegation, so an agent's authority is a subset of its principal's. |
| Accountability | Every version kept; clinician attribution on changes. | A uniform record of reads, changes and agent actions. |
| Openness of the source | The core server is open source. Breeze's own clinical definitions are not yet released. | An explicit scope for wider release and for operating the platform independently. |
What open means here.
Openness at three levels: documented access to data and workflow capabilities; the ability to extend or replace services and to choose who provides the AI; and inspectable software with a viable path to operating the platform independently. An interface alone does not fulfil that. What is released, under which terms, and what it takes to run are stated explicitly for each offering, and where they are not yet settled this page says so.