Part III: Follow Up to PHR Access Post and GTUG Campout "Breach"- Google Health, Ringful, and the Asthma Journal App Experience
|
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.
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 Judgment 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.
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.
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.
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 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!
|
