Building a HIPAA-compliant rules engine for text-based service company

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.

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.