Reach the clinician while the patient is in the room.
Decision support in Breeze is how an organization reaches its clinicians at the one moment that changes care: while they are in the room with the patient, writing the note, still deciding. Not a memo, not a meeting, not a message waiting in an inbox afterwards.
A rule is a readable statement of the group's own judgment: if the patient is this age and has not had this vaccine and the note says this, show this. It runs in milliseconds, inline, in the section of the note the clinician is working in. It is the closest thing to having your medical director in every exam room at once, and it is how a protocol the board agreed on actually reaches every provider at every location.
Informing, not interrupting. Most decision support waits for the clinician to act and then objects: a pop-up when the order is signed, a task in the inbox after the visit. People learn to click past those. Suggestions that arrive while the note is being written are part of the thinking rather than an obstacle to it, which is what makes them educational rather than something to dismiss.
The same answer every time, with a reason. The same record produces the same suggestions, for every clinician, every time, from rules anyone can read. A model can answer differently tomorrow and cannot fully explain why; a rule can always be pointed at.
Language models have their place too: reading a long history, drafting, summarizing, answering a question nobody wrote a rule for. Think of it this way: a rule is where the practice's judgment lives, and a model is where the labor gets done. A model can draft; rules keep watch. Both are being built into daily work on the same platform, under the same permissions, with a person reviewing what a model proposes.
Your clinical leadership owns the rules. Rules are data, not code: your medical director can read them, argue about them, change them, and publish the change to everyone at once, without waiting for a software release. The new rule editor lets clinicians write a rule the way they would say it, as a sentence with blanks, and author the suggested items with the same editors they use during a visit. It is built, and reaches each practice as it moves to the new version of the clinical application.
A channel to the clinician, open at the moment of the decision.
Every medical group has things it wants done a particular way: a screening at a certain age, a follow-up after a certain result, a protocol the board agreed on and the medical director owns. The hard part has never been deciding them. It is getting them to the person in the room with the patient, at the moment the decision is actually made.
The usual channels all miss that moment. A memo is read once. A staff meeting reaches whoever attends. A chart audit arrives weeks later, when the visit is over and the patient has gone home. A message in the inbox is read after the fact, if at all. None of them are present while the clinician is deciding what to do for the child in front of them.
A rule is present. It is evaluated against this patient's record as the note is written and it shows what the group wanted said, in the section it belongs to, while the decision is still open. That is the difference between a policy the group has and a policy the group practices: one lives in a document, the other appears in the exam room.
It works the same way at every location and for every provider, including someone covering a clinic for the first time, and it reaches a new clinician on their first day without anyone having to remember to tell them.
Clinical protocol, and the rest of the visit.
The obvious rules are clinical: a vaccine due, a screening for this age, a follow-up a result calls for, a symptom worth asking about given the diagnosis. The same engine reads the same record for everything else a visit has to get right, so a rule can just as well notice that something was done but not recorded in a way that would be billed, or that a visit is missing what it needs before it is closed. It is one engine over one record, so the group does not need a separate product for each of those.
Every rule is a statement someone in the group wrote and can point at. When a suggestion is wrong or no longer wanted, there is a specific rule to change, and the change reaches everyone at once.
What clinicians see.
As the note is written, suggestions appear in the section they belong to: conditions for the history, findings for the review of systems, follow-ups for the plan. A clinician accepts one with a click, ignores it, or asks for more.
An accepted suggestion becomes an ordinary item, indistinguishable from one entered by hand. A suggestion that is already recorded is not offered again. The suggestions come from rules the practice can read, so when someone asks why a suggestion appeared, there is a rule to point at, and when someone asks why it stopped appearing, there is a version to compare.
Why deterministic.
A suggestion that changes from one day to the next, or from one clinician to the next, cannot be relied on and cannot be reviewed. Breeze's decision support is deterministic: the same record produces the same suggestions, every time, from rules written down once. That makes suggestions something a practice can govern: review the rule, change it, publish the change, and know that every clinician sees the new behavior at the same moment.
It is also fast. The rule engine holds the practice's rules compiled in memory and re-evaluates only what a change touches, so a suggestion follows a keystroke by milliseconds rather than a page reload. The engineering behind that is on the platform site.
Authoring rules.
Until now a practice's rules have been authored from example visits: build the visit the way it should look, and the items in it become suggestions tied to their triggers. That keeps the familiar item editors but ties rules to the encounter they came from and makes them hard to find and compare.
The new rule editor, built and reaching practices as they move to the new version of the clinical application, keeps the item editors and changes the rest. A clinician writes the rule the way they would say it, as a sentence with blanks: when an encounter's diagnosis is in [a value set], in [this section], suggest [this item]. Each blank offers only what makes sense for that part of the record. Rules are named, grouped in modules the practice owns, searchable by what they read and what they suggest, and published as releases distinct from drafts. Adding a condition splits a rule into visible cases, with and without, so nothing is narrowed by accident.
In the note, every suggestion has an information button that opens the rule behind it, and when several rules suggest the same thing the clinician sees one suggestion. A practice can copy a shared set of rules, change its copy, and send its changes back to the set's owner for review.
Where language models fit.
A language model is the right tool when the work is open-ended: reading a long history before a visit, drafting a section, summarizing a conversation, answering a question nobody wrote a rule for. Its draft goes to the clinician for review before it becomes part of the record. Rules and models are being brought into daily work on the same platform, under the same permissions, with a person deciding what a model proposes. A model can draft; rules keep watch.