What you need know about HIPAA compliance and your mobile app
HIPAA stands for Health Insurance Portability and Accountability Act. In 1996, Congress enacted a law to protect and keep private medical records and personal health information of individuals. The law protects all “individually identifiable health information” or PHI (protected health information). This law ultimately affects the way information is stored and shared over technology, including mobile apps. Therefore, before embarking on a mobile app project that involves storing or sharing health information, you must understand how what HIPAA compliance is and how it relates to your mobile app.
When it comes to understanding HIPAA compliance and your mobile app, there are a lot of complexities, mostly due to the ambiguity around what exactly is considered PHI (protected health information). It’s also not so cut and dry in terms of what apps need to be compliant or not. As a general rule, it really falls down to what information is being collected. Consumer apps that are collecting information, such as calorie count and weight loss information, typically don’t need to be compliant. For example, the Google Fit and Apple Health apps are not collecting any PHI, so HIPAA compliance is not necessary in these cases. On the other hand, medical apps are usually up for deeper scrutiny. If an app will be used by medical personnel, then there’s a good chance that the app will fall into the category of needing to be compliant.
Prior to developing a mobile app or any other service which interacts, either directly or indirectly, with sensitive patient health information you should consult with your legal counsel and reach out to an experienced HIPAA mobile app developer to understand what the potential ramifications are to your project.
There are a few questions that often come up when thinking about building a mobile app that will be collecting and storing health information:
What exactly is HIPAA?
Does my app need to follow HIPAA compliance?
Should I avoid collecting of PHI altogether?
What are the penalties if my app does not fall within HIPAA compliance?
The experts weigh in…
We asked a few experts for their input in the area of security, privacy and HIPAA. We spoke to experts about the areas of specific classifications and grey areas when it comes to HIPAA, as well as legal ramifications and secure technology options to think about when building out an app.
Kate Borten, is a former CISO and, since 1999, President of The Marblehead Group, a healthcare privacy and security consultancy dedicated to compliance audits, risk assessments, and remediation guidance to the full scope of the healthcare industry. She is a frequent speaker and author of several books on HIPAA.
JoAnna Nicholson is an attorney at Nixon Peabody’s Health Care practice group. Her practice centers on corporate, transactional and regulatory counsel within the health care industry with a focus on state and federal privacy issues, including HIPAA and HITECH Act compliance.
Andrew Mitchell is VP of Engineering at TrueVault. TrueVault is a HIPAA compliant data store that offers healthcare applications a secure API to store protected health information (PHI).
Bobby Gill is CEO at Blue Label Labs. Blue Label Labs is a mobile app development agency that work works with a number of healthcare clients building out their mobile app solutions.
First, the terms…
When it comes to HIPAA, first and foremost, you need to make sure you understand a few of the terms that are frequently used throughout the act. Terms that you will hear and see most often include:
“Covered Entities” or (CEs)
“Business Associates” or (BAs)
“Business Associate Agreement” or (BAA)
“Protected Health Information” or (PHI)
Knowing the specific terms and definitions will be important in understanding the role that you play and the actions that you need to take so always be sure to refer to your counsel for clarification, full terminology, and complete understanding of the Act.
Privacy and Security
“…knowing whether you are a BA and whether the data is PHI is not always black and white.”
We asked Kate Borten a few questions about HIPAA and the complexities around security and privacy with mobile apps that collect personal data…
What exactly is HIPAA and does my mobile or watch app need to be compliant?
HIPAA includes regulations describing security and privacy requirements for “Covered Entities” (CEs) and their “Business Associates” (BAs) who have access to or handle Protected Health Information (PHI) on behalf of one or more CEs or other BAs. If you fit the definition of a CE or BA, and your mobile app includes or accesses PHI, most likely your organization and your app need to comply.
However, knowing whether you are a BA and whether the data is PHI is not always black and white. For example, a developer of personal health records (PHRs) is a BA when the company provides a PHR system to a hospital; further, the data in the PHR is PHI. But if the developer provides the same app or system directly to the general public, it is outside the scope of HIPAA; it is not a BA, nor is the data PHI although it may be identical to the data in the hospital-branded system.
Within health apps, what counts as PHI and what doesn’t count as PHI?
Be very careful about identifying what is and what isn’t PHI. This too is tricky, and there are some misconceptions! Here is a very general, unofficial, definition of PHI: PHI is any information about a patient’s health, past, present, or future, in any form, that can identify the patient, and is created or obtained by (or on behalf of) a CE. Even information that may not seem to identify a patient, such as date of birth with zip code, can readily be used for identification when matched with public census data. PHI also includes genetic information about a family. But this wide scope of PHI only applies when the data is in the context of a CE (or a BA performing work on behalf of a CE). For example, the same data solicited from the public for a research study may not be PHI.
What kind of challenges will I face if my health app is not compliant when it should be?
There are stringent civil and criminal penalties that can be imposed by the US Dept. of Health and Human Services, as mandated by Congress. In addition, state attorney generals are authorized to enforce HIPAA.
If medical personnel will be using my health app, does that automatically mean it needs to be compliant?
Not necessarily. If the app does not include or give access to individually identifiable data defined as PHI, it is likely to be out of scope. For example, the app may provide aggregate data or comparison statistics.
“Once you have a solid foundation, you have a long list of rules to meet; it’s a lot more work than building a simple Rails app on Heroku.”
Andrew Mitchell gives us a bit more insight on file storage when it comes to HIPAA compliance and talks to us more about data de-identification…
What should anyone creating a mobile app consider when thinking about file storage?
When you’re building a mobile app, it’s important to think about the various states your data will experience:
In use, on the device: when your data is stored in memory on the device and is being entered/reviewed by your user. This data is generally not encrypted until it is persisted.
At rest, on the device: if you save any records to disk on the device, it is absolutely critical that you encrypt them. On iOS, you should definitely use the secure enclave to store your encryption keys. A common shortcoming is using a library that silently stores data on disk when the network is unavailable. If you do this without encrypting, you’ve just breached security and may find yourself out of compliance.
In transit, from device to server: You should always use TLS, and insist on modern cipher suites. Certificate pinning is crucial if the devices will be used on untrusted networks, and is generally a good practice even if this is not the case. Despite what countless irresponsible Stack Overflow answers suggest, you must do hostname validation on your cert. Otherwise, you are an easy target for man-in-the-middle attacks. Grade your server’s TLS settings with https://www.ssllabs.com/.
Server side: Once your data has made it safely to the server, there are a whole host of concerns around encryption, key management, key rotation, encrypted backup, audit logging, etc. These are all solvable problems, but easy to get wrong if you’re not an expert.
Are there ways to create an app that collects PHI but where I don’t have to go through an overwhelming process of making sure I’m compliant?
Yes. Data de-identification is a great way to achieve compliance without overhauling your entire application. [Read more about data de-identification on truevault.com]
How is storage in the cloud HIPAA compliant?
HIPAA compliance is multifaceted. When you’re thinking about cloud storage, your first concern should be the Physical Safeguards required by HIPAA. If your hosting provider isn’t able to meet these requirements (and sign a BAA attesting as much), you need to find a new hosting provider. Once you have a solid foundation, you have a long list of rules to meet; it’s a lot more work than building a simple Rails app on Heroku.
“Medical app developers must be mindful that they use and safeguard protected health information in accordance with HIPAA, and also ensure that their consumer-facing privacy policies are not deceptive.”
JoAnna Nicholson helps us to understand the legal ramifications of having an app that falls out of compliance…
When it comes to legal ramifications with HIPAA, what could happen if my app is in violation?
App developers that handle protected health information on behalf of health care providers covered by HIPAA are considered “business associates” and are now directly subject to the HIPAA regulations. The ramifications for HIPAA violations for “business associates” can include penalties and required corrective action. Civil penalties range from $100 to $50,000 per violation depending on the intent (negligence vs. willfulness), with an annual maximum of $1.5 million per type of violation. However, the true financial exposure for business associates depends on what the regulators find in terms of violations, the intent behind those violations and how the regulators decide to count the violations. For example, in a breach scenario, if the regulators find that there were HIPAA violations on the part of the regulated entity, the violations could be counted per individual whose information was breached (ex. 100 affected individuals could result in a fine of up to $500,000 if the regulators determine that the security violations were willful). On the other hand, if the regulators conduct an audit and find deficiencies in the company’s policies and procedures, they may just enter into a corrective action plan and not impose penalties at all.
Are there any recent cases or settlements worth noting?
The most recent settlement entered into by the government with a HIPAA business associate (i.e., a vendor handling patient information on behalf of a HIPAA-regulated health care provider) involved a breach scenario where the business associate’s mobile device was stolen and 412 individuals’ information was compromised. The government found that at the time of the incident, the business associate lacked required policies on mobile device usage and that the business associate had no risk analysis or risk management plan. In that case, the government issued a fine of $650,000, but it could have been more, as the government took into account the fact that the business associate was servicing an at-risk population in need of its services.
As of 2017, are there any new laws or compliance issues as it relates to HIPAA that we should know about?
There have not been any substantial new laws or regulations pertaining to HIPAA since the modifications under the 2013 Omnibus Rule. However, 2016 saw heightened scrutiny by the Department of Health and Human Services (HHS) on business associate relationships between HIPAA covered entities and their business associate vendors. There were a number of penalties imposed on providers for not having required business associate agreements in place with their vendors, and, as I discussed above, there have been fines levied directly on business associates themselves. Further, there has been substantial guidance issued by HHS and other agencies in 2016 regarding HIPAA compliance. Of particular interest to app developers who use protected health information is the October 21, 2016 joint guidance from HHS and the FTC reminding both HIPAA covered entities and their business associates that not only must they comply with HIPAA in using and disclosing consumers’ health information, they must also ensure that their statements about and practices relating to consumer privacy do not violate the Federal Trade Commission Act (the FTC Act). In other words, medical app developers must be mindful that they use and safeguard protected health information in accordance with HIPAA, and also ensure that their consumer-facing privacy policies are not deceptive.
HIPAA compliance and your mobile app
“… the key thing to know is that any mobile app using personal data should always be designed with security and privacy in mind.”
Bobby Gill gives us a deeper insight into what you should think about before coming to a mobile app development team…
What should anyone looking to create an app that collects personal data think about before beginning work with a mobile app developer?
There are complexities when it comes to HIPAA and mobile app development, but it’s all about making sure it’s done in the right way. HIPAA is a very specific law that affects anyone dealing with users’ personal health information. We, as mobile app developers, are just as liable as the Covered Entity or (CE), so it’s crucial for us to understand what’s the purpose of the app, who will be using it, and what information will be stored, collected and shared. It can get especially complicated when you factor in authorization and who is entering the personal health information. We will want to know who is entering the data. Will it be entered by the user? Or will doctors and medical personnel be entering the information? We will also ask questions such as where will connections be established? In office or at-home? For example, will a user first register and login in front of a medical administrator or at home? This can be tricky because if done at home, how can you verify that person’s actual identity? There are a number of nuances when it comes to HIPAA, the key thing to know is that any mobile app using personal data should always be designed with security and privacy in mind.
Learn more about HIPAA
For additional references on HIPAA compliant apps, there are a number of sources available that you can refer to across the web. We’ve compiled a list of a few helpful resources below:
Health & Information Privacy on HHS.org
Your Mobile Device and Health Information Privacy on healthit.gov
Mobile Data Security and HIPAA Compliance on hipaajournal.com
Security and DevOps tools for engineers on aptible.com
HIPAA Compliance Checklist on truevault.com
Electronic Code of Federal Regulations on ecfr.gov
Cover Photo by rawpixel on Unsplash
Blue Label Labs is an award-winning product strategy, design and development agency based in NYC. To learn more about our work, contact us. This blog should not be used as counsel or in any legal capacity whatsoever. No guarantee is given regarding the accuracy of any statements or opinions made on the blog by Blue Label Labs or any of it’s contributors. This blog post is for information purposes only and shouldn’t be seen as privacy and security, or legal advice in anyway. As always, everyone’s app is unique, it’s best to reach out to us directly for any specific inquiries regarding your app.
Get the latest from the Blue Label Labs' blog in your inbox.
More in Development
My Picks for the Best Driving Enthusiast Apps
During the day, I’m the COO of Blue Label Labs, so I…
10 Top Rated Mobile App Mockup Tools
Functionality and aesthetics now cross realms more than ever. This is precisely…
How Much Does It Cost to Maintain an App?
Software is just anything you can possibly own – there is a…