Drawing from within: Implantable devices yield new types of patient generated data [Video]

Project HealthDesign National Program Office

We are in the final six-month stretch of Project HealthDesign, and we’re trying to share some of our project’s most relevant and dynamic findings with respect to patient-generated data. We learned through our recent grantees’ research that familiar consumer electronic devices, like cell phones and tablets, can help patients capture observations of daily living and personal insights, and allow them to easily share these data with their clinicians. 

There’s another type of patient-generated data out there. We’ve learned from conversations with people whose health lives depend on implantable devices like cardiac defibrillators and insulin pumps, that data derived from these devices  provide important information not only about how the device is performing but also about the patient’s health state.  It is timely to figure out how to make data acquired through such implantable devices accessible and useful to patients as well as clinicians and researchers. 

In this video, Patricia Flatley Brennan offers some compelling thoughts about the need to imagine and harness this novel patient-device data to make sure it serves the ultimate health interest of patients.  Device makers and federal bodies who regulate these devices should pay particular attention. While watching this video, keep these questions in mind:  How can we ensure that patient-device data are 1) understandable to and accessible by both patients and clinicians; 2) completely secure from disruption and tampering, and 3) regulated carefully and fittingly? 

Project HealthDesign wants your input on this important matter. If you have thoughts, suggestions, ideas about all types of patient-generated data, post your comments below or send them to [email protected]

 

Developer Challenge Roundup

Libby Dowdall, Communications Coordinator, Project HealthDesign National Program Office

Gather a team of developers and innovators and plan to enter an upcoming developer challenge. The following developer challenges, organized by the Office of the National Coordinator for Health IT (ONC), provide several opportunities to engage in health-related topics that could help to improve health and health care.

ONC i2 Challenges

Health Innovations in Commuting Challenge

• The challenge: Create and submit a conceptual document that outlines ideas and models for improving the health of American commuters through better collection, exchange, and analysis of health data.
• Requirements and desired functionality: Challenge entrants will submit a conceptual document that outlines how health data may be appropriately collected from commuters in a safe and secure manner during the overall commute or during key milestones or events of the commute; how health data may be transmitted in a secure and standardized manner; how health data may be analyzed, either at an individual or population level.
• End of submission period: March 5
• Learn more or register for the challenge.

EHR Accessibility Module Challenge

• The challenge: Create and test a module or application that makes it easy for disabled users to access and interact with the health data stored in their EHRs.
• Requirements and desired functionality: The resulting app or module will enable individuals with disabilities to easily interact with their health data, link to relevant local or online communities or organizations, be able to download data from at least one EHR system, leverage and extend NwHIN standards and services including, but not limited to, transport (Direct, web services), content (Transitions of Care, CCD/CCR), and standardized vocabularies. The resulting module or app must also comply with web and other designated accessibility standards.
• End of submission period: July 23
• Learn more or register for the challenge.
  
  

ONC and Partnership for Patients Challenge

Discharge Follow-up Appointment Challenge

• The challenge: Develop a web-based tool that makes post-discharge follow-up appointment scheduling a more effective and shared process for care providers, patients and caregivers.
• Requirements and desired functionality: Develop the tool using user-centered design principles; incorporate messaging and EHR interface capabilities. Create a plan for how to scale and encourage adoption.
• End of submission period: April 30
• Learn more or register for the challenge.

Developer Challenge Roundup

Libby Dowdall, Communications Coordinator, Project HealthDesign National Program Office

From new PHR platforms to creative mobile health applications, the opportunities for improving health and health care seem to multiply daily. We hope to see more developers and designers become passionate innovators in the health and health care space. Participating in developer challenges such as these upcoming opportunities might help you catch the vision!

Robert Wood Johnson Foundation Challenge

Aligning Forces Challenge

• The challenge: Develop an application that builds on the publicly available Aligning Forces for Quality (AF4Q) health care quality measures and helps patients access better care.
• Requirements and desired functionality: The application should incorporate AF4Q health care quality measures, allow patients easy access to inpatient and outpatient health resources, and guide them through the decision-making process.
• End of submission period: December 31
• Learn more or register for the challenge.

ONC i2 Challenges

One in a Million Hearts Challenge

• The challenge: Develop an application that empowers individuals to improve their heart health.
• Requirements and desired functionality: The application should educate individuals about the Million Hearts initiative, allow individuals to input information about their current health state, use the health data they provide to generate targeted recommendations about how to improve their heart health, and be capable of transferring the individual’s information to an EHR using Direct specifications.
• End of submission period: December 31
• Learn more or register for the challenge.

popHealth Tool Development Challenge

• The challenge: Create an application that leverages the popHealth open source framework and provides greater insight into patient populations (e.g., help clinicians improve patient safety, help providers engage patients and families, etc.).
• End of submission period: January 20
• Learn more or register for the challenge.

Reporting Device Adverse Events Challenge

• The challenge: Develop an application that facilitates the reporting of adverse events related to patient use of medical devices in hospitals, clinics and home environments.
• Requirements and desired functionality: The application should allow patients to record adverse events easily, integrate with EHR and PHR platforms, capture patient demographic information, capture information about the medical device, be platform-agnostic, and employ NwHIN standards.
• End of submission period: February 3
• Learn more or register for the challenge.

popHealth Tool Development Challenge

• The challenge: Work with a public health expert to co-create an application makes it easy for users to use the Healthy People 2020 Leading Health Indicators (LHIs) in meaningful ways.
• End of submission period: March 9
• Learn more or register for the challenge.

dwellSense Visualizations

Anind Dey, Ph.D., dwellSense Principal Investigator, Carnegie Mellon University

During an earlier phase of our research, we identified the prospective information needs of our various stakeholders: elders, caregivers, occupational therapists and primary care physicians. In particular, our elders were quite interested in real-time or daily information about their performance of their everyday activities, but didn’t find a lot of value in long-term data or trends. They weren’t opposed to the long-term data, but they really wanted to have the daily information in order to see if they had taken their medication, and to see how well they were doing each day.

We designed the visualization below to run as an application on a Samsung Galaxy 10.1” tablet. The visualization has three horizontal panels, one for each of the ODLs that our sensing systems are tracking: medication taking, making phone calls and coffee-making. The large type size, the colors used and the simple design were purposefully chosen to make it easy for the elders to consume the information.

For medication tracking, we present information about morning and evening pills. In the visualization below, you can see that the subject took their morning medicine on time at 5:07 a.m., but had difficulty determining the right day of the week, having opened the Sunday and Monday doors before correctly opening the Tuesday door. The subject missed the evening pill completely. The two bar charts on the right indicate how timely the subject was in taking his or her medicine and how well the subject performed the task. Because the subject missed his or her evening medicine, the timeliness bar chart is red . The other chart is yellow to indicate his or her difficulty in selecting the correct pillbox door. These bar charts are intended to serve as quick additional abstractions to make it easy to consume the medicine-taking information.

For the phone calls, the visualization indicates the number of calls made and, of those, the number of times the user . The bar chart provides a summary of how well the user performed this task.

For coffee-making, the visualization indicates whether the subject made coffee correctly. In particular, it shows whether the subject performed each of four key coffee-making tasks correctly: getting water, adding the coffee, placing the carafe in the coffee maker and starting the machine. In this case, the subject performed all four tasks correctly, which is what the associated bar chart indicates.

 

We are still going to provide a long-term visualization to some of our subjects to see what value it can provide, despite their seeming lack of interest. This will be a more traditional line graph, with time on the horizontal axis, and the quality of the performance of the task on the vertical axis. Subjects will be able to click on any of the data points to receive the regular daily view for the chosen day. We expect that by providing both kinds of views, we can improve subjects’ awareness of their own performance, and that this will cause them to engage others in discussions (e.g., caregivers, occupational therapists, doctors) about their abilities, with the goal of improving their performance over time.

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

 

iN Touch Mobile Application Overview

Holly Logan, iN Touch Project Coordinator, San Francisco State University

We worked with TheCarrot.com team to customize a mobile application for iPod Touch and iPhone. Our participants have been using this personal health application to capture their observations of daily living (ODLs). Here is a sample walk-through of how a participant may interact with the app:

1. Participants in our study first sign in to the application on their iPod Touch devices.
   
   
   
   
2. After they sign in, they come to a homescreen that manages their trackers. Users could choose to manage a variety of trackers,  but for the iNTouch study, participants have been asked to keep track of four trackers: exercise, food, mood and socializing.
   
   
   
   
3. Let’s say this participant, Jim*, just got home for the day and wants to record his activities and observations. First he decides to record what he ate with his friends that day. To do this, he selects “Food” on the “My Trackers” page and comes to the screen below:
   
   
   
   By adding a food and then searching for it, Jim can easily record what he ate with his friends. Let’s say he wants to add strawberries. He can type the whole word or just part of the word into the search box below:
   
   
   
   Once he finds what he wants, he clicks the orange plus button to add the food to his folder. When he's done adding the foods he's eaten, he selects the green save button in the lower right-hand corner. When he hits the save button, he is sent back to the “My Trackers” page.
   
   
4. Jim may then decide he wants to record his mood for the day. When he selects “Mood” on the “My Trackers” page, Jim comes to this page:
   
   
   
   Let’s say Jim is stressed out and sad because he should have been doing his homework instead of hanging out with his friends, and now he has a lot to do and is running out of time. He is also feeling angry and unhappy about this situation. By touching the orange plus button next to each emotion, Jim adds these moods to his folder and comes to this screen:
   
   
   
   The green check next to each emotion means that Jim has added that emotion to his folder. The folder is located in the top left-hand corner, where it shows that he has added four emotions. Once Jim moves the sliding buttons to note how intensely he feels each emotion,  he can hit save in the lower right-hand corner, which takes him back to the main “My Trackers” screen.
   
5. Let’s say Jim also wants to track the amount he socialized that day. When he selects the socializing tracker, he comes to this screen:
   
   
   
   This screen operates much like the “Moods” screen. Jim  tracks how much he socialized, whether people influenced him negatively or positively and whether people supported him a lot or not much. Let’s say Jim decides he wants to add some personal details about his socializing experience, so he decides to write a note by clicking the “Notes” button on the lower part of the screen. He then comes to the “Notes” screen:
   
   
   
   On this screen, Jim can write a note about what he did with his friends; once he’s done, the green save button takes him back to to the “Socializing” screen:
   
   
   
   When he’s done entering his information, Jim can select the green save button to go back to the main “My Trackers” menu.
   
   
6. Finally, Jim remembers to  record his exercises from the night before in the “Exercise” tracker. When he selects “Exercise” on the main “My Trackers” menu, he comes to this screen:
   
   
   
   On this screen, Jim searches for his exercise and adds what he has done by hitting the orange plus button. When he adds running as an exercise entry, he comes to this screen:
   
   
   
   Because Jim is adding an exercise entry for the previous night, he needs to correct the date and time. When he selects the calendar image at the bottom of the screen above, he is taken to the screen below, where he can change the date and time before selecting the green save button (in the upper right-hand corner), which takes him back to the “Exercise” screen. 
   
   
   
   Once Jim saves his exercise entries and finishes recording his observations for the day, he can take a look at his progress by looking at his “Journal.” To get to the “Journal,” Jim clicks the notebook symbol at the bottom of the screen to review his “Journal,” which displays his progress.
   
   
   
   

Our participants seem to accept our app well, and they report that it is pretty easy to use and takes only a few minutes a day. We are doing exit interviews as participants complete our study, so we’ll be able to share more of their feedback in a future post.

*Jim is not a real participant in the iN Touch study.

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

Tweet

BreathEasy Android Application and Web Dashboard Design

Yuying Zhang, Lead Developer of BreathEasy Android Application and Brian Olive, Lead Developer of BreathEasy Web Dashboard, RTI International

The BreathEasy Android application is designed to be an easy-to-use tool that allows study participants to enter observations of daily living (ODLs) such as peak flow readings, asthma triggers, stress and activity levels, sleep patterns, symptoms and medication use. Data are collected through a few self-guided questions in a way that is similar to traditional survey data collection. With built-in data validation and smart logic design, most users will require fewer than five minutes each day to record their ODL entries. The main menu of the BreathEasy app offers three options: “enter daily data,” “enter rescue data” and “review partial data.” “Enter rescue data” allows participants to quickly enter rescue medication usage information for that day. Patients can review their partial ODL entries and make edits to them before the data are automatically sent to our RTI central server for analysis and storage.

In order to track our patients’ ODL reporting over a several-month period, a reminder system is a must. We developed a notification mechanism in the app that reminds the patient to enter their data at a predetermined time (set by each patient) every day. The app also automatically sends real time ODL data to the RTI central server. The monitoring system on the back-end server gathers all data and analyzes them. If a patient fails to enter her ODL data for more than 36 hours, then a text message, which reminds her to record her ODLs, is instantly sent to her phone. If the patient still doesn’t respond once the message is sent, a different set of text message reminders is then triggered.

Based on the results of our focus group study, we designed the web dashboard to give clinicians a quick overview of their patient’s status between office visits so that they can provide feedback to the patient if needed. The  web dashboard provides graphs of peak flow measures for each individual patient for a given time period; symptoms, activity levels, mood and anxiety levels as well as other ODLs are plotted on the same graph for a comprehensive view of the patient’s overall health status. Clinicians can select areas where they want to see more detailed information on the patient’s graphical display. The web dashboard allows easy navigation from one patient to the next. It is very secure and uses industry standard 256-bit encryption and user authentication.

The BreathEasy Android app is developed on an open source system called Open Data Kit (ODK), which is a native Android application targeted for Android OS 2.1 or higher. The BreathEasy website is an ASP.Net and SQL server-based application. These two very distinct systems communicate via standard http protocols over the Internet. We’re finishing up development in anticipation of laboratory-based user testing, which will begin soon.

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.

Online Communities as Sources for Quantifying Observations of Daily Living

Shadeequa “Dee” Miller, Project HealthDesign Ph.D. in Engineering Student, University of Wisconsin-Madison

Online communities are increasingly being used for health information purposes and social support — especially among adults who have been diagnosed with chronic diseases. In fact, online communities have been found to have a positive effect on participants’ well-being and health care behaviors (Nimrod, 2009). However, there is little research on the use of web-based communication technologies such as e-mails, mailing lists, news groups, forums/message boards, chat groups, interactive sites and blogs as sources of information for the development of tools to capture observations of daily living (ODL) data.

Last semester I observed discussion boards for several online communities that connect people who are living with different chronic diseases. I found discussions that covered all aspects of chronic diseases, from treatments and symptoms to basic health matters and interpersonal relationships. I paid particular attention to discussion boards that address adherence to medication or treatment regimens. As I reviewed the discussion boards, I tried to identify ODLs, keeping in mind that participants perceive online communities to be safe, informative, useful and fun places to meet other people with similar health circumstances, to share experiences and to find information that helps them manage and/or cope with a chronic disease. The ODLs I identified were more detailed than I had expected. The additional contextual information users provided helped me to identify communication patterns in the expression and prioritization of ODLs. This led me to question whether ODLs are the same in online settings as in offline settings. If they are not the same, then why and how are they different?

Also, can online communities serve as resources for quantifying ODLs by allowing researchers to convert qualitative, patient-reported ODLs into numeric/quantitative ODLs? I believe the answer to be yes. A content analysis of discussion board messages that address treatment regimen and adherence could be collected and analyzed to identify ODLs, which may be one way to quantify ODLs. Another useful technique that may be used is Latent Semantic Analysis (LSA), also known as Latent Semantic Indexing (LSI), which would allow researchers to analyze discussion boards  to find the underlying meaning or concepts — ODLs in this case — of the boards.

My observations lead me to believe that some ODLs are the same in both online and offline settings. People may, however, provide more contextual information online. This trend may be related to the fact that online communities are places where users value trust and compassion. Patients find comfort in sharing health-related information, as well as emotions, online with peers who may have had similar experiences. These online peers can often provide the understanding and practical advice that clinicians are not always able to offer.

As I examined the online communities, I found that the manner in which ODLs were described changed as the intended audience changed (e.g., whether the intended audience used an avatar/was a regular participant in the forum) and as the community changed (e.g., comments varied between informal and formal communities). These are aspects that should be taken into consideration if online communities are to become resource through which to examine ODLs.

Do you think online communities could help researchers to quantify qualitative ODL data? Would this information be useful to clinicians? Is the integrity of online data compromised? What characteristics of online communities must be taken into consideration before using the information? Could device designers use these types of online information to help develop tools that capture ODLs?

Oodles of ODLs

Katherine Kim, San Francisco State University, iN Touch Principal Investigator

In early October, I attended San Francisco’s Health Innovation Week (http://healthinnovationweek.com/) – an annual, week-long “immersion in the world of health and technology innovation” event that combines forums on HIPAA (privacy and security), regional extension centers/health information exchange, electronic health records, HealthCampSFBay and Health 2.0.

As I immersed myself in the HIPAA Forum, I considered how much we still needed to know about ODLs and how to handle them (these questions were keeping me up at night). I realized that we ask our iN Touch participants to record ODLs so that they are more mindful of their actions, able to analyze their decisions, and can improve the collaboration with their care team. Those same prompts would be helpful when it came to the questions swirling in my mind so I came up with these ODLs as I travelled through the sessions.

• Privacy ODLs: Podls (poodles) Oct 4, 2010, 1:30 pm

DHHS Office for Civil Rights is holding consumer “listening” sessions to hear their concerns about HIPAA privacy. I wonder how much concern consumers have about privacy of personal health records. Wish I could attend.

• Regulation ODLs: Rodls (Roodles) Oct 5, 2010, 6:45 am

FDA may regulate mobile devices and health decision making software as medical devices.  Will that include programs like iN Touch?

• Mobile ODLs: Modls (moodles) Oct 5, 2010, 11:00 am

DHHS Office of Minority Health says mobile applications are widely used (PDAs, text messaging) by minorities, an effective approach internationally.

Check out National Health IT (NHIT) Collaborative for the Underserved http://www.shireinc.org/nhit/

• Security ODLs: Scodls (pronounced scoodles) Oct 5, 2010, 2:15 pm

Security for social media for healthcare. Texting, email, social networking, health information exchange. Consumers are way ahead of the healthcare industry. We need to catch up and still be secure.

• Safety ODLs: Safodls (safeoodles) Oct 5, 2010, 7:39 pm

In the news - cell phones may cause brain damage? Good thing we are using iPod Touch, it’s not held near the head. Will patients or their parents/guardians be concerned about this for our project?

• To Do List ODLs: ToDodls (Todoodles)

Write a blog about the Project HealthDesign ODLs and ask “Track one of these ODLs for a few days and send me your findings.”

Maybe we should start using these terms more throughout our project because some of the names are sure catchy. Feel free to start using of these ODLs and send us your findings.

Action Research: A cyclical intensity for sustainable social change

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

Read all FitBaby blog posts.

“The best way to understand something is to try to change it.” – Kurt Lewin

My research projects tend to focus on the creation of local,
sustainable, social change.  To me, it is impossible to develop
feasible solutions to real problems without intense, and sometimes
very messy, engagement with the people and problems that lie at the
heart of these projects.  Action Research (AR) offers a systematic
collaborative approach to research that satisfies both the need for
scientific rigor and promotion of sustainable social change.

AR is explicitly democratic, collaborative, and interdisciplinary.
The focus when conducting AR is to create research efforts “with”
people experiencing real problems in their everyday lives not “for,”
“about,” or “focused on” them.  AR is cyclical in nature, with an
emphasis on problem formulation, design of an intervention, action,
observation of the effects of the action, reflection, and then
redefinition of the problem to start the cycle again. The goal is not
to arrive at the solution but to attempt to create a solution that is
in some way “better” than previous solutions and helps the actors to
learn through the action they take.

 The steps we take in my lab usually fit the model for AR:

(1)    Find a community partner. We always try to remember, we are
research facilitators and partners not observers outside the realities
of the situation.
(2)    Develop problem statements and research questions together with
community partners.
(3)    Design sociotechnical interventions with our community partners
not for them.
(4)    Evaluate our interventions while considering outcomes that are
important to community stakeholders and to our research team.
(5)    Write with our community partners…. Not just by adding their
names to our papers or getting casual feedback, but really writing
together.
(6)    Celebrate the things that have gone well regularly.
(7)    When we leave, make sure we created sustainable change, which
means they don’t need us anymore.
(8)    Act ethically, which for AR means ensuring community partners
have a lot of power as both participants in the research and
co-creators of the research design.