In healthcare, having a complete picture of a patient’s health record is key to providing high-quality care. Yet that is seldom the case, even though a majority of physicians and almost all hospitals have implemented an Electronic Health Record (EHR) system.
What usually happens in the current environment is that one can see the information contained in the record system within one’s own institution (hospital, doctor’s office), but records from outside one’s own four walls is not readily available. It requires effort to get that outside data, assuming one knows all the places to go look.
This is not surprising. Consider the evolution of EHRs. Back in the days when most health data was on paper, it was contained within the “chart racks” of a given doctor’s office, or hospital medical records department – in short, the data was contained within the institutions that created them. When EHRs started to make their way into the medical market, they were often closely linked with medical billing systems. Computerized billing systems represent a mature market, and have been around since the 1980s. EHRs were a natural outgrowth of that, and relied heavily on creating documentation that supported billing codes – a result of a fee-for-service payment environment. In fact, some of the criticisms of early EHRs was that they were more “coding maximization tools” rather than “clinical care tools.”
We are now at a time when we rely heavily on the clinical data in our EHRs. And the shortcomings of the state of clinical data, fragmented along institutional lines, is becoming apparent.
Clinical data is different
Moving Clinical Data Aggregation Beyond Interoperability Institutions keep data that is appropriately about the institution. This would include things like accounts receivable management data (billings, payer contracts, even value-based performance data) and accounts payable management data (payroll, vendor contracts, payables). This is data proprietary to the institution, and legitimately would not need to be shared with others, particularly competitors.
Clinical data, however, is not about institutions – it is about patients. The center of that data is the patient. All the institutions and care providers connected to that patient are feeds to that data. By definition, therefore, clinical data is cross-institutional and patient-centric – a hub-and-spoke structure, with the patient as the center of the hub and each institution or doctor as a spoke around that hub. Carrying this notion out to its conclusion, that means that this data needs to be outside of any given institution. It needs to be hosted in a secure cloud environment. Such data should be accessible by each of the “spokes” of the hub, so that the full patient story is available to each care team member who has a therapeutic relationship and is rendering care to that patient (or at least to that subset of the patient’s data which the patient has given permission to view).
Related: Taking A Patient-Centered Approach to Building Healthcare Data
This notion of aggregated patient data goes beyond the concept of data interoperability, which has been the focus of much attention in the past year. Interoperability has been approached as a way of connecting data-access pipes between the institutional data silos, either by direct connection or by connection through centralized hubs (health information exchanges, or HIEs), but leaving the data in place in the silos where it resides. In short, this approach tries to achieve the patient-full-story goal in a way that keeps the institution-centric nature of clinical data intact. This will only go so far. It will face serious challenges as it tries to scale, particularly as new types of data from consumer devices starts to become significant.
Aggregated data is an approach that is fundamentally different. It collects all the data into one place, and does so in a way that it can be accessed by those who need it and have consent to do so. This new way of thinking about clinical data can much more easily allow for new kinds of data sources to flow into the central data store – things like consumer devices, wearables, and patient-entered data (all sources that are outside the domain of HIPAA).
As an aside, not all physicians want device-generated data to be dumped directly into their EHRs. There is a legitimate feeling of overwhelm at the potential volume of such data, and there is an implied liability – “if I miss something, I will be liable.” With an aggregated data store, only views of subsets of the data are visible to each connected audience. A physician may want to see his/her own records, and the records of others caring for their patient, including hospital and emergency department records, but may only want selected dashboard views of certain device data. A patient may want a view of everything (or at least those elements of the record that the physician wants to share), and may be very interested in viewing his/her own device-generated data. If patients want to share some of the device-generated data with the physician, they may need to ask their physician if she/he wants to see it (which the physician can accept or decline).
How do we get there?
We can see the future nature of clinical data as being de-coupled from institutional silos and EHRs, and aggregated into a common data store. This is a landscape quite different from what we have now. How do we get there? Will institutions or vendors open their doors and dump their data into a common pool?
Not only is this unlikely, it is actually not possible, given HIPAA and the need for permissions. A data dump most likely does not have the needed permission. The only realistic way of creating a path to such a necessary next-stage vision is to do so at the time of encounters with the healthcare system.
In my view, this is best done at the time of transition of care – upon referral from one doctor to another, or from discharge from a hospital or emergency department. These are appropriate moments when shared data can be generated, and consent can be obtained. It is the patients themselves who can power this change, if given the opportunity and the tools. “I want my data in a single place where I can see all of it, and those taking care of me can see my whole story.”
By implication, this means that an aggregated data store will build incrementally, not all-at-once, driven by patients and by transitions of care. If built right, with frictionless tools that create such data in an easy way, the build-up of a centralized universal data layer for health IT can be quite rapid – even viral.
Implications for future EHRs
Many physicians dislike their EHRs – recent surveys showed about 70% of physicians are dissatisfied, mainly because of slow-down in their productivity. One of the biggest barriers to dumping a “bad” EHR and moving to something better is the challenge of data portability. How do you get your data from your old system into the new one? Each vendor represents its data internally in completely different ways, proprietary and opaque. So long as the data is trapped within the EHRs that create them, moving from one system to another one is painful.
If the data layer is de-coupled and is outside the EHR, accessible through API linkages that are seamless and in the background, then the EHR becomes a user-interface (UI)-only product. It then doesn’t matter which product one uses, because the data is still there. Specialized use-case customized UIs can emerge, which interact with the external data layer, and can result in EHRs that compete with each other based on usability. Market pressures can move the EHR experience much more quickly in such an environment, and can overcome the “I’ve got your data, so you can’t leave” inertia that dogs the current EHR marketplace.
Conclusions
Clinical data has historically grown out of a legacy of fragmented, local data housed in the institutions that created them. Not all institutional data should be shared, but clinical data is different. It is not about institutions – it is about patients.
Attempts at connecting the institutional data silos via traditional “interoperability” methods are a step in the right direction, but are limited. They leave the data in the silos where they currently reside. A next-level approach is to actually aggregate the data into an external universal clinical data store – a de-coupled universal data layer for all of health IT, accessible through managed APIs. Such an approach will much more easily accommodate not only traditional health data from doctors’ offices and hospitals, but also from consumer devices and the burgeoning field of wearables.
Such a universal data layer for health IT will come into being incrementally, facilitated by new products that can capture patient permission at the moments of care, and during care transitions. The implications for the EHR market are staggering. No longer will data be trapped in their EHRs – the new generation of EHRs will be UI-only, able to interact with the external universal clinical data, and therefore be able to compete with each other based on usability. In the next few years, the landscape will look very different from the one we have today.
Dr. Robert Rowley is the Co-Founder and Chief Medical Officer of Flow Health, a next generation communication platform for care teams and patients, facilitating transitions of care, and aggregating patient-centered data from all the sources where it is found. From its inception through 2012, Dr. Rowley had been Practice Fusion’s Chief Medical Officer, having created the underlying technology in his own practice, and using that as the original foundation of the Practice Fusion web-based EHR. Source
