Computer-Interpretable Guideline¶
A clinical-guideline knowledge artifact that formally links patient conditions and decisions to recommended actions or plans for computational interpretation.
Core Idea¶
A computer-interpretable guideline (CIG) is a clinical-guideline knowledge artifact whose patient conditions, decisions and recommended actions or plans are specified in a form software can interpret for a case. A clinical recommendation is the content being represented; a GLIF3 step network or an Asbru plan hierarchy is the formal artifact. The artifact can exist before it is connected to a local electronic health record (EHR), run on a real patient or shown to improve care.[1][2][3]
Formalization exposes which patient facts matter and what recommendation follows under specified conditions. It need not remove every judgment left to a clinician. The InterMed authors distinguish decision criteria that can be evaluated from patient data from choices left to a user when safety or unspecified knowledge matters. Their 2004 review rates one encoded chronic-cough guideline intermediate in computability.[4][1]
Structural Signature¶
Signature: identifiable clinical guidance → formally represented patient state or eligibility → interpretable decision or plan relation → linked recommended action → a convention for reading those parts as a case-level guideline. Local record binding, evidence trace and institutional adaptation may be added, but they are not required of every CIG.[1][2][3]
- Guidance source. A clinical guideline or protocol supplies the problem and the intended recommendations. Encoding it does not independently prove those recommendations clinically correct.[1][4]
- Patient-case condition. An encoded state, observation or plan filter identifies when a step applies. A human-readable topic label without interpretable case criteria is insufficient.[4][3]
- Decision or selection. A formal relation connects relevant conditions to alternatives, actions or plan choices. It may include a clinician choice instead of complete automation.[4][3]
- Recommended action or plan. The artifact represents what the source guidance calls for, with ordering or timing where its formalism and example specify them.[4][3]
- Interpretation medium. Linked GLIF3 steps and Asbru plans use different structures; their shared role is to make the condition-to-recommendation relation available for computational reasoning.[2][3]
What It Is Not¶
A narrative guideline, software-neutral requirements document or flowchart with only prose labels is not yet shown to be a CIG. An isolated alert rule is not automatically a multistep guideline encoding; the InterMed review distinguishes Arden medical logic modules from task-network guideline models. Conversely, a decision-support engine without encoded clinical knowledge is software infrastructure rather than the guideline artifact.[1]
WHO's level-two Digital Adaptation Kits (DAKs) organize recommendations as software-neutral requirements. That is useful preparation, but a DAK alone does not establish an inspected formal condition-and-action artifact. A later formal logic implementation would have to be examined on its own terms. Local EHR integration and evidence links can make a CIG more deployable or auditable without defining every instance.[5][1]
Scope of Application¶
In a GLIF3 chronic-cough encoding, the authors give a patient-state criterion for cough persisting over three weeks: latest_cough_end_time >= now and latest_cough_start_time < (now – 3 weeks). The timestamp variables are defined through Get_Data actions linked to patient-data concepts in a domain ontology. The authors also show a conditional source recommendation represented in GLIF: when cough is productive, order four-view sinus radiographs before beginning postnasal drip syndrome (PNDS) therapy. This is a historical guideline representation, not current clinical advice. Their example does not show that this particular branch was automatically evaluated on a patient.[4]
In an Asbru newborn-hyperbilirubinemia encoding, the authors instead describe a hierarchy of time-oriented skeletal plans. Guideline and treatment-step eligibility can be expressed as plan filter conditions; diagnostic information can be a treatment condition or an explicit diagnostic plan; treatment choices select among applicable plans, whose conditions can govern starting, aborting or completing them. The accessible original abstract and publisher previews support this plan-level map, not a particular bilirubin cutoff, patient execution or treatment effect.[3]
Clarity¶
The condition, choice and action should be named separately. In the cough case, the three-week expression is an explicit eligibility example. The productive-cough clause and imaging-before-therapy order are a represented conditional recommendation. The 2001 paper's distinction between case steps that can evaluate criteria from patient data and choice steps left to a user describes GLIF3's model; it does not identify the PNDS branch as fully automated. The 2004 review's “intermediate” label applies to the broader chronic-cough encoding.[4][1]
Asbru fills the same roles with filters and plans rather than a GLIF3 step network. No universal passage through a narrative, semi-formal and fully executable sequence follows from these two formalisms. Boxwala and colleagues describe conceptual, computable and institution-specific implementable specifications within GLIF3, and describe the last as a specification layer, not proof of a completed installation for this cough case.[2][1]
Manages Complexity¶
The artifact separates a source recommendation from its formal case conditions, control relations and clinical actions. This makes it possible to ask which part supplies a patient fact, which part selects or leaves a choice, and which part states the recommendation. A readable diagram can help a human author, but labels alone do not supply the computational criteria. The InterMed authors report that earlier GLIF2 step attributes were unparsed text and could not support automatic inference simply by appearing in a flowchart.[1][4]
GLIF3 allows a nested chronic-cough subguideline structure; the 2004 review's Figure 2 contrasts a flat flow with a nested version containing three action steps as subguidelines. Asbru manages a different form of complexity through a hierarchy of plans and temporal conditions. These are concrete design choices, not requirements that every CIG share one syntax or level of executable detail.[1][3]
Abstract Reasoning¶
Consider the cough criterion as a formal test of represented patient timestamps. If the encoded end time is at least the current time and the start time is more than three weeks earlier, the expression as written is satisfied. The published example establishes the expression and its data-item links; it does not establish what a particular EHR would return, how missing values would be handled in that installation, or whether the later PNDS branch is a machine-run case step.[4]
The Asbru case makes the same structural separation without using that expression. A plan filter may represent eligibility, selection chooses among treatment plans, and plan conditions describe how a selected course proceeds or ends. If the eligibility-to-plan relation were removed, a timed list of possible treatments would no longer encode patient-specific guidance in the sense used here.[3]
Knowledge Transfer¶
To test another proposed CIG, trace one concrete source recommendation into a represented patient condition, a decision or plan relation, and a linked action. State which parts are formally interpretable, which require clinician judgment, and which have only been proposed for later local implementation. Then check the original work's level of inspection: an abstract about a formalism cannot establish every branch of a worked clinical case.[1][4][3]
The GLIF and Asbru examples show that the role pattern can survive a change of clinical setting and formal representation. They do not establish equivalent clinical effectiveness, universal terminology binding, per-element provenance, safe deployment or a common threshold convention. Those require separate evidence in each new setting.[2][3]
Examples¶
Chronic cough in GLIF3. Peleg and colleagues give the exact cough-over-three-weeks expression and specify how Get_Data variables link to patient data definitions. Their Figure 2 represents a productive-cough recommendation that imaging precede PNDS therapy. The related 2004 review places chronic cough among outpatient diagnosis-plus-management guidelines spanning multiple encounters and classifies its computability as intermediate. The case therefore shows a formal condition and linked action, not a claim that all branches ran in an EHR.[4][1]
Newborn hyperbilirubinemia in Asbru. Seyfang, Miksch and Marcos use an identified newborn guideline to model diagnosis and treatment with plan filters, treatment selection and time-oriented plans. Diagnosis can be embedded as treatment conditions or made into diagnostic plans. The original abstract and accessible publisher previews do not warrant a numerical treatment threshold, a particular patient trace or a clinical outcome.[3]
Structural Tensions¶
The sources motivate a practical design question without proving a universal trade-off. A conceptual flowchart helps human comprehension; formal conditions and data definitions support case interpretation. The 2001 GLIF3 paper treats expressiveness and comprehensibility as development requirements and distinguishes this development task from later implementation, use and maintenance. More of one property does not, on the inspected evidence, necessarily reduce the other.[4]
A second scope diagnostic concerns incompletely specified clinical decisions. The GLIF3 authors provide case steps for criteria evaluated from data and choice steps for judgments reserved to a user. For each encoded step, ask whether the stated patient data support automatic evaluation or whether safety or unspecified knowledge leaves a clinician choice. Formalizing one eligibility expression does not establish an intrinsic opposition between specificity and discretion, or that every later clinical choice can or should be automated.[4]
Structural–Framed Character¶
Vocabulary travel: “guideline,” “workflow,” “rule” and “decision support” can all describe nearby things, but the named artifact here combines represented patient conditions with linked clinical recommendations. Evaluative weight: calling an encoding computer-interpretable does not validate its medicine, fidelity or clinical benefit. Institutional origin: GLIF3 and Asbru emerged from clinical informatics work on making guidelines sharable and reasoned over, while local record interfaces remain additional work.[1][2][3]
Human-practice dependence: clinicians and guideline authors supply, interpret and sometimes choose among recommendations; formal encoding does not remove that role. Import versus recognition: an observer should recognize a CIG only by inspecting the condition-to-action map, not by importing the label from a software product, a WHO programme or an executable engine. Structural–framed placement: mixed-structural: the formal condition-to-action relation is structural, while the clinical guideline target and acceptable interpretive scope depend on human and institutional judgment. Its character: it is a domain-specific formal representation artifact whose interpretation is bounded by its clinical source and stated computability.[4][5]
Structural Core vs. Domain Accent¶
The core is an identifiable clinical recommendation represented through patient-case conditions, decision or plan relations, linked actions and a machine-interpretable convention. Chronic cough, a three-week expression, PNDS imaging, neonatal hyperbilirubinemia, GLIF step types and Asbru plan filters are accents of the two source cases. Remove those particular diseases or syntaxes and the same clinical-representation identity may remain; remove the formal condition-to-recommendation link and it does not.[4][3]
The portable act of representing a target in another interpretable medium belongs to the live Representation Prime, which is the reviewed strict parent. The clinical condition/action content and guideline purpose make this child narrower. A wider Prime claim for CIG itself would require independent nonclinical instantiations of its full signature, which these clinical sources do not supply. EHR deployment and clinical outcome remain separate questions.[1][2]
Instantiates / Related Primes¶
This entry is a kind of Representation.
- Representation — strict parent. The reviewed child-to-parent subsumption captures the guideline source, formal medium, mapped conditions/actions, interpretation convention and case-level use. Representation also includes many nonclinical artifacts.
- Knowledge Representation and Reasoning — neighboring discipline. It studies representations and inference, whereas this entry identifies a particular encoded clinical artifact.
- Rule-Based System — neighboring implementation. Some guidance can be run in a rule system, but an Asbru plan or GLIF model need not already be an operating rule-application system.[1][3]
- Best Practice — neighboring evaluation. Being formally encoded does not prove a recommendation best or effective.
- Point-of-Care Medical Information Summary — neighboring reference. A maintained human-consulted summary does not itself establish formally interpreted patient-case logic.
- Formal Language — encoding resource. GLIF3 and Asbru supply distinct structures; a syntax is not the particular guideline artifact it can encode.[2][3]
Relationships to Other Abstractions¶
Current abstraction Computer-Interpretable Guideline Domain-specific
Parents (1) — more general patterns this builds on
-
Computer-Interpretable Guideline is a kind of Representation Prime
A computer-interpretable guideline represents clinical recommendations in a formal medium that supports patient-case reasoning.Every admitted computer-interpretable guideline has clinical guideline or protocol content as its target, an encoded step or plan structure as a distinct medium, a mapping from source conditions and recommendations into that structure, a bounded commitment to preserve their decision or plan relation, an interpretation convention, and operational use for computational reasoning about a patient case. GLIF3 and Asbru realize these roles differently. Representation also includes nonclinical maps, models and diagrams, so the child is strictly narrower. This edge does not assert flawless fidelity or completed deployment.
Hierarchy path (1) — routes to 1 parentless root
- Computer-Interpretable Guideline → Representation → Abstraction
Neighborhood in Abstraction Space¶
Computer-Interpretable Guideline sits in a sparse region of the domain-specific corpus (97th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.
Family — Unclustered & Miscellaneous (2551 abstractions)
Nearest neighbors
- Rule-Based System — 0.80
- Spectrum Bias — 0.78
- En ventre sa mere — 0.77
- Drug Repositioning — 0.76
- Blood Culture — 0.76
Computed from structural-signature embeddings · 2026-10-08
Not to Be Confused With¶
The historical chronic-cough imaging instruction is an example of represented source text, not patient advice. Neither its encoding nor the newborn plan example proves clinical efficacy. A software-neutral DAK, a single alert, a diagram without formal case criteria, and an engine without encoded guidance each lacks some identity-bearing role. A CIG can still be partial: the original cough model is rated intermediate, and a clinician choice can remain part of the formal workflow.[4][1][5]
References¶
[1] Mor Peleg, Aziz A. Boxwala, Samson Tu, Qing Zeng, Omolola Ogunyemi, Dongwen Wang, Vimla L. Patel, Robert A. Greenes, and Edward H. Shortliffe, The InterMed Approach to Sharable Computer-interpretable Guidelines, A Review, Journal of the American Medical Informatics Association 11(1) (2004), 1–10, DOI 10.1197/jamia.M1399. The printed title uses a colon before “A Review.” Original author full text, especially “A Shared Guideline Modeling Language,” Table 1, Figure 2, “The Relationship between GLIF and Other Guideline Formalisms,” and Conclusions. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p
[2] Aziz A. Boxwala et al., GLIF3, a representation format for sharable computer-interpretable clinical practice guidelines, Journal of Biomedical Informatics 37(3) (2004), 147–161, DOI 10.1016/j.jbi.2004.04.002. The printed title uses a colon after “GLIF3.” Original article abstract inspected; its three specification levels are not evidence of this chronic-cough case's completed local deployment. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h
[3] Andreas Seyfang, Silvia Miksch, and Mar Marcos, Combining diagnosis and treatment using ASBRU, International Journal of Medical Informatics 68(1–3) (2002), 49–57, DOI 10.1016/S1386-5056(02)00064-3. Original article abstract and publisher section previews inspected; full article pages and exact numerical thresholds were not independently checked. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p
[4] Mor Peleg, Aziz A. Boxwala, Samson Tu, Robert A. Greenes, Edward H. Shortliffe, and Vimla L. Patel, Handling Expressiveness and Comprehensibility Requirements in GLIF3, MEDINFO 2001, Studies in Health Technology and Informatics 84(Pt 1) (2001), 241–245, DOI 10.3233/978-1-60750-928-8-241. Original author-uploaded full text inspected through indexed text; direct PDF open was unavailable. Printed pp. 242–243 “Definitions, recommendations, and algorithms” and Figure 2 provide the chronic-cough expression and represented PNDS recommendation; pp. 243–244 “Representing decision-support guideline tasks” distinguish case from choice steps. Original PubMed record confirms work identity. registry ↩a ↩b ↩c ↩d ↩e ↩f ↩g ↩h ↩i ↩j ↩k ↩l ↩m ↩n ↩o ↩p
[5] World Health Organization, SMART Guidelines, Digital Adaptation Kits, Implementation research and technical support, official WHO project brief, 6 February 2022, Overview. The printed web title uses a dash and a colon; the linked title uses commas to give the citation binder a full, parseable title basis. The page describes level-two DAKs as software-neutral structured documentation, used here only as a boundary source. registry ↩a ↩b ↩c