I think it makes sense for the HIPAA Security Rule (even in its latest form from the Omnibus update)  not to be prescriptive. For one, the Rule is meant to address HIPAA Covered Entities (CEs) and now (with the Omnibus update) Business Associates (BAs) that come in all shapes, sizes and sophistication levels (Think single provider practices versus large hospital systems, one person billing coder versus large payers or clearing houses). The second reason I think it makes sense is that this is after all a Federal Government Regulation (as opposed to a industry regulation like PCI DSS). We all know how laborious and time consuming the Federal Government rule making process can be. Consider for example, the fact that the Omnibus Rule update to the HIPAA Security/Privacy Rules took more than four years after the relevant statute (HITECH Act of 2009) was signed into law. If the HIPAA Security Rule were prescriptive (like PCI DSS for example), the rule would need to be updated frequently in order for it to remain relevant in the constantly evolving environment of security threats and vulnerabilities. We know PCI DSS gets updated every three years or so, not to mention the constant stream of guidelines that PCI SSC issues.

For all that makes sense for the HIPAA Security Rule to be as non-prescriptive as it is, I think it could use one prescriptive requirement. And that is to require all CEs and BAs to have a current diagram of the PHI Data Flows. This in fact is a newly included requirement in the recently released PCI DSS 3.0 (pdf). Below is a screen capture of the the new PCI DSS requirement 1.1.3.

In my view, maintaining a current Data Flow Diagram showing all locations PHI is created, received, stored, processed  or transmitted is so “foundational” to Healthcare Security and Privacy programs. After all, how can one implement appropriate safeguards if one doesn’t know what and where to safeguard? It is also for this very reason that we have this requirement as the very first in our list of Top 10 PitFalls in Security/Privacy Risk Assessments.  The closest that the HHS Office for Civil Rights (OCR) comes to addressing this is buried in the last statement of the audit procedure in OCR Audit Protocol  (see screen capture below)  which says “Determine if the covered entity has identified all systems that contain, process, or transmit ePHI”. In my view, this procedure step is not good enough because “identifying systems” is not the same as having knowledge of all the PHI Data Flows.

In my experience, lack of knowledge of the PHI Data Flows is a very common challenge among most CEs and BAs regardless of their size or scale. The problem is especially acute when the data goes out of structured systems (EHRs, Revenue Cycle Management Applications etc.) in the form of unstructured data for one or more reasons. It is extremely hard to track and safeguard unstructured PHI so it is important that the organizations get a clear understanding of their PHI data flows and closely manage the flows. As such, any investments in a Security/Privacy program without first getting an understanding of the the data flows may not deliver the desired returns or help achieve the objective of safeguarding PHI or patient privacy.

I’ll be interested in hearing your feedback or opinions. What are your thoughts? What other prescriptive requirements would you like to see included in the HIPAA Security Rule?