- Overview
- Medical Record Summarization
- About Medical Record Summarization
- Roles and permissions
- A template's lifecycle
- Create a template
- Edit a template
- About policies
- Create a policy
- Edit a policy
- Refining decision model rules
- Deploy a template
- Send documents for processing
- Review a summary
- Medical Record Summarization (MRS) output data
- Manage deployments
- Manage review workflows
- Customize application appearance
- Experimental features
- Template sections reference
- Policies reference
- Clinical review reference
- System components
Guidance for refining a policy's decision model in Medical Record Summarization, covering evaluation qualifiers, gated conditions, field instructions, and outcome exclusivity.
The decision model the AI extracts from a policy document is a starting point rather than a finished rule tree. This page covers the build decisions that determine whether the model evaluates the way the policy intends.
For what each element of the tree is, see Policies reference. For the procedures, see Edit a policy.
Choosing an evaluation qualifier
Each rule group's qualifier determines whether the group can resolve at all, not only how strict it is.
| Qualifier | When to use it |
|---|---|
| All are required | Conditions that must all hold at the same time for a single real case. Keep alternative and conditional provisions out of the group: if two items can never both be true for one case, a group requiring both can never resolve true. |
| Any 1 is required | Genuinely alternative conditions, that is, different routes to the same outcome. For example, linkage explicitly documented, or an objective marker threshold met. |
| First match | A real hierarchy among conditions, where the most specific or most severe case is checked first and more general cases apply only if it does not. Order changes the result here, unlike Any 1 is required. |
Requirements within a condition, or separate conditions in a group
A single condition can carry more than one requirement, and all of them must be true for the condition itself to be true. That is a native way to express AND logic, not a workaround.
Each approach fits a different situation:
- Requirements stack inside one condition when they share a single citation or rationale.
- Separate conditions under a rule group are the better fit when they come from distinct provisions, when OR logic or ordered evaluation is needed between them, or when each needs its own citation.
Applies when gates
Some provisions only make sense for a subset of cases. A condition specific to postprocedural sepsis, for example, should apply only when the case is postprocedural at all.
That qualification belongs in the condition's Applies when gate, not in an additional requirement. Conditional language in the source text, such as if, unless, or should be queried, is a signal that the provision belongs behind a gate instead of in an unconditional chain.
Writing field instructions
Every field's instruction should state what happens when the record does not address the question at all, since silence must resolve to a defined value. The same silence-handling logic should be expressed consistently across related fields, so that explicitly ruled out and never addressed never collapse into the same value. Two related boolean fields, such as Linkage documented and Linkage ruled out, should use opposite defaults for a silent record, not the same one.
Keeping outcomes mutually exclusive
Outcome groups must be mutually exclusive by construction. Nothing enforces this automatically: if two outcome groups can both evaluate true for the same case, the case resolves to an undefined outcome rather than to either of them.
Exclusivity is guaranteed by building every outcome group from the same underlying fields, with opposite or non-overlapping value combinations across groups. If Validated requires Field A to be yes, Not validated should require Field A to be no on that same field, rather than an independently invented condition. Outcome groups that reuse the same fields symmetrically cannot overlap.
Source text
Source text exists for citation and traceability, showing a reviewer which part of the policy document a condition came from. It does not feed extraction and has no effect on evaluation. Editing it changes what a reviewer sees, not how the condition behaves. Only requirements and qualifiers affect the result.