Skip to content Skip to navigation

The Single Patient View

October 16, 2007
by Lindsy Strait
| Reprints
There are some common missteps that IT professionals make when trying to bring about the single patient view.

Right patient, right information, right time, right place: that's the adage many of us use to describe the much sought-after "single patient view." But what's missing from that oversimplification is the need to present the information in the way that a provider needs to see it and work with it. This is exactly where so many organizations get off-track. They rely on solutions that simply cannot deliver the end-user value that is so important to integrated healthcare. Here's a look at where they're going wrong — and how they can get back on track.

1. Taking a single-system approach

Whether they're based on multiple data models, master patient indexes and spines, multiple automated medical record paradigms, or any of a number of other frameworks that have emerged, most approaches to the single patient view have one thing in common: They're premised on the idea that you can build such a view by procuring a single application (or a single set of applications), administrating clinical data into a repository or integrated exchange layer, and then providing read-only roll-ups across systems for specific information.

While this single-system model may allow unprecedented data views, it does nothing to enable data utility. If providers want to work with the data, they're forced to choose one of two weak solutions: a) a proprietary system that supports data modifications but does not allow you to work outside of that system and the data it manages, or b) a solution that enables an extracted or aggregated set of data from anywhere across a number of distributed systems but does not provide the data modification capabilities to support workflow.

The result is usually that the provider ends up bouncing between systems to try to establish some meaningful insights, and then using multiple applications to conduct workflow. It's frustrating, time-consuming, and unsustainable as a long-term solution for the single patient view.

I believe the answer lies instead in an integrated composite application — one that spans multiple applications and administrators and is workflow-optimized to provide not only data access, but also the ability to update, modify, and otherwise work with the data. No single application can deliver these comprehensive capabilities, but a solution that integrates capabilities from multiple systems in a service-oriented architecture (SOA) environment can.

2. Basing everything on a single repository

A single patient view based on a single repository is not realistic for a number of reasons. For one thing, it is likely to be economically unfeasible for many organizations. And even if that is not the case, such a solution is going to be inherently complicated to administrate, difficult to secure, and a challenge to keep current and accurate. It might be useful for light data aggregation for specific timeframes or domain spaces, but it is not likely to be sufficient over the long term.

The biggest problem is that no single repository can maintain all the relevant data from a multitude of independent sources that is needed to cover the full continuum of care. I believe a more sensible approach is to store and maintain data at the source of origin or the point of service. Then, when called upon for workflow support, the relevant data elements can be exposed and integrated in a specific-workflow data set, regardless of where they are administrated.

This is not something that a typical single repository can do in a cost-effective manner — if at all. Rather, it requires a composite approach that draws from multiple applications and elements without attempting to consolidate the data from them in a single physical repository.

3. Counting on a single MPI

No single master patient index, or MPI, can accomplish all of the identity management functions that a single patient view requires. For example, there are times when a specific patient record needs to be identified; an index key certainly provides the functionality to do this. But there are also times when data structures need to be exposed and navigated; directories are a better choice for this. And there are times when relationships need to be systemically arranged and managed; catalogues do this best.

All these functions are required to accomplish the optimal coordination of data state transition and relevance matching for a single patient view, and a single MPI simply cannot deliver all of them.

The main problem with attempting to use an MPI to provide an integration layer is that an integration layer alone does not help to accomplish the true goal of integrating not just the data, but the workflows associated with it. It may provide single patient identification and a roll-up capability for data, but it cannot enable workflow optimization. To do that, you need to be able to integrate and update data from multiple sources across multiple geographic, organizational, and other boundaries in a secure, integrated fashion. Again, a composite approach is far better suited than a single MPI to achieving this goal.

4. Trying to maintain a single point of control

It's true that many delivery networks, insurance companies, government agencies, and other healthcare entities are currently attempting to maintain electronic health records (EHRs), outcome databases, and MPIs at the enterprise level. But where they can get into big trouble is in trying to centrally control the flow. I maintain that it will never be practical for a single organization to administrate an adequate data and service set to support a single patient view across the full continuum of care, given the amount of effort and legal control required.