Challenges Involved in Establishing a Web-based Clinical Decision Support Tool in Community Health Centers

Background

Clinical decision support (CDS) systems (CDSS) that summarize a patient’s cardiovascular disease (CVD) risks and provide individualized care recommendations can improve rates of guideline-concordant CVD care.[1–16] Some form of CDSS are in place in most US healthcare systems; by 2017 almost all hospitals and 80% of other care settings had implemented some CDS functionalities,[17] and use of such CDS varies widely.[18, 19] The deployment of a given CDSS beyond the care system in which it was developed is often limited,[20] in great part because guideline-based CDSS must be continually updated as new evidence emerges, requiring resources including clinical and programming expertise.[21] Care systems might minimize the burden of maintaining CDSS by sharing a single, regularly updated, web-based CDSS that integrates with their EHR – a ‘hub-and-spoke’ approach to CDSS.

A 2018 report from the Office of the National Coordinator on Health Information Technology called for expanded efforts to enable CDSS that can integrate data from different sources,[21] and described the barriers to doing so. One such barrier – lack of standardization of data elements – may be addressed by efforts currently underway (such as Fast Healthcare Interoperability Resources (FHIR),[22] CDSHooks,[23] and the Logical Observation Identifiers Names and Codes (LOINC) standardization of medical laboratory observations).[24] However, other challenges remain, and guidance on establishing hub-and-spoke CDSS in primary care is needed.

CV Wizard©, developed at HealthPartners Institute (HPI),[15] provides encrypted CDS generated from a single firewall-protected web service. A build package installed in the EHR initiates a secure data transfer (e.g., selected vital signs, laboratory test results, medications, diagnoses, allergies, along with a unique patient identifier code) to the web service. The web service processes these data through algorithms that are informed by current national guidelines [25–28] and updated when new evidence-based guidelines are released. (For example, when the guidelines defining blood pressure control changed in 2017, CV Wizard incorporated them within a few months.) The CV Wizard© system alerts clinic staff when a given patient’s modifiable 10-year CVD risk is ≥10%. When staff click on a URL link within the alert, CV Wizard© generates a personalized, prioritized summary of the patient’s modifiable CVD risks (blood pressure [BP], Body Mass Index [BMI], lipids, glycated hemoglobin [A1c], smoking, aspirin use) for point-of-care review. A clinician summary includes care recommendations that account for the patient’s medications, allergies, comorbidities, etc. (Figure 1). A low-literacy patient summary can be printed (in English or Spanish) and given to patients to facilitate shared decision-making (Figure 2). CV Wizard© also enables users to send questions or criticism of the tool’s care suggestions to the Wizard team[15] for review and resolution as indicated. CV Wizard’s seamless presentation within the EHR, individualized and prioritized recommendations, adaptation to a patient’s changing clinical state, and feedback functionality make it one of the most sophisticated CDSS tools for CVD risk management.

Figure 1.

Example of CV Wizard© Clinician Summary

Figure 2.

Example of CV Wizard© Patient Summary

CV Wizard’s adoption rates and user satisfaction at HealthPartners are high, and its use significantly improved patient outcomes in that setting.[15, 29, 30] CV Wizard is currently in use at multiple integrated care systems in 11 U.S. states, with an average of 250,000 web service calls per day. Its application in these systems required creating a business associate agreement and a service agreement to permit secure data transfer between the systems’ EHR and the CV Wizard web service, and 4-6 months for the data mapping, programming, and testing required for implementation.

Given CV Wizard’s successful adoption in the HealthPartners care delivery system, we are formally testing its effectiveness in the community health center (CHC) context, in a 5-year randomized trial (R01HL133793). This paper describes the challenges encountered and addressed in establishing the CV Wizard CDSS in the CHC setting, as part of this trial. We present this work to guide others and facilitate the spread of ‘hub-and-spoke CDSS’ in CHCs and other primary care settings.

Organizational Context

OCHIN, Inc., is a non-profit organization that provides information technology support, including a shared Epic© EHR, to >600 CHC clinics in 47 states. These CHCs’ socioeconomically vulnerable patients have high rates of hypertension, lipid disorders, obesity, and diabetes. The 68 CHCs taking part in the clinical trial are OCHIN members.

To activate CV Wizard in the study CHCs, the OCHIN and HPI teams – which included experienced health services researchers, primary care clinicians, and EHR programmers – met every two weeks by phone from March 2017 to April 2018. At these meetings, the teams identified and resolved numerous challenges involved with establishing the CV Wizard CDSS in the EHR shared by the study CHCs. Problems identified and solved while establishing CV Wizard for use in the OCHIN clinics fell into three categories: legal / compliance, technical, and clinical implementation. These categories were anticipated a priori, based on team members’ past experience in implementing EHR-based tools in four large care systems. They were addressed based on the HPI team’s experience to the extent possible, given the differences between OCHIN and other settings where CV Wizard had been implemented previously. No standard ‘playbook’ for implementing CV Wizard existed, but it was established from the onset that working on legal / compliance, technical, and clinical / operational requirements simultaneously would be necessary for implementation within the pre-specified project timeline (about 6 months for full CDSS integration).

Problems and Solutions: Legal / Compliance

Address data security and other legal considerations.

Both parties’ legal counsel conferred to ensure the legality of the data exchange and formalize data governance. Documents created to this end included: a Master Service Agreement to specify the terms of CV Wizard’s delivery (e.g., both parties’ responsibilities, trademark use, monetary exchange, future use); a Business Associate Agreement covering terms for disclosure of personal health information from OCHIN to HPI; and a Secure File Transfer Protocol for transferring EHR data and proprietary programming code. Finalizing these documents took five months.

Ensure that data are sent securely.

We established and executed a plan for securely exchanging data between the CDSS and EHR, including personal health information. In brief, CV Wizard generates and stores a unique patient identifier. When a ‘display call’ occurs, the CDSS matches this identifier against a key to display the CDSS tools. For analytic purposes, CV Wizard also creates a per-patient study ID which is saved in the EHR.

Decide who maintains records.

We determined that EHR data sent to the CDSS is owned by OCHIN, CV Wizard and the CDS web service are owned by HPI, and all ‘study materials,’ including CDS results, belong to OCHIN. HPI purges the patient name but saves all other received data and sent responses for two weeks, to enable addressing provider questions about the CDS output. In a non-study situation, these data would then be purged; for study purposes, after the two-week hold, the data is saved in a CV Wizard-generated analysis dataset. These datasets, sent to OCHIN monthly, include a study ID that links via crosswalk to the EHR. Both parties maintain copies of the analytic datasets throughout the study, but HPI cannot use the data without permission, and will destroy it upon request.

Determine which data are sent to the CDSS.

CV Wizard’s algorithms use patient data (medications, laboratory results, allergies, vital signs, demographics, diagnoses) relevant to CVD risk. Because CDS algorithms are updated as new evidence and guidelines emerge, which can happen frequently, our choice was to send: only the EHR data that the algorithms use at the moment, risking having to change programming on OCHIN’s end every time updated algorithms require new data points; or, all patient data in a given category, risking slowing the data exchange and sharing data that might never be used by the CDSS. After weighing concerns about data safety versus future maintenance needs, informed by both organizations’ compliance teams, we opted to send all data from the relevant categories. The deciding factor was a desire to facilitate ongoing use of CV Wizard.

Problems and Solutions: Technical

Establish a structure for data exchange between the CHCs’ shared EHR and the CV Wizard server.

EHR data had to be sent securely to the CDS web service, and CDS results had to be returned for real-time display in the EHR. Enabling this exchange involved developing data extraction tables within the EHR (e.g., medication, laboratory, diagnostic codes, vitals), and EHR MUMPS (“Massachusetts General Hospital Utility Multi-Programming System”) program routines, to transmit EHR data to the CDS web service, save responses in EHR flowsheets, and display results in the EHR.

Manage lab data from multiple sources.

OCHIN’s >600 clinics receive laboratory data from >60 interfaces, which add result components to the system on an ongoing basis. Because prior implementations of CV Wizard relied on static lists of laboratory-specific variables to find laboratory data, a new system was needed to accommodate OCHIN’s dynamic generation of result components. HPI redesigned the algorithm code to let key elements be defined in an interface table (instead of being hard-coded), and to allow the algorithms’ existing lab keys to map to flexible metrics. These metrics look up past lab values using standard application program interfaces (APIs) based on dynamically identified groups of lab components, using any of a number of standard component classification schemes, including ‘base names,’ which OCHIN already uses and sets according to LOINC codes supplied by lab interfaces. HPI also programmed a ‘listener’ on labs to detect anything not already in their tables, and flag if they received lab data that could not be mapped to these components.

Improve the CDSS’ MUMPS program routine’s performance.

In initial tests of CV Wizard in OCHIN’s EHR, the routine through which its server ‘calls’ the data was untenably slow for certain patients. As this was due to code-checking each individual visit in the past 5 years independently for diagnoses and laboratory results, we decided to use more efficient dual-key indexing / standard APIs to retrieve encounter diagnoses, problem list, allergies, medications, vitals and other patient data. This reduced the amount of data retrieved from the database to supply CV Wizard with the elements needed for the CDS calculations, increasing speed and avoiding unnecessary lag as the systems exchanged data.

Manage other data exchange components.

EHR data on medications and allergies were mapped by HPI to fit the algorithms’ code. Because OCHIN’s EHR uses a different medication database vendor than HPI’s prior CV Wizard implementations, this required substantial effort over six months, including 25% full-time equivalent of an experienced Epic programmer to conduct initial identification, medication matching, coding of pharmacologic class information, loading data, and iterative testing, with ongoing input and reviews by the study leads (physicians).

Optimize the CDS in the shared EHR.

To ensure that CV Wizard worked accurately in the CHCs’ shared EHR, the CDS results and displays were quality-tested through OCHIN’s standard processes for testing all changes made to the EHR. This involved working in a testing environment, using fictional patient records designed to be challenging for the CDSS to process, e.g., by having highly complex clinical characteristics. Additionally, CV Wizard is designed to target decision support suggestions to high-risk patients. To ensure that the CHCs’ staff were alerted when a high-risk patient was identified, an EHR alert was built to tell clinic rooming staff when CV Wizard had identified one or more care gaps and had actionable suggestions for a given patient. A link was embedded in the alert so that the user could go to the CV Wizard interface with one click.

Problems and Solutions: Clinical Implementation

Establish how to generate data on CDS use rates.

The CV Wizard team observed in prior applications that providing clinicians and clinic leaders with regular feedback on CDS print rates is key to achieving and maintaining high CDS use rates. We sought to provide similar data to OCHIN clinics, but because OCHIN is a collaborative of hundreds of clinics, the reports needed to be self-service and clinic-specific, without requiring representatives from all those clinics to log into HPI’s website for their reports. Instead, OCHIN created reports using Epic’s panel management tools to show how often CV Wizard was opened for targeted high-risk patients when it was recommended for them, at the clinic and provider levels. HPI also added an option for OCHIN to “call back” into CV Wizard after each visit to find out if the CDS was printed. Once this was implemented at OCHIN, print rates were added to the use rate reports.

Modify the ‘feedback’ function.

At HPI, clinician feedback is sent via email to a single CV Wizard point of contact for the whole EHR. OCHIN sought to enable clinicians and staff to send feedback to someone at their clinic as a first step, similar to other existing systems for user feedback on the EHR. Thus, CV Wizard’s feedback was changed from a centralized to a distributed system. We routed feedback data to each clinic’s EHR specialist via the EHR’s InBasket ‘Help Desk’ function. These specialists were trained to receive and triage Wizard feedback (answering the question directly or sending it to their clinic’s CV Wizard ‘Clinician Champion’). Questions remaining unresolved after these steps would be sent to the OCHIN study team and discussed with HPI as needed.

Customize the risk threshold for triggering the CDSS.

If a CDSS alerts too rarely (e.g., for narrowly defined groups of patients) likelihood of consistent use may decline; if it alerts too frequently, users may grow frustrated.[31] HPI achieved CDS use rates of 70-80% at alerted encounters with a risk threshold set such that the CDS use was recommended at about 20% of all adult patient visits. We were concerned that differences between HPI and OCHIN CHC patient populations would mean that using the same risk threshold at OCHIN could generate alerts at unacceptably high or low proportions of visits: CHCs serve a high percentage of multimorbid patients, which might increase the alert firing rate, but also a high percentage of younger patients, which might decrease the rate. We ultimately decided to begin with using the same risk threshold criteria as at HPI, targeting adults with: 10-year modifiable CVD risk ≥10%; or diabetes plus >=1 uncontrolled CVD risk factor or high A1c; or existing ASCVD + >=1 uncontrolled major CVD risk factor. We agreed to revisit this choice if we observed that CDS was targeting >30% of adult care visits in a given month for any of the study clinics; as this did not occur, the original criteria were retained.

Unresolved Questions / Lessons for the Field

It is inefficient (and could introduce unwanted variation) to reprogram multiple CDS systems whenever the underlying evidence base changes, which can occur frequently. Remotely operated hub-and-spoke CDSS that accept and process data from many care delivery systems could address this inefficiency and expedite the adoption and dissemination of current care guidelines. Establishing such hub-and-spoke CDSS in new settings presents numerous challenges: ensuring that data exchange meets legal standards; resolving complex technical issues inherent to exchanging the data needed for CDSS to operate; and modifying CDSS components to fit the new setting while minimizing customization. Such challenges can be resolved, as demonstrated here, but future efforts to use hub-and-spoke CDSS should be aware of and prepare for them. (As noted above, national data standardization efforts will remove some of these challenges and may further enhance health care systems’ ability to use evidence-based, hub-and-spoke CDSS like CV Wizard©.) As these challenges are addressed, hub-and-spoke CDSS could be used both in CVD care, as discussed here, and in myriad health conditions; given the known potential for CDSS to improve health outcomes,r211 diverse clinical content areas might be well-served using such tools.

As little has been published regarding the challenges involved in establishing hub-and-spoke CDSS in new settings, the lessons presented here may be useful for others seeking to harness the benefits of such CDSS. While aspects of the problems and solutions described here are likely to vary between settings, several overarching themes are likely to be broadly applicable. Notably: time and resources will be needed to manage legal considerations when connecting a new setting to a hub-and-spoke CDSS, to ensure secure exchange of data, and to determine ownership of records generated by the CDSS. A balance will need to be struck between sending data currently needed for the CDSS and data that might be needed in the future, while maintaining efficiency in the data exchange process. Linking data from a new source to an existing CDSS is likely to involve resources in terms of time and staff with appropriate expertise, as is the need to conduct data standardization of the data. If the new setting differs substantially from that where the CDSS originates, assessing how to optimize the CDS output for users at the new setting may be critical.

Getting such CDSS to work accurately in distal EHR systems is only the first step in such tools’ adoption by clinical teams; the uptake of advanced EHR tools like CDS varies widely between clinical sites, teams, and individual providers.[18, 19, 32] Far more research is needed on best practices for helping care teams adopt such tools into standard workflows, and sustain their use in practice.

IMPLEMENTATION LESSONS.

• Establishing a shared ‘hub-and-spoke,’ web-based clinical decision support system (CDSS) in an EHR shared by >600 community health centers incurred a myriad of challenges, which are summarized here to guide others seeking to use similar CDSS.

• Legal and compliance challenges involved ensuring secure data exchanges, determining which entity maintains data records, and deciding which data are sent to the CDSS.

• Technical challenges involved using lab data from multiple sources and improving the CDSS’ cache routine performance in its new setting.

• Clinical implementation challenges involved identifying optimal strategies for generating data on CDSS use rates, modifying the CDSS functionality for obtaining clinician / staff feedback, and customizing the risk thresholds that trigger the CDSS for the new setting.