Health apps and HIPAA: APIs as tools for protecting health data

One of the most exciting things about mobile applications is the potential to leverage data from multiple sources--such as GPS, local device storage and the Internet--to produce up-to-date and context-aware information and communications at the touch of a finger. This is no less true when applied to the realm of health, where the ubiquity of smart devices—and the growing popularity of wearable devices such as those from Jawbone and Fitbit—holds the promise of providing a new layer of data and insights targeted directly at helping us to eat better, exercise more effectively and stay healthier.
 
But unlike many types of applications, those that deal with health may come into contact with data protected under the Health Insurance Portability and Accountability Act (HIPAA). The key for health app developers—as well as a potential stumbling block—is to determine if an app needs to be HIPAA-compliant, and, if so, to take the necessary steps for safety and security. Making this determination can be complicated, and, if a company is found to be non-compliant (when it should have been), the financial penalties can be significant.
 
Therefore, one option for developers to mitigate risk and ensure compliance is to use a third-party service to manage their health data in a HIPAA-compliant way, and APIs provide a powerful mechanism for data transfer and other functionality within this context. One company offering this type of service is TrueVault.

“The mission for TrueVault is to be the Fort Knox for data,” said Jason Wang, TrueVault’s founder and CEO. “Any data you store in TrueVault is HIPAA-compliant.”

TrueVault's services are accessible through a simple and easy-to-use API that provides a range of functionality, including the ability to store a JSON document, retrieve a JSON document and search. From the developer’s perspective, the API behaves much like any other document-based database, such as MongoDB, but under the hood it has a proprietary implementation. For instance, TrueVault uniquely encrypts every document sent to the system with its own encryption key and validation factors, and the data is distributed to multiple physical locations.

TrueVault also offers an SDK for iOS. Overall, TrueVault provides secure, off-premise data storage that goes above and beyond what is required by HIPAA.
 

Filling the HIPAA Gap

For developers who excel at creating innovative and useful apps but may not have the background to tackle the legal and regulatory complication associated with HIPAA, TrueVault helps to fill the gap.

“What TrueVault does really well is abstract the HIPAA compliance concerns [away] from the developers," according to Wang. "For a developer, here’s a RESTful API that developers know and are comfortable with—and they know that by storing data in TrueVault, they’re complying with HIPAA regulations. We are implementing all of the HIPAA best practices, so, as a developer, you can focus on the user experience of your app and let TrueVault handle the security and compliance aspects of your application.”
 

The Basics of HIPAA Compliance

For health data to be considered protected health information, or PHI, it needs to meet two criteria: It must be personally identifiable, and it must be created, used or disclosed in the process of health care, such as during diagnosis or treatment.

There are two kinds of entities that need to be compliant with the HIPAA rules and should therefore be aware of their exposure to PHI. The first are covered entities, which include healthcare providers (such as doctors and clinics), health plans (insurance companies and others) and healthcare clearinghouses. The second—as a result of an update to HIPAA in September 2013—are business associates: people or entities that perform certain functions or activities, such as claims processing or data analysis, to assist a covered entity in its operations. Application developers will typically fall under this second heading.
 
As an example, consider an app that helps a user to record his or her diet and exercise over a period of time. The user can personally leverage that information to track progress, take note of where improvement is needed, and so on. Even if the data can be linked to that particular person—and so would be considered personally identifiable information, or PII—it is not considered PHI unless it is used or disclosed to a covered entity in the process of healthcare.
 
The tricky part is that any app that handles PHI—even if it wasn’t designed for that purpose, or perhaps isn’t even health related—must still follow the HIPAA rules. Therefore, the crux of the matter is this: When PII is used in the course of medical service, whether in diagnosis or treatment, it becomes PHI, and any business associate that comes into contact with PHI needs to be HIPAA-compliant. The data might be stored locally or on a remote server, but regardless of how the information makes its way to a covered entity in the course of care, it becomes PHI. So, in the app example, if a user shares her diet information—collected by the app—with her physician, and then receives recommendations during her next appointment about what to eat, then that app has been exposed to PHI and must be HIPAA-compliant.
 
Finally, it should be noted that the HIPAA rules require physical, technical and administrative safeguards, and a company like TrueVault only takes care of the first two categories. When I asked Wang about administrative safeguards, he described them as very broad; overall, they include responsibilities such as the appointment of a privacy or compliance officer, semi-annual HIPAA training for employees, and implementation of up-to-date policies and procedures, among other things. Wang explained: “It’s very much the human and policies and procedures side of HIPAA compliance. So it doesn’t dictate what your policies and procedures need to be, because every business is different, but it does dictate that you have to review them, renew them and make sure that they are appropriate for your business. Obviously, what’s appropriate for a hospital and what’s appropriate for a software developer or a paper shredding company [may be different].”

Companies such as Accountable, Compliance Helper and Compliancy Group can help businesses with fulfilling the administrative elements of HIPAA compliance.
 
Wang emphasized that one of the key considerations for developers in this space—as compared to those in, say, gaming—is customer expectations: “In health care, your customers are concerned about data security, personal privacy and, of course, compliance. … What you need to provide is very different,” he said.
 

Potential Challenges for Health App Developers

It’s clear that HIPAA is complicated, and in talking with Wang about health app development, he noted the difficulties in understanding the HIPAA requirements.
 
As a contrast to HIPAA, he pointed to the Payment Card Industry (PCI) Data Security Standards: “PCI governs credit card numbers and is extremely explicit,” he explained. If you take the right steps, then you’re PCI-compliant. “But with HIPAA, the language says, ‘Where reasonable and appropriate, do this.’ Well, [a developer might ask], ‘What does it mean where reasonable and appropriate? If I don’t do this right, then I get fined.’ It’s incredibly hard for start-ups, enterprises.”
 
According to Wang, it's for this reason that many companies are being cautious when they store PII, and don’t know how it’s being used downstream. For these companies, if data seems even close to being PHI, they just treat it as such.

It’s also a matter of customer trust, said Wang: “If you have a product related to healthcare, consumers are trained to ask, ‘Is this HIPAA-compliant?’ So for a lot of our customers, it’s easier to become HIPAA-compliant than to say, ‘No, we don’t have to be HIPAA-compliant, and let me tell you why.’”
 
On the other hand, some companies do not take the necessary safeguards and treat PHI as if it were PII only. That’s when breaches can happen, records can be lost, and trust in these applications can be severely undermined. There can also be hefty fines, ranging from $100 to $50,000 per violation (or per record), depending on a number of factors, including intent and knowledge of the violation.

“So if you’re a hospital and you have 200,000 patient records, and they find gross negligence in your actions, then [the fine could be] $50,000 times 200,000,” Wang said.

But even a lesser fine could amount to a substantial total penalty.
 
Complicating matters is the fact that while there is no safe harbor with regard to HIPAA, there is also no official certification for HIPAA compliance. So, even for developers looking to do the right thing, no third party can provide a stamp of approval. Only the U.S. Department of Health and Human Services (through the Office of Civil Rights) can perform audits, and if the office disagrees with the organization’s self-assessment of compliance, that’s when fines can be imposed.
 
To make things concrete, Wang pointed to two final examples: Evernote and FitBit. Similar to the illustration above regarding the theoretical diet and exercise app, Wang warned of the sometimes-blurry boundary between PII and PHI: “While, technically speaking, [these apps] don’t need to be HIPAA-compliant, they come dangerously close to having to become HIPAA-compliant.”

For instance, Wang said, doctors sometimes use Evernote to take notes on patient conditions, even though that is not the application's intended use. But in this type of medical setting, it may be pulled under HIPAA. He illustrated a similar scenario with regards to FitBit: “Doctors are now telling patients to get a FitBit so that data can be collected between visits. Then, when a patient goes in for an annual blood test, the doctor can say, ‘Let’s pull up your FitBit dashboard, and I can give you dietary advice.’ FitBit is now being used as a medical device and is being pulled to the other side of HIPAA.”
 

Health Platforms

On top of these considerations, healthcare software development platforms from Apple, Google, Microsoft and Samsung provide both an exciting opportunity and another potential layer of complication for developers. Each of these platforms exposes a set of APIs that allows health data to be stored to and retrieved from a central repository, while also providing apps and dashboards that allow users to gain insights from their data and set their security preferences. At the same time, each of these platforms has its own usage terms, protocols and other policies designed to protect users’ data, and this impacts developers.
 
For instance, the Apple website states: “HealthKit data is not saved to iCloud or synced across multiple devices. The data is only kept locally on the user’s device. For security, the HealthKit store is encrypted when the device is not unlocked.” In fact, the App Store Review Guidelines explicitly say that apps using HealthKit will be rejected if they store users’ health information in iCloud. In addition, any app that uses the HealthKit framework must provide a privacy policy, and apps may not use data gathered from the HealthKit API for advertising or other data-mining purposes unrelated to health improvement. Apple’s website also includes two links to guidance on creating privacy policies--one for non-HIPAA apps and one for those covered by HIPAA. (For both, the site also explicitly states that this guidance is for reference only and Apple assumes no liability.)
 
Google Fit comes with its own set of terms and conditions, including prohibiting the use of health content—unless permitted by the content owner and by law—“in connection with any advertising, sponsorships, or promotions or [to] share or sell that content to any data broker or information reseller.”  Moreover, Google’s website states that the company does not “intend uses of Google Fit to create obligations under [HIPAA].” It goes on to say that Google is not claiming Fit satisfies HIPAA requirements, and, in fact, requires that developers not handle PHI if they are (or become) a covered entity or business associate, unless they receive prior consent from Google. Part of the reason for this additional precaution may be that the central repository in Google Fit resides in the cloud rather than on the local device.
 
In all cases, the dynamics between health platforms and health apps will play out over time. From Wang’s perspective, one big question is how compliance responsibility will be shared among entities and how consumers will be protected, especially as health-related apps continue to proliferate. “Who is actually watching these independent developers?” he asked.

In many cases, consumers may pay a few dollars to purchase and download an app, but they may not know if the developer is concerned with the privacy and security of their health data. In the worst-case scenario for consumers, the non-compliance risk may be tolerable enough for some developers to ignore, especially if they believe they can move on to another project after a potential incident occurs.
 
Wang shared with me that he believes compliance is ultimately the responsibility of developers, because they’re the ones who are taking ownership of the data. And from the perspective of Apple, Google and other platform creators, it likely doesn’t make sense to endorse any kind of compliance because of the potential liability they would incur—and because it’s unclear what happens if the government disagrees. For Wang, the focus should be on the developers, and consumers should ask developers what steps they’re taking to be HIPAA-compliant and how their information is being safeguarded.
 

APIs and TrueVault as tools for HIPAA compliance

APIs present an interesting mechanism by which health app creators can achieve HIPAA compliance, and, in fact, it’s a role very similar to that of Stripe and its API in credit card transactions and PCI compliance. Similarly, in the health context, an API not only provides a consistent and well-structured way to store and retrieve health data, but also the encryption, security and other protocols required by the rules.
 
“We feel that [APIs] are the future of the world--that’s how systems should talk to one another,” Wang said. “Why come up with a proprietary way of storing health data? It should be as simple as storing credit card numbers today.”

But from Wang’s perspective, developers are still worrying about HIPAA compliance, and that’s where TrueVault can fill an important niche.
 
Over the longer term, and as wearable devices begin to penetrate the market in even greater numbers, it’s clear that issues surrounding health data, apps and compliance will continue to be a relevant consideration for developers. But despite the potential pitfalls, these changes also present significant opportunities for innovators in this space, and Wang was bullish about that.

“There’s so much you can do in healthcare. It’s one of the areas that’s least utilized,” he said. “Before, people couldn’t innovate in healthcare because they were held back by regulation, but, now, everything is coming together. You have the necessary devices, the ubiquitous aspect of our mobile phones, and the fact that Apple and Google are behind this. Now, developers can actually have a platform to build on and innovate, and we feel this is a great opportunity for TrueVault to help developers out.”

Stuart Iler Stuart Iler has broad educational and professional experience across a number of disciplines, including information technology, environment, energy, and economics. Follow me on Google+

Comments