Lessons from Implementing a Combined Workflow–Informatics System for Diabetes Management

Abstract

Shortcomings surrounding the care of patients with diabetes have been attributed largely to a fragmented, disorganized, and duplicative health care system that focuses more on acute conditions and complications than on managing chronic disease. To address these shortcomings, we developed a diabetes registry population management application to change the way our staff manages patients with diabetes. Use of this new application has helped us coordinate the responsibilities for intervening and monitoring patients in the registry among different users. Our experiences using this combined workflow-informatics intervention system suggest that integrating a chronic disease registry into clinical workflow for the treatment of chronic conditions creates a useful and efficient tool for managing disease.

Introduction

In its landmark report “Crossing the Quality Chasm,” the Institute of Medicine described a gap between knowledge and action. ¹ According to the Institute of Medicine, this gap is the result of a systemwide problem that requires overall redesign of the care delivery system.

Nowhere is the need for systemwide redesign as apparent as in the area of diabetes care. ² Less than 10% of the adults in the United States with diabetes attain recommended treatment goals for glycemic, blood pressure, and cholesterol control. ³ Using a multidisciplinary, population-based approach to diabetes care, we revised our diabetes management workflow process and concurrently implemented a registry population management (RPM) application to manage the patient data. This provided each team member with appropriate and critical information in a timely manner so that they could perform their specific tasks.

In this report, we describe the problems in patient management before we instituted the new application, our implementation of a new workflow model using the RPM application, the RPM application itself, and a list of points to consider before building an electronic diabetes registry based on our lessons learned.

Background

Defining and Using Chronic Disease Registries

In its simplest form, a registry is a list of patients who share one or more common characteristics (e.g., a disease diagnosis) and belong to a practice of one or more physicians. ^4,5 Tracking patients by disease lets clinicians better organize the care of these individuals. ⁴ Advanced registries can provide clinical reminders (e.g., to check a patient's hemoglobin A1c level) and identify patients not meeting specific clinical metrics (e.g., low-density lipoprotein cholesterol levels above goal). Registries are used in at least five distinct ways ⁶ : (1) to generate performance feedback reports to physicians on clinical metrics or end points ^7,8 ; (2) to provide physicians with exception reports that identify patients who are noncompliant; (3) to create point-of-care clinician reminders that summarize a patient's care and identify any tasks that are due; (4) to generate patient reminders that are mailed to the patient when a specific task must be done ^9,10 ; and (5) to identify high-risk patients who require health care resources for more intensive management.

Several studies suggest that registries can improve clinical processes and outcomes for patients with diabetes. 7,8,10–14 However, despite the evidence to support this approach, the overall use of these tools remains low. ^6,15 For example, less than 25% of U.S. primary care practices use a patient registry to track one to three conditions. ¹⁵ Furthermore, Schmittdiel et al. ⁶ surveyed 1,040 physician organizations and found that only 47% of the physician organizations with 20 or more physicians reported having at least one chronic disease registry. Many organizations reported that these registries were not linked to clinical data, suggesting that the registries, although developed, were not being used. ⁶ This lack of active registry use among physician organizations suggests that barriers exist not only in adopting a registry system, but also in continuing to use one as well.

Care management processes, such as disease registries, reminder systems, performance feedback, case management, and self-management education, have been shown to improve the quality of care for several chronic conditions. ^8,16–19 According to a review by Bodenheimer et al., ²⁰ the top five barriers to adopting care management programs are lack of resources, reimbursement that does not reward high quality, inadequate information technologies, physician resistance, and physicians being too busy. In contrast, facilitators to adopting such a system include a mixture of intraorganizational (leadership, culture, and information technology) support, and improved reimbursement.

On the basis of their experience implementing a web-based registry application called Diabetes Flow Manager in 61 primary care clinics, Gabbay et al. ²¹ proposed that to increase their use, registries should be able to identify patients with a specific condition such as diabetes, capture searchable data in real time, link to clinical guidelines via the internet, give feedback to providers, and generate patient letters. We propose adding another critical feature to ensure effective care coordination and sustained registry use: the ability to integrate the system with the organization's workflow. ²²

Integrating Information Technology Registry Tools with the Chronic Care Model

Bodenheimer et al. ⁵ developed the chronic care model as a conceptual framework for designing innovations to change current chronic disease care. This model has been validated for diabetes ^23–25 and describes six key components for managing patients with a chronic illness in a primary care setting: clinical information systems, self-management support, delivery system redesign, decision support, health care organization, and community resources. Key themes of this approach focus on prevention, longitudinal care, and coordinating patient care. The chronic care model approach with regard to diabetes relies on advanced information technology as the backbone for coordinating the management of patients with diabetes.

The chronic care model recommends that the current organization be reorganized. Practice teams with clear divisions of labor must be created, and teams' responsibilities for acute and chronic care must be separated. The chronic care model also suggests using evidence-based clinical guidelines for care that are integrated into daily practice via clinical reminders. The model further suggests that the registry application should present the right information to the right user based on that user's role. Each provider or administrator needs the proper tools not only to intervene but also to quickly record the intervention.

Design Objectives

We had four pre-existing problems with our existing system with which we had to contend: (1) inefficient tracking and managing of pay-for-performance patient data, (2) unclear effectiveness of interventions, (3) no tracking and fewer interventions for non–pay-for-performance patients, and (4) poor information exchange between the Massachusetts General Physicians Organization and practices regarding patient contact.

To address these problems, we redesigned the workflow at the health care organization and practice levels and built a RPM application to support this new workflow. We wanted to ensure synergy between the diabetes workflow analysis and the RPM system design. We designed a system that would accurately assess patients, determine their needs, provide interventions, and track the effectiveness of these interventions, all in real time, while freeing up staff time for important considerations like patient care. Because workflow change and implementing an information technologies solution are inextricably linked, we wanted to ensure cooperation within the system between administrative and clinical processes. In this article, we describe our experiences and the lessons learned as we designed and integrated a novel intervention that includes informatics and workflow changes.

Workflow Analysis and System Design

Understanding Workflow Using Activity Diagrams

Activity diagrams are useful for showing information flow. ²⁶ To construct activity diagrams that would identify diabetes patients needing a clinical care reminder, we interviewed two administrators, three diabetes nurse managers, and four physicians directly involved with diabetes management. We selected these people because they accurately represent each of the three tiers that manage pay-for-performance patients with diabetes at our institution. Questions in our analysis focused on who performed what aspects of care, how often, in what context, and in what order. In addition to these interviews, we spent four sessions at the practice sites and three sessions at hospital administrative offices observing the delivery coordination of existing diabetes-related care. Based on these focus groups and observations, we constructed activity diagrams of the current diabetes management process. During this time, we also asked users how they would perceive ideal diabetes care workflow. Using this feedback and collaborating with the administrative staff at the Massachusetts General Physicians Organization, we designed a new workflow for managing diabetes care at our institution.

The Revised Diabetes Population Management Workflow at Massachusetts General Hospital

We developed two activity diagrams: The first diagram shows the workflow patterns for management without the RPM application (▶), the second represents the revised workflow that operates with the RPM application (▶). In our revised workflow process (▶), we shifted the responsibility for identifying patients needing a reminder from the central office to the practices, thereby removing the need for centrally created patient lists for practice review, and increasing the sense of process ownership with the practice nurses. We established and validated this shift in responsibility with our pilot practice.

Figure 1.

Activity diagram for the current workflow for contacting diabetic patients.

Figure 2.

Activity diagram with RPM. Dashed lines represent optional pathways.

Registry Design, Development, and Deployment

Once we defined the new diabetes population management process and it had been accepted by the administrators, physicians, and nurses, we designed a registry application to facilitate the new workflow. By consulting anticipated users and using small iterative cycles of change during the design process, we emphasized features that facilitated workflow and enhanced care coordination. We devised a system that would track intervention outcomes while linking specific patient populations to appropriate interventions. The application was primarily developed in Active Server Pages, a Microsoft server-side script engine for dynamically generated web pages, using JavaScript. ²⁷ Other technologies included graph components developed in Flash, a set of multimedia technologies developed and distributed by Adobe Systems, ²⁸ and a practice panel administrative tool written in Flex, a free open-source framework for building and maintaining web applications. ²⁸ The clinical database used by the RPM application was located on a Microsoft Structured Query Language server. ²⁹ The RPM application retrieved data from multiple repositories through a data service layer named Smartcache, which translates data requests from Extensible Markup Language, ³⁰ a general-purpose specification for creating custom markup languages into Structured Query Language queries. In its current framework, the RPM application is scalable and can easily adopt other data sources in the future.

System Description

RPM Application User Interface Design, Decision Support, and Database Architecture

As part of the workflow integration process, the RPM application helps determine cohorts of patients with specific criteria, link these cohorts with actionable interventions, and coordinate care between the various providers.

Patient Identification

The RPM application considers only the data recorded in the previous 24 months. The RPM application considers patients 18 years of age and older to be diabetic only if they meet the criteria in one of the two following strategies: Strategy 1 (based on clinical data): one or more codes for diabetes or codes that imply diabetes (e.g., diabetic nephropathy) in the problem lists in an electronic medical record, or one or more codes for antidiabetic medications in the active medication lists in the electronic medical record (metformin was excluded because of its use in treating obesity, metabolic syndrome, prediabetes, and polycystic ovarian disease), or a hemoglobin A1c level > 7. For practices with inconsistent electronic medical record documentation or outside laboratory use, we developed a second algorithm: Strategy 2 (based on claims data): two or more outpatient encounters of the International Classification of Diseases 10 (ICD-10) diabetes codes within 1 year of each other, or one inpatient encounter for the Healthcare Effectiveness Data and Information Set (HEDIS) ICD-10 codes; or one emergency ward encounter for the HEDIS ICD-10 codes.

RPM Application Patient Panels

Accurately identifying patients with diabetes is the critical first step to implementing a successful registry. ³¹ In the current workflow, physicians must confirm their patient roster twice per year on the basis of static lists created by Massachusetts General Hospital's administration. This process is inefficient, inaccurate, and not cost-effective. To optimize workflow, we applied a validated algorithm to determine which patients belong to which physician. In relation to providers, patients were assigned to one of five states:

• • Candidate: care provider has seen the patient or the care provider is listed on the official electronic master patient index for that patient.

• • Primary care physician–linked: care provider has seen the patient, and the electronic master patient index confirms that the provider is the primary care physician.

• • Primary care physician–confirmed: primary care physician confirms that a patient with “candidate” or practice status is his or her patient.

• • Responsible: care provider specialist, nurse practitioner, diabetes educator is not the primary care physician but considers himself or herself responsible for the care of this patient.

• • “Not my patient”: care provider confirms that this patient does not belong to him or her. This patient will automatically be assigned as loyal to the practice in an “unassigned” group.

Patients appear under a provider's roster if they have either the “linked,” “confirmed primary care physician,” or “responsible” state. If patients are not assigned to any primary care physician in a practice, they remain either in the practice or in the Massachusetts General Physicians Organization “unassigned” group.

RPM Application Key Design Features and Functionalities

We created the RPM application to have an intuitive user interface that provides “just-in-time” information and functionality at the right time in each user's workflow. ³² Key features of the RPM application include:

• 1 Navigational menus and page designs: The RPM application uses a hierarchical navigation menu that lets users “drill down” from the overall institution network level to individual practices, or to the individual physician level (▶). Access to each level is privilege protected. This format reflects our institution's organizational structure and facilitates accountability for chronic disease care. At the practice and physician levels, the user has two view options: a graphic view to represent care across populations and a roster view where individual patients can be identified for intervention (▶).

• 2 Drill-down graphs: During focus group sessions, we found that physicians and clinical directors were often skeptical of aggregate statistical reports produced by disease registries and often questioned the accuracy of the patient panels (i.e., Are some patients not diabetic? Are some patients lost to follow-up?). To address this issue, we developed interactive bar graphs that allowed users to identify patients meeting specific clinical criteria. For example, by clicking on the section of a bar graph denoting patients with HbA1c levels greater than 7.0, a user can see the members of said group in a roster view in real time.

• 3 Accuracy of data: Patient panel accuracy was critical to the focus group. We therefore developed tools within the RPM application to allow physicians to edit their panels. The RPM application includes “practice” and “Massachusetts General Hospital unassigned” categories to keep track of patients who are not assigned to a physician. Currently, laboratory data are updated weekly, and appointment data are updated daily. Finally, we built a drag-and-drop tool that lets an administrator add, edit, or remove a physician from any practice.

• 4 Optimized roster pages: Before we developed the new system, we found that diabetes nurse managers had to manually cross-reference data elements from the electronic medical record while reviewing patient lists. By talking with the nurses and through focus groups, we determined the minimal required data set needed to eliminate manual cross-referencing other sources.

• 5 Care coordination and workflow: We created several just-in-time knowledge access tools to improve workflow and care coordination. For example, we devised an interactive interface to show detailed patient information such as patient phone numbers, providers, or other contextually sensitive information when users simply hover the mouse over specific areas on the RPM application screen. Users could also initiate contact with the primary care provider directly via this popup balloon by clicking on the primary care provider's name. This action initiated an e-mail prepopulated with primary care provider's address and the patient's identifying information.

• 6 Integrated interventions: The RPM application also lets users build customized patient lists that indicate the appropriate intervention required. For example, practice managers can create customized lists of patients requiring reminder letters or phone calls. These lists can be processed centrally with batch letter printing, or they can be routed to the call center. To facilitate call center operations, we created an RPM application interface that captures the outcomes of these patient calls so that patient letters and phone calls can be tracked longitudinally, thereby allowing multiple care team members to know the outcomes of prior interventions.

Figure 3.

Only the highest administrative level users at our institution have access to this particular view. The user at this the highest level of access can see data on all practices by navigating the left tree menu. Practice nurse managers will see data relevant to their practices only. The tree menu for nurse managers will show their practice as a whole and the physicians that comprise it in the left tree menu. The view displayed in this figure shows the holistic view drilled down to a specific provider level. To enhance understanding of the graphs, popup balloons with graph descriptions appear while the user is hovering over the info icon.

Figure 4.

Contact roster view. A user can view the contact roster view by clicking on a section of any of graphs. The roster displayed depends on the query associated with the graph. Users can easily review patient's information in the contact roster view and decide which action they wish to pursue (e.g., letter or phone call).

Status Report and Impact on Efficiency

We began to analyze our institution's workflow and design the application in the Fall of 2004. The development team was composed of one developer and one project manager. A beta version was released in 2005 to medical residents only. As the RPM application matured, we added another developer. The version described in this article represents the latest version of the RPM application.

We devised a pilot study at a single practice site where we deployed the RPM application along with the workflow change to assess the impact of our intervention on the time required by nurses to manage information related to diabetic patients. We measured the time required for our pilot practice to identify patients needing a reminder letter before and after we implemented the RPM application. We also measured the time it took to send letters once patients had been identified.

We deployed the RPM application into production in the Fall of 2006. To assess the application within the setting of a new workflow, we conducted a pilot evaluation at a single practice. Using the original workflow (without the RPM application), it took 1 month for two nurses working 1 half-day per week to complete a review of 200 patients with diabetes at a rate of 10 to 30 patients per hour (▶).

Table 1.

Table 1 Time for a Diabetes Nurse Manager to Identify whether a Letter Reminder Should Be Sent

	Without RPM	With RPM
		Cycle 1	Cycle 2
Process rate (patients/h)	10 to 30	180	300
Total number of patients reviewed	200 patients	220 patients	73 patients
Number of patients identified for letter	Variable	38 patients	48 patients
Total time for task completion	1.5 months for two nurses working 0.5 days per week	73 min with one nurse	15 min with one nurse

With the newly revised workflow supported by the RPM application, one nurse could review 220 patients at a rate of 180 patients per hour. That rate increased to 300 patients per hour during a second cycle after the nurse had been given additional user feedback about how to use the patient roster features. In addition, the delay between patient identification and mailing reminder letters decreased from more than 30 days to fewer than 2 days.

Discussion

Four Problems with Our Institution's Traditional Diabetes Management System Addressed by the RPM System

• 1 Inefficient tracking and managing of pay-for-performance patient data. Our institution (the Massachusetts General Physicians Organization) includes more than 15,000 patients with diabetes cared for in 20 primary care practices and one diabetes practice. Approximately 2,000 of these patients have private health insurance. Private insurers have negotiated pay-for-performance contracts with the institution to serve as incentives to improve diabetes metrics.

  Before our intervention, the institution used claims data provided by the private insurers to identify pay-for-performance patients that did not meet contract goals. These data typically were 3 months old. Administrators would then create Excel spreadsheets for each practice by cross-referencing the pay-for-performance patient data with our clinical data repository. Individual practices were then required to review these spreadsheets and identify which patients needed reminder letters or phone calls.

  Because these lists were not updated in real time, nurse managers at each practice often needed more than 1 month to gather the appropriate information from the electronic medical record to compile accurate lists. These lists were then returned by each practice to the central office, which then sent out letters to the patients or called the patients. Before sending letters and making phone calls, each patient was reviewed a second time against the electronic medical record to ensure that the patient had not already had their laboratory work done. This labor-intensive cycle, from patient identification to intervention, took up to 6 months.

• 2 Unclear effectiveness of interventions. Although our institution tracked the number of calls made and letters sent, it did not have a way to assess the interventions. We knew from prior work that there was substantial room for clinical improvement in our diabetes patient cohort.^33,34 However, we did not know what percentage of patients who received a letter or a phone call went to the laboratory to get their blood drawn, or which patients responded better to a letter compared with a call. Furthermore, because making phone calls was relatively more labor intensive than was sending letters, we also would have been interested in determining the cost-effectiveness of each intervention by linking individual interventions to corresponding changes in clinical data. If these data were available, we could have optimized the cost and efficiency of these interventions.

• 3 No tracking and fewer interventions for non–pay-for-performance patients. Unlike pay-for-performance patients, no compensatory mechanism was in place to motivate the Massachusetts General Physicians Organization to track non–pay-for-performance patients. Therefore, non–pay-for-performance patients did not get letters or phone calls from the Massachusetts General Physicians Organization. At the practice level, non–pay-for-performance patients also did not get as much attention because the practices were more motivated to intervene on pay-for-performance patients first. Some practices provided population management of all patients, regardless of payer status, but this required additional resources.

• 4 Poor information exchange between the Massachusetts General Physicians Organization and practices regarding patient contact. The practices at the Massachusetts General Hospital operated differently regarding sending letters and making phone calls. Some practices preferred to make their own calls and send their own letters, whereas others delegated these interventions to the Massachusetts General Physicians Organization. For the practices, this meant that there was no way for them to monitor whether or not patients had been contacted centrally.

Ten Factors That May Contribute to Better Diabetes Care Delivery

We believe that the RPM application has been successful at improving the efficiency of diabetes care delivery at our institution and that the following ten factors are keys to its success.

• 1 Identify current workflow problems before suggesting an overall approach that includes an informatics solution. We successfully developed and deployed a comprehensive disease management application that facilitates managing diabetes patients at a busy tertiary care health care center. Realizing that a software application in this setting is simply an electronic means of implementing clinical management model, our initial step was to fix the broken model and propose a simplified workflow to manage the patients. This required talking to all stakeholders and understanding their roles and responsibilities. Once this was done, we could design an efficient workflow to ensure that all the patients were taken care of and that the staff worked more efficiently.

  Although a workflow-integrated registry may have significantly increased the efficiency of our disease management process, its use over time has been less dramatic. At our institution, we observed sustained use mostly because of effective leadership reminders and pay-for-performance incentives. A registry is nothing more than a tool. The recent failure of the Santa Barbara County Care Data Exchange project, once one of the most publicized and ambitious health information efforts in the United States, is a case in point. Eight years after its inception, the project was shut down because of a lack of financial incentives and ineffective leadership.³⁵

• 2 Request that all stakeholders, particularly frontline users, be involved with the design team. The success of the RPM application resulted in part from engaging all of the stakeholders, particularly the end users, from the very beginning. Because we made the diabetes practice managers an integral part of our design team, we did not have to “sell” the application to them once the RPM application was deployed. Also, because these end users were involved from the start, they could give us feedback and suggestions on how to further improve the RPM application long after deployment.

• 3 Ask yourself continually, “Is this step necessary to accomplish the objective?” Observing the various users is essential to more fully understand their roles and responsibilities in relation to the broader goal of providing quality care. Often, we identified work that did not contribute to reaching that goal. For example, we watched a nurse review a patient using the electronic medical record and noticed that she spent a tremendous amount of time collecting data elements that were irrelevant to her deciding whether or not that patient should receive a reminder letter. Understanding how users think by talking to them as they work facilitates designing the user interface and optimizes integration of the application into the workflow.

• 4 Talk to users on a regular basis, and incorporate their suggestions in the design. We found that contacting end users regularly ensured that the application was used. We promptly addressed any problems and issues that were brought up by end users. Engaging end users as application testers also strengthened the overall deployment experience. For example, we regularly received feedback from end users regarding errors in our application as well as inaccuracies and inconsistencies in our data. These issues often frustrate users who see themselves merely as consumers of the application. Because our end users were testers and members of the RPM application team, key users were in a position to effect improvements in the application.

• 5 Ensure that an informatics approach is the most efficient solution. We learned the hard way that an informatics solution is not always the most effective one. For example, we spent many hours trying to improve an algorithm to predict the relationship between a primary care provider and a patient. Ultimately, we resolved this issue by working directly with the registration office to implement a noninformatics solution to improve the accuracy of the primary care provider designation field in their database.

• 6 Have incentives in place such as leadership and quality-associated reimbursements. Integrating a registry application into a disease management workflow may encourage use, but it is not enough to ensure use. In our case, as with others,³⁵ a key component to sustainability was leadership from the Massachusetts General Physicians Organization. We had leadership that endorsed the use of the RPM.

  Although the RPM application was designed to encompass all patients with diabetes, our data suggest that practices that care for non–pay-for-performance patients did not adopt the RPM application as quickly as have those that care for pay-for-performance patients. This finding underscores the key role that financial incentives play in registry adoption.

• 7 Determine whether physicians need to be part of the workflow. The most common barriers to implementing care management processes include physicians being too busy and their resistance to using it.²⁰ We therefore put in place a policy whereby all pay-for-performance patients with diabetes received a reminder letter or call if they were due for a laboratory test—but identifying patients who require a reminder did not require a physician's input. Physicians could request that their patients be notified, but they also did not have to do anything to have this done.

• 8 Measure the effectiveness of each step. To address the initial inefficient workflow, we used an iterative “plan-do-study-act” cycle that measured the impact changes in the workflow. Although not as rigorous as randomized clinical trials, plan-do-study-act cycles are quasi-experiments that can be done on very small scales and, most importantly, very quickly.^36,37

• 9 Ensure that the model addresses care coordination. Although we did not specifically measure communication among team members before our intervention, we did discover that not having a formal process (e.g., telephone and e-mail) created confusion and frustration among care team members. We therefore integrated the workflow and design of the RPM application so that administrators could coordinate diabetes management within the various practices via these communication modes.

• 10 Track outcomes of your interventions. The purpose of a registry is to identify patients who need specific interventions. We found it valuable to track the outcomes of those interventions in real time. For example, within the RPM application, patients who received reminder letters who did have a laboratory test done are routed to receive a follow-up phone call.

Limitations

Our study has several limitations. We could not distinguish the relative contributions of the new informatics tool in relation to workflow changes. However, we believe that for complex clinical processes like diabetes care, informatics tools do not exist in a vacuum and can be evaluated with corresponding workflow changes.

In addition, the study did not measure clinical outcomes but rather examined one particular workflow process: the time taken to identify pay-for-performance patients with diabetes that require a reminder. Improving workflow processes does not necessarily result in improved clinical outcomes.

Future Plans

After our pilot intervention at one practice, we have deployed the RPM application to the rest of our clinical network at Massachusetts General Hospital. Our goals are to continue to optimize the RPM application by increasing care coordination features such as the ability of a care team to work on a single care plan for a patient; to explore what components, besides a tighter integration to the workflow, will promote sustained use of registries; and to expand the RPM application framework to encompass other chronic diseases such as congestive heart failure. To achieve this last goal, we will explore common concepts and architectural components across chronic disease registries.

Conclusion

Effective management of patients with chronic disease is crucial for quality outpatient care. We facilitated this process at our institution by revamping the established workflow for diabetes management and by building the RPM application. We believe that integrating our diabetes registry into the workflow was a key aspect of our increased efficiency; by doing so we successfully decreased the time needed to notify patients for laboratory work by approximately ten-fold.

We hope that our experiences presented here will encourage others who are implementing similar registries to pay attention to workflow redesign as they design their registries.