With 2,500 Miles Between Us: Learning a New Way to Work

­Sen Hirano, M.S., Ph.D. Student, Department of Informatics, University of California, Irvine

Sen Hirano has been on the Estrellita research team since the beginning of the project.  He spent the fall semester at the University of Toronto and is now back at UC, Irvine.

Not being in the same location as my team was certainly a new experience. While in Toronto, I expected to work on my own part of the Estrellita project with less of a focus on general project elements as I studied with a professor who specializes more in laboratory studies and building things.

Before I left, I tried to make sure that all features were finished so that I would not have to worry about that part of the study anymore. There was, however, one big issue. We had to migrate to a new server that was able to take more connections than the one we had been using. The server, out of some bad luck, did not fully arrive until after I left, leaving Karen Tang, who had not touched the server side yet, to set it all up. Except for the pain of installing all the security certificates we needed, and making them work correctly, the setup was relatively easy. Since I already did that for some other machines, I volunteered to finish that part. And because we were splitting the work, coordinating the use of the new machine was tricky. Like all virtual workstations, no one actually sits in front of it. In fact, like a normal server, it only has a power cord and an Ethernet cable plugged into it. So, as we took turns working on it, we tried to inform each other before our infrequent uses. Even so, my connection was interrupted once, so I just had Karen finish up for me (which, I am now realizing, is a great aspect of our team). After just a couple of days, the server setup was finished, and I was free to do my own work.

I didn’t hear too much from my team while I was away, so occasionally I would get nostalgic and do some routine testing to make sure things were performing well. Karen Tang did her best to filter and address the problems that arose, but ultimately there were things with which I was more familiar. In those instances, she would send me all the details she had gathered in her investigation of the problem and then we would have an instant message conversation about it and try to theorize what was wrong. At this point, I would often remember some relevant part of the code and spend just a few minutes fixing the problem. Then I would save the fix, sync the code, and have both of us test to make sure the fix worked. I occasionally had to proxy through her and have her ask questions or look into something else for me. Even though problems did come up, I’m really glad that none of them was a user interface problem, because those would have been much harder to explain or show long distance.

Learn more about the Estrellita (formerly FitBaby) project.
Read more posts from the Estrellita (formerly FitBaby) team.

In the Wake of Google Health

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

There is wide speculation regarding the reasons for Google Health’s recently reported “failure.” At Project HealthDesign, we’re excited about experiments that probe the potential of personal health applications (PHAs), but we also know some won’t last. Although Google Health was one that didn’t, their experiment still leaves us with many valuable lessons.

The industry-wide consensus seems to be that personal health records (PHRs) and PHAs can only grow as extensions of EHRs. Because it provided a place to store data that has yet to be reliably unlocked from proprietary systems like institutional EHRs, others have indicated that Google Health was in some ways before its time.

However, those remarks are only one part of a larger and more complicated picture. Beyond support for clinical health information, we know people also want support for personal health information like observations of daily living. These types of personal information have little representation within current EHRs. Thus, a central challenge will be to provide systems that can integrate both clinical and personal health information in meaningful ways. In the wake of Google Health, we can learn several lessons about how we might meet this challenge:

Must be social

Adam Bosworth, the original force behind Google Health, provided a very short answer as to why Google Health didn’t catch on with the general public. “It’s not social,” he says. I agree with him: Google failed to create a PHR experience that allows users to know they aren’t alone. Sharing raw health information isn’t enough. Technologies must also allow users to share experience and knowledge.

Unlike most Google products, Google Health didn’t allow users to leverage the prior experience of other users. Contrast this with PatientsLikeMe, which leverages user input to provide new insights into self-management and even potential scientific discoveries. To be fair, Google was working in a regulatory environment that made such sharing difficult. Thus, the challenge will be to develop methods that allow for voluntary sharing of personal health experiences and knowledge in ways that preserve privacy.

Must not add more work to busy lives

Google Health’s failure also suggests that PHR users are deterred by the burden of data entry. Their platform largely required manual data entry. Tech professionals who work with various types of data say that health care data is by far the most complex type of data. Although Google likes keep its products lean and its interfaces minimal, lots of calculation is typically done behind the scenes to leverage prior user input. Without similar ability to leverage the experience of prior users, Google Health’s minimal interface provided new users little direction and little motivation for making full use of the PHR.

Google Health has also been criticized for adapting—rather than adhering to—established standards, such as the CCR. Thus, future adoption of PHRs and PHAs might require some form of template system that allows health records to be set up and quickly populated through the use of interoperability standards. This is where the ability to learn from prior users’ experiences will be crucial.

Must provide a value proposition

A successful PHR platform must provide much more than a central repository for clinical and personal health information. It must also provide a means to easily work with that information to improve personal health and wellness (e.g., a personal health app store). Indeed, devices and apps that provide useful information in an unobtrusive way and integrate seamlessly have already shown some promise, even thriving in a marketplace where consumers have to pay for the service (e.g., Withings WiFi-enabled scale). PatientsLikeMe has had some success with this approach, focusing on smaller communities with unique and complex needs and building applications around them (starting with ALS and adding from there). We must find focused areas of need and create smaller PHAs that interface with data platforms like EHRs in order to add value. And these systems must align with recognized standards and allow users to maintain personal control.

What do people want when it comes to personal health management?

It’s likely that PHRs and PHAs that serve solely as stand-alone data repositories will never see wide consumer adoption rates. If personal health tools are to gain traction, they must leverage previous user input to benefit future users, automate and simplify management tasks (e.g., allow for automated data collection) and create value propositions by targeting demonstrated areas of high demand.

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.

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.

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?

Patient-Clinician Communication Barriers and Bridges

Karmin Enge, R.N., Project HealthDesign M.S.N. Student, University of Wisconsin-Madison 

Last semester, I worked alongside a pediatric nurse practitioner in a pediatric intensive care unit. My goal has been to understand the information needs of families whose children have been involved in traumatic events. One common way to assess information needs in these types of situations is through interviews with patient families.

I have found interviewing to be challenging because some families appear reticent to speak to me about their experiences and their information needs. The fact that I am a student may affect their willingness to speak openly. Also, families are not always eager to speak candidly about their experiences in the hospital while their loved ones are there because they believe what they say may affect the care their family member receives.

Because I used qualitative research interviewing techniques to enhance the interview process, I expected a better response than was ultimately obtained. I feel there may be a barrier between the family and those seeking to understand their needs. It is important to gain an understanding of the family’s needs in order to create a meaningful method to meet their needs. There may be various reasons for this barrier that we don’t understand—these would be worth exploring.

When soliciting observations of daily living (ODLs) from patients, it is imperative to get feedback from patients and families directly since an ODL reflects the perspective of the person who reports it. Further information is required in order to show how students and researchers can build relationships with patient families such that any information obtained is genuine, useful and comprehensive.

I recently read an article that talked about patients and families sharing health-related information on Facebook that they are not sharing directly with their physicians. We need to better understand why they are willing to share information on Facebook, but not with clinicians.

Is it possible to utilize technology and expand upon existing functionality to develop communication tools that bridge the communication gap between families and clinicians?

“Man is least himself when he talks in his own person,” said Oscar Wilde. “Give him a mask, and he will tell you the truth." Can technology serve as a “mask” for patients?

Project HealthDesign Submits Comments to ONC about Future PHR Technology, Privacy and Security

Libby Dowdall, Communications Coordinator, Project HealthDesign National Program Office

Following the Dec. 3 PHR Roundtable, hosted by the Office of the National Coordinator for Health Information Technology (ONC), Project HealthDesign submitted public comments regarding the future of personal health records (PHRs).

Project HealthDesign Director Patricia Flatley Brennan, R.N., Ph.D., commented on the inclusion of patient-generated observations of daily living (ODLs) in PHRs and highlighted the shift toward independent personal health applications (PHAs) that run on top of PHRs.

Walter Sujansky and Sam Faus of Sujansky & Associates, technical partners to the project, noted patients’ desire to assign to family, friends and clinicians customized levels of access to PHRs. They also provided information about the open-source Project HealthDesign Common Platform as evidence of this task’s feasibility.

Principal Investigators Anind Dey, Ph.D., Katherine Kim, M.P.H., M.B.A. and Gillian Hayes, Ph.D., commented on patient expectations in regard to PHR privacy, security, customization of access and ease of use.

Read Project HealthDesign comments.

Read other individuals’ and groups’ comments.

Watch videos of the ONC PHR Panel sessions (see Web Archive section).

 

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.

Android phones: Now that I have one, how do I develop programs?

By Jay Levinsohn, BreathEasy Technology Lead and Yuying Zhang, Lead Developer, RTI International.

Read all the BreathEasy blog posts.

The Android platform is a relatively new open source specification for mobile operating systems. The Android operating system software, hardware to run it and “apps” are all growing very rapidly. In fact, Android phones have taken over the number two position in SmartPhone sales, over taking the Apple iPhone. How does one develop for this platform and the moving target it presents?

There are a number of development paths that one can use to create programs or “apps” for Android based applications. Development is supported for Windows based PCs, Apple Macs and Linux-based machines (e.g. Ubuntu-based), and they have free software tools, so cost is not really a factor. The RTI developers on this project are experienced Windows and .Net developers, so the choice of the Windows platform was the logical and comfortable place for us to start.

Windows-based Development Options

In Windows there are a number of options, including Google’s visual App Inventor and the most often recommended and widely used Eclipse.

App Inventor is designed to allow rapid application development with minimal coding and provides a visual environment with drag and drop placement of controls on the screen. It looks very interesting, however it is still in Beta and not widely available so it was not a viable candidate.

Eclipse is a general Java development environment, which is a visual shell that ties together a number of developer tools. It also allows the addition of modules to support Android development. The components that are needed to start development in Eclipse are:

• Java SE Development Kit - JDK 6  
• Eclipse IDE for Java Developers       
• Android SDK
• Install the ADT Plug-in for Eclipse 

Early Findings on the Development Environment

As of this writing, the tools provided in Eclipse and the Android API seem to allow the development of complex programs. The API provides access to the hardware components of interest (GPS, camera, accelerometer, compass, power control), good support for a SQL file system (SQLite) that allows use of complex data base structures that can be shared among applications and support for web data transfers. There are also useful online samples, with source code that help with the learning curve for both systems.

Additionally, there is a very active and rapidly growing online community of developers, a good emulator (albeit somewhat hard to configure) that allows development without Android hardware and a bridge program (adb) to connect a real Android phone to a PC for file transfers, actually running UNIX commands on the Android and making screen shots or projecting Android images for training.  At first blush, there appears to be fewer screen controls that are typically used in Windows apps but those provided are adequate.

Overall the Eclipse development system is not as polished, not as visual, nor does it seem to be as strong as Visual Studio, but it certainly provides a good development base.