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.
The first step in deciding whether or not you have a process is to name it and apply two exceedingly simple and useful guidelines:
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.
2. That is, you can count how many results you have produced in a day, week, month, year, etc.
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.
(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.