The other day I came across a quote from Walter Cronkite in which he said “America’s health care system is neither healthy, caring, nor a system.”
Although I believe that the people working in healthcare are caring both in terms of the work we do and the patients we treat, I think Mr. Cronkite was correct on the other two issues. American healthcare is not healthy nor a system.
We all know, especially after all the recent federal effort on healthcare reform, that American healthcare is not healthy. We have been hearing for years about rising cost and declining revenue, and the cost of healthcare as a percentage of the gross national product is daunting. Access for individuals is difficult at best, quality is not consistent, administration is complicated and costly and choice for most Americans is restrictive. But what struck me most is the idea that healthcare is not a system. How did this never click for me!
The answer, of course, is that I have been looking at the wrong aspects of what I do. For years, each of us have been working to build an integrated delivery system. The problem is we have been integrating the wrong things. My effort, and I believe many of your efforts, have been to integrate computer systems and data. These are the brush strokes of our work. Making systems talk to each other, dare I say interoperability, has been the canvas on which we are all painting. I work to get data from one place to another but misunderstood the importance of this task. My integration efforts, although important, have been missing a key component. While busy picking colors in the form of data and interfaces I forgot about the background of my painting; the patient and how that patient data is organized to enable high quality treatment. That is the real deliverable. It is not about moving data from A to B; it’s about moving data from A, B, and C to the clinician.
As I started to think about this difference it struck me that it is not only important to deliver data to the clinician but to deliver that data within a context, because healthcare data is contextual. We need to present clinical data within the context of the patient as a changing organism. A blood sugar level of 150 for a type 2 diabetic may be acceptable but a level of 150 for a pregnant woman would mean gestational diabetes. A brittle type 1 diabetic with a blood sugar level of 150 would be a different issue entirely. The context has been the missing component in all the integration efforts.
We need to paint a picture of a person seeking treatment containing not only information, but the context within which that data lives. This background would have to include a problem list, current medication, allergies, and most recent clinical findings, and outcomes. We need to create a comprehensive, holistic views of the patient at the point of care in order to create an appropriate composition in which to understand the data.
This is the system we need to build. A system implies a set of functions within a structure that forms a whole. The context — the composition which defines the structure — is missing in our current application suites. Our current environments of data living in silos outside of a context is not a system. No context, no composition, no system … my God, Walter was right. There is no system.
We need to meet the needs of our patients and we fall short. We have not provided the tools to enable care coordination. We must be able to give our clinicians a picture of the patient sitting in front of them which has the current clinical landscape of care, and we must provide a pallet to deliver care coordination. I think one of the fundamentals of this effort needs to be the ability to share data in the context of the patient. This will improve quality, reduce cost and increase efficiencies. I thought the HIE I have been building would be the means to accomplish this, but now understand I have to go back to the canvas and fill in the background. I have not included the clinical context in the movement of data, and lacking that will not be able to drive care coordination efforts to improve and manage chronic and acute episodes of care.
All this time I thought the HIE would be a tool from which to build a comprehensive longitudinal record, but now think what I need to build is a comprehensive immediate record devoid of all the data noise of clinical history. We can only filter out that noise by framing the information in a context which will change based on clinical speciality and current episodes of care. Have I got this right? Let me know your thoughts.
Marc Holland says
Dan, I couldn’t agree more. In fact, I would go further and say that information delivery should not only be based on the context of the information, but also the workflow context.
If one looks back on the evolution of many of today’s health information exchanges, one sees that those early efforts trace their technical DNA to portal technology. By its very nature, a portal is a display-oriented technology, not a workflow-oriented one – and, for a busy clinician, not the most effective means of information delivery.
Let’s refer to the Wikipedia definition of a portal. It reads “A web portal, also known as a links page, presents information from diverse sources in a unified way… Portals provide a way for enterprises to provide a consistent look and feel with access control and procedures for multiple applications and databases, which otherwise would have been different entities altogether.”
Even today, several of the HIE products remain principally platforms for creating portals. The fundamental design philosophy behind a portal is that it is simply the passive display of data extracted from multiple sources that satisfy the search arguments supplied by the user.
Inherent in this paradigm are several assumptions. First, that the end user has the time and motivation to stop what they were doing to execute the search; second, that the end user is executing the search because he or she generally expects to be successful – that is, they expect to find information that is of value and to find it in a high percentage of cases. If the user doesn’t think a search will yield such results, why would they bother?
What if most of the time we “Googled”, we saw those dreaded words: “Your search did not match any documents. Suggestions: Make sure all words are spelled correctly; try different keywords; try more general keywords”, would we Google quite as often? I think not. And I bet everyone can relate to the experience of entering a search argument that is too general and when you get back 20 pages of mostly irrelevant matches, thinking “who has the time to wade through all of this?”
Now imagine you’re a physician treating a new patient who presents with a specific condition. Would you go search your local HIE for that patient’s medical history if you had only a 25% chance of finding information – any information – for that patient. And what if more than half the time when you did find information it was irrelevant to the problem the patient presented with? How long would you continue to use that information source? Not long, I would argue.
So while for some applications, a portal may suffice, as you pointed out, the most valuable use of historical patient data is dependent on its ability to be delivered “in context” across two dimensions – first, its relevance to the context of the patient’s current encounter and second, its ability to deliver the information at a point in the physician’s workflow when it is most needed. Providing too much information, requiring that it be actively sought or delivering it at the wrong point in the workflow just won’t cut it – especially when the target audience is an experienced, overworked, impatient physician.
If one looks at the most successful exchanges operational today, one finds that they have several characteristics in common: first, they push information out to end users “behind the scenes”, rather than waiting passively for end users to “pull” it down; second, they deliver information in an appropriate workflow context. That said, I’m afraid that we’ll have to wait a little longer before CDS rules engines mature to the point where delivery is consistently governed by an appropriate clinical context.