The healthcare application market is one of the most rapidly growing sectors, expected to be a $60 billion market by 2020. For developers in this surging healthcare application development space, HIPAA-compliant user management, including authentication and authorization, is mission critical.
The Health Insurance Portability and Accountability Act (HIPAA), set forth in 1996, was designed to allow the public to more easily change medical practitioners or insurance providers. Baked in with these portability structures was a set of privacy restrictions to protect that data in motion, in a limited fashion.
In 2013, the Final Omnibus Rule Update amended HIPAA, taking into account the digital revolution and bringing under its umbrella additional organizations beyond doctors, hospitals, and insurance companies.
Let’s tackle this one piece at a time. At its core, HIPAA is about protecting a patient’s PHI, or Personal Health Information. It doesn’t care about protecting all medical data (for example, the heart rate and pedometer numbers being tracked by your Apple Watch), just the stuff collected by or on behalf of your doctor or insurer and used in the course of treating you.
There are two types of organizations that need to be concerned with HIPAA: Covered Entities (CEs) and Business Associates (BAs). A covered entity is typically an actual healthcare provider or insurer, whereas a BA is a third party who has entered into a Business Associate Agreement with a CE to provide some type of service or support. Most application developers operate as business associates. (Pro tip: Stormpath has been audited for HIPAA compliance and can sign a BAA on behalf of any Enterprise Cloud or Private Deployment client.)
The need for HIPAA compliance is individual to every application and its use cases. Let’s look at three common application types in the market today and see how HIPAA comes into play:
Fitness and exercise tracking applications are one of the most popular types in the healthcare space. For this example, imagine you’re building a fitness application that pairs with a user’s smartwatch and tracks type of workout and calories burned. No PHI is being collected on behalf of a covered entity, and your application is not subject to HIPAA.
The pregnancy industry is growing rapidly into digital markets, and a number of applications have come out in recent years to log symptoms and milestones. Your application uploads input from a pregnant patient into a healthcare provider’s database. In this instance, an interoperability agreement is in place between your organization and the healthcare provider to facilitate the data transfer. This agreement, while not a BAA, might lead you to assume HIPAA is in play. In fact, even though PHI is being transmitted to a covered entity, it is still not being done on behalf of that CE, so your application is not subject to HIPAA.
For our third example, let’s get a little complicated.
Let’s say your organization is contracted to build a mobile Personal Health Record (PHR) application for a health insurance provider. You would be operating as a Business Associate and required to sign a BAA declaring compliance. You would be storing and transmitting PHI on behalf of the insurance provider and your application could be subject to HIPAA. Are you starting to notice the key element?
Now, still within our Type Three example, let’s say you clone the application you built under contract and release an insurance provider-agnostic, direct-to-user model. That application would store and transmit the same PHI, but because it’s operating independently, instead of on behalf of the insurance provider, it is not subject to HIPAA.
By now I hope we’ve made clear the key question you need to ask of your application: Is it (and by extension are you) acting on behalf of a covered entity? If not, HIPAA most likely will not apply to you.
As application developers and responsible stewards of users’ PHI, we believe it’s important to provide the best security possible even if HIPAA isn’t in play. In fact, any of the use cases that we describe above could easily outsource their identity management to Stormpath for security, simplicity, and scalability. But say you decide to build your own user management systems. What are the consequences of a breach in compliance if your application is subject to HIPAA?
Fines from the US Dept. of Health and Human Services start at $100 and go up to $50,000 per violation. Violations that demonstrate willful neglect can even lead to criminal charges and jail time.
Almost two-thirds of all HIPAA violations start with Business Associates. If a covered function has been delegated to you, you’ll be asked to sign a Business Associate Agreement and thus bear the consequences of a breach along with the Covered Entity you represent.
As recently as March 26, 2016, North Memorial Health Care of Minnesota paid a $1.5 million settlement in a case involving a BA of theirs who failed to adequately protect patient billing and operations information.
As an Identity API, Stormpath can sign a BAA for customers on our Enterprise Cloud environment or those on a Private Deployment. (In fact, we already have for a number of healthcare clients.) We have gone through a HIPAA audit and are HIPAA compliant on these environments.
There are two common ways healthcare applications rely on Stormpath:
- They use Stormpath to store only user credentials and basic account information, with patient records maintained outside of Stormpath
- They store both credentials and all healthcare records within Stormpath using customData
Moral of the story? Know the role HIPAA plays in your application, and take it seriously. And don’t forget, we’re developers, not lawyers. If you need to make a business decision around HIPAA we encourage you to use our expertise as a guide but to also consult your favorite paid legal expert. </mandatory-disclaimer>
Check out our Build Vs. Buy white paper for more information on deciding to integrate the Stormpath API into your application, or drop us a line at firstname.lastname@example.org to talk compliance directly with one of our architects. We have experience in healthcare technology and can share use cases from other HIPAA-compliant customers.