HIPAA Survival Guide Newsletter, June 2021

The RMF, Swim Lane Diagrams & Upcoming Changes to the Privacy Rule


My colleague has already explained why rationalizing the RMF with your methodology is important to take advantage of the expanded Breach Notification Safe Harbor (BNSH), which was introduced as law as part of the CARES Act (first COVID stimulus package); there is no need to cover the same ground here. This article focuses on Swim Lane diagrams (SLDs) and how they also support this rationalization, and why SLDs are important to the proposed NIST Final Rule (Rule). The BNSH is law today so it behooves HIPAA stakeholders (Stakeholders) to begin taking advantage ASAP.


Before diving in to the SLDs dialogue, some background is necessary to set the stage for this discussion. First, Stakeholders need to have an understanding about how the NIST universal grammar for conducting risk assessments (NIST SP 800-30 Rev1) (Assessments) behaves differently for all privacy-based regimes (e.g., The HIPAA Privacy Rule, CCPA, GDPR etc.) Although having a significant role in creating the Expresso load module for our privacy assessment it took me some time to understand how threats, and consequently the ensuing liability are different in privacy regimes than they are for a security-based regime like the HIPAA Security Rule (SR). If you don’t understand this fundamental difference, then the rest of this article will be difficult to grok.

In the SR Threats may come from the “bad guys” trying to breach your network, insiders trying to exfiltrate PHI for their own gain, no preparedness for environment threats (either natural or man-made) or failing to implement the basic controls that the SR mandates. Complying with the SR has a significant technical component, although process remains paramount. Therefore, the HIPAA SR compliance initiative is often “thrown over the wall” to information technology (IT) experts. We generally don’t agree with this approach but in practice that is what usually occurs.

For a privacy-based regime (i.e., all of them universally) the Threat, and therefore the liability, comes from the rights that have been bestowed upon consumers by the regime. This is such an abstract concept that a concrete example is required. For example, under the PR patients have certain enumerated rights, the right to access, amend, and/or review their PHI. The Threat is that your organization does not have “actualized organizational processes” (as opposed to mere policies and procedures) for satisfying these consumer rights and therefore fail to satisfy these rights in a timely manner (e.g., PHI access requests). Unless you have been asleep at the wheel you should have noticed that OCR, for a least a couple of years now, has been levying considerable Civil Monetary Penalties (CMPs) for those organizations, both large and small that fail to deliver on these rights in a timely manner. There are public policy reasons for this shift in emphasis by OCR, but this remains fodder for a subsequent article.

After promulgation of the HITECH, and the Omnibus Rule, the entire focus was on the SR and rightfully so. The PR has mostly been neglected because in the HIPAA world it was the red-headed stepchild. The healthcare industry (and others) generally ignored patients’ rights for several reasons: (1) the patient, as perverse as this sounds, was not the customer because they didn’t pay the bills; the government and insurance companies did; and (2) OCR was not actively enforcing the consumer’s PR rights and therefore who cared how long it took and organization to provide a patient with its PHI. All those patients could do was complain to OCR and those complaints largely fell on deaf ears.

The proposed FINAL PR rule changes all that: (1) OCR no longer has deaf ears; and (2) the time to satisfy these rights have been cut in half (e.g., from 30 days to 15 days for access to PHI). This is a PR game changer for most organizations that have at best ad hoc processes in place today for delivering on these rights.

Software as an Enabler

First (almost universally) each right that a consumer wants to exercise is driven by a request to the organization. Although having a tool like Expresso’s Requestor was designed to track any consumer request (across various privacy regimes) and facilitate end-to-end monitoring of the consumer request from inception to final deliverable. That’s a nice feature to have when dealing with a privacy-based regime BUT it not the solution to the problem! No enabling software is a solution to the problem. The problem is solved by having an “actualized organizational process” that defines, with some level of rigor “how these rights are fulfilled.” The Requestor is a great tool for the manifestation of that process (i.e., for each type of request the regime allows a consumer to make) but the hard work comes in defining the process that will accomplish the work within the confines of your business. As discussed below, that is where SLDs come into play.

Swim Lane Diagrams for Process Definition

Reinvention and revision of processes is also enabled using an agile, iterative approach to modify or improve any of these procedures. RMF was developed to support an Agile methodology. As you can see in the upper right corner, Expresso provides a “Requestor” that gives individuals the ability to document the request, and names the workforce member who processes the request. 3LP has been using the RMF for years now.

We are helping clients align with the RMF to take advantage of the safe harbor (i.e. which is already law, promulgated as part of the CARES Act).