Posted September 15, 2008 by Lygeia Ricciardi
Friday we talked with Patti Brennan, Director of Project HealthDesign, about this week's Project HealthDesign event in Washington, D.C. Today, we are focusing on the challenges and opportunities that lay ahead for personal health records.
What are the barriers that need to be addressed now in order to advance this new vision of PHRs?
I think there are two really significant issues we need to be paying attention to: privacy and incentives. Right now, our privacy policies tend to be organized around institutional responsibility for safeguarding data that’s generated during the business process of health care; that’s very important and that will never go away. I’m not suggesting we shouldn’t have that focus, but that focus is insufficient and, frankly, cannot be extended easily to the idea of personal health records.
Personal health records are actually, if you will, globules of data and action tools, scattered all over the place. And so to create a model of health privacy policy that affects only one institution in a long chain of data management, and only specifics about the data and not, for example, the kinds of robust privacy-controlling mechanisms that consumers will need, is just not going to enable us to see the real benefits of PHRs. What could really work are policies that enable effective use of data while establishing rules for safe data storage, appropriate data uses and efficient patient control.
The second issue is incentives, and I want to talk about incentives from a couple of different perspectives. We often think about incentives as who’s going to pay for the PHR. To me, PHRs are quite a bit like iTunes. There are musicians that make the music. There are record companies that distribute the music. There is iTunes that provides a different kind of platform for distribution. But in providing that platform, they actually have broken apart CDs so that users only have to take the pieces they want. You don’t have to buy the entire album, just the songs you want. And iTunes offers other important services. They keep track of the music and movies you purchase. They recommend other songs you might like. So this idea of many players in a distributed market of health data suggests that there would be incentives, first of all, for creating various kinds of repositories and action tools, and they might vary quite a bit. So institutions, health care institutions, have an incentive to have good data management, because health data is a capital resource for the institution. But there are other reasons why a company such as Google might want to get into managing health data. Maybe it’ll draw more people to their site, and they can refer other sources or other products to them.
Another kind of incentive that has to be built in is the incentives for lay people to become more active in health management. These are less likely to be financial incentives, although I can imagine how financial incentives could be really quite important to this group. It’s more likely to be power-shift incentives. If a lay person is going to spend the time to record and understand information about themselves and interact with their clinicians about it, they need to be heard, and respected and brought in as part of the care team. So the incentive there--incentivizing lay people to be engaged in health--is as much a challenge to the lay person, to figure out how to grapple with all this stuff, as it is to the clinician to figure out how to work this into their idea of what a client-patient relationship is like.
The third kind of incentive is for physicians and nurses - the incentives to change their practice, which PHRs have the potential to do. Think about decoupling the moment of patient teaching that happens when a patient is discharged from the hospital, or the last five minutes of his medical visit, to a more extended period, where information could be distributed to the individual on a daily, weekly or monthly basis. That creates a challenge to the way clinicians generally behave. So if there is going to be a requirement to change provider practice, it has to be incentivized. Now, no longer can a clinician say, “Well, I told the patient in my office the six things she needs to do to ensure that she is taking this medication properly” and assume the case is closed. If we migrate from a one-time set of instructions to a more ongoing, interactive mode of communication, we have to help providers understand how to do that, the benefits of making this type of change as well as the potential risks.
We also need to look at how some state laws may interfere with clinicians’ ability to fully attend to information presented by a patient. Some state laws basically restrict the ability of a clinician to treat health data, as presented by a patient, in the same way as health data that were generated by a clinical care institution. So the blood test you capture at home is different than the blood test you got at the laboratory. Additionally, there are concerns on the part of clinicians about the enormous volume of potentially important details that might be hidden in a PHR, information that could be significant in care, and to the clinicians’ liability for potentially not looking at the PHR. So the incentive structure has to address this very delicate balance of liability, work flow issues, and clinician cognition when it comes to thinking about changing the work of patient care. I think that’s really far down the line, but I think it’s an important kind of incentive structure to be mindful of right now.
What is the Common Platform and why is important for the advancement of PHRs?
I am so glad you want to talk about the common platform. This is really important. The common platform is a set of software tools, rules and repositories that provide a common (i.e. similar) way of labeling all types of health data, from blood tests to observations in daily living, storing it in a systematic manner, and allowing a whole host of other computer applications to use the data without having to know all of the details about how and where the data are stored.
For example, to a patient, the dispensing information of “take one tablet three times a day” isn’t relevant. But what becomes really relevant is “how much can I modify that dispensing? Do I have to be up every morning at 7:00 to take the first one? Or as long as I take it three times a day, separated by at least six hours, am I all right? ”It is about understanding how to interpret information. And so the common platform provides a way for bringing together the prescribing-dispensing information from a clinician and the consuming or dispensing information from the perspective of the patient.
Since the common platform is a set of software tools, there is actually computer code, and the computer code allows us to both experiment with and demonstrate that it is possible to separate data from applications, to build applications not really understanding exactly what the data structure is, and essentially have the common platform serve as a translator between the way the data looks originally and the way the application actually needs it. So it’s a little bit like how a recipe helps you take things from your cupboard and put them into a cake. The recipe doesn’t know where the butter comes from or where the flour is stored in your kitchen, but it does tell you if you have these things, you can bring them together and you can make a cake here. And so the common platform is the software equivalent of finding things from multiple sites and putting them together in a common way.
It is important to note that the common platform was built to demonstrate a very fundamental principle that we have in patient-centered computing, and that is patient control over data access at the level of the data element, not at the level of the data. So right now, if I give my physician permission to see my medical record, he sees the whole record. But I might want my gynecology records limited to only my women’s health practitioner and no one else, because I don’t think anyone else needs them. Now, I certainly am not talking about controlling what the hospital-based medical record shows, because that is a very different kind of a legal entity. But if I’m keeping really close track of my menstrual cycle and my sex life for a discussion with my clinician, I don’t necessarily want that shared with my dentist. And so being able to assign permissions on the level of data elements is really important. This is pretty complicated, and it gets burdensome to patients. Yet, it is important and that is why we have spent so much time working on the common platform and its role in advancing patient-centered PHRs.
There has been a lot of emphasis on the development of Regional Health Information Organizations (RHIOs) as a key element of electronic health information exchange. What is the relationship between RHIOs and PHRs, particularly stand-alone models? How can they best be integrated?
To me PHRs are essential to getting full value out of RHIOs. The value of RHIOs and the decision to sustain them has got to be because they’re going to do new things that couldn’t be done before. One of those things is being able to integrate patients into the health care system in a totally different way. And so if we think about the last ten feet of a RHIO extending into people’s bedrooms or kitchens, then we have an enormous potential for both reaching in with public health announcements and reaching out with observations about health status indicators across the community. This will help us better understand where there are needs that are currently not met. So the general idea of PHRs and RHIOs actually fits together really well and that’s really important.
Now having said that RHIOs and PHRs fit together really well, I think that they really require a different kind of visioning than we have now. I’d like to think about how physician and institution-directed PHRs can fit with patient-centered PHRs--and they’re really not in conflict with each other. As long as we don’t presume that there is a dominant binder or record that is the patient’s total life history, but rather think that there can be data from many places, that come together for many different kinds of uses. So I may want to pull all of my weight information from the six or seven doctors that have that here now in Madison, to be able to look at how my weight is changing over time, and that wouldn’t be able to be done with a PHR for Dr. X, and a PHR for Dr. Y, and a PHR for Dr. Z. It requires that instead we think about entities, like hospitals and clinics, being contributors and receivers of information with PHRs, engaged in the exchange with them, if you will, rather than being the point where they exist.
We’ll wrap up our conversation with Patti tomorrow with a look towards the future of PHRs and the Project HealthDesign grantees.
Comments