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.
The reality is that the single patient view needs to be a virtual solution that will require not a single, centralized point of administration, but rather an ability to span multiple agents and episodes of care, and the capability to deliver views into a longitudinal set of services at a specific point in time. Such an implementation would also have to:
· fully manage state transition and relevancy across all agents, episodes, and data to present the data meaningfully;
· organize data into user-specific views supported by relevant information and worksets;
· provide a method of allowing users to know which specific types of data are available
· allow the patient, as the owner of the privacy rights, to determine who sees which data, when and where.
I contend that the most feasible way available today and in the near future is to deliver these capabilities through a composite-application approach that draws from multiple applications and systems in an SOA.
5. Plotting a single path from project to production
In the rush to roll out single-patient-view projects, many organizations fail to clearly define the real-world user requirements that the project should meet (and how it will meet them), adequately plan for testing, or take appropriate measures to have the project requirements validated by actual target users. The problem is that foregoing these steps in order to get into production as soon as possible and at the lowest possible cost is likely to have just the opposite effect. The project may get done on time, but it will not satisfy the user requirements and will very likely fail over time.
The key, therefore, is not only to move toward a workflow-centric single patient view and a composite-application approach to achieving such a view, but also to define exactly how the project will enable that outcome. Rapid delivery approaches and prototyping do not eliminate the need for accurate real-world specifications or for measurable success factors that are based on actual real-world workflows.
Clearly, the response to the challenge of the single patient view must go far beyond the current state of any enterprise-level information systems, EHRs, or repositories. An SOA delivering composite applications is the required solution set for a virtual, longitudinal, single patient view. And a well-planned, fully tested, and validated plan for implementing such a solution set will be vital to its success.
Lindsy Strait is CTO of Healthcare and Life Sciences with Santa Clara, Calif.-based Sun Microsystems.
