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.
What a rule is.
A rule says: when the record looks like this, suggest that, here. Each part is explicit.
When. A condition over the record: a diagnosis in a value set, an age range, a result over a threshold, a medication on the list, or a combination of those with and, or and not. Conditions can follow references, so a rule can ask about the visit a note belongs to or the patient a visit is for.
Where. The scope the suggestion applies in: this visit, this section of the note, this specialty.
Suggest. A clinical item: a condition to add to the history, a finding, an order, a follow-up. The suggestion is a real record, authored the way a clinician would author it.
Unless. Suppression: do not suggest what is already there, or what the clinician already declined.
A practice runs thousands of rules, grouped and versioned. Today they are authored from example visits, an approach that keeps the familiar item editors but ties rules to the encounter they came from; the editor described below replaces that.
How the engine keeps up.
Compiled once. The whole rule set is compiled into one graph and loaded into memory, about half a minute per process, shared by every clinic that process serves. A clinic is activated into the warm engine on demand, in about two seconds, and retired when idle.
Incremental. The engine keeps the intermediate results of every rule. When the record changes, only the part of the graph the change touches is re-evaluated, which is why a change costs milliseconds rather than a full pass. New subscriptions are answered from the same working state.
Consistent. The engine only answers once a moment in the record is sealed, so a reply never mixes data from two different points in time. A clinician opening a note sees suggestions that all agree about what the record said.
Embedded. The engine runs inside the clinical application's server, so patient data never crosses a network to be evaluated.
Proving it before switching.
The new engine ran in shadow for weeks: every request went to both the previous engine and the new one, and their answers were compared. That comparison is how the numbers on this page were measured, on live clinic traffic rather than a benchmark. During a five-hour outage of the previous engine in August 2026 the new one kept answering, and its answers matched what the old engine had produced before the outage and after it recovered. It now serves the clinical application, with the previous engine kept as a fallback while the changeover completes.
Where language models fit.
A model is the right tool for open-ended work: reading a long history, drafting a section, summarizing a conversation, answering a question nobody wrote a rule for. Its answer goes to a person for review. A rule is the right tool when the answer must be the same every time and its reason must be showable: a suggestion tied to a diagnosis, a follow-up tied to a result.
They meet in the record. Rules watch the record, and a model's accepted draft lands in the record like any other entry, so the same rules apply to it. A model can draft; rules keep watch. Both read the record under the same permissions, and as the agent work completes, both leave the same kind of trace.
The rule editor, in more detail.
The editor now in design has one job: let a clinician author and explore rules in the terms they think in, without an expression language.
Library. Rules live in modules. A module carries a title, an owner, a rationale, its sources and its revision history. A practice's module can include other modules, replace one of their rules with a local version, or disable one, and every effective rule shows where it came from and how it got there.
Author. Authoring starts from a search: when an encounter's diagnosis is in [a value set]. Under it, the matching suggestions are grouped by where they appear, and each suggested item is an ordinary encounter item card, authored with the same editors used during a visit. Each card opens its full condition: the searched part highlighted, every other requirement, restriction and suppression still visible and editable.
Blanks that know the data. Each blank in the sentence knows the clinical data model. 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; an unknown part of the schema says so instead of offering a free-text box.
Explore. The same workspace answers "how could fever be suggested in the history?" and "what gets suggested when the diagnosis is otitis media, and where?", because rules are indexed by what they read, what they suggest and where the suggestion appears.
Cases, not silent narrowing. Adding a condition splits a rule into two visible cases, with and without, each keeping the original suggestions, so the author decides what each case should suggest. A case with no suggestion is an explicit decision, not a rule that vanished.
Releases. A draft workspace and a published release are visibly distinct. A release pins the module and everything it includes; validation rejects incomplete rules before publication.