HIPAA Survival Guide December 2019

What you need is a workflow..

Introduction

We have often preached our mantra that compliance can only be achieved at the granularity level of a requirement ("Requirement"). Further, the only way to show compliance is by providing visible, demonstrable, evidence ("VDE") that the Requirement's result was delivered. A Requirement presupposes the existence of a discrete deliverable. VDE is an abstraction that indicates how this result is accomplished; however, it only works at 10K feet. To make it actionable within your organization you need a process that works at ground level. What you need is a well-defined process that achieves the result. What you need is a workflow.

Since this workflow topic is "heavy," as you read through this month's article, please note that you may contact us with questions you may have. Email us at: [email protected]

The following are examples of Privacy Rule ("PR") workflows and their attendant results.

• Authorize PHI         ->     PHI Authorized
• Restrict PHI            ->     PHI Restricted
• Access PHI             ->     PHI Accessed (or delivered)
• Amend PHI             ->     PHI Amended
• Disclose PHI           ->     PHI Disclosed
• Account for PHI      ->      PHI Accounted for

To demonstrate the need for a workflow, we borrow from the book: Workflow Modeling, Tools for Process Improvement and Application Development; Second Edition by Alec Sharp. Key definitions From Alec's work are shown below to enable the development of coherent compliance workflows and avoid the recursive semantics that has led many workflow projects into the abyss-turning what Edward Yourdon (father of Data Flow Diagrams) once correctly called "death march projects." Once you have experienced a demolished workflow design process and managed to survive, you never want to experience one again. Unfortunately, because we are veterans of the technology industry, we have managed to survive more than one-a fate that we would not wish on our worst enemies. 

Definition of a Process (aka "Workflow")

It should go without saying that a Process involves some sort of work. Duh. Well not so much because what often appears obvious in the business modeling space isn't.

A Process is a defined method to achieve some result, and that result is far more important to the definition of a business process than the work that goes into it.

Named in Verb-Noun Form

The first step in deciding whether or not you have a process is to name it and apply two exceedingly simple and useful guidelines:

1. The Process name, at it's simplest, must be in the form verb-noun. (e.g. Assign Inspector). It might be in the form verb-qualifier-noun (e.g. Assign Backup Inspector) or verb-noun-noun (e.g. Assign Inspector to Route). Note the Processes are almost always defined in the singular. Not "Handle Orders" but rather "Fill Order."
2. Here's where it gets interesting-the verb-noun name must indicate the result of the Process, as follows. If you flip the terms around into noun is verbed form, the phrase should indicate the intended result of the Process (i.e. as we have done above in the PR examples.

Delivers a Specific, Essential Result

And now it really gets interesting. The result of the Process, in "noun-verbed" form, must meet three criteria. 

The Result is discrete and identifiable

1. That is, you can differentiate individual instances of the result, and it makes sense to talk about "one of them." For instance, the result of Authorize PHI is that one individual or entity is now authorized to view the patient's PHI. It stands to reason that a patient can designate one-to-many Authorizations.

The Result is countable

2. That is, you can count how many results you have produced in a day, week, month, year, etc.

The Result is essential

3. That is, it is fundamentally necessary to the operation of the enterprise, not just a consequence of the current implementation. It is axiomatic that "Authorize PHI" is essential to a Covered Entity ("CE") under HIPAA because it is a HIPAA regulatory requirement.

Producing VDE Requires a Workflow

It is axiomatic that producing VDE requires a Workflow. The "triggering event" in compliance is a Requirement; the result is the fulfillment of that Requirement. Do all regulatory Requirements fit this model? Who knows? We believe that the majority do. Here our objective is not to reach Workflow Panacea, that is way beyond our pay grade. Our objective is to illustrate how widely the Workflow Modeling framework can be applied to compliance, and in this instance to HIPAA. To be a competent Compliance Officer going forward it is essential that you master this discipline. Workflow modeling should be one of many tools inside your toolkit. If you want a seat at the C-Suite table that means getting busy. Iterate. Iterate. Iterate. Literacy. Literacy. Literacy.

Other Workflow Considerations

A Process is initiated to deliver its Result by a triggering event ("TE"). Generally, but not always, the Process is triggered by the "customer" that will benefit from the Result. The customer may be internal or external. In the examples herein, it is the patient or legal representative ("Individual") that triggers these processes. Between the TE and the Result is a collection of tasks, actions, steps (referred to as "Activities") that must be accomplished to deliver the Result. There may also be sub-processes, each meeting the Process definition, that may be interposed between a Process and its Result. For the Processes we present here as examples we will constrain the analysis to a collection of Activities. 

However, within your organization, there may be sub-processes interposed. That is something we leave as an exercise for our readers. Be forewarned, there are some non-trivial technical challenges when you start interposing sub-processes. Each sub-process consists of another collection of Activities.

The Activities within a Process must be interrelated, they are not just some arbitrary collection of work. They must be related either through a necessary sequence or a dependency. A dependency is implicated when Activity "C" cannot occur until Activity "B" is completed. This distinction may be semantic "hair-splitting" because a sequence appears to implicate dependency, although one could quickly think of use cases where this is not true (i.e. where the sequence does not occur in any particular order).

Activities are also interrelated because they all deal with the same "Token." We think of a Token as a single unit of work. For example, in the "Authorize PHI" example the Token is the work required to complete the Authorization, provide the necessary access, or notification of denied access. If we included training staff to deliver Authorizations in that Process than that would introduce a different Token-which under this model would mean that said training constitutes a separate Process.

Privacy Rule Example

The example provided below is intended to be just that. We do not pretend that this example Process will meet every CE's need, or that of any specific CE. We intend, by way of example, to demonstrate how you should be thinking about Workflow Modeling within your organization. We also hope to extend our lexicon to show that producing VDE for a Requirement requires a Process and what that Process might look like when diagrammed.

Authorize PHI

This Requirement is driven by the following PR section: §164.508 Uses and disclosures for which an authorization is required. In general, the Requirement is stated as follows:

(1) Authorization required: General rule

Except as otherwise permitted or required by this sub-chapter, a covered entity may not use or disclose protected health information without an authorization that is valid under this section. When a covered entity obtains or receives a valid authorization for its use or disclosure of protected health information, such use or disclosure must be consistent with such authorization.

Let's provide a specific example. An aging mother (C) requests medical record access from her Physician (CE) for her daughter (Entity A). The TE for an authorization is the Individual ("I" or "C") (e.g. the Mother) who has requested access for her daughter. 

In this simple example the Individual is both the Customer ("C") that triggers the Process ("P") and is the ultimate beneficiary of the Result ("R") (however here there are two beneficiaries: (1) the Mother (C); and (2) the Daughter (Entity A) that actually get authorized access to the PHI). 

• Authorization Requested by (C) for Entity A
• Request communicated to Physician (CE) 
• Validate Request
• Provide Access
• Notify Customer (C) and Entity A

Right away there should be some flags that are set off based on the simplicity of this Process. But first let's determine if all the attributes of a Process are met:

(1)   Here the R is discrete and identifiable: Access to the PHI has been provided and the Individual has been notified (two results here).

(2)   The number of times an Authorization is provided is clearly countable over time.

(3)   The R is essential in that it fulfills a regulatory requirement.

So, it appears that on its face we have a valid process. The issue is not based on the validity of the Process but rather on its simplicity. To see why this is true let's explore other aspects of §164.508. The Rule states as follows:

1) Valid authorizations.

(i) A valid authorization is a document that meets the requirements in paragraphs (a)(3)(ii), (a)(4)(ii), (c)(1), and (c)(2) of this section, as applicable.

(ii) A valid authorization may contain elements or information in addition to the elements required by this section, provided that such additional elements or information are not inconsistent with the elements required by this section.

(2) Defective authorizations. An authorization is not valid, if the document submitted has any of the following defects:

(i) The expiration date has passed, or the expiration event is known by the covered entity to have occurred;

(ii) The authorization has not been filled out completely, with respect to an element described by paragraph (c) of this section, if applicable;

(iii) The authorization is known by the covered entity to have been revoked;

(iv) The authorization violates paragraph (b)(3) or (4) of this section, if applicable;

(v) Any material information in the authorization is known by the covered entity to be false.

It should be clear from above that the Authorization requires validation and that the next steps cannot proceed until validation is complete. Further, it should be clear that "Validate Request," written in verb-noun form, is likely a sub-process with its own set of Activities. The same is true of "Provide Access" and "Notify Customer." 

What are the takeaways thus far? First, it should be clear that Process modeling is iterative. You are simply not going to get it right during your first attempt. Second, in order to model effectively you are going to need some expert knowledge of the subject matter domain. Third, there are other questions and/or flags that should be on your radar by now. For example, what happens if "Validate Request" fails? And a sub-process to "Store Validation?" If we do not perform the latter how will we find the Authorizations that this Individual has triggered when the same (or other) person/entity wants access again?

Here is an example of a Swim Lane Diagram for this Example (Workflow Process). A quick explanation of its components is helpful. 

1. Left side (in grey) contains the names of the individuals or departments responsible for performing the duties to it's right (on the same line) a) Individual, b) Compliance Officer,    c) HIM Department, and d) Entity A.
2. Arrows point to subsequent activities once the prior activity is complete.
3. Notes are entered for clarification and further explanation.
4. Blue starts the process (Triggering Event) and Red stops the Process.
5. Yellow diamond designates yes or no response and may have sub-processes.

Summary

Are we done? No. There are other steps in the Process modeling framework that remain (e.g. creating a more detailed "swim lane diagram"). However, the intent here was to introduce Process modeling and how it might work pursuant to the Privacy Rule. We suspect that most healthcare organizations have not modeled the Processes required to comply with the HIPAA Rules (i.e. Privacy, Security, and Breach Notification). Process modeling is the mechanism by which an organization gets "down and dirty" with the Activities necessary to produce VDE for a single Requirement. 

Stay tuned for future webinars where we will provide additional information about how your organization can use swim lane diagrams (workflows) to improve HIPAA Compliance. 

Signup for our FREE Newsletter here.