Clinical Indication Criteria¶
Clinical protocol — instantiates Domain–Codomain Delimitation
Defines which patients, conditions, and timing an intervention is valid for — and the contraindications and preconditions that place a case outside it — so a treatment isn't given where it was never indicated.
Clinical Indication Criteria bound the input domain of a specific medical intervention: the conditions it treats, the patient populations it is validated for, the timing window in which it works, and — as sharply as the inclusion side — the contraindications that put a case out of domain and the preconditions that must be confirmed before it is even offered. What distinguishes it from its siblings is that the boundary is defined in clinical terms and carries an asymmetric risk profile: applying the intervention to an out-of-domain patient can cause direct harm, so the criteria weight exclusion and precondition-checking far more heavily than a permissive software boundary would. It answers "for whom, when, and only if what is true," and it says nothing about output structure — only about who may validly enter.
Example¶
A thrombolytic drug that dissolves clots is indicated for acute ischemic stroke, but only inside a narrow therapeutic window — roughly the first few hours after symptom onset — and only once a scan has ruled out a hemorrhagic stroke, for which the same drug would be catastrophic. The Clinical Indication Criteria make each of these operational: the condition (confirmed ischemic stroke), the timing (onset within the window, which requires knowing when the patient was last well), the population (adult, no recent major surgery or active bleeding), and the hard precondition (non-contrast CT excluding hemorrhage). A patient who wakes with symptoms of unknown onset time falls into the unsupported region — not "denied care," but out of domain for this intervention — and the criteria route the decision rather than defaulting to treat. The boundary is doing exactly the job the archetype asks of it: keeping a powerful tool off the cases it was never valid for.
How it works¶
The criteria decompose the boundary into inclusion axes (diagnosis, timing, population), a set of absolute and relative contraindications that mark the unsupported region, and preconditions — tests or confirmations that must be true before invocation, not assumed. Each axis is written to be checkable at the bedside, often as a checklist, so that "indicated" is a determination anyone on the team can make and defend, not a judgment call. Relative contraindications create a graded boundary where the decision escalates rather than resolves automatically.
Tuning parameters¶
- Window width — how wide the timing/eligibility window is set. Wider reaches more patients but includes cases with a worse risk-benefit balance; narrower is safer but excludes patients who might still benefit.
- Absolute vs. relative contraindications — how many exclusions are hard bars versus judgment calls. More absolutes make the boundary crisper and safer but less individualized.
- Precondition strictness — which confirmations are mandatory before invocation (e.g., imaging). Stricter preconditions prevent catastrophic misuse but add time, which itself can be harmful in time-critical care.
- Population specificity — how tightly the validated population is drawn (age, comorbidity, pregnancy). Narrow specificity is defensible but leaves more patients formally off-label.
When it helps, and when it misleads¶
Its strength is that it prevents a genuinely useful intervention from being applied where it harms, and it makes the timing-and-contraindication boundary explicit enough to teach, audit, and defend. Its failure modes are two-sided: criteria set too tight leave treatable patients excluded, while criteria treated as a bureaucratic gate invite off-label use — applying the intervention outside its indicated domain on the strength of a plausible analogy, exactly the misuse the boundary exists to prevent.[1] Criteria also go stale as evidence changes, so a window or contraindication that was correct at publication can silently become wrong. The discipline is to pair the criteria with a defined escalation path for borderline and out-of-domain cases (rather than a reflexive yes or no) and to revise them on a schedule as trials update the evidence.
How it implements the components¶
input_domain— specifies the conditions, populations, and timing for which the intervention is valid: who and when may enter.membership_criteria— turns that domain into bedside-checkable inclusion axes a clinician can apply and defend.unsupported_case_boundary— the contraindications and out-of-window cases that explicitly mark a patient as out of domain for this intervention.precondition_statement— the confirmations (e.g. ruling out hemorrhage) that must hold before the intervention is invoked at all.
It bounds only the input side; the structure of what the intervention outputs is not its concern, and the routing of contraindicated or borderline patients to alternatives, escalation, or appeal belongs to Unsupported Case Triage Workflow.
Related¶
- Instantiates: Domain–Codomain Delimitation — the criteria are the clinical statement of an intervention's valid input domain.
- Consumes: an imaging or lab result supplies the precondition confirmations the criteria require.
- Sibling mechanisms: Unsupported Case Triage Workflow · Eligibility Criteria · Input Validation Gate · Model Applicability Card · Scope Change Review · Service Scope Statement · Type Signature · Output Schema · Output Validation · Contract Test Suite
References¶
[1] Off-label use — applying a drug or device outside its approved indications (condition, population, dose, or timing). It is legal and sometimes appropriate under clinical judgment, but as an unexamined default it is precisely the "used outside where it was defined" failure the indication boundary is built to make visible. ↩