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)