Representing Clinical Guidelines and Protocols On a Semantic Web Framework

Semantic Web for Healthcare and Life Sciences Interest Group Note 20 Februry 2007

This version:
Latest version:
Previous version:
Helen Chen, Agfa Healthcare
Chimezie Ogbuji, The Cleveland Clinic
Davide Zaccagnini, Language and Computing
Also see Acknowledgements.


Clinical guidelines and protocols contain medical and operational knowledge that promotes the usage of evidence and best practices in medicine. It has been envisaged that the medical and operational knowledge in the guidelines and protocols can be distributed on an open, standard-based platform, so a clinical information system can integrate the most up-to-date guidelines and protocols seamlessly in its decision support functions. This document describes the experience in the HCLS Interest group to use semantic web technology, including RDF, OWL and Logic Programming Rules to represent clinical guidelines and protocols. A generic declarative process-oriented model is proposed. Formal relationship between processes and other situational constraints, such as context, goals and inclusion/exclusion criteria are explicitly expressed using OWL semantics or logic programming rules.

Status of this Document

This note is a Technical Report Working Draft, produced by the Semantic Web Healthcare and Life Sciences, part of the W3C Semantic Web Activity. This document presents a basic model for representing clinical guidelines using semantic web technology for clinical decision support systems. It is a technical report on experiences gained by the HCLS Interest Group's Adaptable Clinical Pathways and Protocols task force.

Publication as a Interest Group Note does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. This document is informative only. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Table of Contents

  1. Introduction
  2. Use case examples
  3. Representation patterns
    1. Vocabulary for n-ary relations in RDF and OWL
    2. Pattern 1: Introducing a new class for a relation
      1. Use Case 1: additional attributes describing a relation
      2. Use Case 2: different aspects of the same relation
      3. Use Case 3: N-ary relation with no distinguished participant
      4. Considerations when introducing a new class for a relation
    3. Pattern 2: Using lists for arguments in a relation
  4. N-ary relations and reification in RDF
  5. Additional Background
    1. Note on vocabulary: Relations and instances of relations, Properties and Property instances
    2. Anonymous vs named instances in these patterns
    3. Notes
  6. References
  7. Changes
  8. Acknowledgements


Clinical guidelines and protocols are a collection of processes to be executed in a clinical environment, either by information systems, or by care-givers of healthcare, i.e. physicians, nurses. There are currently at least two approaches to the programmatic specification of processes. The first is the prospective enumeration of sequential steps, with boolean branch points based upon axiomatic logic applied to state variables. It is called the "procedural approach". The second approach specifies tasks, the antecedent conditions necessary for their activation, and dynamically allocates tasks when the appropriate requisite conditions met. This approach is the base for the "descriptive" approach. Either approach can be applied both to the sequence of logical steps while making medical decision (often by a single individual), and to the sequence of process execution steps that occur during healthcare service provision (often by multiple individuals).

Significant effort has been devoted to represent clinical guidelines and protocols in a machine-executable and interoperable format [1]. The adaptation of these frameworks has not moved beyond their development environments. The high cost of translating the text-based guidelines to a machine-executable format and the requirement of a specific proprietary guideline execution engine have hindered the wider adaptation of existing computerized guideline systems, and the reusability of computerized medical knowledge. Furthermore, the latency of updating guidelines to reflect new discovery and evidence from medical sciences and clinical trials reduce the usability and credibility of the published guidelines and protocols.

Many have envisaged a new healthcare era when the clinical guidelines and protocols are published in an open, standard-based, computer-interpretable and executable format[2]. In such environment, the published guidelines and protocols can be the seamlessly integrated with clinical decision support systems to generate care tasks for individual patients. The reasoning engine finds the most appropriate next task based on a patient's condition and guidelines or protocols, argumented by applying relevant business rules and other scheduling constraints such as availability of equipments and personnels. Any change to the knowledge base (i.e. update of guidelines, protocols), or change of the status of current process (i.e. completed, aborted, suspended, replaced by) associated with the patient, or a change in the patient clinical condition will trigger a new round of reasoning, in order to make a new recommendation for the next task in the patient's care plan, as shown in Figure 1. Such personalized care plan reflects the patient-specific information and incorporate the up-to-date medical evidence. We call guidelines and protocols published in such new format "Adaptable Clinical Guidelines and Protocols" (ACPP).

Figure 1 Personalized Care Plan Based on Adaptable Clinical Guidelines and Protocols

As one of the task forces at the Semantic Web for Healthcare and Life Sciences Interest Group (HCLSIG) [3], the ACPP task force [4] explores the benefit and practicality of using semantic web technology, including Resource Description Framework (RDF) [5], Web Ontology Language (OWL) [6] as the standard-based, distributed, open platform for representing computer-interpretable, exchangable and enactable clinical protocols and guidelines. More specifically, we investigate how semantic web technology can be used to address the following key aspects in the representation of computerized guidelines and protocols:

Clinical guidelines and protocols present a (somewhat) unique requirement on knowledge representation.  In particular, one of the primary takeways from the work done by this task group was the determination that neither Description Logics (DL) nor Logic Programming by themselves are sufficient for expressing clinical guidelines and protocols.  A combination of both is necessary to capture (respectively) taxonomic patterns & inference as well as representations & inference more closely aligned with First Order Logic Description Logic Programs [10] are a combination of both that accommodates expressivity and computational restrictions with both knowledge representations and an appropriate foundation to express clinical guidelines and protocols with.

This note presents the ACPP model proposed by the ACPP task force to represent computerized clinical guidelines and protocols.  The ACPP model is a declarative model that takes a patient-centric view of representing guidelines and protocols.  It uses semantic web technology as its underpinning execution framework.  This note does not cover "temporal relationship" nor "variance" as these work are still at the initial stage, which will be the focus of the task force in 2007.

Use case examples

The National Guideline Clearinghouse (NGC) uses a set of controlled vocabulary to categorize the published clinical guidelines and protocols [11].  The three guidelines we identified as use cases for our investigation combine diagnosis, treatment, risk assessment, screening.  Each contains elements and patterns that pose as challenges in knowledge representation or semantic web reasoning.
In most guidelines, there are situations where decision is made based on a patient's conditions.  These conditions could be the patient's current or past clinical conditions, demography, or living/care environments.  During the reasoning and execution of guidelines, such information can be extracted from enquiries made to the patient or the respective electronic patient information systems (EPR).

However, when modeling such decision step in ACPP, we assume there is a generic Medical Domain Ontology (MDO) that is agnostic to a particular EPR system. The SAGE project [13] called for a similar concept, with the name "virtual EPR".  As of the writing of this document, the consenus is we do not have such a MDO yet, although a number of distinguishing standards do exist, such as HL7 RIM [14], OpenEHR[15] and Galen [16].  Detail discussions on the requirements of this MDO, or building such ontology are out of scope for the ACPP task force, therefore out of scope for this note.  We will use the initial framework proposed by Chimezie Ogbuji [15] to express concepts related to a patient's condition.     

2.1 ER Stroke Management

Figure 2 shows a protocol used in a ER for applying thrombolysis to the first time stroke patient.  The exception handling steps are omitted.  The sequence of steps is of great importance in this setting, thus need to be specified explicitly and followed-through during the care process.  This is an example of "pre-defined" workflow type of protocols.

Execution of this procedural protocol requires handling of some basic control patterns, such as sequential, parallel split and synchronization.  If the exception handling routines are included in this protocol, we will have to deal with other control patterns, such as exclusive choice and more advanced branching and syn chronizaion patterns [12].  Using this protocol, we test if the ACPP model can handle these known control patterns properly, without having to annotate them in a pre-fixed fashion.

Figure 2 ER Stroke Management Protocol

Goals in the ER stroke management Protocol

Initial triage has_goal(15 minutes, deficit assessed)


Thrombolysis eligibility assessment has_goal(15 minutes, eligibility assessed)


Confirmation of acute stroke has_goal(30 minutes, acute stroke confirmed)


CBC PT PTT has_goal(30 minutes, measure CBC, PT, PTT)


Emergent head CT has_goal(60 minutes, investigate presence of hemorrhage)


STAT radiology read has_goal(15 minutes, confirm exclusion of hemorrhage)


Physician notification with head CT results has_goal(5 minutes, physician notified)


Nurse secures IV access has_goal(5 minutes, available IV access in places)


Nurse obtains informed consent has_goal(15 minutes, informed consent signed)


Physician review lab results has_goal (15 minutes, confirm thrombolosys eligibility)


Phsysician orders TPA has_goal(5 minutes, alert pharmacy to prepare TPA)


Pharamcy prepares TPA has_goal(30  minuets, TPA available)


Nurse administer TPA has_goal(24 hours, treat acute stroke)











2.2 Guidelines and Indications for Coronary Artery Bypass Graft (CABG) Surgery

The American College of Cardiology (ACC) and the American Heart Association (AHA) publish [9] a set of guidelines and indications to aid physicians who perform coronary artery bypass graft operations.  The guidelines are presented in two ways: first as a generic set of guidelines which only address a single risk factor at a time and then as a set of multi-variate risk factor equations evaluated against patient-specific data.  There are at least three noteworthy aspects of this report:

The risk factor equations result in a function which takes patient data and a point in time and outputs the probability of freedom from a future event along with some indication of the precision of this probability. 

Figure 3 Use of hazard functions to encapsulate uncertainty in CABG guidelines

The primary advantage in encapsulating probability calculation in a function is the ability to build probability on top of a logic representation that doesn't support uncertainty reasoning (which is the case with Semantic Web technologies) but supports function symbols.  The latter is historically much more feasible than the former.

Below is an example of one of the single risk factor guidelines:

Figure 4 Treatment Class of the CABG Operation
in Patients With Chronic Stable Class I or II Angina

The following section should be in the section 6, test case, and a *.owl or *.n3 file should be downloadable from the note.  -Helen 12/11/06, 10:54am 

2.2.1 DLP KR Developed (Manchester OWL Syntax and N3)

{ ?S a :CoronaryArteryStenosis;
:VesselStenosisDegree ?deg. ?deg math:greaterThan 50 } => { ?S a :FiftyOrMoreStenosis }
{ ?S a :CoronaryArteryStenosis;
:VesselStenosisDegree ?deg. ?deg math:greaterThan 70 } => { ?S a :SeventyOrMoreStenosis }
Class: ImportantLeftMainCoronaryArteryStenosis
:FiftyOrMoreStenosis and (:CoronaryArtery value 'left main'))))

Class: ImportantLADStenosis
:SeventyOrMoreStenosis and (:CoronaryArtery value 'left anterior descending')

Class: ImportantProximalLADStenosis
EquivalentTo: (:CoronaryArteryAnatomy value 'proximal') and
:SeventyOrMoreStenosis and (:CoronaryArtery value'left anterior descending')

Class: ImportantRCAStenosis
EquivalentTo: SeventyOrMoreStenosis and (:CoronaryArtery value 'right coronary artery')

Class: ImportantPDAStenosis
EquivalentTo: SeventyOrMoreStenosis and (:CoronaryArtery value 'posterior descending artery')

EquivalentTo: ImportantPDAStenosis or ImportantRCAStenosis

EquivalentTo: :SeventyOrMoreStenosis and (:CoronaryArtery value 'left circumflex')

{ ?P a cpr:patient; dol:constant-participant [ a cpr:screening; inf:realizes
     [ a cpr:medical-sign;
inf:ordered-by [ a cpr:anatomical-concept;
skos:prefLabel "Coronary Artery" ];
galen:hasSpecificCause [ a cabg:ImportantLeftMainCoronaryArteryStenosis ]
] } => { ?P a :CABGCandidate }.

{ ?P a cpr:patient; dol:constant-participant
    [ a cpr:screening; inf:realizes
        [ a cpr:medical-sign;
          galen:hasSpecificCause [ a cabg:ImportantProximalLADStenosis ] ] ],
  [ a cpr:screening; inf:realizes
[ a cpr:medical-sign;
galen:hasSpecificCause [ a cabg:ImportantPDAOrRCAStenosis ] ] ],

  [ a cpr:screening; inf:realizes
[ a cpr:medical-sign;
galen:hasSpecificCause [ a cabg:ImportantCXStenosis ] ] ] } => { ?P a cabg:CABGCandidate }.

  This is a simulated ERP entry, can we use your pod ontology as a seperate name space?  i.e. ?P a pod:Patient, also this patient information is at the "instance" level, should be generated on fly for each execution.  Maybe put it in a seperate file?  aslo should be downloadable

I've added namespace prefixes for the POMR ontology as well as one for concepts specific to the domain of this guideline (CABG). --chimezie

{ ?P a cpr:patient; dol:constant-participant
    [ a cpr:screening; inf:realizes
        [ a cpr:medical-sign;
          galen:hasSpecificCause [ a cabg:ImportantProximalLADStenosis ] ] ],

{ ?P a :Patient. ?R a :PatientRecord; dol:constant-participant ?P; dol:part [ a :StableAnginaRecording; a :Class3Or4Angina ] [ a :Event; dol:realizes :ImportantLADStenosis ], [ a :Event; dol:realizes :ImportantPDAOrRCAStenosis ], [ a :Event; dol:realizes :ImportantCXStenosis ] } => { ?P a :CABGCandidate }.

2.3 Community Acquired Pneumonia (CAP) 

This guideline is published by Institute for Clinical Systems Improvement (ICSI) [13].  It presents many contextual descriptions, along with annotated algorithm that can be computerized for decision support systems, shown in Figure 3.

The inclusion/exclusion criteria of this guideline are as following:

This guideline presents two modeling challenges:

Similar to many guidelines what provide "risk factor" calculation scheme, the CAP  presents a list of patient-specific facts to caluculate the "Pneumonia Severity Index (PSI)". 


Figure 5 CAP Algorithm for In-patient treatment

3. Core Concepts in ACPP Model

The ACPP model is similar to a "task-network" model where a step in a guideline is represented as a process or a set of processes depend on the desired ganularity and intended comsumers of the guideline knowledge . Each process is desgiend to accomplish a clincial goal.  It has a context that consists of a set of inclusion and exclusion criteria, as shown in Figure X.  The context of a process describes a set of sufficient conditions that make the process worthy of recommending or being carried out.  Examples of context include patient clinical and physical conditions, states of prior or parallel processes (completed, aborted), or clinical settings (long term care center, or emergency room).  The goal of a process specifies the clinical intention the process is designed to achieve when successfully executed. It consists of expected outcomes and a desired timeframe for these outcomes to be reached.

Figure 6 Process in ACPP Model

In the ACPP model, there is no pre-fixed steps to accomplish a clinical intention, referred as a "plan" in the tranditional format of guideline or protocol publications. The reasoning engine finds the most appropriate next task based on a patient's condition and guidelines or procotols, arguemented by applying relavent business rules and other scheduling constraints such as availability of equipments and personnels.  Any change to the knowledge base (i.e. update of guidelines, protocols), or change of the status of current process (i.e. completed, aborted, suspended, replaced by) associated with the patient, or a change in the patient clinical condition will trigger a new round of reasoning, in order to make a new recommendation for the next task in the patient's care plan.

3.1 Process (intersection with web service orchestration vocabularies?)

To me, the process here is not limited to computerized tasks.  It could be a physio severice or a lab test, that has nothing to do with web service description.  I am not sure if we want to "dive into" the execution side here.  Chimezie, Do you know if there is an accepted WSO ontology we can make a reference to?  I only find WSO with BPEL, and a W3C member submission on "web service modeling ontology (WSMO) http://www.w3.org/Submission/WSMO/, but I don't think there is any adaptation  -Helen 12/11/06, 6:45pm 

I try to incorprorate the following diagram in Figure 1.  Chimezie, do you think we still need this figure here? -Helen 12/11/06, 6:54pm 

3.2 Context

3.4 Goal

In ACPP model, "Goal" is defined as the clinical intention assigned to a task or a set of tasks.  In a given context, i.e. clinical environment and patient clinical state, the physician sets or update the goal iteratively during the course of care.  A clinical decision support system will be able to search the medical knowledge bases and retrieve tasks that are designed to fulfill the goal. Goals will also be used to prioritize tasks and therefore offer a more refined support to clinical decisions as discussed below.

We adapted the BDI[6] model to represent relevant components of clinical reasoning. The BDI model distinguishes three constituents of decision making: beliefs, desires and intentions (therefore BDI). Desires are defined as mental activities not strictly related to the context in which the agent exists (i.e. to be a rock star) and therefore not directly participating in the decision process. In the medical domain, a desire might be to cure a patient. However, this desire might be unrealistic in those unfortunate cases where the illness has no known cure. We therefore don’t consider these types of intentions real goals. In the BDI framework a goal is in fact defined as the ‘commitment to a plan’.

Beliefs, the second component of the BDI model, are defined here as the entire set of available data about a patient.

While is true that clinicians assign different weight to each information and therefore their true beliefs diverge for what's shown by crude data, this finer levels of reasoning are not in the scope of this model. Other mechanisms are used to mimic more sophisticated clinical reasoning such as prioritizing tasks according to availability of resources and time required to bring a task to completion. 

Goal Ontology Structure

Most guideline representation frameworks specify "Goal" in a string.  These strings carry very little semantics and will not facilitate reasoning.  Based on Fox and Zaccagnini's work, we define a Goal Ontology, and use the goal ontology together with ACPP ontology. 

Goals are represented by tuples containing two variables: Time_line and desired_clinical_state. Time-line represents the time in which ta goal must be fulfilled. As an example: the goal of restarting heart beat has a much shorter time_line compared the goal of stop smoking. In cases where more than one plan can fulfill one goal, time_line will be used to select the task that best meets the urgency of the goal. For instance, increasing red blood cells count can be achieved both by a blood transfusion, in few minutes, or by an iron therapy, over many weeks; according to the specific value of time_line the rule engine will be able to decide which of the two plans best applies to the goal at hand.

Clinical_state defines the desired outcome of a clinical process or task. In our model this entity is ontologically equivalent to the current clinical state (the present patient’s clinical status), but it is defined a priori, while the current clinical state is defined by all available data in the clinical information system and constantly updated. In other words the current clinical state is equivalent to beliefs in the BDI model. For the goal ‘reducing blood pressure to normal’, clinical_state will take the value normal blood pressure’.

Every plan is instantiated by one or more goals and one goal can instantiate one or more plans.

Figure: Ontology Structure:

Davide: could you express your concepts here in triples?  We can use a similar graphic notation to express triples as those used in http://www.w3.org/TR/swbp-n-aryRelations/#pattern1.  Instances are shown in rectangles and classes are shown in ovals.  Also, please replace "plan" with "process".  -Helen 12/11/06, 2:22pm 

Tasks and goals for merging guidelines

A majority of patients present concurrent diseases and to use clinical recomendations on these cases raises the issue of conflicting protocols. Our model is designed to meet this challenge by creating modular representations of atomic clincial processes.  For each task a   represented by 

4 First Order Logic Rules

Rules and logic framework are the next layer of the "semantic layer cake", which offer greater expressitivity.  Current RIF working group is working towards a common ground to express or exchange rules.  The intricate complexity of knowledge and interactions need to be considered during the reasoning process often require the higher expressiveness.  Rules can be used to adequately express logic and policies.

A large number of identifiable clinical tasks (processes in ACPP model), goals and clinical conditions (such as disease) can be represented in ontology [Kumar2006, Zaccagnini2006].   Web Ontology Language (OWL) can be used to express these ontological relationship.  However, ontology alone is not expressive enough for representing rules that govern the selecting of appropriate processes and connection of processes (inclusion criteria), ruling out excluded processes to avoid adverse effects.  First order logic rules are used for such purposes in ACPP model.  Currently, there is no standard semantic web rule language, but a large group of participants are working on a rule exchange format (RIF) in RIF working group.  A number of semantic web reasoners are able to process rules expressed in SWRL rule language(cite) or N3 Notation (cite).

For its user-friendly syntax and semantics that can be consumed by euler, cwm and FuXi, we use N3 notation to express rules in this document.

4.1 Connecting Rules: next step

4.2 Goal Enactment Rules

5. Determining an Appropriate Knowledge Representation

  1. Expert Systems and Decision Support
  2. Where Classification Hierarchies (Description Logics) Fall Short
  3. Expressive Inference (Description Logic Programs)
  4. Inclusion/Exclusion Rules

6 test cases


  1. M. Peleg, etc "Comparing Models of Data and Knowledge for Guideline-Based Decision Support: A case study approach" Part 1: http://smi.stanford.edu/smi-web/research/details.jsp?PubId=922;  Part 2: http://smi.stanford.edu/smi-web/research/details.jsp?PubId=923
  2. J. Fox, N. Johns and A. Rahmanzadeh, "Disseminating medical knowledge: the PROforma approach"
  3. An ontological view of clinical protocols
  4. CABG:
  5. ICSI Guideline "Community-acquired pneumonia in adults",  2005, http://www.guideline.gov/summary/summary.aspx?doc_id=9398&nbr=005034&string=community+AND+acquired+AND+pneumonia
  6. The Belief-Desire-Intention Model of Agency Michael Georgef, Barney Pell, Martha Pollack,

    Milind Tambe, MichaelWooldridge

  7. S. Devitt, J. DeRoo, H. Chen, "Desirable Features of Rule-based Systems for Medical Knowledge"
  8. D. Zaccagnini, etc "Design of a Goal Ontology for Medical Decision-Support
  9. ACC / AHA Task Force on Assessment of Diagnostic and Therapeutic Cardiovascular Procedures, "ACC/AHA Guidelines and Indications for
    Coronary Artery Bypass Graft Surgery", http://circ.ahajournals.org/cgi/reprint/83/3/1125.pdf, March 1991. 
  10. Benjamin N. Grosof, Ian Horrocks, Raphael Volz, Stefan Decker, "Description Logic Programs: Combining Logic Programs with Description Logic", http://www.cs.man.ac.uk/~horrocks/Publications/download/2003/p117-grosof.pdf, 2003

11. National Guideline Clearinghouse Classification Sceme http://www.guideline.gov/about/classification.aspx

  12. Workflow patterns http://is.tm.tue.nl/research/patterns/patterns.htm

  15. Chimezie Ogbuji, "A Problem-Oriented Medical Record Ontology", http://esw.w3.org/topic/HCLS/POMROntology, 2006