Health Data Silos Are Growing: Can CDS Hooks Help Bridge the Gaps?

The Clinical Decision Support (CDS) Hooks API is a new specification that builds on Fast Healthcare Interoperability Resources (FHIR), describing how Electronic Health Records (EHRs) can automatically invoke external platforms or apps. FHIR is a standard defines how healthcare information can be exchanged between different computer systems regardless of how it is stored in those systems. For the first time, by CDS Hooks invoking FHIR apps, EHR-only users can have insights relevant to the clinical situation and within their EHR workflow based on data sourced outside of it. CDS Hooks is potentially a powerful way to ensure that all patient data can be accessed via the EHR.

Data interoperability has long been a challenge that has become increasingly important as healthcare moves toward a value-based care model. Being able to share clinical records and other patient data among providers and across different systems is key to helping meet the goals of cost-efficient care with better patient outcomes.

But does the current application of standards bind medical records, patient-generated data and clinical decision support (CDS) tools into a continuous workflow to benefit providers and their patients?

Finding a cure for data access through FHIR integration

Before we dig deeper into this issue, let’s look at how far we’ve come. In 2016, the 21st Century Cures Act enshrined healthcare data access into law by addressing some of the ongoing challenges with regard to data interoperability and electronic health records (EHRs). It required certified EHRs to support patient-facing APIs to allow for increased data access, transparency and interoperability across different vendors and third-party applications. It also outlawed ‘data blocking’ ensuring access to EHR data.

Implementation of the law led to the Office of National Coordinator of Health IT (ONC) and Centers for Medicare and Medicaid Services (CMS) issuing a final rule in 2020 that designated HL7’s Fast Healthcare Interoperability Resources (FHIR) as the protocol of choice for application programing interface (API)-based data exchange. In addition to its RESTFul API, FHIR provides a standard for packaging health data into its Resources, providing a broad, but not tightly prescriptive, foundation upon which EHRs, practice management systems, digital health applications and consumers can seamlessly exchange largely structured health information. Substitutable Medical Applications and Reusable Technologies (SMART), adds a technology layer to FHIR to provide security and workflow standards needed for FHIR to support EHR connected apps.

One of the challenges with FHIR-based APIs is that they are almost entirely “read only.” This means that they’re best suited for workflows and user actions that begin in other systems, like FHIR apps that require EHR data. So, an action in the third-party solution prompts the FHIR API to call the EHR and return data that is needed to complete the workflow in real time. It generally doesn’t work in the opposite direction, which leaves important patient and other data in separate platforms and not always taken into account when EHRs are a primary source of information.

CDS Hooks: Creating a continuous loop of patient information

The CDS Hooks API is a new specification from the SMART group that builds on FHIR, describing how EHRs can automatically invoke external platforms or apps. For the first time, by CDS Hooks invoking FHIR apps, EHR-only users can have insights relevant to the clinical situation and within their EHR workflow based on data sourced outside of it.

This is a particularly exciting prospect for healthcare IT companies that connect with healthcare data stores — like remote patient monitoring (RPM) continuous glucose monitoring (CGM), patient-reported outcomes (PRO) data and more — outside the context of the EHR. Now, with CDS Hooks, this important information can be made available automatically and directly within the EHR workflows.

Removing data silos within the healthcare workflow

CDS Hooks has largely been an academic exercise. But it has growing support among EHRs, and I believe that the time has come for its adoption in the broader commercial world.

With their nearly universal adoption, 95% of healthcare data has resided in EHRs. However, the data silos where the rest of the data are stored have grown in scale and significance with the advent of ever more sophisticated consumer apps, devices like Apple watches and Fitbits, and other healthcare tools, like blood pressure cuffs and continuous glucose monitors, and more ubiquitous remote patient care. The growth in the adoption of these technologies and devices is exponential, and many of them take measurements every few minutes, resulting in an increase in patient generated data that will soon dwarf that residing in the EHR.

CDS Hooks is potentially a powerful way to ensure that all patient data can be accessed via the EHR. Importantly, it offers a way for this multitude of home data stores to have a timely entry point into the clinical workflow. So, when an action is taken in the EHR, such as a physician writing a prescription, CDS Hooks-enabled platforms, with access to home-generated data can be notified and respond appropriately. This clinical decision support can help ensure the patient receives the best treatment, taking into account all known variables, regardless of where the data resides.

Conquering alert fatigue by integrating FHIR and CDS Hooks

Alert fatigue is another issue that has become all too common with the growing amount of patient health data being generated. With devices taking measurements frequently throughout the day, it’s easy for medical records and providers to be overwhelmed and ‘tune out’ if they are notified of every reading. Yet, clinical insights from this data can be important and usable if provided usefully and appropriately in the context of the clinical workflow.

The CDS Hooks specification envisions three different types of CDS Cards that may render to a user: informational cards, suggestions cards or app link cards that would launch a FHIR app. Each of these card types could be applied to support the problem of siloed health data. First, a CDS card could notify the clinician upon opening the patient chart that some patient-generated health data needs to be reviewed. For example, a patient with a continuous glucose monitor who spent more than 5% of their time over the last two weeks in a very low glucose range. This would be an informational card.  Additionally, the CDS card could allow for direct launch of the SMART app to visualize the supporting data in greater detail (app launch card) or to order a new prescription to address the highlighted issue (a suggestion card).

Despite the best efforts of earlier standards, and now FHIR, the challenges of using patient data silos have grown in significance because there are an ever-increasing number of increasingly sophisticated and clinically relevant sources of patient-generated data operating outside of traditional EHRs. Now is the time to consider adoption of CDS Hooks to complement FHIR and bridge this gap to ensure that patient data from third-party systems and home data stores is incorporated into EHR workflows and made actionable. By automatically presenting patient data in the EHR workflow at the appropriate time, providers will have a more complete picture of an individual’s health and clinical status and be able to more quickly and efficiently make better decisions that improve outcomes.

By MARK BRAUNSTEIN

Rimidi, Inc. Board of Directors member, Mark Braunstein, M.D., is also a long-time advisor to the company. He is Professor of the Practice Emeritus at Georgia Tech where he developed a unique health Informatics graduate seminar in which student teams work under the mentorship of a domain expert to develop a FHIR app to solve a problem they posed. While at Georgia Tech, Braunstein was a faculty member of the Institute of People and Technology.

Original article was posted at medcitynews.com on July 26, 2022.