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
- Introduction
- Use case examples
- Representation patterns
- Vocabulary for n-ary relations in RDF and OWL
- Pattern 1: Introducing a new class for a relation
- Use Case 1: additional attributes describing a relation
- Use Case 2: different aspects of the same relation
- Use Case 3: N-ary relation with no distinguished participant
- Considerations when introducing a new class for a relation
- Pattern 2: Using lists for arguments in a relation
- N-ary relations and reification in RDF
- Additional Background
- Note on vocabulary: Relations and instances of relations, Properties and Property instances
- Anonymous vs named instances in these patterns
- Notes
- References
- Changes
- Acknowledgements
Introduction
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:
- Weighted Inclusion/exclusion criteria
- Workflow processes
- Temporal relationship
- Goal
- A mechanism to evaluate the performance of pathways
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 guidelines are driven primarily by patient data and not procedural
constraints
-
The report emphasizes the value of decision support by guidelines that are
patient-specific
-
The patient-specific risk factor equations require support for 'black-box'
uncertainty reasoning
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
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
EquivalentTo:
:FiftyOrMoreStenosis and (:CoronaryArtery value 'left main'))))
Class: ImportantLADStenosis
EquivalentTo:
: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')
Class:ImportantPDAOrRCAStenosis
EquivalentTo: ImportantPDAStenosis or ImportantRCAStenosis
Class:ImportantCXStenosis
EquivalentTo: :SeventyOrMoreStenosis and (:CoronaryArtery value 'left circumflex')
-
A patient whose record indicates important left main coronary artery
stenosis is a candidate for a CABG operation
{ ?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 }.
-
A patient whose record indicates 3 vessel disease with LAD/CX stenosis
is a candidate for a CABG operation
{ ?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 }.
-
A patient with chronic stable class III or IV angina with a record
indicating 3 vessel disease is a candidate for a CABG operation
{ ?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:
-
include patients 16 years of age and older
-
exclude patients with HIV infection and pneumonia in
immunocompromised patients
This guideline presents two modeling challenges:
-
calculation of PSI (black-box function for reasoning)
-
matching N conditions out of M prerequisites, as indicated in
Annotation 3: "Obtain chest x-ray, especially if patient has two or more of
these signs".
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?)
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:
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
-
Expert Systems and Decision Support
-
Where Classification Hierarchies (Description Logics) Fall Short
-
Expressive Inference (Description Logic Programs)
-
Inclusion/Exclusion Rules
6 test
cases
Reference
-
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
-
J. Fox, N. Johns and A. Rahmanzadeh, "Disseminating medical knowledge: the
PROforma approach"
-
An ontological view of clinical protocols
-
CABG:
-
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
-
The Belief-Desire-Intention Model of Agency Michael Georgef, Barney Pell,
Martha Pollack,
Milind Tambe, MichaelWooldridge
-
S. Devitt, J. DeRoo, H. Chen, "Desirable Features of Rule-based Systems for
Medical Knowledge"
-
D. Zaccagnini, etc "Design of a Goal Ontology for Medical Decision-Support
-
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.
-
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
