|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
from the New England Journal of Medicine
https://www.linkedin.com/pulse/covid-19-reminder-reason-deborah-leyva-rn-hcp
"How long will this pandemic last? When will we find a treatment or vaccine? Which drug should we give our patients? Will we run out of personal protective equipment (PPE)? When will everyone return to work? We find ourselves in a time of great economic, social, and medical uncertainty. Faced with a crisis, Lee Iacocca, the late automobile company executive, once said, “So what do we do? Anything. Something… . If we screw it up, start over. Try something else. If we wait until we’ve satisfied all the uncertainties, it may be too late.” Similarly, in the heat of the Great Depression, Franklin Roosevelt commented, “Take a method and try it. If it fails, admit it frankly and try another. But by all means, try something.” Though a trial-and-error approach may be appropriate in business and politics, should it be applied to medical decision making during a pandemic?"
Posted at 01:43 PM in Current Affairs, Health IT, Health Reform, Healthcare, Population Health | Permalink | Comments (0)
See CISA, MS -ISAC, NGA & NASCIO RECOMMEND IMMEDIATE ACTION TO SAFEGUARD AGAINST RANSOMWARE ATTACKS. Really, circa mid-2019 (i.e. the date that the above “advice” was promulgated) is this the best that Team USA can do? NO! But you can rest assured for the foreseeable future this is the best that Team USA will do, premised on national security concerns. Team USA is not about to go any further than the “proverbial toe in the water”—doing nothing more than reinforcing the anemic response that it has shown pursuant to cybersecurity threats over the last four decades. It’s not about to expose its sources and methods by coming to the rescue of the healthcare industry. If patients must die, then so be it. After all we are at war. People die during wars. It’s the inescapable nature of the beast. This is on us. Team USA will do little more than what its already done by offering platitudes yet not venturing into the no man’s land of reallocating public/private Risks pursuant to cybersecurity threats. Big Brother is not coming to the rescue anytime soon.
Posted at 02:00 PM in Current Affairs, Health IT, HITECH / HIPAA, Information Technology for Healthcare (EHR/EMR), Internet Resources, Webinars | Permalink | Comments (0)
In case I haven't mentioned it, we recently began a Compliance Podcast where we first reviewed The Compliance Manifesto, 2nd Edition and its contents at a high level. We also plan to have conversations with industry luminaries to discuss issues of importance in the compliance space as well as other relevant topics. Download a Podcast Episode from the Podcast player of your choice as shown here.
Posted at 09:21 AM in Health IT, Healthcare, HITECH / HIPAA, Internet Resources, Podcasts | Permalink | Comments (0)
FREE FEBRUARY WEBINAR
|
A Short History of Cyber War and Why it Matters |
Posted at 11:03 AM in Current Affairs, Health IT, HITECH / HIPAA, Information Technology for Healthcare (EHR/EMR), Internet Resources, Webinars | Permalink | Comments (0)
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.
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:
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
The Result is countable
The Result is essential
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.
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).
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.
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.
Posted at 02:55 PM in Current Affairs, Health IT, Information Technology for Healthcare (EHR/EMR), Knowledge Management | Permalink | Comments (0)
To sign up for our free monthly newsletter and webinars, click here.
Expresso Release 2.5 Shipped!
Expresso Release 2.5 features our Breach Notification Wizard that shipped on October 23, 2019. See the Press Release! The Wizard allows Expresso Users to analyze Security Incidents to determine whether a Breach has occurred. It walks users through an automated analytical framework to determine if a Breach is triggered and, if so, it provides the reporting times required under applicable federal and state law. With this release, we continue to deliver on the promise of Enterprise Compliance for the Masses. Ask us for a demo to get a preview! Email us at [email protected].
Webinar Title: How Other People Comply with the Security Rule (Redux)?
Description: This webinar will review one of the most insidious Required implementation specifications of the HIPAA Security Rule: Information System Activity Review and provide some "show and tell" of an elegant and affordable solution to this problem.
Featuring
Proactive Patient Privacy Monitoring
Accurately Detect Inappropriate Access - The First Time It Happens
Advanced data science enables automatic and accurate reporting of impermissible use by anyone who accesses your clinical or business systems.
Date: October 24, 2019
Time: 2:00 - 3:30 p.m. EST
Register here for the Webinar!
Introduction
Given the quality of today's "alert tools," (e.g. Google Alerts) fulfilling the "Addressable" implementation specification ("Security Control" or "Control") under the following section of the Security Rule should be a "no-brainer:"
(5)(i) Standard: Security awareness and training. Implement a security awareness and training program for all members of its workforce (including management).(ii) Implementation specifications. Implement: (A) Security reminders (Addressable). Periodic security updates.
Still, we believe that this seems rather basic Security Control rarely gets implemented, and when it does, it's done in a manner that is either trite or overwhelming, neither of which make it actionable for your Workforce. First, let's clear up (again) a myth about what an "Addressable" Control means.
One bright-line rule that you can take to the bank is that it doesn't mean optional! In plain English, an Addressable Control under the Security Rule means: (1) that you must implement the Control as stated in the Rule; or (2) that you must implement a suitable alternative for an organization of your size, sophistication, resources, etc.; or (3) you must document a compelling rationale why you decided to do nothing. Simply ignoring an Addressable Control is likely to get you a "willful neglect" fine; which start at $50K a pop (ouch).
The Challenge?
The challenge here is that we can think of no compelling rationale(s) why even the smallest Covered Entity or Business Associate cannot implement this control. Further, let us remind you of one of the guiding principles that underpin the Security Rule and that is, you are required to do what is "reasonable and appropriate." We often call these legal "weasel words" because it is how HHS, or a court of law, can "bite you" even when you believe that you are otherwise in full compliance. For example, encryption is also an Addressable Control under the Security Rule, but if you are storing your PHI in the cloud (e.g. on AWS or Azure), where you can literally encrypt with "clicking a checkbox," do you really believe that the authorities would find it "reasonable and appropriate" if you failed to check the box? Of course not.
So that begs the question, why is this Control so often ignored or implemented in a manner that makes it virtually useless? One reason is that you can't continue to provide "motherhood and apple pie" Security Reminders and not expect them to be ignored, (e.g. do not share passwords, use strong passwords, lock your workstations when not in use, don't open emails from people you don't know, etc., etc.). It's not that "motherhood and apple pie" are bad things in and of themselves, it would be silly to suggest that. However, if that's what your Reminders consistently regress to then it's akin to your mom nagging you to clean your room when you were a kid. You may eventually do it because the nagging becomes "worse than the cleaning," or out of fear of some more dire form of reprisal (e.g. taking your Nintendo away) but it's unlikely to change your conduct going forward. Mom will continue to nag because you will continue to need it.
The Purpose?
That brings us to the critical question we want to pose in this article: "What is the purpose of Security Reminders?" From our perspective, the purpose is to change your organizational compliance DNA over time so that this small, but meaningful, Control significantly contributes to the creation of a "culture of compliance" within your organization. Compliance is not a "set and forget or once and done" process. In the 24/7 365 online world that we all now inhabit, cybersecurity must be transformed from some necessary regulatory evil to a mission-critical piece of your value proposition for patients and other stakeholders. Even a small breach is going to ruin your day and cost you thousands of dollars to analyze and report. If a robust Reminder program can prevent and/or mitigate the same, then this is a huge organizational win.
Summary
So, what should a robust Reminder program consist of? Like so many things in the HIPAA compliance universe, there's no single way to go about implementing one. However, as a guiding principle, it should produce "news your Workforce can use" (i.e. in addition to motherhood and apple pie) regarding emergent "zero-day" exploits, including but not limited to, remediation for new: (1) phishing schemes; (2) attack vectors; (3) ransomware; and (4) encryption strategies, etc. Reminders should also be used to inform your Workforce of material changes in the law and events that mandate new Risk Assessments, like mergers and acquisitions, moving your data center, and other significant modifications to your operational environment.
Posted at 08:01 PM in Health IT, HITECH / HIPAA, Webinars | Permalink | Comments (0)
Posted at 09:18 AM in Current Affairs, Health IT, HITECH / HIPAA, Web/Tech, Webinars | Permalink | Comments (0)
Posted at 12:56 PM in Health IT, HITECH / HIPAA, Webinars | Permalink | Comments (0)
![]()
Title: Compliance Repository: A Single Version of the Truth!
Description: Storing your Visible Demonstrable Evidence
Date: November 15, 2018
Time: 2:00 p.m. EST
|
Posted at 06:50 PM in Health IT, HITECH / HIPAA, Webinars | Permalink