The same suggestion, every time.
Some help should be deterministic. When a diagnosis is entered, the suggestions that appear should be the same for every clinician, every time, with a reason that can be shown and a version that can be reviewed. Breeze runs a rule engine alongside the record for exactly that, and it answers in milliseconds as the note is written.
Language models have their place too: reading a long history, drafting, summarizing, answering a question nobody wrote a rule for. 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.
A new rule editor, now in design, will let 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.
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.
Today a practice's rules are 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 rule editor now in design 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.
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.