Building a HIPAA-compliant rules engine for text-based service company
evrone.com
evrone.com
(And yes, there's more to HIPAA than the security rule - but not everything in the regulations applies to every covered entity, and the combined regulation document you need to read to get started is a total of 115 pages you can read in a day or two).
https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/ad...
Part 164 subsection C covers the entirety of the security rule, and is less than 10 pages.
Ultimately, these are the fundamental ones that you need to pay attention to when developing or deploying software that deal with ePHI:
Keep anything that stores (e)PHI physically (and electronically) secure
Limit access to (e)PHI to only those who need it
Keep records of access to (e)PHI by users (no shared accounts, each individual must be uniquely identifiable)
Encrypt (e)PHI _where possible_; this is an addressable requirement which means it is not mandatory, but should be followed where technically and administratively feasible
All of this is literally common sense to most developers when dealing with PHI. There are more obnoxious security frameworks some healthcare companies opt to follow like Hitrust (the personal hell I live in), but it's not like CMS or any other government agency mandates anything beyond the HIPAA regulations.
There's actually, I think, more than most people think, its just as lot less in the way of unambiguous, blanket, technical requirements that a product can check off. (Which means that saying that a technical component in isolation is "HIPAA Compliant" means almost nothing, and particularly does not mean that it is practically usable by any particular HIPAA covered entity while maintaining their compliance with HIPAA.)
"We put the backing data in a 'HIPAA Compliant database'," is not surprising as all they say about HIPAA compliance, but it does make the use of "HIPAA-compliant" in the title seem like empty clickbait.
> The HIPAA security rule defines a set of administrative, physical and technical safeguards that must be met - how you accomplish those is up to you.
Complying with the HIPAA Security Rule is insufficient for HIPAA compliance, however, especially when building a system that you want a HIPAA covered entity to use while maintaining their compliance.
Particularly, in addition to the security rule itself, one needs to also considered the Breach Notification Rule (45 CFR Part 164 Subpart D) and the related guidance on encryption methods [0]. Also, to the extent you are building something which generates or processes electronic transactions used in health care (or works with components of electronic transactions) for which standards exists, the Transactions and Code Sets rule (45 CFR Part 162 Subpart I & J) and the associated rules for specific identifiers and transactions (so, potentially, all of 45 CFR Part 162) become relevant, including all the separately published standards incorporated by reference, and all the additional standards incorporated by reference in those standards.
[0] While you might think this is not important to people developing IT systems since on the surface it seems like it is about processes when a breach occurs, because it defines (even going so far as to identify technical standards for encryption) when PHI is considered "unsecured" such that breach notification is required, it has substantial relevance to the design of systems that will be used in a HIPAA compliant enterprise.
More often than not I see people think the HIPAA regulations are in fact some gargantuan list of checkboxes and red tape like PCI. So, no, I think generally speaking following HIPAA regulations is far easier than most think.
> Complying with the HIPAA Security Rule is insufficient for HIPAA compliance, however, especially when building a system that you want a HIPAA covered entity to use while maintaining their compliance.
No, but when it comes to developing software in a covered entity or business associate it's the one people make such a big deal out of and I see the most misinformation on.
> Particularly, in addition to the security rule itself, one needs to also considered the Breach Notification Rule (45 CFR Part 164 Subpart D) and the related guidance on encryption methods [0].
Absolutely. But while this in particular ties into the security rule due to the definition of "Unsecured personal health information", it's hardly difficult or shocking.
> Also, to the extent you are building something which generates or processes electronic transactions used in health care (or works with components of electronic transactions) for which standards exists, the Transactions and Code Sets rule (45 CFR Part 162 Subpart I & J) and the associated rules for specific identifiers and transactions (so, potentially, all of 45 CFR Part 162) become relevant, including all the separately published standards incorporated by reference, and all the additional standards incorporated by reference in those standards.
Maybe it's just because I've worked in healthcare for nearly 7 years, but there's just nothing shocking about NPI, CPT, ICD, and other relevant identifiers. Thanks to the HIPAA mandate they are industry standard, so if you're dealing with anything that uses these identifiers you will learn pretty quick (speaking from experience here, but I also work for a medical billing firm so I get an extreme amount of exposure as getting claims and bills out the door is our entire purpose).
The challenge with HIPAA isn't really the technical safeguards. It's processes and controls you have in place to make sure that you don't violate HIPAA.
On a small team, this is pretty easy to have your CTO take this responsibility simply by being involved in EVERYTHING. At a certain point that breaks, then you need good processes.
Personally, the biggest pain of HIPAA is actually the product restrictions (or requirements) rather than the technical requirements.
* Lots of limitations on how you can use and share information * Lots of requirements for durability/accessibility/forgettability * Lots of mindfulness of where you store data and what has access to that data.
For example, look at cookies. It's a best practice to not store sensitive data in there. In a non-HIPAA environment, you don't really have to worry about it. Worst case, you identify the problem and resolve it. In a HIPAA environment, the could result in a violation, so you need to build a process to avoid storing sensitive data in an insecure manner.
Extrapolate to a bunch of different risks and suddenly you have a lot of surface area to look after.
Best I can tell, being HIPAA compliant isn’t exactly difficult, it’s just costly if you fail. Encrypt everything, delete patient data when you don’t need it, automatically log out users after as short a time as acceptable, and have a legal team ready to handle contracts.
This is great too: https://www.aptible.com/hipaa and https://github.com/truevault/hipaa-compliance-developers-gui...