Apple HealthKit Integration: Duke Leads the Way

Posted: April 6, 2016 to Blog.

Tags: Malware, HIPAA, Data Breach

Now that smart phones have become ubiquitous to our daily lives, making everything from banking to turning on the lights more convenient, it’s not surprising that the healthcare industry is trying to utilize this technology to provide better patient care by giving doctors information in real time. Unfortunately that convenience may come at the price of security. Along with Stanford, Duke University is one of two hospitals in the country trying an experimental program that allows patients to track and share health information with their physicians from their smartphone. The hope is that by doing so, doctors can diagnose and treat illness sooner. For example, a patient with heart disease can take and chart their blood pressure, then send it to their physician through their phone. Their doctor can then look at that information and see whether or not it’s running high or low and adjust the patient’s medication, all without them ever having to visit a doctor’s office. Duke’s program is one of the first to integrate Apple’s Healthkit software into their own Epic electronic medical record. If a patient opts into the program, their doctor enables HealthKit in the system. Patients have to consent to the Epic MyChart app sending health information to their heath care provider, but they can choose what type of health information to share. One of the major concerns about sharing this type of information is whether or not this information is sent securely and if patients’ privacy is protected. One of the reasons program developers chose Apple’s HealthKit as their platform to work with was that all the information it collects is stored on the user’s phone rather than in the cloud, meaning Apple doesn’t have access to it. While this does make it more secure in that regard, it by no means eliminates risk and patients are required to sign a form saying as much. Apple and Google have done what they can to mitigate the risk of malware being available through their respective app stores, but hackers are continually trying to find ways through those defenses. Even seemingly safe and approved programs can be used to steal user data. For example, thieves can create an app and submit it to the app store for review. It’s scanned, and if no security flags are raised, then it becomes publicly available for users to download. Over a period of time, this app that is totally clean can have updates then slowly begin to incorporate pieces of malicious code. Eventually, a harmless app can be turned into something malicious. When Apple was developing HealthKit, the Federal Trade Commission raised similar concerns about the privacy of user data, but were eventually swayed, deciding that Apple’s privacy agreement would prevent that data from being shared with third parties. Unfortunately, as more health tracker apps become integrated into our healthcare, this will become a greater concern. A recent study found that 26% of free apps did not have a privacy policy and 39% sent user data to a third party whose name was not disclosed in the privacy agreement. Some apps may encrypt data that is sent over the internet, but that information may then be stored by a third party. Sharing information may be revolutionary for patient care, but there are steps that will have to be taken to protect their information. While all the information patients provide to Duke is part of their medical record and therefore can’t be shared by the university, HealthKit is designed to help apps share information, raising the concern about data leakage due to hackers introducing malicious code through other apps. In order for users to better protect their privacy when using smartphones, users should consider doing things like only typing on encrypted keyboards and using two factor authentication. Here are some additional tips to consider:

• Do not cache health data locally in the App’s folder.
• Only read/write health data from/to the Health store.
• Avoid sending the user's health data to a server.
• Try to do most of the processing on the device.
• As a source App, consider checking if the device has a passcode set before recording sensitive health data.
• As a reader App, only request access to the types of data that are actually needed for the App’s functionality.