Can Meaningful Use Become More Meaningful for Patients?

Patricia Flatley Brennan, R.N., Ph.D., Project HealthDesign Director

Because so many of the Stage 1 meaningful use criteria apply primarily to professionals’ uses of health information technology (HIT) in clinical care settings, Project HealthDesign is pleased to see criteria proposed in Stage 2 that would allow patients to become beneficiaries of meaningful use of HIT.

Meaningful use shouldn’t focus exclusively on electronic health records (EHRs) and clinical care settings. It’s time to ensure that the benefits of HIT meaningful use extend to the everyday lives of patients and families.

We call for accelerating the criteria for meaningful use Stage 2 that would lead HIT to:

1. Exchange health data back and forth between EHRs, which house clinically originated data, and PHRs, which house patient-originated data. Health data arise from a variety of sources. Our work on Project HealthDesign has shown that patients value health data that they themselves define and generate. These types of health data, or observations of daily living (ODLs), can include data related to mood, pain levels and even sleep quality.
   
   
2. Allow patients to invite trusted others, including family members, friends and surrogate decision-makers, to access selected health data. The coordination of patient care would benefit from this type of shared access, which engages patients, clinicians and other individuals designated by the patient while also allowing each patient to maintain the level of privacy he or she desires.

Now is the time for a broader, bolder approach to meaningful use. Patients are relying on HIT professionals to ensure that the bilateral exchange of health data between EHRs and PHRs is meaningful for both patients and clinicians. For more information, please read the full Project HealthDesign Stage 2 meaningful use comments.

Related resources:

• View the full draft of proposed Stage 2 meaningful use criteria [pdf].
• Read Project HealthDesign national advisory committee member John Halamka’s comments.

Stakeholders Weigh in on PCAST Report

Deven McGraw, Health Privacy Project Director, Center for Democracy & Technology

Project HealthDesign Director Patti Brennan recently blogged about the report issued by the President’s Council of Advisors on Science and Technology (PCAST), which set forth recommendations to facilitate more effective use of technology for health information exchange. In the post, she praised the more expansive vision of exchange promoted by PCAST and noted the absence of a robust discussion on the need to include patient-generated data as part of this broad vision.

Efforts to analyze the PCAST report and determine how its vision of greater health data liquidity can be achieved have begun in earnest. The Health IT Policy Committee (HITPC) has established a PCAST Report Workgroup, which held a day-long public hearing on Feb. 15.

Stakeholder groups testifying included consumers and patients, providers, technology experts, and health information exchanges. Nearly all agreed with the goal of facilitating more widespread electronic exchange of health data for treatment and secondary data uses like public health and research. But stakeholders also raised a number of concerns about some of the recommendations in the report, including:

• fears that exchange of information at an “atomic data element” level would rob the information of the context necessary for providers and researchers to understand it;
• concerns that providing patients with very granular choices about how their data is shared could be difficult for patients and providers to manage;
• uncertainty about whether the PCAST recommendation for a “universal exchange language” would disrupt (or build on) existing data standardization efforts; and
• questions about whether the designated approach to protecting privacy – tagging data elements with meta data about privacy preferences and other applicable data sharing constraints – would be workable and effective.

The key task for the PCAST Workgroup, the federal advisory committees, and ultimately HHS will be to find a path forward to promote the PCAST vision in a way that builds on work that has been done in the past and effectively responds to implementation concerns raised by stakeholders. Here are a few possibilities:

• Ramp up the requirements for health information exchange in Stages 2 and 3 of meaningful use, including active exchange of data with patients.
• Adopt and implement standards that will allow patients and providers to exchange computable data with one another no matter which EHR, PHR or software application is being used.
• Develop the infrastructure for a query-response model of health data exchange that is based on the needs of the patient.
• Pilot privacy-enhancing technologies (including but not limited to the meta data tagging approach recommended by PCAST) and research both their efficacy and impact on care.

This first year of the meaningful use program provides us with an opportunity to test the efficacy of current strategies for effective use of health IT to improve health and health care. The PCAST Report provides yet another opportunity to consider whether these efforts are headed in the right direction and how we can accelerate progress toward the goals we share.

This week, those interested in HIT have another opportunity to influence future public policy in this arena: HITPC is soliciting public comments on proposed Meaningful Use Stage 2 objectives through Friday, Feb. 25.

BreathEasy Clinician Proposes New Model for Patient-centered Health Information Systems

Barbara L. Massoudi, Research Triangle Institute, BreathEasy Principal Investigator

Alex Krist, MD, MPH, a member of the BreathEasy team from the Virginia Commonwealth University Department of Family Medicine, recently published a commentary in the Journal of the American Medical Association (JAMA), “A Vision for Patient-Centered Health Information Systems” (JAMA, Jan. 19, 2011, Vol 305, No.3). In the commentary, he discusses the current state of patient-centered health information technology and proposes a model for a patient-centered health information system based on five levels of functionality (see graphic). 

Upon reading the commentary, I started to think about which level of functionality the BreathEasy project falls into, or for that matter, which level any one of the Project HealthDesign projects would fall into. The highest level of functionality is designed to help patients take action — certainly something that fits well with the Project HealthDesign focus on observations of daily living (ODLs) and putting “tools” into patients’ hands. In describing this level of functionality, Dr. Krist says “Trust comes when the personal health record has the endorsement of the physician and is designed to seamlessly interface with care delivery, as when output is shared and the personal health record refers patients back to their physician for assistance or helps them prepare for upcoming office visits.” This is certainly the goal of most, if not all, of our projects.

Dr. Krist goes on to describe some of the challenges related to building systems that function at the highest level, including programming to personalize messages, cultural competency and integration with clinical workflow. These are all issues we’ve considered at length while working on the BreathEasy project. We’ll be conducting lab-based usability testing of our BreathEasy application with both patients and clinicians in the next couple of months, so we’ll soon see how we’re doing.

Learn about BreathEasy.
Read more posts from the BreathEasy project team.

Image: JAMA

RWJF’s Steve Downs on the Future of Mobile Health

In his recent blog post, “Data, Apps and the Rules that Bind Them,” Steve Downs, assistant vice president of the Robert Wood Johnson Foundation’s Health Group, comments on the popularity of mobile health and the importance of personal health record (PHR) data. In the post, Downs notes several policy questions related to mobile health privacy and security that must be addressed if the mHealth surge is to continue.

“Until policymakers step in and provide guidance, the chilling effect on innovation will continue, furthering our reliance on an antiquated model of care that does little to empower patients to be active participants in their own health decisions.”

He notes three PHR-related themes that are particularly important as policymakers look toward the future of mobile health: separating the apps from the data, expansion of the definition of health information, and the increasingly social nature of health care.

Read the full post on the Pioneering Ideas blog.

Do People Hide “Bad” Observations of Daily Living?

Tim Patton, Project HealthDesign Ph.D. in Engineering Student, University of Wisconsin-Madison
Uba Backonja, Project HealthDesign Ph.D. in Nursing Student, University of Wisconsin-Madison

People might not be willing to share all of their observations of daily living (ODLs). This may be old news to health care providers, but it was a bit of a surprise to the engineers among us as we looked for information to help us design systems that support patients’ real needs in regard to personal health management, decision-making and monitoring behaviors.

Because they are indicators to which an individual pays attention and finds important to his or her health, ODLs are very specific to individual patients. To begin to obtain a systematic understanding of ODLs, we recently conducted a pilot in which we performed one-on-one interviews with 10 college students. The ODLs that emerged focused on health behaviors (e.g., exercise) and monitoring symptoms (e.g., pain). Because we framed the questions in terms of health, this is largely what we had expected. Throughout the pilot, we found that participants seemed willing to talk about very personal ODLs and discuss their personal habits’ and relationships’ impacts on their health.

Because of this apparent comfort with disclosing highly personal information, we assumed that participants would be comfortable disclosing all ODLs. However, we have some reservations regarding whether that assumption is true. During the interviews, not one student mentioned drinking alcohol, smoking, drug use, sex (unsafe or otherwise) or partying. In fact, none of the ODLs the students reported to us carried a negative social stigma, or could be seen as a “bad” ODL.

Were we simply lucky with our sample? The CDC estimates that 21.4% of adults ages 18–24 smoke and that  young adults and adolescents under 21 drink 11% of all alcohol consumed in the United States. Furthermore, the CDC estimates that 43% of all students report drinking in a high-risk manner at some point during college. Statistically, it is unlikely that such behavior was truly absent in our sample population.

Thus, we are left to ponder why the “bad” ODLs were missing. We have considered the following:

1. Our questions may have biased participants toward ODLs that improve or maintain health.
2. Participants didn’t think to observe the effects of “bad” things as ODLs.
3. Participants may deliberately avoid mentioning ODLs that might cast them in negative lights.

First, given that participants did mention things that detracted from health (e.g., lack of sleep, poor diet), we don’t think this can be explained by a positive bias in our interview questions. Second, other negative behaviors were noted (e.g., poor diet choices and exercise habits). Thus, we are left with a sense that people deliberately avoided telling us about “bad” ODLs.

Due to the anonymous nature of our interviews and the encouraging early results, we were hopeful we could avoid this potential issue and strive to account for it in future work. To properly design systems in support of ODLs, we must understand the full range of personal observations, including those that people prefer to keep to themselves. Thus, as we continue to push for systems that support personal health, we will likely need to find ways to safely and securely elicit all ODLs, whether good or “bad.”

Read more posts about ODLs.

Dogs as Animal Models for Research

Gillian Hayes, University of California, Irvine, FitBaby Principal Investigator

As a researcher who focuses on computing systems and their designs and uses, the checkboxes on all my various research oversight forms for preliminary animal research and animal models never made a lot of sense for my work. Two things happened this month, though, that made me rethink the whole idea of animal models for my research.

First, I watched a fascinating PBS documentary about dogs. As a dog-lover, I was keen to learn about the co-evolution of our species, both biologically and sociologically. Dogs are key animal models for research in the standard sense of being good disease models for certain human diseases. Beyond that, however, their evolution and behavior also serve to inform us about human history, migration patterns, the development of societies and more. From this documentary, I also learned the important role that dogs have in acting as “juveniles” in the lives of humans. In other words, we like them in part because they act so much like human children.

That got me thinking about one interesting way I have used my dog in my research lately: as a proxy for a premature infant. I have been debugging our FitBaby application for the last few weeks by logging information about my 9-year-old retriever. When my dog Savannah and I go out for a walk, I log in our application “Took baby for a walk;” when Savannah poops, I log another dirty diaper in the application.

As is to be expected, I have found in our software a lot of little bugs, which we are fixing. What surprised me, however, is how I began to change my behavior. I never sing to my dog. First of all, I am not a great singer, but secondly, it has never occurred to me that she might like it. The little icon on the screen that I am not earning by not singing, however, has a profound effect — one that we planned it to have on parents, who we hope will sing to their babies. I find it taunting me, wanting to be earned, and so I sing to my dog. She actually seems to like it. So, maybe we are on to a new tradition.

Learn about FitBaby.
Read more posts from the FitBaby project team.

Practical Wisdom Gleaned from the Development of iN Touch

Katherine Kim and Christina Sabee, San Francisco State University, iN Touch Principal Investigators, and Ed Young, iN Touch Research Assistant

Even from our first meetings in early 2009, we were excited about the possibility of using TheCarrot to improve young adults’ abilities to manage their health and improve communications with their care teams. This partnership was a way for us to explore how new technology could interface with our public health system. The platform seemed easy to understand and use on a mobile device.

So how hard could it be to tweak the existing technology for our project? The answer: hard.

Even when working with an existing technology and responsive partners, it turns out that meeting diverse needs, interests and experiences takes time, and energy and patience. So what have we learned?

1. Expect delays: Our work with health care providers at San Francisco General Hospital and with our Youth Advisory Board has been invaluable for learning about the needs of our community. Providers and patients have different needs and they are not used to translating those needs into techno-speak. So, we’ve iterated, reviewed, tested and fixed to get to our final launch version.
2. Be ready to coach users on the technology. One of the reasons that we decided to partner with TheCarrot was that the application was easy for us to use. But as we began to demonstrate to potential users, it became clear that they would need assistance. Users like to explore. They don’t just follow your test scripts. Therefore, we have to be ready to help them wherever they end up.
3. Communicate as much as possible to the technology developers and have realistic expectations. Our user meetings are exciting because we come up with really interesting ideas about how to meet everyone’s needs. Users have great imaginations! Translating those amazing ideas early and staying in touch with the development team is critical. We have to balance users’ grand ideas with our scope, cost and timeline.
4. Write up everything you need and make sure all parties understand what the needs are. Being clear about needs and interests is important in any kind of negotiation, but when engineers and users are trying to come to a clear understanding, the needs are more important to communicate than anything else. Users can draw pictures, imagine the ways that an application might work and even describe exactly the feature that they want. But until we explain clearly exactly why we want the feature (i.e., the need that has generated the idea), engineers will struggle with implementation.
5. Plan, plan, plan and stay flexible because nothing goes according to plan. We understand this lesson quite well. Our brainstorming sessions from almost two years ago represent the beginning of our planning and we’ve spent about 18 months thinking, reviewing, testing, interviewing and testing again. We’re ready to see how this application works with our participants now, but it’s been a long road, and we’ve had to be flexible along the way.

Learn about iN Touch.
Read more posts from the iN Touch project team.