Health Apps on Phones?
Posted by Craig H on 8 February 2010
This post is about trustworthiness (security in a broad sense) and specifically about reliability.
I see increasingly frequent suggestions that people should use their phones to monitor their health. This is, on the face of it, attractive; being an insulin-dependent diabetic, I carry a blood glucose meter with me pretty much everywhere, and in line with the general trend of convergence (calculator, camera, music player, radio, etc.) wouldn’t it be great if that was built in to my phone?
Well yes, that would be very convenient, but I’m afraid I think it’s a fundamentally bad idea.
The great attraction of smartphones is due to them running general purpose operating systems, thus their functionality is “limited only by your own imagination” — provided you’re a competent programmer, and aren’t trying to defeat DRM, break subsidy lock or distribute self-propagating malware 🙂
Unfortunately this very openness to the unknown is not a good characteristic for a device that needs guaranteed reliability; coupled with a device that has limited resources (processing power and battery life) you are surely tempting fate.
We already face this issue in one way: mobile phones can be life-saving devices when used to make an emergency call, and phone manufacturers and network operators are required by law to make best efforts to connect any emergency call regardless of other concerns (whether the account is in credit, whether the phone has registered to roam on to that network, and whatever else the phone is doing). Obviously you can’t make a call if the battery has run out or there are no base stations in range, but also third-party software installed on the phone could potentially prevent a call going through (Symbian tries to stop that by requiring applications that use capabilities that could interfere with voice calls to go through Certified Signed testing, but sadly that’s not a guarantee).
At a recent Symbian Feature and Roadmap Council (FRC) meeting, the council members voted on their top six desired future focus areas. Number 3 was Monitoring & Sensors: “(especially around enabling healthcare and wellbeing use cases)”. That really rang alarm bells with me.
In the case of emergency calls, the risk of a failure is manageable: your call either goes through or it doesn’t, and if it doesn’t you shout for help and hope someone nearby has a working phone. In the case of health monitoring, however, failures could be much more insidious, either leading to misinformed decisions for medical intervention or, probably worse, a false sense of security if you think your observations are fine but actually they’re not.
This isn’t just a matter of conscience, either – I’m not just saying “don’t do this, someone might die,” I’m also saying “don’t do this, you could lose a lot of money!” Consider being required to do a full device recall because of a flaw in the UI – this is a clear possibility, looking at the long list of US medical device recalls here. You may think “oh, clearly a phone wouldn’t be classed as a medical device,” but it’s a very broad category; the list includes baby teething rings, heat pads, beds, a laboratory information system and, most to the point, several blood glucose meters. The meter recalls seem generally to be for cases when users have been confused by switching (possibly inadvertently) between US and European units for the display. My point is that it only takes a few cases of this kind of “user error” and the manufacturer is required to recall all the devices.
That said, obviously there is a spectrum of risk here; a biorhythm app is clearly harmless, a pacemaker control app is clearly dangerous, and of course what is being proposed will be somewhere in the middle. For me the dividing line is whether users are going to make any decisions for or against medical intervention as a result. Letting your phone be your doctor? No, really, please don’t do that.
There is a proper way of doing this, which is to have a separate highly reliable medical device that communicates with or via your phone, but I’m fairly sure that’s not what the FRC had in mind…