A Model to Support Shared Decision Making in Electronic Health Records Systems

Abstract

Shared Decision Making (SDM) is an approach to medical care based on collaboration between provider and patient with both sharing in medical decisions. When patients’ values and preferences are incorporated in decision-making, then care is more appropriate, ethically sound, and often lower in cost. However, SDM is difficult to implement in routine practice because of the time required for SDM methods, the lack of integration of SDM approaches into electronic health records systems (EHRs), and absence of explanatory mechanisms for providers on the results of patients’ use of decision aids. This paper discusses potential solutions including the concept of a “Personalize Button” for EHRs. Leveraging a four-phased clinical model for SDM, this article describes how computer decision support (CDS) technologies integrated into EHRs can help insure that healthcare is delivered in a way that is respectful of those preferences. The architecture described herein, called CDS for SDM, is built upon recognized standards that are currently integrated into certification requirements for EHRs as part of Meaningful Use regulations. While additional work is needed on modeling of preferences and on techniques for rapid communication models of preferences to clinicians, unless EHRs are re-designed to support SDM around and during clinical encounters, they are likely to continue to be an unintended barrier to SDM. With appropriate development, EHRs could be a powerful tool to promote SDM by reminding providers of situations for SDM and monitoring on going care to insure treatments are consistent with patients’ preferences.

Introduction

Shared Decision Making (SDM) is a widely held ideal for clinical practice that is, according to a recent New England Journal Commentary by Barry and Edgman-Levitan, the “pinnacle of patient centered care.” (1) SDM includes both patient use of decision aids and clinical decision making that is respectful of patients’ preferences and values. While electronic health record systems (EHRs) often have companion systems that may promote patient engagement such as patient portals, EHRs contain very little data about patients’ health preferences and values, except for largely un-encoded data on end of life care preferences.

Why should we be concerned about patients’ preferences? As recently argued by Mulley and coauthors, healthcare providers often “misdiagnose” their patients’ preferences and at times, misdiagnosis can have serious consequences (2). In other contexts, patients’ cognition may be impaired or their diseases may evolve too quickly for patients to participate in SDM and previously reported preferences may need to direct care. (3) This paper proposes a model for use of clinical decision support (CDS) techniques to alert clinicians to opportunities for SDM with using Electronic Health Records (EHRs), help them individualize care using decision aids, monitor care for a potential misdiagnoses of preferences, and alert providers of actions potentially inconsistent with patients’ preferences.

Background

SDM is based on a model of communication where healthcare provider and patient each contribute to clinical decisions in unique ways: clinicians offer information on options health risks and benefits; patients describe their preferences and values. Decisions are shared between clinician and patient in two-way discussions (“deliberation”) after appropriate patient education and values clarification exercises. (4) Value clarification exercises are tools to help patients understand their own preferences both about treatment strategies and also about outcomes or health states. (5) In many circumstances, education and value clarification tasks are performed using clinical decision aids (DAs). DAs have been developed in paper, audio booklet, video, and website formats, and have internationally recognized standards for content (6–8). Meta analyses of DAs show that these tools typically increase the knowledge of the patient about risks and benefits and reduce the amount of conflict that they feel making any given decision (9). Use of DAs also may reduce unnecessary care (10), Recent trials suggest as much as 30%^ for knee and hip replacements (11, 12)

However, these trials also identified many barriers to use of DAs and SDM in clinical care. Foremost is the time required for use of existing SDM techniques. (12) Legare and coauthors describe time requirements as a “universal perceived barrier” in a meta-analysis. (13) In a world in which clinicians have 18 or more hours’ worth of work to do in an 8-hour day (14) and in which less than 60% of recommended practices are provided to patients (15), it is easy for SDM to take a back seat to activities that are known to improve health.

Applying informatics technologies to support SDM in hospital and clinic

Implementation Science is the branch of translational research that addresses the adoption of proven technologies by providers. (16) Appropriate use of informatics tools is a critical component of implementation science (17). As EHR use becomes ubiquitous in medical practice (in 2013 about 72% of providers used an EHR (18), integration with EHRs will become more central to strategies to remind provides of opportunities for SDM and to integrate SDM into the workflow of their clinics, Furthermore, the ongoing government incentive/penalty program based on certification “Meaningful Use” (19) provides a potential means to mandate the inclusion of specific technologies, such as those required for SDM, into computer software for EHRs.

How could EHRs support SDM? Figure 1 shows our model for integration of SDM into clinical workflows through EHR technology. The approach stresses separation of software for assessment of patients’ preferences and for decision support on preferences from vendor’s “closed box” functionality using informatics standards-based methods. This is critical both for economies of scale and to expand, as described below, the types of assistance that could be offered to both patients and providers. Moreover, without a standards for support of SDM, it seems likely that, similar to the current environment for CDS in EHRs, a hodge podge of incompatible systems would evolve that would require each vendor of EHRs to develop its own technologies and would limit the availability of EHR compatible decision aids. Our approach is based on a four-phase conceptual model of integration of the SDM process into clinical workflows that combines the work of several groups of authors (11, 12, 20, 21). The phases are: (1) identifying and context for SDM and initiating the process, (2) exploring options for care, (3) deliberation between patient and provider on the risks and benefits of different approaches and (4) monitoring of ongoing care to ensure treatments respect preferences.

Figure 1.

Overview of CDS for SDM system.

Initiating SDM

SDM cannot occur unless a provider and patient, within a clinical encounter, mutually recognize a context with preference sensitive care ((21))—a situation where equipoise about treatment options exists and where patients preferences should drive healthcare choices (Step 1) There are essentially Four options for interface designs for software systems in EHRs to help a provider recognize and respond to a context for SDM: blocking EHR alerts, reminder style EHR alerts, Infobuttons, and standing orders.

Option 1, which is widely used in clinical decision support, is to set up an alerting system that presents alert that blocks operations in the EHR until a user provides input. In a case where patient’s preferences should direct care (example: treatment of systolic hypertension in middle aged patients (22). The EHR alert activates a “popup” dialogue box on its interface that blocks the provider from taking further actions in the EHR until the provider responds to the alert. (23) The dialogue box would give the provider two options: initiating SDM or dismissing the alert. An example of a rule-based alert is shown in Figure 2. Note that in the past, rule based alerts have been developed for the opposite context: situations where there is strong evidence as to what the provider should do (example: vaccinate a 60 year old male previously unvaccinated with pneumovax).

Figure 2.

"Blocking" style alert for shared decision making.

There are pluses and minuses to using a rule-based alerting system and blocking provider activities. Because this alert interrupts the provider’s actions (what is called in the industry a “hard stop”), it forces the provider to stop what he or she is doing for care with the EHR to address the issue of SDM (24). This can results in “alert fatigue” -- providers ignoring the advice of the computer system, even when appropriate (25). In some settings, providers override 90% of certain types of blocking alerts. (26) Moreover, if a provider did not complete his or her note while in the room with the patient, the alert would serve no purpose (23). Because of their intrusive nature and the cumulative effects of alert fatigue, some software developers believe that blocking alert dialogue boxes should only be used for urgent clinical problems.(27)

A second approach is the use of an asynchronous alerting system. (23). As shown in Figure 3, asynchronous alerting systems display actions that a provider needs to undertake at some time within the visit, but may be clinically optional in some circumstances, in a dedicated portion of the screen. Examples of these types of actions might include an order for a diagnostic test (HBA1C) or to check a blood pressure or to review of its results. Asynchronous alerts are reminders for providers to take appropriate actions, but do not block providers from taking other actions within the EHR. The number of asynchronous alerts that physicians have to respond to in some EHR systems can be very large—more than 50 alerts a day. (23). As the number of alerts grows, providers increasingly dismiss alerts, even if clinically correct, without reading or acting on the information in the alerts. Rules for triggering of alerts might be integrated into an institutions EHR (the current technology), where each EHR implementation has to have its own rules, or might be exist in an Internet-based knowledge repository to which the EHR sends anonymized patient data (28).

Figure 3.

Reminder style alert implemented within the Veteran's Administration's CPRS system.

Option 3 is based on the use of the Context-Aware Knowledge Retrieval standard (Infobutton) (29). Infobutton is a computer-software standard that provides a Web-based mechanism for EHRs to convey the clinical context of a particular patient to online resources using standard clinical terminologies so that the resource can individually tailor materials retrieved. Software developers have found infobuttons to be easy to implement and the infobutton standard functionality is a requirement for EHR certification in the United States for Stage 2 of Meaningful Use(30).

To assist providers with recognition of a context for SDM in an unobtrusive way that does not interrupt workflows or contribute to alert fatigue, we propose inserting an icon of a person on the EHR to signal such a context. This icon might also appear in a Personal Health Record, to provide a similar signal to patients when reviewing their records to prepare for a visit. We call this icon a Personalize Button and use a different icon than other applications of Context Aware Knowledge Retrieval Standard because personalizing is a fundamentally different task than seeking information to meet an unmet knowledge need (31) (the typical application of software using this standard). Clicking on the person icon accesses, through server customized for the institution information resources on preferences, including how preferences are distributed in the population and the implications for medical decision-making, potential resources for SDM, limitations of assessment methods and past measurements of the preferences of the patient if they exist.

The fourth alternative to initiate SDM is to do it automatically as part of a computerized standing order—an order that applies to all patients in a specific context (32). For example, a standing order for use of a decision aid might be coupled to the order for the referral to a specialist for evaluation for treatment. The default action would be ordering of a decision aid along with the treatment or referral. However, a provider could override the default action. Removing the physician or other provider from the process is probably not advisable, as the context for the decision aid might be incorrect or there might not be equipoise for this particular patient. If, customization of the context for standing orders can occur, a provider may be confident enough in their patient relationship and in the clinical context of referral to use automatic delivery decision aids in some instances.

Exploring Options with the Patient

The next step in most SDM models is for patients to explore the options available for diagnosis or treatment. (20, 21) In our informatics enabled model, this process might be performed outside of the patient provider interview either during a patient visit or at home. After responding to the alert or other reminder, the provider would use the EHR to send an order for use of a decision aid or other software for patient education and preference elicitation to the preference engine. (Step 3). There are parallels between this process and the concept of an “information prescription” (33). The EHR would utilize standards to transmit orders for education and preference elicitation to the Preference Engine. The elicitation engine stores the order until the patient logs in from a web portal or kiosk. As shown in figure 6, a reminder would show the patient that he or she has an educational tool to complete in his or her patient portal account. To access educational and preference elicitation tools, the patient would click on the personalize button or other link. This would signal the preference engine module to access educational materials, DAs, and/or elicit the patient’s health preferences and values via an Internet device such as a patient portal or a smart phone.

Figure 6.

Modification of a patient portal to illustrate a patient specific reminder to complete a tool for SDM.

The preference engine manages the use of online decision aids to explain choices to the patient, tracks the patient’s completion of those materials, tracks preferences elicited by decision aids as part of value clarification exercises in the DA’s, and captures data on accuracy of preference elicitations (findings such as lack of attention or inconsistency in responses (31, 32); Step 4, Figure 1.) These “metadata” (data about data) will be presented back to the provider when the patient “returns” for the next conversation. We believe metadata on the use of decision aids and on preferences may be critical to helping providers understand patients expressed values after use of the decision aid. In addition, if a patient shows inattention to educational materials a provider might want to retest the patient’s understanding of the choices when he or she discusses options later in the process. The results of preference elicitations are influenced by a variety of procedural factors (34–36). These may bias results toward one outcome or another and human intervention may be helpful. If measures of the validity of preference elicitations (37) suggest that elicitations are inaccurate then a provider may want to repeat those measures.

The Preference Engine encodes data on a patient’s preferences and values as well as data about the quality of the elicitations, numeracy and health literacy, and patient’s attention using the CDA Patient Generated Document format (36) and, where appropriate, LOINC identifier codes (38). Preferences and the quality of information from the use of decision aids would be transmitted and stored in the provider’s EHR (Step 5 in Figure 1) for later use, perhaps initially as semi structured data (ie, a text report similar to a radiology result), but as standards evolve, as coded data.

The “native” results of preference elicitation also could be stored in a Preference Repository (Figure 1). This regional or national database would store anonymized patient data for application of “big data” style of decision support techniques to help patients and providers make better decisions. The preference repository is designed to allow decision support using the principles of collaborative filtering. (39) Providers might access this database when reviewing a context for decision making to better understand the baseline variability in patients’ preferences and the need to tailor decisions to preferences. After completion of a decision aid, patients might access this database to learn about the choices of other patients with similar disorders and values to their own. By comparing their values to others and see how other patients made their choices, both patients and provider decision-making could be improved. This approach to decision support is widely used in decision support in retail settings; however, values are typically inferred from prior behaviors (web browsing, movie selection, purchases), rather than measured. However, in this case, storage of the results of use of the value clarification components of decision aids would allow patients to find others with values similar to their own and review their choices.

Deciding on a Treatment Together

The third phase of SDM brings the patient and the provider together to discuss treatment options and to “deliberate”. (20, 40) Currently providers often do not have access to data from decision aids and metadata on patient’s understanding in clinical encounters that follow use of a decision aid. Freidberg, and coauthors’ study found the absence of a mechanism for communicating patient preferences and self-reported values to providers as a major barrier to implementing SDM in a real world study(11). We believe that use of a decision aid should be something more akin to use of a diagnostic test—informative, but not definitive of specific action, with normal ranges and interpretations. Measures of preference require discussion and interpretation prior implementation. (41) Therefore, in the CDS for SDM, in a subsequent encounter or after completing the decision aid, the provider would access reports of the patient’s preferences by looking up the result similar to a lab test, or possibly by using a Personalize Button or after being prompted by an alert in the EHR (Step 6 in Figure 1) Information on the quality of measurements and patient attentiveness from computer assessments would be combined with the reports from the decision aid, to help the provider weigh the results of elicitations, and together, patient and provider deliberate on the best option for care.

Note that, in this model, it is possible, in fact even desirable, for patients to revise his or her preferences for treatments in the decision talk. Providers have special knowledge of local conditions (for example, local variability in the quality of treatment options). Providers also will have seen, in many cases, the outcomes of treatment and how experience with the outcomes may change patients’ preferences. In addition, patients also may have relevant experiences within their family or in their own history that are outside of the scope of the decision aid ordered for them, that should inform the decision-making. Thus, patients and providers can work to counsel each other and avoid decisions that may be short sighted or harmful, consistent with the model of shared decision making as deliberation on options. (42)

Insuring Treatment Respectful of Preferences

After deliberation, providers may require help with tailoring of treatments based on reports of preferences, both to address lack of knowledge on how to tailor and overcome therapeutic inertia. Unfortunately, this may be a common problem. Even after use of a decision aid for colon cancer screening, in a context where providers wanted to personalize care, about 40% of orders for screening were discordant with patients’ preferences (43). One approach to address this issue might be to use rule-based methods (similar to those described for detection of SDM opportunities), to tailor order sets.

A fourth task is ongoing monitoring of care to insure ongoing treatments to insure care respectful of preferences. As we develop better systems to encode patients’ preferences in computer readable form, it will become possible to detect situations where providers orders conflict with patients preferences. In this setting, computer automata that monitor a patients’ medical care and conditions, sometimes called “agents” (44, 45) that run either within an EHR or in some outside infrastructure independent of the health system might monitor care to insure that it is respectful of preferences. For example, in end of life care, if advance directive orders were encoded in computer readable form, a EHR could alert a provider, using a blocking popup style of alert, of an order for mechanical ventilation or other aggressive therapy that was not consistent with the patient’s preferences.

Feasibility

The EHR capabilities and standards used in this approach (Steps 1, 3) are required for EHR certification in MU Stage 2 (30) (i.e, Infobutton). Technologies supporting Steps 6 and 7 are proposed as certification criteria for MU Stage 3 (46). Work done within the Consumer Technology Workgroup of the Standards Federal Advisory Committee for the Office of the National Coordinator for Health information Technology also includes recommendations for how patient generated data should be incorporated into the electronic health record that have specifically been designed to accommodate preference data from decision aids (47).

There are a number of other important obstacles. The wide variety of DAs and the large number of approaches for measurement of preferences, make this a complex area for both healthcare providers and for patients. Cognitively oriented strategies for explaining the results of preference measurement to providers and to help providers to integrate preferences into their clinical reasoning need to be developed. Curation of a formulary of validated DAs and preference elicitation tools will be essential and the use of Infobutton-compliant technologies may make this easier. In addition, proposed models for capture and storage of data on preferences such as those proposed by Ruland and Bakken (38) will need to be refined and extended.

We believe that adding both information on patients’ preferences to EHRs and workflow support is eventually feasible and is supported by existing standards. A first step may be the addition of a Personalize Button to EHRs, which will serve as a non-obtrusive reminder of potential clinical contexts for SDM and as a link to existing DAs, through a lightly modified Infobutton approach. A second step would be the development of DAs that could return to EHRs reports on measures of patients’ preferences, at least in semi-structured form, and the development of EHRs that can store reports of patients’ preferences. This would allow the creation of more adaptive systems. With the development of coding systems for preference data, more complex decision support methods to monitor care could be developed to help insure that health systems always act in patients’ best interests. However, if we are serious about promoting SDM while clinicians are using EHRs during clinical encounters, EHRs will need to be modified to support this task. What is needed is research into how to do this. The technologies exist to make this feasible but the implementation science around how we do this optimally needs further development, starting with demonstration projects and moving to comparative effectiveness approaches.

Figure 4.

Use of personalize "button" (in this setting a left-click option menu) for SDM.

Figure 5.

Use of a "person icon" (personalize button) to highlight a SDM opportunity for influenza and pneumococcal vaccine administration based on preferences.