Legal Levity

The minimum necessary principle serves as a cornerstone of any covered entity’s approach to HIPAA compliance. In a nutshell, the minimum necessary principle states that when disclosing Protected Health Information “PHI”, a covered entity should only disclose the smallest amount of PHI possible, while still: 1) adhering to the patient’s authorization; 2) complying with the law; and 3) responding to the request.  With that in mind, I present the PHI Shred Theory of Application Development.

PHI Shreds: PHI Shreds are a manner of developing health IT applications wherein the developer focuses on keeping as little PHI on the mobile device or computer as possible. While this seems simple and logical, think about the recent mobile device and computer breaches. For instance, the recent Aspire Indiana breach (Erin McCann did a great write up here) where several unencrypted laptops were stolen that contained: Name, DOB, Client info, Employee Info, HIV data, and substance abuse information. At some point, the decision was made that case workers/nurses/doctors using these laptops needed: 1) a mobile device; 2) with heavy unencrypted PHI content; and 3) a client database stored locally.

In a PHI Shred environment, the laptops and applications utilized by Aspire would have done a few things differently. First, the laptops would be encrypted. Seriously, we can debate about this all you want, but an unencrypted laptop is a recipe for disaster. Second, the laptops would have only contained the shreds of information the employee needed at the time they were working, rather than full databases.

To implement the PHI Shred theory, sit down with case workers and ask them, what do you need to do your job? The answers may honestly surprise you. Most of the case workers I have met with, whether in the office or in the field, wanted a wide array of information removed: full SSN, medicare/medicaid numbers, core demographics, family member names, financials, etc.  What the case workers wanted was first name, last initial; case notes of past 2-3 interactions, most treatment plan, and medications. Then, if an emergency arose or they needed to be able to break the glass, access to all the client critical info was possible.  Time and again, I have had case workers tell me that automatic access to full client data made them nervous. With that feedback in hand, lets see how a PHI Shred environment would work in the real world.

Scenario #1 – Case Worker in the Field

Covered entity serves a client base in the field. While out in the field, the caseworker uses a laptop to gain access to their client’s info. When the caseworker sits down and opens their client’s EMR, a lite version of the client record is downloaded and viewed. At that point, all that is located locally on the laptop is first name, last initial, the past 3 encounter notes, the treatment plan and medications. After making their notes, the caseworker closes the EMR and the new information is pulled off the laptop, sent to the server and the laptop returns to being a mere portal with no PHI. If the caseworker does not have internet access, they will either have to click an ‘offline’ button to direct the laptop to pull down the lite client record, or will have access to a blank ENR. New information the caseworker inputs will be automatically pulled up to the server upon resuming connection to the internet.

Scenario #2 – Front Desk Receptionist

Covered entities see hundreds of patients a day, with a central receptionist scheduling, guiding, and organizing the patients and doctors.   Unlike most traditional covered entities where the receptionist often has full access to the client record, the receptionist can only see Name, Appointment Info, Date of Birth, or other demographics needed to schedule and route appointments. Amazingly enough, there have been several breaches of stolen receptionist computers containing full unencrypted client databases.

Final Thoughts: The concept of PHI Shreds really focuses on taking the minimum necessary principle to the next level. Mainly, restricting what PHI our employees are viewing to those items that they only really need.  Most organizations already have group level security and permissions models that could take this concept and run with it. At a basic level, each field in an EMR would be assigned a permission level. In order to view a field (in full or in part), your login would need the appropriate permission level.  This type of application development really takes HIPAA compliance to a whole new level; not only are you working on the human side and computer security, but HIPAA compliance is literally hard coded into your development.

/s/ HH @legallevity