Towards a Formal Process-driven Framework for Streamlining...
Transcript of Towards a Formal Process-driven Framework for Streamlining...
Towards a Formal Process-driven Framework for
Streamlining Patient-centric Care
Wen Yao1, Akhil Kumar
2, Jerome Rolia
3, Sujoy Basu
3, Sharad Singhal
3
1College of Information Sciences and Technology, Penn State University 2Smeal College of Business, Penn State University, University Park, PA 16802
{wxy119,akhilkumar}@psu.edu 3Services Research Lab, Hewlett-Packard Laboratories, Palo Alto, CA 94304, USA
{jerry.rolia, sujoy.basu, sharad.singhal}@hp.com
Abstract. Rapidly growing patient interests in participating in their care process
and accessing their health data has motivated health organizations to provide
patient-oriented care delivery both in clinical and homecare settings. With the
goal of giving patients a more proactive role in their own care, we motivate and
propose a formal process-driven framework for streamlining patient-centric
care and improving patient-provider communication. It will lead to patients
having better access health services and taking more responsibility in their
health management. At the same time the burden on healthcare professionals is
reduced, while enabling greater efficiency, improved safety and higher quality.
We also developed an architecture for system implementation. Finally, we
demonstrate a next generation health care delivery system with a use case.
Keywords: patient-centric care, process-driven, clinical pathway, medical
guideline, healthcare, patient communication, metrics
1 Introduction
Despite the advances in life expectancy and quality of life, the current healthcare
delivery system faces significant challenges in terms of cost, accessibility and quality
[1]. One of the goals established by the Institute of Medicine in 2001 is that
healthcare delivery should be patient-centric [2], which means it should provide care
that is respectful of and responsive to individual patient preferences, needs and val-
ues. Another goal is to ensure that patient values guide all clinical judgments and
decisions. As mobile devices become pervasive, and patients become more informed
with ease of access to health information, it is reasonable to assume that they will play
a more interactive role in decision making about their health matters. Hence, there is a
need to develop a formal methodology to foster patient-centric care service delivery.
A clinical workflow delineates a path for a patient through the various steps in in-
teracting with a clinic, lab, pharmacy and other participants in the healthcare system,
as shown in Figure 1. In this care process, the patient is the only constant who is in-
volved in all the steps and communications among a large number of participants in
the healthcare ecosystem. For example, when patients schedule an appointment, or are
discharged from a hospital, they communicate with administrative staff. At other
points in this process they undergo clinical activities such as detection and treatment,
which involve various departments, staff, resources, medical decisions, etc. In this
setting, it is important to take a process perspective to maintain coordination and flow
of information between the patient and other entities to ensure an optimal outcome.
Fig. 1. The healthcare ecosystem
However, due to limited hospital resources and lack of emphasis on patient-centric
care, healthcare organizations have proven to be operationally inefficient, offering
poor quality of service for patients, and providing limited resources for patients to
access their health data and participate in decision making. Cost, accessibility and
quality of service delivery are largely a function of how the ecosystem works. Some
major challenges in this regards are: (1) longer life spans, an aging population and
greater incidence of chronic illnesses are leading to steady increases in overall
healthcare spending; (2) since patients have very limited access to their own health
data, they are unaware of the overall processes they are undergoing, how long each
step in a process takes, and who they will interact with at what time, etc.; (3) As a
result, patients get confused, even frustrated since they do not know what to expect at
various points of care; (4) When multiple treatment options exist, patients do not un-
derstand the pros, cons, costs, and detailed procedures of each option, and feel they
have no say in their own health matters. In general, it is also important that clinical
practice should follow evidence-based guidelines to ensure an optimal outcome.
To solve the above problems, this study proposes a process-driven approach to
streamline patient-centric care. We formalize clinical pathways based on medical
guidelines and propose a patient information model that incorporates patient needs
and preferences. Then, we propose a decision model to derive alternative clinical
decisions based on best practice and patient preferences. The decision model allows
patients to collaborate with clinical teams to determine their treatment. Thus, this
framework aims to allow patients to: (1) access their health data and gain insights into
the whole process; (2) express choices and take more responsibility; and (3) get a
more personalized and coordinated continuum of care (i.e., care supply chain). From
the providers’ perspective, our approach transfers time consuming but redundant as-
pects of patient communication workload from medical staff to the system, presents
the patient’s choices and continuum of care to all teams to improve coordination, and
tracks clinical pathways so that process improvement can occur. These enhancements
enable care teams to focus on their work while operational efficiency is improved. We
present a hypothetical case study to demonstrate how our approach is expected to
improve patient satisfaction and safety along with quality of outcomes.
This paper is organized as follows. Section 2 discusses motivation and related
work. In section 3, we propose a formal framework to streamline patient-centric care.
The decision model is illustrated in Section 4. Then, we describe the system architec-
ture and a use case in Section 5. Finally, Section 6 concludes the paper.
2 Motivation and Related Work
In recent years, there has been increasing interest in research on the support of clinical
processes. We summarize these approaches from the perspective of healthcare pro-
viders and patients depending on who is the principle user of the system. Another
perspective identifies whether the approach is process driven or unaware, depending
on whether it has underlying process models that drive the care delivery or patient
interaction. Table 1 summaries these related studies. It is notable that there has not yet
been much attention to process-driven, patient-oriented research in the literature.
Table 1. A comparison of related work for healthcare service delivery
Perspective Provider-oriented Patient-oriented
Process-
driven
Computer-interpretable guidelines (e.g.,
Asbru, GLIF, PROforma) [3, 4]
Workflow management (e.g., AgentWork
[5], ADEPTflex [6], jBPM [7])
Alberta’s system [8]
(Not many studies found)
Process-
unaware
Verbal patient communication [9]
Follow-up (e.g., diet program)
Patient portal/PHR [10] (e.g.,
iTrust, Tolven, MyOSCAR)
Stand-alone applications for pa-
tients (e.g., asthma kiosk [11])
A number of methods have been proposed to support clinical processes from the
providers’ point of view, including the development in computerized medical guide-
lines and workflow management. Medical guidelines were originally in the form of
free-format text documents, but more recently various methods have been proposed to
represent them as Computer-Interpretable Guidelines (CIGs), most of which can be
visualized in flow charts, e.g., Asbru, EON, GLIF, PROforma, and SAGE (see [3, 4]).
Peleg et al. [3] reviewed six CIG modeling approaches and established a consensus on
common structures, including (sub)plans, decisions, actions, and patient state. The
focus of CIGs is on supporting medical decision making based on best practice so as
to improve the compliance of clinical practice and reduce variations. Since these
methods are primarily used for clinicians, other aspects in clinical pathways (e.g.,
administrative activities) are currently not integrated. Thus, these approaches are pro-
vider-centric, and not patient-centric. Our approach employs such methods to improve
the dialog between patients and clinical teams.
Workflow technologies offer a natural way to automate and monitor patient path-
ways, with an emphasis on flexibility and adaptability. For example, such systems
have been developed to enable dynamic changes in predefined process models, such
as ADEPTflex [6] and AgentWork [5]. Other open source process modeling tools (e.g.,
jBPM [7]) have also been developed to support flexible process modeling especially
for clinical pathways. These approaches concern logistics of patient flow but lack
integration with medical knowledge. Further, they hardly concern patients’ communi-
cation with providers or their needs and preferences. While we aim to employ such
technologies to assist in semi-automating a patient’s delivery of care (e.g., schedule
an appointment), we also rely on workflow technologies to document a patient’s actu-
al clinical pathway to support process monitoring, analysis, and improvement.
More recently, as the focus of care providers shifts towards patient-centric care, a
first step has been to develop many applications to support patient access to their own
health data and facilitate their communication with providers. A list of open source
PHR applications can be found in http://www.medfloss.org/taxonomy/term/6, includ-
ing Tolven and MyOSCAR. These are all open source systems, designed in a way that
patients can browse their personal health records (PHR), schedule appointments, send
messages to their doctors, and receive reminders and notifications. A selection of
web-based PHR applications is reviewed in [10], such as WebMD. Lacatelli et al.
[12] conducted a case study of a web clinical portal in Italy and showed how such
open source technology can provide clinical and organizational advantages from pro-
cess monitoring to pattern recognition in care delivery. Other efforts are devoted to-
wards patient participation and decision making in stand-alone applications. For ex-
ample, Porter et al. [11] designed an asthma kiosk application to capture critical in-
formation to drive guideline-based care for pediatric asthma. Other non-technological
approaches have been proposed to improve the interactive communications between
patients and practitioners, e.g., Breen et al. [9]’s study.
These patient-oriented methods have greatly improved patient communication with
care providers and their accessibility to health data. However, for the most part they
fail to recognize the underlying process a patient undergoes in receiving medical care.
We only found a few studies (e.g., Alberta’s system [8]) that plan patient pathways
for patient self-management. Hence, there is a need to integrate the process perspec-
tive into patient-centric care and make it visible to patients, to facilitate patient-
provider interaction in a structured manner and to give patients a more proactive role.
3 A Process-driven Framework for Patient-centric Care
In this section, we propose a formal process-driven framework that supports stream-
lined patient communication. The goal of this framework is to give patients access to
more information to interact with their service providers and take a more active role
in their own care. Their preferences and values are sought and integrated in medical
decision making. We also keep track of clinical decisions, actions, and outcomes at
various time points so all providers in the care supply chain can share it.
3.1 Overall Framework
Figure 2 presents the overall framework of our approach. All steps and decisions are
guided or driven by medical guidelines and patient preferences, needs and values
captured in the Patient Information Model (PIM). Context-building is the process of
obtaining patient information by conversing with patients (e.g., when they are waiting
in a clinic) in a structured way. Thus, the decision algorithm integrates guidelines,
patient needs and preferences, and suggests options. Finally, an action is determined
based on the discussion and agreement between the patient and the doctor. All medi-
cal decisions, actions, and outcomes for each patient encounter are documented in a
personal clinical pathway which is a part of PIM. The system will detect any devia-
tions from medical guidelines and request the doctor to enter reasons for any major
deviations, which will be logged automatically, and remind the doctor perhaps at a
later time. The framework helps to guide patient communication by semi-structured
process models and coordinates activities among various participants. It helps to re-
duce the work required by the patient to interact with the system (e.g., duplicate data
solicitation) and enables the patient’s participation in various tasks by letting them
know what to expect and what actions to take at all points throughout their care. We
will describe each component in the following sections, as shown in Figure 2.
Context
building(Section
4.2)
Patient information model (PIM)
(Section 3.2)
Item Parameter Value
Symptoms Coughing YES
Symptoms Vomiting No
Signs Blood pressure 140
Lab tests Blood count Normal
Preference 1 2 3
Treatment Medica-
tion
Surgery Device
therapy
Rehabilita-
tion
Exercise Salt-
rest. diet
Alcohol-
rest. diet
Patient preference profile
Personal health records
Patient conversation model
(Section 4.2)
EHR
Personal clinical pathway
Medical
knowledge base
(Section 3.3)
Clinical
pathways
Medical
guidelines
What symptoms do you have?
Coughing Headache Dyspnea
Vomiting Fatigue Edema
Preference to the treatment methods?
Device therapy: 3 Surgery: 2
Medication: 1
Preference to the living styles?
Exercise: 1 salt-restricted diet: 2
Alcohol-restricted diet: 3
Time Dept.
(loc)
Exam Lab
tests
Treat-
ments
8.15-9am Exam
room
Vital
signs
N/A N/A
9.20-
10.35am
Lab
(RM01)
N/A X-ray,
CT scan
ACE
inhibitor
1-2.15pm Ward N/A N/A Diuretics
2.20 pm Discharge N/A N/A N/A
Clinical pathway: heart failure Patient name: John Smith
Expected LOS: 1 day Attending physician: David Lee
Admission date: 11/28/2011 Discharge date: _______
Personal clinical pathways
# Time Details
… … …
The Decision
Algorithm
(Section 4.3)
Fig. 2. Overview of process-driven framework for patient-centric care
3.2 Patient Information Model
Definition 1 (Patient information model). A patient information model (PIM) is
comprised of three parts: PIM = (PHR, PPP, PPC), where
PHR represents personal health records
PPP reflects the personal preferences of an individual
PCP summarizes personal clinical pathways
A personal health record (PHR) is a patient’s lifelong health information that she is
allowed to access, coordinate, and share with her other parties [10]. The PHR might
include patient-reported symptoms, lab results uploaded by patients, or even data
from smart devices. Usually, it is maintained by patients themselves and can include
data from many health organizations that they have visited. Here, we assume that the
PHR is electronic, and is accessible online at any time.
A personal preference profile (PPP) captures an individual’s preferences, needs,
and values pertaining to her current situation. A personal clinical pathway (PCP) uses
a clinical pathway as a template and documents the decisions, actions and outcome
organized in chronological order pertaining to a specific patient. It allows deviations
from best practice to satisfy a patient’s preferences. We discuss the details shortly.
Example 1 (patient preference profile). The matrix in Figure 3 shows the preference
profiles for three patients P1, P2 and P3, on a 1 – N scale while applying heart failure
guidelines. A larger number indicates a stronger preference. In this way, the system is
aware of patients’ preferences of treatment methods (e.g., medication or surgery),
quality-of-life aspects (e.g., exercise- or diet-based rehabilitation program), etc. A
PPP is acquired from context-building to be discussed at length in Section 4.
Obviously, the medical conditions of patients should take priority over their prefer-
ences whenever there is a conflict since patient safety is more important. For example,
although surgery is the least preferred treatment method of patient P1, if she has re-
peated hospitalization because of heart failure despite aggressive medical therapy, she
should be considered to have a cardiac transplant.
Item Applied strategy Treatment method Rehabilitation program
Choice Normal Aggressive Medication Surgery Exercise Diet Education
P1 1 2 1 2 3 2 1
P2 2 1 2 1 3 1 1
P3 1 1 2 1 1 2 3
Fig. 3. Matrix of patient preference profiles (partial)
3.3 Medical Guidelines and Clinical Pathways
A medical guideline (a.k.a. clinical protocol or clinical practice guideline) is a docu-
ment that guides decisions and criteria regarding diagnosis, management and treat-
ment in specific areas of healthcare. For example, guidelines can be categorized by
disease types like pediatrics, pulmonary or heart diseases. This is naturally aligned
with the way they are developed, i.e., by medical staff with different expertise areas.
Definition 2 (Medical guideline). Let be a clinical guideline,
where T is the set of all tasks, N is the set of all control nodes, E is the set of all edges
connecting tasks and control nodes, and goal is the objective of this guideline. Based
on common structures identified by Peleg et al. [3], we allow the task node denote various task types, and the
control node denote the four basic control-
flow constructs.
Selecting a guideline for implementation at a particular clinic or hospital requires
an agreement among care professionals at that site and its patients, since different
kinds of guidelines exist with different sources and goals, and sometimes even have
conflicts [13]. Thus, in practice, guidelines are adapted to a specific clinical setting.
A clinical pathway (or treatment plan) implements medical guidelines after they
are tailored to local and individual circumstances, e.g., availability of resources. In
the clinical pathway, different tasks (performed by clinicians involved in the care) are
defined and optimized in a logical time sequence. Outcomes are tied to specific inter-
ventions, e.g. taking medication for a week or an angioplasty procedure might reduce
blood pressure. In general, a clinical pathway may be developed from many different
guidelines. Ideally, a clinical pathway is the result of evidence-based medicine that
drives the treatment of a specific group of patients with a predictable outcome.
Definition 3 (Clinical pathway). A clinical pathway can be represented as a collec-
tion of guidelines:
, , where is a guideline
and the adaptation of made based on local settings. Alternatively, a pathway can
be represented as where . A clinical pathway is basically a template from
which concrete patient treatment cases (i.e., process instances) are derived. It is repre-
sented in a flow chart as shown in Example 2.
Fig. 4. A clinical pathway incorporating two guidelines from AHRQ [14]
Example 2 (A clinical pathway for heart failure management). Figure 4 depicts a
clinical pathway that associates two medical guidelines from AHRQ for heart failure
management [14]. The first guideline is a general one for evaluation and care of pa-
tients with heart failure, and it invokes a second guideline for initial evaluation. For
detection and treatment tasks, other guidelines can be triggered depending on patient
conditions and choices made by the attending doctors. In this way, Figure 4 guides the
treatment of patients with heart failure in a structured, process-driven manner. When
this pathway is initialized for an actual case, human still take control.
Using Figure 4 as a template, a personal clinical pathway (PCP) documents the
actual execution for a specific patient along. Thus, it keeps track of medical decisions
(e.g., prescribe ACE inhibitor or Beta blocker), actions (e.g., dosage for ACE inhibi-
tor medication), and patient outcomes (e.g., normal body temperature) in chronologi-
cal order for each patient situation. As noted above, deviations are allowed. A final
outcome, e.g., the patient is cured, or ultimately passes away, indicates the end of a
PCP. The PCP is a result of clinical decision making to be discussed in Section 4.
Definition 4 (Personal clinical pathway). A PCP is the execution log of a clinical
pathway (e.g., Figure 2). where is a decision, i.e., , is an action, i.e., , and
indicates patient outcome or state, i.e., . Each task is associated with a
time t to denote the time of occurrence. Other elements such as assessment and vari-
ance are captured as well in a similar way but not shown here.
4 Patient-centric Decision Making Process
In this section, we describe patient-centric decision making. Medical knowledge for
decision points is formulated in rules to derive recommendations based on best prac-
tice or patient choices. Patient preferences are collected through context-building with
a patient conversation model and giving patients more responsibility.
4.1 Medical Rules
Rules embody medical knowledge and are used to help make complex decisions in
clinical pathways through logical reasoning. For example in Figure 4, N2 is a decision
node to decide the next step (treatment or further evaluation) based on patient diagno-
sis results. A number of medical rules can be associated with node N3 (to be dis-
cussed in Table 3). Integrating these rules and applying results from rule-based rea-
soning into a clinical pathway is critical for implementing evidence-based practice.
In addition, each rule is associated with a strength of evidence (SOE) value to indi-
cate its reliability. AHRQ has developed a three-level quality-rating system for classi-
fying SOE into levels A, B and C (see Table 2). Further, we add another category D to
include latest evidence from new research results. Rules from all categories are auto-
matically triggered and provide results to patients and care providers. We describe the
algorithm for rule-based reasoning in Section 4.3.
Table 2. Classification criteria for strength of evidence (SOE)
Symbol Description Source of evidence Level of evidence*
A Good evidence Evidence from well-conducted random-ized controlled trials’ or cohort studies
Levels I-III
B Fair evidence Evidence from other types of studies Levels IV-VI
C Expert opinion N/A Level VII
D New evidence Latest research results N/A
*Note: please refer to AHRQ quality of rating system for details
Example 3 (Medical rules for heart failure). Table 3 shows several example rules
acquired from AHRQ guidelines [14]. Their reliability is indicated by the SOE value
in the last column. They are categorized in a way that each rule is associated with a
decision node in the clinical pathway in Figure 4. For example, rule R1 is used to
decide whether a patient needs further examination and diagnostic testing (T14) or not
(End node). Similarly, R2 and R3 are associated with two different decision nodes in
T14, which refer to another guideline (or subplan) which is not expanded in Figure 4.
R3 is more complex and has two levels of reasoning. Finally, the medication rules
R4-R6 show which medication therapy is appropriate along with their SOE levels.
Table 3. Example rules for heart failure based on AHRQ guidelines [14]
Category # Description of guideline rules SOE
Initial evaluation
R1 (N5)
If a patient has the following symptoms: awakening from sleep with shortness of breath or shortness of breath upon lying down or new-
onset dyspnea on exertion
Then the patient should undergo evaluation for heart failure
Unless PHR and physical exam clearly indicates a noncardiac cause
B
Physical
examination
R2
(T14)
If a patient shows symptoms that are highly suggestive of heart failure
Then the patient should undergo ECHO or RVG test to measure EF Even if physical signs of heart failure are absent
C
Diagnostic testing
R3 (T14)
If a patient is suspected of clinically evident heart failure Then practitioners should perform: a chest x-ray; ECG; complete
blood count; serum electrolytes … liver function tests; and urinalysis;
If the patient is over 65 with no obvious etiology
Then a T4 and TSH level should be checked
C
Medication R4
(T10)
If a patient’s systolic blood pressures < 90 mmHg and
there is a higher risk of complications Then prescribe ACE inhibitors managed by an experienced physician
A
R5 (T10)
If a heart failure patient has symptoms: fatigue or mild Dyspnea on exertion; and he has no other signs or symptoms of volume overload
Then ACE inhibitors may be considered
C
R6
(T10)
If a patient has heart failure and signs of significant volume overload
Then the patient should be started immediately on a diuretic
C
4.2 Context-building through a Patient Conversation Model (PCM)
A medical decision is context-dependent, where context is patient specific and can be
collected and summarized by pre-asking questions of a patient at a previous point of
time. For example, in Figure 4, context that is used at node T3 (detection and treat-
ment) can be collected prior to that point, e.g., at node T1 (pre-admission) or T2 (pa-
tient admission). Then, depending on the patient answers, the subsequent questions
need to be adjusted or customized. We use a patient conversation model (PCM) to
describe all questions used at a specific point of care for a specific disease. This mod-
el is process-aware since context becomes increasingly available as the care process
proceeds. It is obviously knowledge-dependent since the questions for managing heart
failure and managing pediatrics will be totally different.
Example 4 (Patient conversation model for heart failure). Fig. 5 shows an exam-
ple patient conversation model represented in a decision tree. The top part is derived
from medical guidelines or rules in Table 3. The other two parts are developed based
on practical experience and patient needs. These questions are available for patients to
answer any time prior to T3 (detection and treatment) in the clinical pathway of Fig-
ure 4. For example, a patient can enter her answers at home or while waiting for ex-
amination. As a result, the answers are stored in PIM. Some answers become a part of
PHR while some of PPP (see Example 1). In future, we aim to interview clinicians
and patients to get a complete set of questions. In a strict sense, they are context de-
pendent within a clinical pathway. The models can be built, shared and adapted to
specific healthcare settings in the same way that medical guidelines are adapted. We
also aim to automate the techniques for constructing conversation model trees.
Fig. 5. A partial patient conversation model in a decision tree
Via the conversation model, we also give an opportunity to the patient to ask ques-
tions of the provider. For example, if the system suspects a patient of hypertensive
heart failure, a patient may ask the treatment options she may have and details associ-
ated with each option (e.g., expected recovery time, cost, side effects, and success
rate). In general, when patients take the steps to proactively seek information regard-
ing their illness, they are in a more advantageous position to share their specific
knowledge and concerns with their doctors. Thus care providers spend less time to
make patients aware of readily accessible information while ensuring a patient-centric
decision. In practice, we should also consider other aspects of context, such as those
related to clinical staff (e.g., expertise level), resources (e.g., availability), etc.
4.3 The Decision Algorithm
Medical decision making should follow best practice through medical rules (in Table
3) and take into account patient information from context-building (in Figure 5). Fig-
ure 6 describes the algorithm for patient-oriented decision making. When a decision
node D is reached, we retrieve the rule set RS associated with D, run them against
PHR and get results. Other options not triggered by rules will still be presented (with
notation SOE = “N/A”) to patients who know that no guideline supports this option.
In addition, SOE values and patient preference levels (from PPP) are shown. Exam-
ple 5 shows how this algorithm works continuing with the above examples.
Algorithm: patient-oriented decision making (when decision node D is reached)
Input: personal health record PHR, personal preference profile PPP, decision node D
Output: options list options
1. Put all the action nodes from the outgoing branches of D into a list option_list
2. Define rule set RS = rules associated with decision node D
3. Run RS against PHR and get the result vector result_list //a subset of option_list 4. Define a temporary tuple <option, rule, pref>
5. FOR each item op in option_list
6. tuple.option = op.name //assign the option name
7. tuple.pref = preference_table.findPref(op.name) //assign preference from Figure 3 8. If op is in result_list //this option is a result rule-based reasoning or best practice
9. tuple.rule = the content of the rule that trigger this action op (with SOE value)
10. Else //op is not option from guideline, no rule is applied but this is still an option
11. tuple.rule=“N/A” 12. Insert tuple into options
13. END
14. Rank options first based on SOE (AC), then based on patient preference (highlow)
15. Return options
Fig. 6. Algorithm for patient-oriented decision making
Example 5 (Patient-centric decision making). Fig. 7 shows an example of decision
making at node N2 (Diagnosis). During initial evaluation, this patient underwent a
physical exam and diagnostic testing. Her signs indicate that she might have had heart
failure. Specifically, her systolic blood pressure is 85 mmHg and there is a high risk
of complications. Her previous symptoms (a part of PHR) include shortness of breath
upon exertion and while sleeping, volume overload, and a little chest pain. According
to the decision algorithm in Figure 6, we get the option_list = {T3, T5, T6, T7, T8,
T9} and rule set RS (line 1-2). The result of rule-based reasoning against PHR is re-
sult_list = {T5, T7} (line 3), since only two rules are triggered for her PHR: R4 and
R6 (see Table 3). Then we go through each option in option_list, if an option (such as
R4 and R5) is triggered by rules, assign its SOE value from Table 2 and preference
value from Figure 3 (line 5-9). Otherwise, if a rule is not triggered such as R5, the
value for its SOE will be “N/A”, indicating it is not applied (line 10-11). The output
of the decision algorithm is shown in the table below. Thus, ACE inhibitor and Diu-
retics are recommended based on best practice (SOE equals A and C respectively).
Nevertheless, patients and doctors are allowed to choose other options. For example,
if the actual action is a Beta-blocker therapy, then the system will detect such devia-
tion in real-time and ask the physician to enter reasons for it, perhaps at a later time.
Medication therapy (T2)
Patient and family consulting (T3)
Beta blocker (T6)
Diuretics
(T7)CABG (T8) PTCA (T9)
Heart failure
patients with angina,
or history of MI
Patients with signs
of heart failure
Patient
information
model
Diagnosis? (N2)
Surgery treatment (T4)
R4,R5… …
R4, R5, R6 …
R1, R2, R3…Initial evaluation
(T1)
No signs of heart failure
Options Pros Side effect/Risk Prcd. Cost SOE Pref
ACE
inhibitor
Reduce mortality in severe heart
failure…
Decrease in blood pressure,
increase in potassium …
… 1.5k R4 (A) 2
Diuretics Treat various conditions, e.g., high BP Nausea, dizziness, fatigue... … 0.8k R6 (C) 2
Beta-
blocker
Reduce risk of recurrent heart
attacks…
Side effects similar to heart
attack itself
… 1k N/A 2
CABG Prevent further ischemic injury… Increased mortality risk … 12k N/A 1
PTCA Unclear Relieve angina, improve
wall motion
… 15k N/A 1
…… …… …… …… …… …… ……
Output
table
R6…
The Decision
Algorithm
Context-building
ACE inhibitor (T5)
Fig. 7. Illustration of the decision algorithm
5 Implementation
This section describes our implementation architecture with illustration of a use case.
5.1 System architecture
Figure 8 shows the architecture for system implementation using a variety of open
source tools. The patient information model (PIM) maintains three parts of patient
data (see Def. 1). Clinical pathways derived from customization of medical guidelines
are modeled in a formal workflow modeling language (e.g., BPMN 2.0) and stored in
the repository. As noted above, the patient conversation model (PCM) is tailored from
guidelines and integrates with practical experience. When a clinical pathway is initial-
ized for a specific patient case, the jBPM workflow engine [7] is responsible for main-
taining the status of the running process and coordinating with other components. It
triggers the Conversation Manager at various points of care to help patients to con-
verse with the system based on PCM. As a result of context-building through patient
conversation, their data are sent to update PIM (either PHR or PPP) through PIM
Manager. jBPM also integrates with Drools-expert rule engine, which is responsible
for rule-based reasoning. Rules in Table 3 are formalized in the Drools rule language
and executed by Drools-expert. When a decision node is reached, the decision algo-
rithm (see Figure 6) is executed and available options are presented to both patients
and providers. We plan to extend the open source PHR tool MyOSCAR to develop
this patient-oriented portal.
Our system can also interact with other health organizations through HL7 messag-
ing protocol [15], which has been developed as a leading standard for data integration
in heterogeneous systems today. It is a message-based standard for data exchange
among hospital applications when certain clinical trigger events occur. A cloud-based
architecture raises a number of issues, among which security is the most significant.
The information security community has devoted a lot of effort towards securing
cloud-based PHR (see for instance [16]); however, it is beyond our current scope.
Health
Organization A
Questions
EHR
Workflow
Engine
(jBPM)
PIM ManagerClinical
Pathway
RepositoryRule
engine
Guidelines &
Pathways
Browser
Patient-
centric
portal
(on top of
MyOSCAR)
Web service
(HL7) Web service
(HL7)
Web service
(HL7)
Guideline navigation
• What is next?
• Who should I contact?
• Previous decisions
• Current options
Medical
Guidelines
Answers
Personal Clinical
Pathway ManagerPIM
PHR
PPP
PCP
Conversation
Manager
PCM
Repository
Process-
driven
Health
Organization B
EHR
Health
Organization C
EHR
(Drools-expert)
Fig. 8. Implementation architecture
5.2 Use case analysis using quality measurements
In this section, we analyze two before and after scenarios for a single patient situation
to illustrate how implementing the process-driven approach can help to improve pa-
tient satisfaction, compliance, and outcomes.
The case background is as follows: a 68-years old male patient named John Smith
encountered an heart attack or myocardial infarction (MI) one year ago and has been
using a PHR to log and monitor his health data (e.g., body temperature, symptoms,
dietary, and exercise). He also uses the PHR system to communicate with his primary
physician Dr. Oz through secure emails and messages for inquiry, medication and diet
program follow-up. One day, he feels shortness of breath during exercise and makes
an emergency appointment by phone to see the doctor. Figure 9 describes two treat-
ment scenarios: a process-unaware PHR vs. a process aware one.
A key objective in developing and implementing such a system is to improve qual-
ity as reflected in concrete measures. Although detailed discussion of quality is be-
yond the scope of the current work, some key measures of quality are: reduced wait-
ing time, reduced verbal communication, less burden on care providers, more acces-
sibility to health data, resources, reduced medical errors through enhanced compli-
ance, informed alternatives of best practice for service providers, etc. Improved pa-
tient satisfaction results from making them aware of uninformed time, general process
flow (and details for each step), and offering them alternative treatment options. Thus,
their preferences and values are appreciated. Moreover, decisions, actions and out-
comes are tracked to benefit patients and care providers down the care chain. These
metrics will inform the evaluation of the impact of the proposed system.
Scenario 1 (process-unaware PHR) Scenario 2 (process-aware PHR)
Check in, see a long queue, and start conversation with
PCM system; enter symptoms and learn about possible
causes and treatments, etc. (see Example 3)
See doctor since the case is prioritized by the system
based on seriousness of symptoms; doctor answers
questions pre-asked by John (satisfied);
Take physical exam and learn while waiting that he has
elevated jugular venous pressure ; learn the 6 lab tests
suggested by the system; after consulting with the
doctor John decides to do 4 of them because 2 tests are
time consuming, costly, and not fully reliable in his case
10 min more of informed waiting during which he learns
more about the physical exam results and diagnostic
testing suggested by the system. He learns about the
pros, side effects, detailed procedures, expected results,
and strength of evidence of each test. (see Table 3)
Finish four lab tests and told to get results in 30 minutes
(tired but know what to expect)
30 min informed waiting and 10 min uninformed
waiting (play around with conversation manager and
learn various expected results/treatment; enter more
questions in the system for the doctor
See doctor and get lab results; consent to doctor’s
prescribing ACE inhibitor and Diuretics (see Figure 7)
since he prefers medication therapy and SOE of these
two therapies are convincing. (relieved)
Get medicine at pharmacy and go home
Rest at home and more self-education through
conversation with the system
Check in and wait for 20 minutes with no
attention (uninformed waiting* period that adds to
patient stress and dissatisfaction)
See the doctor; present printed PHR to the doctor;
complain about Dyspnea on exertion and other
symptoms
Take physical exam and heard he has elevated
jugular venous pressure (but no clear idea what it
is and what to expect); told to get a number of
diagnostic tests (more worried); no time for
questions since the doctor is extremely busy
seeing the next patient
10 min informed waiting (anxious)
Finish 6 lab tests (exhausted, worried); told to get
lab tests in about 1 hour
1 hour informed waiting (still anxious)
35 min uninformed waiting (anxious)
See doctor and told systolic blood pressures < 90
mmHg and signs of significant volume overload
(still no idea); doctor said no big problem and
prescribe medication (still a little worried)
Get medicine at pharmacy and go home
9.00
9.10
9.20
9.30
9.40
9.50
10.10
10.50
11.00
11.10
12.00
12.35
12.50
13.00
9.30
9.20
9.40
11.00
Rest at home
Timeline
process-driven
Fig. 9. Comparison and description of two scenarios for the use case
Note: *In uninformed waiting, patients do not know how long they need to wait and often even
why they are waiting; In informed waiting they know and can also interact to receive updates.
6 Conclusions
In general, care providers should promote consistency and uniformity in care delivery
through implementation of evidence-based practice. The paradox is that on the one
hand, it is desirable to reduce variation by standardizing workflows to conform to best
practice; on the other, clinical pathways should be designed to allow flexibility to
meet specific needs of patients and resource constraints of a medical facility. Thus, a
formal and radically new approach is required for streamlined communication be-
tween patients and providers to deliver evidence-based, yet personalized, care where
patients can play a more proactive role in their health care matters. In this paper we
described the blueprint for such an approach in detail.
In future, we plan to extend and refine the structure of the patient conversation
model based on inputs from health professionals and patients. We also intend to au-
tomate the construction of the conversation model. A proof of concept prototype is
anticipated and further details of a cloud-based infrastructure are to be worked out.
References
1. Purdue University: A Healthcare-Delivery System for the Next Generation. (2006)
2. Institute of Medicine: Crossing the Quality Chasm: A New Health System for the 21st
Century. National Academies Press, Washington, D.C. (2001)
3. Peleg, M., Tu, S., Bury, J., Ciccarese, P., Fox, J., Greenes, R.A., Hall, R., Johnson, P.D.,
Jones, N., Kumar, A., Miksch, S., Quaglini, S., Seyfang, A., Shortliffe, E.H., Stefanelli, M.:
Comparing computer-interpretable guideline models: A case-study approach. Journal of the
American Medical Informatics Association 10, 52-68 (2003)
4. de Clercq, P.A., Blom, J.A., Korsten, H.H.M., Hasman, A.: Approaches for creating
computer-interpretable guidelines that facilitate decision support. Artificial Intelligence in
Medicine 31, 1–27 (2004)
5. Müller, R., Greiner, U., Rahm, E.: Agentwork: a workflow system supporting rule-based
workflow adaptation. Data & Knowledge Engineering 51, 223–256 (2004)
6. Reichert, M., Dadam, P.: ADEPT flex—supporting dynamic changes of workflows without
losing control. Journal of Intelligent Information Systems 10, 93–129 (1998)
7. Koenig, J.: JBoss jBPM white paper. JBoss Labs (2004)
8. Delon, S., Mackinnon, B.: Alberta's systems approach to chronic disease management and
prevention utilizing the expanded chronic care model. Healthcare Quarterly (Toronto Ont.) 13
Spec No, 98-104 (2009)
9. Breen, G.-M., Wan, T.T.H., Zhang, N.J., Marathe, S.S., Seblega, B.K., Paek, S.C.:
Improving Doctor–Patient Communication: Examining Innovative Modalities Vis-à-vis
Effective Patient-Centric Care Management Technology. Journal of Medical Systems 33, 155-
162 (2008)
10. Kim, M.I., Johnson, K.B.: Personal health records. Journal of the American Medical
Informatics Association 9, 171–180 (2002)
11. Porter, S.C., Cai, Z., Gribbons, W., Goldmann, D.A., Kohane, I.S.: The asthma kiosk: a
patient-centered technology for collaborative decision support in the emergency department.
Journal of the American Medical Informatics Association: JAMIA 11, 458-467 (2004)
12. Locatelli, P., Baj, E., Restifo, N., Origgi, G., Bragagia, S.: Open Source Clinical Portals: A
Model for Healthcare Information Systems to Support Care Processes and Feed Clinical
Research. In: Arabnia, H.R., Tran, Q.-N. (eds.) Software Tools and Algorithms for Biological
Systems, vol. 696, pp. 667-677. Springer New York, New York, NY (2011)
13. Lenz, R., Reichert, M.: IT support for healthcare processes-premises, challenges,
perspectives. Data & Knowledge Engineering 61, 39–58 (2007)
14. Konstam M, D.K., Baker D. : Heart Failure: Evaluation and Care of Patients with Left-
Ventricular Systolic Dysfunction. Rockville (MD): Agency for Health Care Policy and
Research (AHCPR) (AHCPR Clinical Practice Guidelines, No. 11.), (1994)
15. HL7: Health Level Seven.http://www.hl7.org/
16. Li, M., Yu, S., Ren, K., Lou, W.: Securing personal health records in cloud computing:
Patient-centric and fine-grained data access control in multi-owner settings. Security and
Privacy in Communication Networks 89–106 (2010)