Still Chasing Integration: Why Healthcare Data Stays Disconnected

Anyone who has worked in a rural emergency department has witnessed a situation like this. A patient comes in, having been transferred from some other location, but their records do not come with them. Someone has to call the other location to begin to get some sort of history. The transfer that should have been simple has turned into a monumental chore. This continues to happen daily and is not due to a lack of effort.

One physician who has been a guest on The Signal Room has described, very accurately, how absurd this is. You can go to almost any ATM somewhere in the world and retrieve cash from your account. However, a hospital in Boston cannot obtain an MRI from the hospital, which is a mere mile away, because the two entities have competing software systems. The MRI, in and of itself is not the impediment. An MRI is a digital image housed in a format which is a de facto standard. The systems are simply not able to communicate.

This illustrates the problems which exist after so many years of significant investment in digital health. The systems have become busy, but the data has become disconnected, inconsistent, and still functionally unusable. This is not a lack of focus on technology. This is a problem which has become increasingly complex, and most teams continue trying to solve at the incorrect layer.

Growth Leads to Variation, and Variation is Persistent

Most health systems grow through acquisition. Each hospital, practice, and service line that joins a system includes tech, policies, procedures, and documentation practices. These differences are not eliminated at go live, but become permanent. The result is a combination of electronic records, tools, and processes that do not interface, but are used, and integrate, in their original context.

Variation is not limited to different systems. It is also present within a single system. When individual practice groups document, and process the same information in their own way, then producing an accurate and reliable enterprise number is impossible.

The Issue was Never the Integration

Many years ago I attended a long series of enterprise reporting meetings at a large academic health system. Many of the groups were trying to consolidate reporting into one enterprise system. Each group had its own method and was reliable in the use of its own data. The problem was the individual meanings were distinct, and in many cases contradictory. Thus, each group was correct in its own reporting, and there was no trusted enterprise number. This resulted in every meeting becoming an exercise in determining which of the competing reports was correct, rather than allowing the participants to derive actionable insights from the analysis.

Initially, I thought this was a problem with disparate reporting systems, but I understand now that it is actually an ownership problem and a problem of shared meaning. I have looked at data integration this way since. Integrating systems is the simpler part of the process. Identifying data ownership and building a consensus around the meaning of the data is the most challenging and is the most underestimated work.

The True Cost of Disconnection

The cost of the disconnected systems is greatest in the care that is delivered to the patient. If a clinician cannot access a prior test, that test has to be ordered again. Imaging can mean a patient being dosed with unnecessary radiation. If previous records are not available, it can even mean a delayed and even a missed diagnosis. The same physician leader also talked about how this can cause longer-term costs. AI systems cannot be built without shared data. The disconnection systems that clinicians have to deal with today actually limits the potential of the system tomorrow.

This is an ownership problem and a patient data problem that I have thought about often. The data does not belong to the hospital. The data does not belong to the vendor. Patients share data so the systems can better serve the patient. When data is housed in systems that cannot share or communicate with each other, that is not a proprietary business strategy. That is a failure to fulfill the patient data agreement.

A Developed Role for AI

It is confirmed that AI has potential in this area. Natural language processing and summarization has the capability to analyze across different sources that were not originally intended to be related, and pull organization from disorganized notes. It has the potential to be used for time management to interpret organizational goals. AI has the potential to further address backlogs and be used for operational tasks. AI is more useful when targeted, but optimal use necessitates that operational tasks keep AI more focused.

AI cannot do every task. Model tasks have to be more based around the repeated and highly rule based tasks that require no decision-making. Clinical judgements have no business being relegated to AI, nor have direct patient contact conversations. The goal of AI embedded in operational tasks should be to relieve caregivers, not to create a replacement for care delivering functionality.

Working Alongside the Stakeholders

Progress is due to a shared characteristic of these teams; the early inclusion of clinicians to adjust documentation. Integration is not merely an indication of how many systems work in cohesion. Integration, in this case, is an agreement between data, workflow, and personnel. It is a slower and, overall, less striking achievement than the implementation of a new system.

Running enterprise data consolidation allowed me to learn this in a real-world context. The consolidated integration we designed addressed the majority of requirements, but the specific needs of the endocrinology specialty could not be met by the common data pipeline, so a specific path was constructed. This experience taught me that, contrary to popular belief, integration is not about constructing one universal connector. It is an array of specific choices we make about which pieces belong together, for which audience, and to what degree.

Where to Start

To begin, focus on documenting items where standardization is truly applicable, and where it is not, do not force uniformity, as this does not equate to trust. Two separate teams may mean different things by a similarly completed template. Rather than designing a middle layer which facilitates the movement of data from one location to another, design it to interpret data from disparate sources. Produce the necessary views to allow crossing of service lines as opposed to focusing on a single line. Close the gap between tool design and usage via adequate training and onboarding. Maintain a feedback loop regarding the analytics and those who operationalize the analytics.

The most important consideration is to maintain the patient focus in both the technical and the human question. In the technical question, can these records be connected? In the human question, does connecting these records honor the trust under which the data was shared? If you achieve this, even your most laborious work will be worthwhile. Skip it, and an integration that connected everything in the background still leaves you with a number no one trusts.

Christopher Hutchins Founder and Chief Executive Officer, Hutchins Data Strategy Consultants