Hacker News new | past | comments | ask | show | jobs | submit login
Building a HIPAA-compliant rules engine for text-based service company (evrone.com)
23 points by Evrone 56 days ago | hide | past | favorite | 15 comments



Disappointed to see almost no details or specifics in the section about HIPAA compliance


I’ve been struggling to find a “HIPAA for dummies” or at least something I can understand in a few days.

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.



Perfect, thank you.


Because there isn't as much to HIPAA compliance as people like to think. 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.

(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).


I agree and disagree.

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.


> Because there isn't as much to HIPAA compliance as people like to think.

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.


> 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.)

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).


Would you happen to know where I can read these rules? It would be really helpful to me.


Here's a link to the dry text of the HIPAA regulations:

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.


Thank you so much, that is extremely helpful


Note that you still have to care about other sections like the privacy rule, but that along with the rest of the regulations are requirements on how employees, business and healthcare providers themselves work with PHI and not technical requirements for software - so what applies varies based on company, department, etc. and just gets handled by policies and training.


Datica has a pretty good reference on their Github: https://github.com/catalyzeio/policies


What a useless article. I was hoping to see some interesting details about how their rules engine could differ from those I've written for clients.


They probably used CLIPS, PyKE, Durable Rules, or PyKnow, since they mentioned doing it in Python. Most folks in heal care tech use Drools though. All of the analyst types know how to write rule for it, and it works pretty well even if you aren't a java shop.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: