Technology, HIPAA and You Part 4: HIPAAtrek

Wow what a whirlwind of a month. Since my talk at BSides San Francisco I have been in Dallas, Chicago, San Diego, and points beyond working on the intersection of HIPAA and Infosec as a new paradigm for thinking about how we secure PHI. There was also my guest piece @Tripwire on The New Normal in Breaches, Audits and Enforcement.

On top of that I got to meet with a company called HIPAAtrek, located in St. Louis, MO. HIPAAtrek was founded by an amazing group of individuals headed up by Sarah Badahman. As a quick note, I am not a client of HIPAAtrek, nor did I receive any compensation for this review. Part of what I do for this blog is work to find the best and brightest (in my opinion), products and people out there to help you navigate the HIPAA mine field. To that end, here is what I found on my run through of HIPAAtrek.

The goal behind HIPAAtrek is to develop a platform for HIPAA that works to take the complexity and expense out of compliance and compliance tracking. To that end, the people at HIPAAtrek created a web facing product that serves as the dashboard for your HIPAAtrek experience.

Dashboard and User Tracking

The basic five icons are a bit deceiving in the amount of information they really contain. The HT Dashboardmanage users tabs allows you, if you choose, to manage every employee in your company, the level of training, alerts, and even when they have accessed the website to review materials. As someone who constantly struggles to get employees to do training, the ability to track, send out alerts, and badger the crap out of someone appeals immensely. There is even a dashboard to tell me who has viewed alerts or other reminders. Security Reminder LogMy understanding is that in the not to distant future HIPAAtrek will offer the ability to administer and track trainings. If they can add videos, tests, and uploaded training materials this portion of the HIPAAtrek offering will really kick it up a notch. Most audits involve the inevitable questions: who did you train; when did you train; and what did you train. Already, many certifying organizations for healthcare require these types of reports and it would be a real cherry on top.

POlicy page and todo’s

Policies PageThe policies page is one of my favorite. Each of the icons represents a different policy or group of policies and frankly makes it a lot easier to figure out what you are looking for when browsing. Even in my own policy set, I often have to hunt until I find something. These intuitive links make that easier. The links here are broken into 20 categories ranging from Security Management Process and Contingency Plan to Workstation Use and Breach Notification. Also, along side each picture is a little number that indicates the number of policies contained within. Once you click one of the icons, you are taken to a policy page. Each category takes you to a page that describes the category, the overall purpose and the policy statements that you create. Also a part of this page, is a nifty progress bar that gives you a percentage of completion for your HIPAA policies. Each of these policies is tagged as either ‘Finalized’ or ‘In Progress.’ Reminder Report

This page also gives you a handy download to .pdf option in case those pesky auditors come around or you have an employee who must have paper. Ideally, a feature will be added in the future that will track revision number, date, edits, or even a button to track notes and/or specific things you want to remember when working in this category. Given the emphasis on business continuity and disaster recovery, I could see a place to upload your outcomes, dry runs, and findings from DRBC simulations. This brings me to the real sweet spot and a clear differentiator of HIPAAtrek. By using this Policy Moduleservice they will help you create your own policies from scratch, import policies you have already created, and yes (gasp) review the policies you have for gaps. A lot of services out there either utilize the pump and dump method where you get blank policies to fill in or they fill out policies with zero feedback or input from the stakeholders. HIPAAtrek leverages a different model that actually feels collaborative.

closing thoughts

I have reviewed and used a lot of HIPAA compliance programs that I have not, and would not, review. Too many firms overcharge and under-deliver in an expanding HIPAA compliance field that all too rarely provides fluff and stuff over depth and breadth. As with any compliance efforts, HIPAAtrek will not do the work for you. HIPAA compliance must be looked at like climbing a mountain, you and your organization do the work, but having a sherpa (or HIPAA Sherpa) to guide you along the way makes things significantly smoother and less fraught with icefalls, audits and crevasse. The bottom line is that audits are growing in number and breaches are expanding exponentially. Take a look at this piece I did on the OCR HIPAA Breach Reporting Data if you aren’t convinced.

Prepare now or pay later!

/s/ HH @LegalLevity

By the Numbers: 2009-2015 HIPAA Breaches

Here we are six months into 2015 and its time for the midway report on what has happened in the world of HIPAA breaches. It bears mentioning that the numbers below are ONLY representative of events impacting 500 or more individuals and reflects reporting up to June 23, 2015. All of the research below is my own and derives from publicly available data.

2015 Breaches: 1/1/15 – 6/23/15

The first numbers below are a breakdown of the sources of breaches in 2015. The percentage after the number shows what proportion of the overall 2015 breaches are attributable to that source. You will note that the numbers listed below do not equal the total sum, this is because OCR allows for an “other” designation when no other description fits.

Total number of Breaches in 2015: 93,963,272

Number of Breaches Since 1/1/2015 Attributable to:

Paper: 155,729 (0.1%)

Laptops, Desktops, and Portable Electronics: 295,655 (0.3%)

EMR: 22,203 (0.02%)

Email: 515,901 (0.5%)

Network Server: 92,672,601 (75%)

The numbers of 2015 are clearly skewed towards the BCBS, affiliates, and subsidiaries (“BCBS”). The breaches of BCBS account for a tremendous number of impacted individuals. Given the tremendous weight and skewing associated with the BCBS breach, I decided to control for those numbers and run the same report without the two huge BCBS breaches, a total of 89,800,000.

TOTAL NUMBER OF BREACHES IN 2015 (sans BCBS): 4,163,272

Paper: 155,7289 (3.7%)

Laptops, Desktops, and Portable Electronics: 295,655 (7.1%)

EMR: 22,203 (0.5%)

Email: 515,901 (12.4%)

Network Server: 2,872,601 (68.9%)

Whats intriguing is that the numbers are still heavily skewed towards loss attributable to a network server. Even controlling for the huge BCBS numbers, nearly 7 out of 10 stolen PHI records stolen came hacked network servers.

Historical look at the data on breaches

After running through the numbers for 2015, I decided to do a retrospective and look back at the data since reporting began. Here are the total breach numbers and their sources since reporting began in 2009.

Total Number of Breaches Since 2009: 134,870,039

Number of Breaches Since 2009 Attributable to:

Paper: 1,866,133 (1.4%)

Laptops, Desktops, and Portable Electronics: 13,760,826 (10.2%)

EMR: 2,840,852 (2.1%)

Email: 1,399,920 (1.0%)

Network Server: 102,420,230 (75%)

Once again, these numbers skew heavily towards the most recent 2015 mega BCBS breaches. Once again controlling for those number and subtracting them from the report, we get the following percentages.

TOTAL NUMBER OF BREACHES SINCE 2009 (sans bcbs): 34,070,039

Paper: 1,866,133 (5.4%)

Laptops, Desktops, and Portable Electronics: 13,760,826 (40.3%)

EMR: 2,840,852 (8.3%)

Email: 1,399,920 (4.1%)

Network Server: 12,620,230 (37%)

Amazing how once we control for the 2015 BCBS breaches, the numbers seem to almost normalize in a pattern with roughly 2 out of 5 stolen records coming from Laptops, Desktops and Portable Electronics; and 2 out of 5 stolen records coming from breached network servers. This means that approximately 80% of all of the breaches come from those two sources. These numbers really give weight to the idea that encryption and heavily investing in network architecture pays off in the end. This is only highlighted by the recent OPM breaches that were a product of legacy server infrastructure and unencrypted data.

Tarred and Feathered: BCBS, subsidiaries and affiliates

One of the most amazing things I am across in this research was the amazing number of breaches attributable to one organization: BCBS. Of the all time largest breaches, BCBS is responsible the number 1 and number 2 spots, and 6 of top 20 spots.

Total Number of Breaches Attributable to BCBS: 92,803,208

This number represents 68.8% of all breaches since HIPAA reporting began. In full disclosure, my information was stolen in one of their breaches. Even more amazing is the attitude that these breaches are not impacting the individuals who had their data stolen. On the dark web, PHI records often fetch 10-15 times as much money as a credit record and are often much more expensive to fix. According to the recent Medical Identity Fraud Alliance report the average cost to the individuals who have their information stolen and used is $13,500.

Now is the time for change.

/s/ HH @legallevity

BSides San Francisco 2015 – Recap

On April 19-20 the BSides organization held the 6th Annual BSides San Francisco event. The event was amazing. The range of people, topics, and interactions were incredible. If you have not read up on BSides, take a quick peek now. This organization is doing #infosec right – BSides 

I was very fortunate to be asked by BSides to speak on Day 2 about HIPAA.

Among the many amazing people there I got to meet the infamous @banasidhe

The facilities provided by @OpenDNS were fantastic. They provided an great venue in a great location. If you are not familiar with OpenDNS, take a quick peek over at their website and learn about the great work they do. OpenDNS

Turning to my presentation, things started off well and generated a lot of questions.

Also amazing was the live art during presentations. While I spoke, @kellykingman drew out my words:

The art was courtesy of @tripwireinc and organized by @joepetitt2

Before wrapping up and heading back to the real world there were several questions I promised some attendees I would follow up on, here they are.

1) Third Party Security/HIPAA Gap Analysis: On the web at Parameter Security and twitter @ParameterHacker

2) Third Party HIPAA Compliance: On the web at HIPAATrek and twitter @HIPAATrek

3) Post Regarding 60 Minute Notification Requirements for HIPAA Breach in Texas

4) More information regarding the Alaska Thumb Drive HIPAA Breach

5) Info on the HHS Security Risk Analysis Tool

6) Information on NIST HIPAA Compliance ToolKit

7) Information on what HIPAA requires for Encryption

Thank you again to BSides for an amazing opportunity and thank you for reading my blog. Up next week, I will do a review and walkthrough of HIPAATrek compliance tool!

/s/ HH @legallevity

PHI Shreds Theory of Application Development

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