Wearables are popping up left and right. From bands, to watches, to shirts, earbuds and more. All of these devices have the opportunity to collect PHI and require HIPAA compliance. While many will choose to initially collect anonymous data that doesn't require HIPAA protection, the need to add true utility to the devices will likely push many of them down the road to compliance.
As an application developer for wearables it's important to consider whether the data you're collecting now will remain anonymous (such as a simple pedometer report) or if you're building something more ambitious that requires a larger set of personalized data that will be transmitted to HIPAA covered entities (PHI).
If it is the latter, you're likely better off building the software for the wearable in a HIPAA compliant environment to begin with, to protect against unforeseen use cases, unexpected PHI, etc.
Today's wearables are typically "always on" with data presentation layers that are outside of a protected lock screen or similarly private state. Therefore careful consideration needs to be taken related to how and when health data is presented on the device.
Much like the push notifications on mobile devices, andy alerts generated by your application should be anonymous in nature and devoid of any PHI.
Proactively pushing PHI as part of an alert opens up all sorts of privacy concerns. What happens if the device is on a desk at the office, for instance?
Similarly default displays should be carefully considered. A default display contain PHI is a big privacy issue. Even more mundane and typically anonymous data can be troublesome due to the fact that the device is on the person.
For example, heart rate isn't really an anonymous data point when it's being tracked in real time on the watch face of the person wearing it, now is it?
One of the most exciting aspects of wearables may be in patient health management and compliance (e.g. does the patient get their exercise in per the doctor's orders?) In order for these apps to be used efficiently in this use case they need to talk seamlessly with the applications and software being run by covered entities.
Covered entities and their business associates are required by law to be HIPAA compliant, so any application hoping to connect to one of these entities as part of patient care must be HIPAA compliant.
It is possible, based on the features and functionality that you include in your application or wearable device that it may actually be classified as a medical device. It’s important to look up FDA regulations and check whether your app will be considered to be a medical device or not.
If it does fall under those definitions it may require FDA approval which brings with it a whole host of further regulations.
Don’t launch your app until you’ve determined whether or not you are safely outside the FDA’s medical device classification.
Because most wearables lack a user interface to add or manage security features on the device in the event it is lost or stolen, it's important for wearable software developers to take the appropriate precautions to encrypt the data on the device as the default.
HIPAA requires that data recovery be possible in the event of a disaster or emergency. Therefore, depending on the device you are developing for, you may want to take advantage of proactive synching features instead of waiting for the user to synch the device themselves.
If the device enables background synching over bluetooth or while connected to the main device it's recommended that you take advantage of that opportunity to synch your user's data automatically.
Chapter 9: Mobile Applications | Chapter 11: Apple HealthKit and iOS 8