31.8.09

Part III

Taking off my Health 2.0 analyst and Contagion Health startup founder hats for a moment, my essential concerns are related to these 'normal user' issues, which I'll describe very generally here: 

1. It was challenging for me to connect the Axial appspot access back to Ringful and Asthma Journal. I can only imagine what would have happened if an 'average' PHR user tried to figure out what happened. I would like to see more user-friendly language telling me what company and individual is accessing my health data on Google Health, and for use with which specific app (and I want to be able to give permission for that app info ONLY, not broad access to my entire PHR). For example, I should be able to set my Google Health preferences to allow Asthma Journal (Axial app engine) access ONLY to the condition of relevance in my condition listing - Asthma - unless I choose otherwise. 

2. I couldn't find information about Axial and how it is connected to Ringful and Asthma Journal anywhere on Ringful's homepage. 

3. If it took this much time and effort for me to dig through this information and find out what was going on, the 'average' Middle 80 healthcare consumer doesn't have a snowball's chance in hell of getting this untangled before they call a reporter with news about a PHR breach (our sector's equivalent of Judgement Day). 


It is VITAL to the future health of the integrated PHR, EMR, and EHR ecosystem that application developers think VERY carefully about user-centric language and adopt easy to read opt-in permissions structures that make relationships between organizations and applications crystal clear. We're treading on quicksand here. 

So, I'm going to my Patient Advocate hat back on now.

I don't want to be associated with all talk and no action. 

Policy recommendations (and process criticisms) look great on paper, but if they're never integrated into current practice they're a spectacular waste of time and blog/tweetstream real estate. I don't want to preach about what to change from the pulpit and then not woman-up. 

Moving forward, here's what I plan to do about the issue (other than just blog and tweet), with corresponding timelines and requests for assistance - ie, how YOU can help: 

1. Work with Google, Microsoft, Ringful, and any individual/organization willing to participate to create a template recommended "MY HEALTH DATA - universal user friendly TOS (terms of service) for mHealth (iPhone, Android, Palm, etc.) applications accessing personal health records. Contagion Health apps, and any mobile health apps I participate in building, will adhere to this #myhealthdata TOS as a minimum baseline. 
TIMELINE: 2 months to release of #myhealthdata TOS for mobile health applications to wider health community. 
NEEDS: Help composing if you've got strong feelings on the matter, or a twinkle in your eye, or both. The community's feedback when a draft is ready. 

2. Designing future Contagion Health apps, I'd like to provide users with the option to grant expiring 'test' access of a specified time period to see if they like the app/find it useful, after which they essentially lock the app out of their record. I'd like to see this kind of opt-in protection become sector standard best practice. 
TIMELINE: Concurrent with rollout of apps in which I (and Contagion Health) are involved in bringing to fruition (winter 2009). 
NEEDS: Developer assistance to see if this is possible to add to mHealth data exchange workflows when accessing web-based PHR or other health data stored/accessed online. 

3. We need to find out if there is a way to delink app/PHR integration/link/content sharing *automatically* if a user uninstalls an app. This sounds like a great idea in theory but we're shooting way out from potential practice here. We'd need plenty of permission screens, especially since IF the mobile health app has real-time update functional integration to the PHR, any changes made by the app would be entered and stored in the PHR, even if you uninstall the app. This could be sort of like having your PHR essentially act as the backup server or hard drive for your mHealth app data. 
TIMELINE: Take a look at this issue through fall and winter.
NEEDS: Developer assistance to see if this is possible. 

CHALLENGES RELATED TO THESE GOALS: 

1. Can PHRs currently available on the market handle this amount of granular data flow/input from apps? 
2. Are PHR designed, and are their workflows organized, to take these inputs and return search results in n=1, consumer/patient-friendly ways? (I'd argue not currently - all PHR platforms in my estimation miss the mark with this, which is why our open-source work on Chief Medical Officer and the work Contagion is doing is so important). 
3. How would a user uninstall the app and reflect that uninstall/delink on the PHR interface? 
4. What language would you use to remind users that they are uninstalling a health app and some data may be lost? Tech-wise, how do you try to ensure this data is NOT lost, but rather stored on the PHR?
5. mHealth application building is still a very small, tight field, essentially still wet and squawking in the birth sac. Will these sorts of permissions and programming requirements scare potential developers away from an already difficult to enter field? 

As you can see, I'm doing a major brain dump here. If anyone wants to help sort out these issues, time, feedback, haranguing vigorously welcomed. 

I've learned an extremely valuable lesson here as both an interaction designer and a PHR user. This episode has changed the way I view PHR access and mobile health application integration, and instilled a commitment to KISS design and opt-in sharing.

This post, and my views on consumer-centric care, are not without significant personal and professional bias. I firmly believe that consumers should own health data as a personal asset, and control the sharing and dissemination of that data at will (if they so choose). 

This is my sector. I'm putting significant skin in the game. mHealth and eHealth is where I've chosen to create and cultivate a work/life. Improving consumer access to and control over health data sharing is the reason I started Contagion in the first place.  Contagion Health has a significant interest in designing and building user-friendly, safe mHealth applications, so this kind of episode couldn't have arrived at a better time if it was heaven-sent (and I'm not entirely sure it wasn't). 

Now, back to building.

To your health - 

Jen S. McCabe
@jensmccabe

CEO/Founder: aaaa

Posted via email from Jen's Posterous

No comments: