Building Configurable Order Sets Without Breaking Care

I do not trust the phrase “make it configurable” until someone tells me what is allowed to vary, who can vary it, and what happens when they do it badly.

That is the whole game with order sets and clinical templates inside an EMR. Everybody asks for flexibility. What they usually need is controlled variability. Those are not the same thing, and mixing them is how you end up with a beautiful interface that quietly produces garbage orders.

In the systems I work on, the hardest part is not rendering the template. It is deciding where the source of truth lives. If the template decides the workflow, the order composer, the default doses, the required documentation, the payer-facing body site, and the departmental routing, then one bad edit becomes a platform incident. I have seen teams treat these artifacts like static OBY forms. That works right up until a clinician copies a set, changes one line, and every downstream rule still thinks it is the original.

When I say executable, I mean it in the practical sense. A template has to drive UI behavior, but it also has to drive clinical behavior. That means we need clear fields for default orders, conditional sections, required attestations, instruction text, discrete mappings, and suppressed fields. If a template says “chest pain”, the system should know whether that means a rule-based set of labs, a nursing triage section, a diagnosis-specific note block, and a pathway for escalation. If those pieces live in disconnected config tables, nobody can reason about the result on the floor.

One mistake we made early was letting specialty stakeholders edit everything they could see. Everyone loved the freedom. Then usage got weird. One group buried a required medication under optional guidance text. Another copied an existing set because it was “close enough” and never noticed the problem list mapping was wrong. The template looked correct in review, but the clinical workflow downstream was off by one invisible assumption. That is the kind of error you do not catch with a prettier editor. You catch it with tighter data structures and less permission to improvise.

The architecture I prefer is boring on purpose:

1. Separate content from behavior Keep the display text, the order payload, the validation rules, and the workflow triggers as distinct objects. If the same JSON blob carries all four, you will regret it the first time one field changes and the rest do not.
2. Version everything that can affect care A signed-off order set is a snapshot. The active clinical behavior must always point to a version, never to a mutable draft. That lets you audit what was live when an order was placed.
3. Use controlled inheritance Build a base set once, then allow child variants to override only approved fields. I do not allow arbitrary copy-and-edit without diffs. That is how quiet divergence starts.
4. Validate before publish Run rule checks for missing required elements, duplicate labels, unmapped codes, invalid dose units, and broken routing paths. Publish should fail loudly if a discrete field cannot resolve.
5. Measure drift after launch A set that is used differently than intended is a bug, even if no one reported it. Review edit frequency, abandonment, missing field overrides, and copy rates by specialty.

The validation step is where a lot of vendors are too soft. They validate for syntax, not for clinical intent. A set can be syntactically clean and still be clinically nonsensical. I care about whether the artifact can survive the real workflow: a rapid intake, a nurse pre-pend, a provider interruption, and an order sign-off that happens ten seconds earlier than the template designer expected.

That problem shows up a lot in specialty documentation. A template that asks for everything on every visit is not thorough. It is punishing. The right answer is conditional sections tied to definitely known context: encounter type, diagnosis family, location, provider role, and whether a prior result exists. If a field should only appear after a nurse triage flag or a diagnosis code is selected, wire that dependency into the configuration engine. Do not fake it with visibility rules in the front end alone.

At AST, I like to start with the clinical pathway, not the screen. We map the decision tree first, then identify which parts belong in an order set, which belong in a template, and which belong in a shared library. That sounds obvious until someone tries to build the UI first because it is visible. I have seen that movie. It ends with a nice-looking editor and a support queue full of “why did this set place the wrong order?” tickets.

If you are building this in an existing platform, your integration edges matter as much as your editor. In Epic, Cerner/Oracle Health, athenahealth, PointClickCare, and homegrown EMRs, the real trouble is mapping configurable clinical objects into whatever the platform uses for discrete orders, smart phrases, tasking, and routing. HL7v2 feeds, FHIR R4 resources, and internal APIs all express different pieces of the same truth. Your template engine needs to know which source wins when the same concept exists in three places.

This is one of the places where AST’s EMR platform work becomes very concrete. We have had to modernize legacy order workflows where the old system stored note text, order definitions, and display labels in partially overlapping tables. That design survives a demo. It does not survive a live specialty practice with multiple administrators editing different parts of the same care pathway. We have also seen the opposite: over-normalized models that made every small authoring change require a database migration. That is just another way to tell clinicians they have to wait on engineering for routine clinical maintenance.

The sweet spot is a configurable model with hard boundaries. Clinical admins should be able to change wording, sequence, optional sections, and approved default order contents. They should not be able to change code mappings, billing semantics, or workflow triggers that power downstream decision support without review. Those changes need guardrails, approvals, and rollback paths. If you do not separate those layers, then every “simple” update becomes an untracked clinical change request.

When I review an EMR build for order sets and templates, I ask four questions:

• Can I tell exactly which version of this object was active when an order was placed?
• Can I see what changed without reading the entire template from top to bottom?
• Can a specialty user safely modify content without breaking discrete mappings?
• Can the system explain why a field appeared, disappeared, or defaulted the way it did?

If the answer to any of those is no, the product is still pretending to be configurable.

There is also a governance piece most teams delay too long. You need ownership by clinical domain, but you also need an engineering gate for structural changes. I do not mean a heavy process for every text edit. I mean a clear distinction between content changes and schema changes. If a template editor can accidentally change the object model, you have put the platform at the mercy of whoever clicks fastest.

For teams that want to get serious this week, I would start here:

1. Inventory every active set and template Find duplicates, near-duplicates, and “temporary” copies that somehow became permanent. These are where drift hides.
2. Classify each field Tag fields as display-only, required clinical data, routing input, decision-support input, or billing-relevant. You cannot govern what you have not classified.
3. Separate edit permissions by layer Let clinical users edit what they should own, and lock the structural pieces behind approval.
4. Add publish-time validation Refuse to activate any object with broken mappings, unresolved references, or conflicting defaults.
5. Build a rollback path first If a bad template version goes live, you should be able to revert without duct tape and after-hours heroics.

The great misconception is that configuration means speed. It does not, not by itself. Configuration only helps if the system can absorb change without producing ambiguity. A configurable order set that is impossible to audit is worse than a hardcoded one, because it gives everyone false confidence.

That is why I push versioned clinical objects, controlled inheritance, and editor tooling that exposes structural risk. It is not glamorous. It is the work that keeps the care team from discovering a broken default halfway through a shift.

If you want this done right, the platform has to respect three realities at once: clinicians need speed, administrators need control, and the engine needs determinism. Miss any one of those and the whole thing becomes theater.

At AST, this is exactly the kind of platform work we do inside real clinical environments. We have built EMR workflows where the editor, the validation layer, and the downstream integration logic all had to agree before a set could go live. That is the only way these tools stay useful after the first three rounds of feedback.

If you are building configurable clinical content, do not ask whether users can edit it. Ask whether the system can defend it.