Healthcare in the U.S. is on the threshold of fundamental change. Powered by advances in federal policy, the underlying way in which we pay for healthcare is moving from the traditional fee-for-service, pay-for-volume historic approach to one that pays for demonstrated value.
The way in which value is measured is still evolving, but risk-sharing, measuring the health status of populations, and coordinating care in order to improve effectiveness and reduce the total cost of care are the basic planks upon which this new environment is being built.
This next chapter of U.S. healthcare will require changes on several levels. For starters, the way physicians are organized is changing. Though still prominent elements of the landscape, small and solo practices are fading – sometimes by going out of business, sometimes by retirement, sometimes by being bought by health systems.
What are growing are organized health delivery networks, either in consolidated centers or distributed in local practices in the community (but owned by, or affiliated with, larger, recognized institutions). The capital needs and staffing reconfiguration are things that are generally beyond the reach of smaller practices.
Bringing on other care team members, beyond just the doctors – case managers, care coordinators, health educators, and numerous other new roles that have yet to fully emerge – generally just doesn't work in smaller practices. This is particularly true in a fee-for-service environment, where the only way to get paid is to have face-to-face contact with doctors. In that setting, everything else is overhead. In a value-based setting, all that changes.
What kinds of tools will be needed to power this change? In the last 10 years, we have seen the proliferation of electronic health records systems, rising from a 4 percent penetration into clinical practices, to now over 80 percent of practices. EHRs have become the norm.
The shortcomings of EHRs
EHRs grew up in a fee-for-service environment. They are designed to address the workflows within a given office or hospital, and are created more as documentation tools from which billings can be generated. They are not designed as collaboration tools across organizations.
Clinical data is organized around clinicians, practices and hospitals – it is not organized as a patient-centered, patient-owned record that follows a person longitudinally over their lifetime. As a result, a given patient's full story is fragmented, with each institutional silo containing only a segment of a patient's full story.
As EHRs, pushed by federal policy (meaningful use, along with the attendant product certification), try to address the fragmentation of clinical data, much is being said about interoperability. At the current stage of EHR evolution, this means that an organization's EHR reaches out in order to locate records for a given patient that might be found in other organizations' systems.
Health information exchanges try to do this, but are limited by the number of subscribers to their hub. Data-querying hubs by large EHR vendors have a wide reach, especially with other users of the same EHR. Other product-agnostic efforts tend to be local, usually supported by hospitals and health systems, and have achieved some success in connecting data together via queries. But overall, these efforts are still in their infancy. The kind of data that is exchanged is limited, mainly confined to the elements found in standardized message types such as consolidated clinical summaries (C-CDAs).
Some proposed changes being debated for the next stage of meaningful use (Stage 3) would require EHR vendors to lower the barrier for data exchange by making available back-end modern APIs of specified types.
This theoretically would allow easier, more standardized connectivity between different EHRs, and help extraction and insertion of data more readily. Expensive customized interfaces between systems would not be such a hurdle. But even there, EHR users would still need to find each other, somehow know (or query) whether there is data in the external system about the patient at hand (assuming that patient matching is successful), and then fetch it.
The problem with this approach? It leaves the data fragmented. Simply querying via a record-locator service and fetching a copy or a view of a record for a patient does not change the fundamental fragmentation of health data. It leaves the silos intact. This problem will never be solvable by traditional EHRs – it is a fundamental structural shortcoming of our current technology platform.
Another way to look at it is this: EHRs are built to improve the workflows of clinicians doing their siloed work. They do not require complete knowledge of a patient's case in order to help maximize documentation and billing. In a value-based environment, complete knowledge of a patient's health status is critical.
This is especially true for care coordination between different settings of care – for example, a community hospital, a tertiary specialty center, the primary care physician, the many specialists involved, and the home health agency providing after-care. EHRs do a poor job of this. A new type of tool, built on knowing the entire patient story, is needed.
So what do we need to build for value based care?
If the world were to remain fee-for-service, current EHR technology might suffice. More or less. But as we change the payment approach from pay-for-volume to pay-for-value, and the organization of healthcare delivery becomes more systematized, it becomes critical that there be a technology layer which is built around collaboration, and creates longitudinal patient-centered data that draws from all sources.
This is more than simply building a tool, or a new technology that adds-on to the current landscape. It requires a whole new operating system.
Central to this operating system is a secure HIPAA-compliant cloud-based data platform that is able to absorb clinical data from all different sources – from EHRs, from hospital notifications (admission/discharge/transfer messages), from insurance claim data, from pharmacy data, from laboratory data, from home health agencies, from imaging centers, and from patients themselves (self-entered and device-created).
It must be able to uniquely identify each patient, each provider, each organization, using robust modern algorithms that can tag all the incoming data into the correct patient center. It must use modern data technology to build a structure that can scale massively and yet be responsive. That is the input pipeline.
The outputs of this platform need to be similarly robust and responsive, so that actionable data can be extracted in a real-time way. Aggregated data for individuals needs to be available for EHRs (current ones or next-generation ones that don't need to keep local siloed data), population data needs to be available for value-based organizations, and de-identified data needs to be available for insights and research. That is the output pipeline.
Such an operating system is more than just "interoperability" between disconnected systems. An OS can focus on workflow between applications, achieved through deep API level integrations. Such an OS can enable access not only to common data, but can share common capabilities. Think of push notifications on a mobile device – you open a mobile notification that appears on your smartphone created by one app, and you can launch an appropriate second app directly.
Thinking of this platform as an operating system, a collection of apps can be built. The initial set of apps both demonstrate the power of universal patient-centered data, and also help build that data.
A provider-facing app shows clinicians the timelines of the patients which they have permission to see.
An office-based check-in app that replaces the paper clipboard, and gathers context-specific information from the patient, pre-populated by the data that is known already, drawn from all combined sources and not just from the EHR of the clinician that the patient is seeing. With good EHR integration, patient-entered data can be inserted into today's chart note in the clinician's EHR, helping streamline the in-office workflow, and can help prompt the clinician to do things needed for disease management, preventive care, and health risk stratification and documentation (important in Medicare Advantage and other similar programs where risk assessment is the basis for payment levels).
Also, a patient-facing app can show all the aggregated clinical data from all members of the care team in a consumer-friendly way, and allow a secure way to message back and forth between patients and care team members. It addresses the demand for "give me my data" voiced by many consumer advocates. Depending on how it is configured and supported, such a universal patient portal can even be used for remote visits in support of telemedicine efforts.
Other use cases for this operating system also emerge. Things that had been discrete problems in the traditional institution-centric layer of health IT, and had required specific products to address them (such as Enterprise Master Patient Indexing to match patients in different data sources, or Medication Reconciliation programs), are solved intrinsically as part of the platform. The platform can be used for patient matching and data scrubbing, such as medical groups or health plans feeding their messy and fragmented data into the platform, and then retrieving that data back in a clean and normalized fashion for their internal use.
Conclusions
In order to support the sea change occurring in medicine – moving from fee-for-service to value-based care – the technology platform must also be re-invented. Institution-centered technology, which is the soil where current EHRs have grown, will no longer work. No matter how much effort is put into connecting data silos with record locater services and lowered technology barriers between them – dubbed "interoperability" in current lingo – the solution will not be sufficient. A universal data platform is needed, where patients and care teams can see their information and use it in meaningful ways.
This is a new paradigm. It is an operating system for value-based care. It is a modern platform that has input pipelines and outputs, and draws from modern social technologies that have emerged in other arenas outside of healthcare. It includes some apps as starting points, and encourages the health IT developer community to build on top of it.
