A Framework for Incorporating Patient Preferences to Deliver Participatory Medicine via Interdisciplinary Healthcare Teams

Abstract

Participatory medicine refers to the equal participation of patients and interdisciplinary healthcare team (IHT) members as part of care delivery. Facilitating workflow execution is a significant challenge for participatory medicine because of the need to integrate IHT members into a common workflow. A further challenge is that patient preferences should be considered when executing a workflow. To date there is limited research on supporting patient workflow as part of participatory medicine practices. To address that shortcoming we used a two-phase approach to develop a framework for participatory medicine that integrates different IHT members and workflows including the incorporation of patient preferences about care delivery options. Our framework uses a domain ontology to define the patient, IHT concepts and relations, as well as a workflow for operationalizing participatory medicine via an IHT. Proof of concept of the proposed framework is illustrated with a palliative care pain management case study.

Introduction

An increased prevalence of chronic illnesses and the identification of the benefits of team-based healthcare delivery are resulting in more care delivery by interdisciplinary healthcare teams (IHTs) [1,2]. One of the big challenges of care delivery via an IHT is integrating the various workflows and information flows of the different IHT members [3]. While models exist for supporting clinical workflows of individual providers, these models are often unsatisfactory when they are scaled up to support IHTs [4,5]. Therefore new approaches are needed to develop distributed models that represent a meso perspective of how clinical workflows and IHTs are integrated as part of care delivery.

Participatory medicine refers to the equal participation of patients and/or their family members and clinical IHT members in decisions about care delivery [6]. Developing solutions to support participatory medicine is largely about supporting distributed IHT workflows; including having the appropriate IHT member profile for specific tasks [6]. Patient participation in care delivery can have great benefits that include reducing adverse events [8], decreasing hospital lengths of stay [9], increasing patient satisfaction, and improving outcomes such as pain management [10]. However it is a challenge to incorporate patient oriented workflows as part of delivery participatory medicine. [4,7].

In theory, health information systems (HISs) are well suited to support participatory medicine via IHTs as they can coordinate the diverse processes and information flows across different IHT members. A shortcoming with existing HISs, however, is that they often focus on individual workflows and not on the distributed workflow that defines an IHT [7,11]. Before we can design HISs to support participatory medicine we need to develop better models of participatory medicine and the distributed workflows that define it [7]. In particular there is a need for models that incorporate patients as active members of an IHT. To date most HIS applications to support patient participation are generic and focus largely on information access and not on how to support patient participation in processes like decision-making. Examples of existing patient participatory applications include healthcare specific applications like ‘Patients Like Me’ and generic social media platforms like Facebook or Twitter. A new term, “healthicant,” has been suggested to describe technology-enabled applications to enable patient participation in their healthcare delivery [12]. HIS design to support “healthicant” activities differs from current patient-participatory applications (i.e. Patients Like Me) in that the focus of HISs needs to be on eliciting patient preferences and using them in the creation and execution of patient-oriented workflows [12].

Although the need for care delivery via IHTs and participatory medicine has been well described there is a lack of frameworks showing how to integrate patient preferences and IHT workflow to deliver such deliver care. Existing models of IHTs are conceptual and does not provide details of how to operationalize them in clinical settings [13]. Moreover most of them focus just on isolated tasks conducted by individual providers [3]. Furthermore there is a shortcoming of frameworks showing how to incorporate patients as part of participatory medicine. Patient participation is a workflow issue for clinicians who are unprepared for the impact that patient participation will have on their workflow [14].

We believe that there are three key areas related to IHTs and participatory medicine that require more research attention. First, we need more formal approaches for developing distributed models of IHTs that support the dynamic integration an IHT and a workflow including assignment of tasks and team leadership and maintenance. Second, we need to incorporate patient preferences into the models to enable true participatory medicine. Third, we need approaches to enable us to operationalize the model in clinical settings. This paper addresses these three research needs by developing a framework for participatory medicine that integrates different IHT members and workflows including the incorporation of patient preferences about care delivery options. We present a two-phase modeling approach to develop a framework for participatory medicine by an IHT that includes patient participation. We then illustrate operationalization of our framework with a case study of palliative care pain management. We conclude the paper with a discussion and implications of our research.

Method

Ontological engineering was used as the research approach for modeling participatory medicine via an IHT. Ontologies formalize knowledge by means of concepts, attributes to characterize them, and relations between the concepts [15]. In ontological engineering a domain ontology, often referred to as a knowledge base, is developed first. Application ontologies are then developed by defining instances of classes from the domain ontology for the purpose of solving specific problems [16]. Ontologies have been used in healthcare for various tasks such as systems design, execution of clinical guidelines and representation of workflow for point of care decision support system design [17, 18]. Ontologies are particularly valuable for modeling concepts that are dynamic or flexible such as healthcare teams [19].

Proposed Framework

We followed a two-phase process to develop a participatory medicine-Interdisciplinary health Team (PM-IHT) framework. In the first phase we developed a conceptual model in the form of a textual description of important concepts needed for modeling an IHT (e.g., team, patient, preferences, and workflow), relations between them, and strategies to operationalize these concepts (e.g., a strategy to form and maintain a team, integrate patient preferences). In the second phase we formalized the conceptual model into a domain ontology and a set of algorithms detailing the operationalization strategies. In the following sections we describe the results from both phases with an emphasis on the domain ontology, as it is the central component of our framework.

The conceptual modeling phase (phase 1) assumes that an IHT manages a patient according to a case-specific workflow. We define a case as a disease or specific trauma that is managed by a workflow. The IHT is formed when the disease specific workflow is identified and patient management starts and is disbanded when the execution of the workflow (and related patient management) is completed. The team has a leader responsible for overseeing the execution of the workflow, for handling exceptional situations and for assigning workflow tasks to appropriate team members (i.e., members who are capable of performing the task). Drawing upon the principles of participatory medicine [6], the leader may consult with the patient prior to making any relevant decisions (e.g., selecting a therapy, or selecting a team member). The team has one leader at a time but s/he can change during workflow execution (e.g., at one point a physician might be the leader, while at another this role is transferred to a nurse). Finally, an IHT can be modeled as static entity, where a team is formed and remains in place for the entire workflow, or a dynamic entity, where members are recruited as needed and discharged after the task is executed. Given that care delivery in itself is a dynamic process, our conceptual model employs a hybrid approach where the IHT always has a leader (static approach), while other team members are recruited as needed to execute tasks from the workflow and then are dismissed from the team after task completion (dynamic approach). However, it is important to stress here that the leadership role is static but the team member assigned to this role can change.

Phase 2 formalizes the conceptual model into a domain ontology that serves as the PM-IHT framework (Figure 1). The framework can be divided into three areas that define the concepts and relations associated with the team, patient and workflow respectively. These three areas are not mutually exclusive but rather there are two concepts, valued capability and presentation, that are shared between the three areas. The concept of valued capability is fundamental for our framework. It couples a capability, understood as an ability to perform a certain clinical task [20] (e.g., ability to conduct a particular assessment), with an additional score that indicates the competency associated with this capability (for example, it may correspond to the level of clinical expertise). The other shared concept, presentation, represents any presenting complaint by the patient (e.g., a disease, symptom, or other problems).

Figure 1.

Domain ontology for the PM-IHT framework

We now describe each of the three main areas (team, patient, and workflow) of our PM-IHT framework.

Team-related Concepts and Relations

Team-related concepts are team, representing an IHT, and practitioner, representing any care provider (physician, nurse, pharmacist, dietitian, etc.) who is a member of the IHT. Practitioners are characterized as having valued capabilities, which provides the fine-grained description that is necessary to allocate team members to tasks [20]. The team manages a patient case with a certain presentation by executing a workflow specific for this presentation. The workflow is formed upon the patient’s arrival and dissolved once the execution of the workflow has been terminated. Team members – practitioners – are recruited dynamically based on their valued capabilities (see the description of the workflow-related concepts below) and dismissed after they have completed their delegated tasks.

The team has a leader who is responsible for considering and following the patient’s preferences when executing a workflow, for delegating tasks to team members, and for handling exceptional situations (e.g., inability to reconcile patient preferences). The leader is appointed just after forming the team and the leadership may change throughout the workflow execution depending on the requirements prescribed in the workflow (see the description of workflow related concepts below).

Patient-related Concepts and Relations

The patient-related concepts include patient, partner, preference model, and episode. The first two concepts complement each other – patient represents a receiver of care and “provider” of clinical data (associated with an episode of specific presentation), and a partner represents the patient as an active participant in all decision-making activities that affect care delivery. The partner concept is crucial from the perspective of participatory medicine.

A partner has one or more preference models that are consulted before making various types of decisions (e.g., selecting a specific intervention among different possibilities). While there are different approaches to represent preference models, we advocate using functional models with additive value functions. Such models are well established and widely used in clinical practice in the form of various score or measures. A drawback of functional preference models is the difficulty associated with their elicitation. However, several methods, e.g., GRIP [21], have been proposed to construct such models from examples of decisions in order to structure relevant preferences.

In terms of interactions between the partner and the team, it is the leader who is responsible for communicating with the partner, presenting possible decision options, and capturing suggestions. More specifically, before recruiting any new team member, the leader presents eligible candidates to the partner who applies the preference model to identify the most preferred one. Moreover, wherever a task involves any decision-making related to the patient (e.g., selecting a therapy or a procedure), the available choices are communicated by the leader to the partner who consults a preference model in order to identify the best choice.

While in most cases the patient and partner is the same person, there are situations where it necessary to have a distinction between the two concepts because they may be two different people. For example, during the care of a pediatric patient it is parent or guardian who becomes the partner. In palliative care it may be a family member who is the partner if the patient is too ill or otherwise unable to make a decision. Thus, separation of these two concepts allows us to employ the principles of participatory medicine regardless of circumstances.

Workflow-related Concepts and Relations

The workflow-related concepts and relations between them have been inspired by Business Process and Model Notation (BPMN) [22]; however, they have been expanded to address the specificity of IHTs and participatory medicine. The central concept is clinical workflow that is specialized into specific workflow and generic subworkflow. The former represents a “top-level” workflow that is associated with a specific presentation that is executed upon arrival of a patient with this presentation. The latter is a generic workflow (i.e., not associated with any presentation) that may be invoked by other workflows as a supporting workflow.

Each clinical workflow is composed of arcs and nodes, so it can be seen as a directed graph. The node concept is specialized into a gateway node, event node and activity node, depending on its purpose. The gateway node is further specialized into decision gateway node and parallel gateway node, which allows for conditional branching and parallel paths respectively. Event nodes are used to indicate starting and ending nodes in a workflow (via start event node and end event node). Finally, an activity node is specialized into task node, sub-workflow node and leadership node, corresponding to the three types of basic activities in a workflow – executing a clinical task, invoking a sub-workflow, and appointing the team leader, respectively. A clinical task can be delegated to a single practitioner who satisfies a requirement specified in terms of valued capabilities. Such a requirement is defined by associating valued capabilities with a task node. A practitioner has to possess all the required capabilities and his/her competency scores of possessed capabilities should be equal or better than competency scores of the required capabilities. The same mechanism for specifying and checking requirements is applied to leadership nodes – the only difference is that selection of the leader has a more permanent nature as the selected leader is retained until the next leadership node is encountered. Moreover, if a new leader is appointed in an invoked sub-workflow, the previous leader is retained and restored once the sub-workflow has been completed. As we explained above, the leader is selected after forming the team and the team has to have a leader at all times. This is achieved by introducing at least one leadership node into a workflow right after the start event node.

Case study: Palliative Care Pain Management

We used a case study of a palliative care pain management derived from a local palliative care unit. Palliative care aims to improve quality of life of patients and their families through the prevention and relief of suffering by means of early identification and assessment and treatment of pain and other symptoms including physical, psychosocial, and spiritual symptoms [23]. Palliative care is well suited for illustrating the interplay between participatory medicine, workflow execution, and patient management because a basic tenet of palliative care is that patients (or family members) are involved in care decisions and processes that implement decisions.

Pain management is a significant component of any palliative care management protocol as it is estimated that up to 70% of advanced cancer patients experience pain [24]. Pain in palliative care patients is complex and can include physical, spiritual, and psychosocial dimensions [25]. These different dimensions necessitates that palliative care be delivered by an IHT composed of palliative care physicians, psychologists, physiotherapists, nurses, and occupational therapists, among others [26]. The complexity of palliative pain also means that there is a range of possible pain management therapies (i.e. medical, spiritual, psychological) depending on the type and level of pain. A key aspect of palliative care pain management is that patient therapeutic preferences need to be incorporated into the decision-making and subsequent delivery of care services. For example, some patients prefer no pain and are willing to accept the side effects of opioid medications (e.g. drowsiness) to achieve that outcome. Other patients prefer to spend quality end of lifetime with family and friends and would prefer therapies that combine opioid and non-pharmacological therapies in order to manage drowsiness. Thus palliative care pain management needs to be tailored to the preference of each individual patient [27].

The process of palliative care pain management starts with assembling a palliative care team according to the framework presented earlier in order to execute the appropriate workflow. Drawing on existing pain management guidelines [25, 28] and in consultation with domain experts, we developed a set of workflows (a specific workflow and several sub-workflows) to sequence and structure all activities associated with assessing, diagnosing, and managing a palliative care patient’s pain. Figure 2 shows a specific (top-level) workflow and selected sub-workflows. We used a standardized notation inspired by BMPN (Business Process Model and Notation) [22] to represent the workflows. In order to distinguish between particular types of activity nodes (represented as rounded rectangles) we use colors – sub-workflow nodes are white, task-nodes are light grey, and leadership nodes are dark grey. All task and leadership nodes are associated with required valued capabilities with competency scores expressed on the Likert scale (1 indicates the competency of a beginner/resident, 2 – the competency of a staff clinician, and 3 – the competency of an expert). The competency scores (and also the valued capabilities in table 1) are for the illustrative purposes only. They were determined from the pain management guideline in consultation with the palliative care clinicians consulting us on this research. Finally, we use the “consult with partner” tag to highlight the task nodes where the partner’s preferences need to be incorporated and reconciled.

Figure 2.

Overall IHT workflow for palliative care pain management (scores in brackets are competency scores for the task)

Table 1.

Team members and possessed valued capabilities

Practitioner	Possessed valued capabilities
Palliative care physician	access_PQRST (2) classify_pain (2), evaluate_clinical_condition (3) reconcile_therapy (3) plan_pharmacological_therapy (3) plan_occupational therapy (2)
Clinical nurse specialist	assess_PQRST (3) classify_pain (3) evaluate_clinical_condition (2) evaluate_psychosocial_condition (2) implement_pharmaceutical_therapy (2) implement_occupational_therapy (3)
Nurse practitioner	evaluate_clinical_condition (1) implement_pharmaceutical_therapy (2) implement_occupational_therapy (1)

Patient management starts with the task of establishing an IHT leader who possesses the capabilities specified in the workflow. An initial assessment of the patient’s condition follows. Completion of this activity requires executing an assessment sub-workflow that involves clinical and psychosocial and assessments and pain evaluation. While clinical and psychosocial assessments are tasks to be completed by appropriate team members (therefore they are ascribed with the required valued capabilities that control recruitment and selection of practitioners), pain evaluation is guided by a separate sub-workflow. This sub-workflow involves pain evaluation using the PQRST (provoking, quality, region, severity, and timing) pain evaluation tool for pain classification [29]. Once the initial assessment is completed, execution of the workflow continues. Palliative care pain management is an ongoing process that involves frequent reassessments and adjustments of the therapies in response to changing state of the patient [28]. The workflow terminates when therapy is no longer revisable and a new therapeutic workflow is needed.

In order to illustrate the versatility of the proposed framework, we will use two examples showing how the IHT is operationalized. One example involves the transition of a leader role, and the other illustrates how a partner’s (patient, family member, etc.) preferences are explicitly taken into account when the therapy-planning task is executed.

Example 1: Dynamic Selection of the Team Leader

Table 1 provides information about the practitioners who could be IHT members executing the palliative care workflow from Figure 2. At the outset of palliative care pain management, a team leader is identified that is capable of planning the pharmacological and occupational therapies (i.e. the leader is chosen based on the competency scores ascribed to the tasks in Fig 2).

According to the data from Table 1, the only practitioner who meets the leadership requirement is a palliative care physician, who therefore becomes the team leader. The leadership remains unchanged until the therapy implementation sub-workflow needs to be executed. At that time new leadership requirements are encountered and in this case a clinical nurse specialist becomes the IHT leader. Once the therapy implementation sub-workflow is completed, the leadership goes back to the palliative care physician.

Example 2: Considering Partner’s Preferences in Therapy Planning

Participatory medicine advocates that a patient is an active participant in decision-making and care plan development. According to the IHT framework presented in the paper, we incorporate the tenet of participatory medicine through the concept of a “partner” – who can be a patient, family member, or legal custodian. We illustrate how patient preferences interplay with a tasks’ execution by the practitioners by using an example of therapy planning for pain management (specifically we focus on the therapy reconciliation task).

The patient’s pain was assessed and determined to be in step 1 on the WHO Analgesic Ladder [30]. This corresponds to an assessment of a mild to moderate pain that should be managed with non-opioid analgesics, possibly combined with an adjuvant such as anticonvulsant or antidepressant medication. Assessment of the patient’s psychosocial and clinical condition identified the possibility of combining pharmacological management with a non-pharmacological approach for pain management. The following three therapeutic options were identified by the IHT: (1) a standard therapy, (2) a therapy with alternative route of administration (transdermal) and (3) a less frequently applied therapy using cannabinoids (they have been demonstrated to have significant analgesic properties, but also are associated with a number of side effects like dizziness or nausea). The three therapies are given in detail in Table 2.

Table 2.

Identified therapeutic options

	Pharmacological	Adjuvant	Non-pharmacological
Therapy 1	Acetaminophen administered orally	Antidepressant medication	Superficial heat & cold method
Therapy 2	NSAID with transdermal administration	Antidepressant medication	Guided imagery
Therapy 3	Cannabinoids by oral mucosal spray	None	None

The patient preference model for therapy selection in this particular case was constructed using the Generalized Regression with Intensities of Preferences (GRIP method) [21]. First, possible therapy options were characterized using two criteria: complexity of a therapy and associated drowsiness. The complexity of a therapy was defined by the compliance burden associated with this therapy – for example, a therapy that involves taking one dosage of medication per day has low complexity, while a therapy that involves multiple doses using different modes of administration has high complexity. Then, we elicit patient preferences by asking a patient to compare pairs of possible therapies. Once this preferential information is collected, it is processed by GRIP to calculate the so-called marginal value functions for the patient. These functions represent patient preferences associated with individual criteria (there is a separate function for each criterion) and constitute the patient preference model (see Table 3). It includes two marginal value functions (complexity and drowsiness), each represented as a set of numerical scores (marginal values) for all possible evaluation criteria. Higher marginal values are preferred by the patient. The patient preference model shows that the patient prefers therapies of low complexity that cause minimal drowsiness.

Table 3.

Patient preference model for assessing therapies

Complexity		Drowsiness
Evaluation	Marginal value	Evaluation	Marginal value
low	0.4	minimal	0.6
medium	0.2	moderate	0.2
high	0.0	maximal	0.0

The patient preference model not only gives insight into patient preferences, but it can be also used to evaluate therapies according to these preferences. The overall value of a therapy is computed by adding the marginal values for each individual criterion. The best therapy would get the overall value of 1.0, while the worst one would get a value of 0.0. The preference model is then used to assess the potential therapies (see Table 2). Table 4 presents the evaluations for each therapy for the two criteria, as well as the overall value. Based upon the patient’s preferences, therapy 3 is the most preferred therapy (overall value of 1.0) - it involves just one medication type, is simple to administer, and also causes minimal drowsiness. Therapy 3 is therefore selected to manage the patient’s pain.

Table 4.

Assessment of identified therapies

	Complexity	Drowsiness	Overall value
Therapy 1	medium	moderate	0.4
Therapy 2	low	moderate	0.6
Therapy 3	low	minimal	1.0

Discussion

While participatory medicine is a common healthcare objective there is a shortcoming of studies that illustrate how to operationalize it through an IHT. Further, despite calls for patient centered workflows there is a dearth of studies showing how to implement them in clinical settings. In this paper we presented a framework for IHTs that integrate multiple workflows to support participatory medicine that includes patient participation. The novelty of our research lies in the detail we provide on how the IHT is assembled for a particular situation. A patient’s presenting condition drives the creation of a workflow specific for that presentation. We then use the notion of capabilities and competencies to assign IHT members to tasks as part of the workflow. We also assign an IHT leader role to the workflow that is responsible for considering and incorporating patient preferences into the workflow and for delegating tasks to IHT members based upon capabilities. Finally, we define a series of patient related concepts that enable the active incorporation of patient preferences into the IHT workflow. A preference model was developed to formalize the potential options to enable the patient or family member to make an informed decision about their preference.

To date much of the work on IHTs has focused on specific activities such as information seeking or group decision-making. However an IHT is not a set of isolated tasks but rather a distributed workflow that needs to integrate IHT members and task capabilities during workflow execution. IHT workflow is also very dynamic and a key part of workflow execution is coordinating team members to be in the right place at the right time to enable timely completion of workflow tasks and re-scoping of workflow if patient preferences change. Our framework provides the means of coordinating IHT members (through team leaders, capabilities and competencies) as well as re-tailoring the workflow if patient preferences change.

Our framework has implications for HIS design to support participatory medicine. A shortcoming of existing HISs is that they do not assume team-based management or allow for incorporating patient preferences, and therefore are not designed to support participatory medicine. The first step in HIS design is requirements definition and development of a conceptual model to drive HIS design. Our framework provides such a foundation by first developing a conceptual model of patient and IHT support as part of operationalizing participatory medicine. In phase 2 we formalize the conceptual model into an ontology that describes the concepts, relations, and workflows for participatory medicine. Two specific contributions from our framework are one, an attempt to implement participatory medicine principles by explicitly accounting for patient’s preferences and two, the dynamic alignment of an IHT and a workflow, including support for assignment of tasks to practitioners, team leadership, and team maintenance. A key factor in HIS design to support participatory medicine is that system design cannot be done with a one size fits all mindset. IHT composition and the workflows that support it are dynamic and may change according to patient preferences. A key aspect of our model is that it enables a HIS to be designed to enable run time agility to support the dynamic nature of IHTs (i.e. leadership changes, evolving tasks) as part of implementing participatory medicine.

The next step in our research is translating our framework into a prototype multi-agent system (MAS). This will be done in two stages. First we first we assume that the practitioners are represented by the agents. Second, we will use the domain ontology (fig. 1) and follow ontology-driven design combined with O-MaSE [18] to design a prototype participatory medicine HIS. The HIS will be implemented using Workflows and Agent Development Environment (WADE) [31] for workflow execution.

In this paper we provided methodological foundations of our framework and illustrated them with a case study of palliative care pain management. We discussed how our framework enabled selection of team leader and how participatory medicine principle of patient involvement was explicitly modeled through inclusion of a “partner” team member and a preference model. While the research presented in this paper is illustrated using a specific case study of palliative care pain management, the proposed modeling framework is applicable for supporting other patient management situations involving IHTs.

Conclusion

There is an increasing body of knowledge calling for care delivery via participatory medicine that includes patient participation. However there are few studies that provide the means of operationalizing the workflow to deliver patient engaged participatory medicine. This paper provides a framework of how to operationalize participatory medicine, including patient preferences, via an IHT. Our framework can be used to design and evaluate informatics solutions for supporting participatory medicine.