Data interoperability? Let’s talk first about data creation!
There are few things more annoying than finishing an episode of your favorite Netflix show only to start the next episode and have no idea what’s going on and how the plot advanced so far without your knowing. You’re left wondering what happened, you double check that you didn’t accidentally skip an episode, but to no avail. Eventually you make peace with your lack of understanding and accept that the producers probably chose to cut costs at the expense of a consistent narrative.
Following the trail of data left behind by a patient as they navigate the U.S. healthcare system is a very similar experience.
Historically, it’s been nearly impossible to connect all of a patient’s healthcare data because the U.S. healthcare system is so siloed and hence, understanding what actually happened in patient’s care journey was nearly impossible. As patients access different providers over the course of days, months and years – from primary care physicians, to specialists, to in-hospital care and others – the data is often inaccessible to each subsequent care provider. If the above chain of visits were real (primary care → specialist → hospital), the hospital wouldn’t be able to get the patient’s data from the specialist and the specialist wouldn’t be able to get data from the referring primary care physician and so on. There are exceptions, such as at large IDNs (i.e., Kaiser, Intermountain Health and Geisinger) where all data is theoretically interoperable across payer and provider functions (though even in these system it is far from being solved), but in general, the lack of data interoperability in the broader healthcare system is a well understood problem. If we could just connect all these data sources, the thinking goes, we could follow each patient’s care journey over time, quickly improving the knowledge of physicians and nurses at the point-of-care, and thus improving the quality and efficiency of the system as a whole.
Only a few years ago, interoperability remained more an ideal and buzzword than an actionable business opportunity. However, there has been a dramatic change in the last couple of years, especially given the passage of the 21st Century Cures Act, that created meaningful incentives for payers and providers to adopt interoperability solutions. As a by product, a wide range of companies have recognized the opportunity to sell software and data-as-a-service solutions to both payers and providers to facilitate healthcare data interoperability. The figure below provides an abbreviated list of companies providing interoperability solutions or related cloud data infrastructure services.
While there are already many shot on this target and it seems like swe are starting to make progress there is still much that can be done to improve data interoperability (for more color on interoperability, Brendan Keeler’s HealthAPIGuy Blog on Substack is an excellent resource). But even if it will solved, interoperability is only part of the problem.
Incomplete data entry and the tail of “garbage in / garbage out”
Ultimately, the end goal is to understand what has really happened to a patient at each juncture in their care journey, and interoperability is only one prerequisite to achieving that. Even if all payers and providers were able to connect all of the relevant data sources so that there was a seamless pipeline of information from data abstraction, to data cleansing and harmonization, to (when needed) data deidentification and anonymization, and finally to data exchange, in most cases that system would still be incapable of delivering actionable data around what really happened and why (“outcomes”) to a specific patient over time. Before considering how to make data interoperable, we are dependent on what data actually exists (anywhere), i.e. what data is being captured during each medical encounter. In most cases, current documentation is often lacking in breadth, quality or both.
To be clear, I’m not reiterating a common complaint about unstructured data in healthcare (“80% of healthcare data is unstructured... NLP.... Argh”), nor am I advocating for the need for remote monitoring or technologies to follow patients outside medical facilities (although this can be SUPER helpful despite its challenges). No. The fundamental problem is related to what data actually exists from medical encounters, regardless of format, structure, medium or mode of acquisition. The fundamental problem lies with our inability to capture the full and complete context of a medical encounter at the point of care.
It’s well known that physicians hate their computers. They already spend too much time on them instead of actually talking with and treating patients. Many physicians feel burned out, required to see ever growing numbers of patients in shorter time spans as many departments suffer from staff shortages.
The result?
The problem is that we can’t properly interpret the outcome without sufficient context. I’ll use an example of a cancer patient to illustrate.
For many patients, their experience receiving treatment for cancer resembles a very challenging wandering path from one intervention to another. The physician may switch the patient from one type of drug to another, then have an additional drug added to their regimen, step down from an aggressive treatment regimen to a more conservative one, then stop treatment altogether. Each intervention and change in their treatment regimen is based on multiple factors, including disease progression, side effects, treatment efficacy, mental health status of the patient, and social and financial considerations, among many others. Since a specific intervention can have different causes, the reporting of contextual data is needed to provide a full understanding of the physicians’ considerations and patient’s experience along their care journey. For example, was the treatment stopped because of remission (good) or progression and lack of efficacy (bad)? Was a drug altered because of an adverse event (but was effective) or was it altered because it was ineffective? Was treatment stopped for financial reasons or because the patient went into remission?
An outcome can only be understood within in a context, and insufficient data from a medical encounter means insufficient context. This lack of contextual data has real consequences, as it effectively prevents the proliferation of value-based care models, which require accurate measurement of outcomes to function properly (more on that point in this post).
Move from data capturing to “clinical capturing”
In 2019, Fred Schulte and Erika Fry (of KHN and Fortune, respectively) published the article “Death by a Thousand Clicks” in which they detailed how current EHRs are often plagued by software glitches, poor user interfaces and improper or failed installations. While the article details how such faults in EHRs have led to clear cases of malpractice, a less alarming but more pervasive consequence of these shoddy systems is poor data quality and inadequate capturing clinical context.
“…Rather than an electronic ecosystem of information, the nation’s thousands of EHRs largely remain a sprawling, disconnected patchwork. Moreover, the effort has handcuffed health providers to technology they mostly can’t stand…”, “…Our investigation found that alarming reports of patient deaths, serious injuries and near misses — thousands of them — tied to software glitches, user errors or other flaws have piled up, largely unseen, in various government-funded and private repositories…”
Moreover, a 2019 survey by KFF found that more than 20% of patients say that they or a family member have noticed an error in their EHR.
Outright “errors” in the medical record (in the form of either incorrect or insufficient information) diminish the physician’s ability, or the ability of any body reviewing the data, to understand what is going on clinically, either for a patient or a population of patients. “Garbage in, Garbage out.” No interoperability solution can solve that.
Another reason that current EHR systems do a poor job of capturing the data, specifically the data that would provide clinical context to other physicians and providers, is because that’s not what EHRs were built to do. First and foremost, EHRs are billing tools. Rather than facilitate the documentation of information necessary to improve patient care (which afterwards will allow to understand “what happened” in the most efficient and comprehensive level), they primarily facilitate the documentation required to ensure optimal billing for the provision of various services during a medical encounter.
It would be a tremendous understatement to say that changing how EHRs are built will be an up-hill battle. It has been discussed for more than a decade and little has changed (some future thoughts in this piece by Seth Joseph on Forbes.
Scribes such as Nuance (now Microsoft), Rubin, Suki and others offer some hope, but mostly remain narrowly tools that by large generate additional pile of unstructured data rather than usable, organized information that can flow seamlessly into the workflow. Thus, for physicians using a scribe to help take notes, they must still at some point sort, clean and organize that data, which means more manual work by the same people who already feel burned out from too much manual work.
Documenting information for the medical team
In my opinion, any solution that aims both to improve data quality and reduce physician burnout first and foremost must NOT generate more noise (or manual work), but rather integrate seamlessly as possible into each workflow and capture information (rather than data) in the right context, at the right time and with the right breadth. That is to say, a tool that has the ability to capture the most relevant and useful information. While we currently have tools that can recognize words, they lack the sophistication to determine whether those words are important in one context or a redundancy in another.
The key distinction is the difference (or the gap) between generating data, information and knowledge, which I’ve touched on when describing the challenges of remote patient monitoring. We have torrents of data in healthcare, but much less information and a scarcity of actionable insights, although it is the important piece. This is what we need to focus on in the future.
Source: Michael N. Liebman
Perhaps even more important, we need software solutions that medical teams see as partners rather than oppressors. Solutions that providers use not because they are imposed on them, but rather due to a genuine desire to improve the efficiency of their team and the quality of care provided by them to the patient. This is true not only of data capturing tools, but any provider focused software or data solution.
Finally, even more than we physicians hate our computers, we hate the feeling of being under surveillance. Whether by an administrator within our place of practice or by an industry partner (payors, regulators, etc.), the feeling of being watched causes physicians to act differently. Instead of practicing on top of their licenses, physicians will constantly be thinking about how not to lose their license (i.e. being sued for malpractice). Physician buy-in is crucial to avoid the defensive medicine that results from this feeling. Defensive medicine also reflects on documentation and thus missing what really happened in the encounter / what should have been done. The result, is, well… garbage in and garbage out.
To create this buy-in, any data capturing requirements must be primarily intended to provide better care to patients. Data capture tools or any type of physician-facing solutions should be developed together with the providers and not “for them”.
I’ll finish with a recent investment we made at Arkin based on this notion which hopefully can serve as a good case study (and show we put our money where our mouth is :)
“Speech to workflow insights” in behavioral health
Behavioral health clinicians endure an extreme version of the problems I described above. Typically, behavioral health visits require more documentation compared to other fields, however in addition, there is a severe shortage of therapists, leading to reduced time for patient visits, AND there is generally little administrative support available to clinicians, many of which operate independently. Enter the “black-box” problem of behavioral health which is a big pain both for providers and payors.
Eleos health aims to ease this pain of behavioral health providers by seamlessly analyzing conversations from both virtual and in-person behavioral health encounters in order to generate actionable information for the therapists. Eleos produce an automated patient summary note (in most cases no changes are needed to sign off) as well as many more real time insights, such as an opportunity to quickly recap on the major themes in past sessions or flag key events to make sure they are addressed properly (i.e., patient X had suicidal thoughts when we talked about Y). Consequently, Eleos is allowing better, more efficient and value based behavioral health care while simultaneously creating unique data (type, breadth and quality) for future research.
Big thanks to Peter Tortora for his help!
Nadav
Want these posts seamlessly in your mailbox?