Explosive growth in digital health over the last few years means there are many developers and managers who haven’t worked under HIPAA before. This article is written for startups (and small businesses operating online) who could use some help with the basics of HIPAA compliance.
This post is lengthy, but if you read it all, by the end you will have a solid understanding of HIPAA, compliance with HIPAA requirements, and how all of this will affect your engineering organization.
One caveat: This post is for informational purposes only. Aptible is not a law firm, and this post is not legal advice. You should contact an attorney to obtain advice with respect to any particular issue or problem.
HIPAA is a federal law that protects the privacy and security of health data. It is enforced by the Office for Civil Rights (OCR) of the U.S. Department of Health and Human Services (HHS).
HIPAA was passed in 1996 and updated by a law called HITECH in 2009. In 2013, HHS published a large administrative "Omnibus" rule to implement HITECH. For our purposes, HIPAA, HITECH, and the Omnibus Rule all refer to the same concept: The HIPAA regulations.
The HIPAA regulatory rules are, in practice, the most important aspect of HIPAA because they define the obligations of regulated entities and penalties for non-compliance. When we talk about "HIPAA compliance," we are referring to compliance with the regulatory rules.
The HIPAA regulations apply to organizations, not products or features. A company can say it is “HIPAA compliant”, but it doesn't make sense to refer to a product that way.
If you are regulated, HIPAA requires that you ensure your organization:
That is a drastically simplified summary, of course. In practice, the requirements are more complicated. The pilot audit protocol U.S. Department of Health and Human Services (HHS) used for its first round of audits has several hundred "key activities," most of which contain several audit procedures. The most challenging part of a good HIPAA compliance program is being able to prove to an auditor or OCR enforcement agent that you did everything you were required to, and that you made reasonable decisions along the way.
HIPAA’s formal name is the Health Insurance Portability and Accountability Act of 1996. HIPAA has a special limit: it only regulates entities that handle data that has been (or will be) related to a health insurance transaction.
HIPAA divides regulated entities into two categories:
Covered Entities - Health insurers, self-insured employers, claims clearinghouses, and health care providers who engage in certain types of electronic insurance transactions. In practice, almost all providers that take insurance are regulated, even if only some of their patients use insurance.
Business Associates - There are several kinds of business associates. The most common type is an organization that handles PHI on behalf of a covered entity or another business associate. HIPAA requires that business associate relationships be formalized in a contract or agreement, commonly called a "Business Associate Agreement" or BAA.
Business associate relationships can form a chain, usually when multiple sub-vendors are needed to provide a service. This is very common in cloud-based SaaS.
An example may be helpful: Stitch is a team communication platform for healthcare professionals. Doctors and other providers can chat, send private messages, and share pictures, video, and files with each other. Stitch has a freemium model where larger customers pay for advanced features. Stitch runs on Aptible, which in turn runs on AWS.
In this example, Stitch's customers are usually covered entities. Stitch is their business associate, because Stitch handles PHI on their behalf. Stitch in turn has several business associates, including vendors like Aptible. For a typical Aptible customer, AWS is Aptible's business associate. Aptible customers don't need to execute a BAA with AWS unless they want to use a HIPAA-eligible AWS product on their own, such as S3.
To determine whether your specific organization is regulated, you should consult an attorney.
To be regulated, health data must be individually identifiable and contain health information. Together, this would be what HIPAA calls "protected health information" (PHI). General personally identifiable information (PII) alone is usually not enough, but this can be tricky: PHI is a very, very broad category.
As HHS says:
Protected health information is information, including demographic information, which relates to:
- the individual's past, present, or future physical or mental health or condition,
- or the provision of health care to the individual,
- or the past, present, or future payment for the provision of health care to the individual
- and that identifies the individual or for which there is a reasonable basis to believe can be used to identify the individual.
Protected health information includes many common identifiers (e.g., name, address, birth date, Social Security Number) when they can be associated with the health information listed above.
PHI is broader than just health insurance transaction data. HIPAA is like a springing trap - it hooks you, then expands to cover much more data than the hook.
Two special notes:
De-Identification: Aggregate or de-identified data is not considered PHI. HIPAA has specific rules for how to de-identify datasets.
Encryption: Encrypting PHI does not change its status as PHI. You and anyone who handles encrypted PHI for you must still comply with the HIPAA rules, including the requirement to have a BAA in place.
The Office for Civil Rights of the Department of Health and Human Services is conducting its first round of HIPAA business associate audits in 2016. The audits will be a mix of on-site audits and "desk" audits, where entities submit proof of compliance remotely. HHS publishes sample audit protocol that will likely resemble the protocol used for the upcoming audits.
Your Customers & Partners will want to see evidence of your security and compliance practices before they entrust you with sensitive data. Compared to the likelihood of an HHS audit, customer audits are almost guaranteed. Smaller entities may send you a short checklist or schedule a brief meeting to review your security posture.
Larger, more sophisticated customers and partners will run you through an extensive vendor security review process involving a combination of:
Third-Party Auditors you hire to assess your organization. HITRUST is commonly used, although many consulting firms will conduct HIPAA-specific assessments.
Yes, HHS can impose fines for violations of any provision of the HIPAA rules, not just ones that result in breaches.
Breaches are the only violations with reporting requirements, but HHS may investigate any complaint that a covered entity or business associate is not complying with the HIPAA regulations. That said, OCR usually reserves fines for cases where a breach occurs. HHS has the discretion to determine the amount of a penalty, up to certain limits, and must consider factors such as the nature and extent of the harm resulting from a violation. Breaches are more likely to cause serious harm, whereas other violations may be less harmful.
The dumb answer is just "follow the HIPAA rules." If you comply with the rules, then you are "HIPAA compliant." Duh.
There are several problems with the dumb answer:
Complexity - Again, look at a sample audit protocol. Even if you determine the applicable rules and satisfy them all at a single point in time, maintaining compliance over time is difficult and expensive, especially in terms of your team's time.
Ambiguity - In order to maintain HIPAA compliance, you are responsible for implementing what HIPAA calls "reasonable and appropriate safeguards" over PHI, but it's not always clear which rules apply to you, and how. For example, encryption in transit is an "addressable" implementation specification under the Security Rule. Is it reasonable and appropriate not to encrypt traffic between an app and a database inside a virtual private cloud? What if the database protocol doesn't support encryption? Should you use a different database? There is little official guidance for engineers and developers today, although HHS has announced plans to publish some in the future.
Uncertainty - There is no official certification for HIPAA. Ultimately only OCR can decide whether you have been compliant or not, following an investigation or enforcement action. Obviously you would like to avoid those. Hopefully the upcoming HITECH audit program results will clarify how HHS interprets some of its own rules.
A better answer to "How do we become HIPAA compliant?" might be:
Decide on a repeatable, scalable strategy for tracking compliance events. The low end might be a spreadsheet, the high end might be a GRC ("governance, risk management, and compliance") system. Examples of things you might want to track include:
You will probably want help with this at some point. You can hire in-house, hire a consultancy, buy a product/service (such as Aptible), or some combination of those.
HIPAA has three main “rules,” or sets of regulations, that specify how regulated organizations need to operate and handle PHI. HIPAA actually has more rules, but most of the time when we use the phrase “HIPAA compliance,” we are referring to these three.
The HIPAA Privacy Rule applies to PHI in all forms (oral, written, electronic, etc.), and covers issues such as:
The HIPAA Security Rule applies only to electronic PHI. It contains requirements for administrative, physical, and technical safeguards. It also requires published policies and procedures that document how you select and enforce those safeguards. You must retain documentation and evidence of your Security Rule compliance for six years.
For many engineering organizations, the Security Rule is the hardest, most burdensome part of HIPAA. It can also be confusing: The rule is divided into “standards,” which are required but often vague, and “implementation specifications,” which are either required or “addressable” and usually not much more specific than the standards. HHS is working on collecting questions from digital health developers, but firm guidance and best practices are still be hard to come by.
In order to help you understand how the Security Rule may apply to a cloud-based SaaS team, we've included the following questions and notes. You can read the text of the regulations to compare.
Management controls, encoded in policies and procedures, related to how you select and implement a security management program, including risk management.
Specific safeguards include:
Security Management Process:
Information Access Management:
Security Awareness And Training:
Controls to protect the physical facilities, computers, and devices that house PHI, such as data centers, offices, laptops, thumbdrives, workstations, etc. Most cloud-deployed SaaS companies try to limit their physical footprint, in terms of handling PHI. Specific scoping measures might include prohibiting your team from downloading or persisting PHI to laptops, phones, and portable media.
Specific safeguards include:
Facility Access Controls:
Device And Media Controls: Ideally you leave all PHI in your production cloud environment, and do not permit PHI to be stored on hardware or electronic media that you manage.
Controls implemented through engineering processes. The technical safeguards contain elements of privacy and security by design, and should be incorporated as early as possible into your technical design process.
Specific safeguards include:
The HIPAA Breach Notification Rule establishes:
Who you must notify in the event of a breach. Possible entities include:
In many cases, your BAA with a larger customer will be more stringent than what the Breach Notification Rule requires. For example, you might have to report breaches sooner than 60 days following your discovery of the breach.
The Breach Notification Rule also contains the rules under which unauthorized access to encrypted PHI can be excluded from being a reportable breach.
You now know just enough about HIPAA and how to become compliant to be dangerous. As you plan out your go-to market strategy, you'll be able to identify potential issues before they arise. If you'd like to chat about how to design and scale a HIPAA compliant engineering organization in the cloud, feel free to get in touch with us anytime.
Discuss this post on Hacker News.
Update - March 29, 2016: Added a table of contents and link to Hacker News discussion.
Update - October 29, 2016: Formatting edits.
Update - March 17, 2017: Editing for clarity.