HIPAA For Smarties - Part 1

So, you have a “thing” that you sell today, and that thing serves some sort of medical purpose. You’ve been selling it for some time now, and its success with both positive clinical outcomes and market results is starting to attract attention. Whether you like it or not, you have to admit that you are at risk of losing market share to competitors that have or soon may introduce a “connected thing”. 

The trend for the next few decades will be the increasing delivery of care outside of the clinical setting, so your traditional strength in focusing on the needs of the physician or healthcare provider is starting to diffuse as the payers and consumers gain influence and care settings change. Software needs to become a more central part of the solutions you provide, and web and mobile access to the information collected or to configure or control the device or therapy is becoming an essential part of the solution.

Sound at all familiar? If so, then read on. If not, but you still want to understand what it means to deliver HIPAA-compliant solutions in this new reality, then read on. If none of this is interesting, then have a nice day, and here’s some adorable cat videos: https://www.youtube.com/watch?v=cbP2N1BQdYc

Idea 1: You can’t HIPAA certify software

Let’s start from the end of the story and work backwards to the beginning: we need to be clear that HIPAA-compliance is something that really only applies to healthcare providers and health systems and the technology solutions they use in the context of delivering care to patients. Another way of saying this is that you can take a software application that has all of the important non-functional features to deliver HIPAA-compliance and misapply it within your clinical setting such that your operation is not HIPAA-compliant. You can also take software that is missing key features that would make HIPAA-compliance easier to implement and compensate for those missing features through manual processes that accomplish the same end result. Either way, there is no way for a software application to be HIPAA-compliant except in the context of how it is used to deliver services to patients. However, it is also a LOT easier to be HIPAA-compliant and efficient and affordable if you have software that simplifies all aspects of HIPAA compliance.

Idea 2: Expanded access creates new security challenges

Working back one more step, there are many ways to architect and deploy a software solution such that its use can be HIPAA-compliant. Because it is the job of the healthcare provider to protect the privacy of its patients, the earliest way and easiest way to do this is to use standalone products that don’t store any sensitive information about a patient, or if they do, they only store it locally where you would have to have physical access to the computer or device to get to the information. 

Of course, you are going to want to network these systems, so a centralized server that stores the information so you can move between rooms or terminals is inevitable, but if you keep those servers on your own internal LAN and within your own firewalls, then you are going to have the least risk. Some went so far as to realize that having computers with information on them out in the public areas was itself risky, so they moved to dumb terminals that you use to connect to terminal servers and the information is only stored on the central servers.

We consumers of healthcare are left wondering why we can’t have access to our health information and even choose our providers based on increased access to information, and we are also seeing an increased pressure to deliver care outside the clinical setting, so healthcare providers have needed to extend access beyond their four walls and to people that fill a variety of roles in the healthcare supply chain. With each of these innovations, we have had to change our technical approach to security in order to maintain the basic principles of HIPAA, but there is a solid and defensible answer to each of these challenges.

Idea 3: Start with a “secure-by-default” foundation

Let’s start with some of the non-functional requirements that can drive many of your architectural choices as you pick technologies to use to implement your solution. There are two simple assumptions about encryption that offer the path of least risk - if you encrypt all data “on the wire” and all data “at rest”, then you don’t have to show auditors how you make sure that the right data is encrypted when it needs to be. This does affect performance and cost of your solution, but I think in nominal ways, so it’s not worth the extra effort of handling Personally Identifiable Information (PII) and Protected Health Information (PHI) differently than other data. 

There is plenty of room for debate here - many companies will consider solutions like encrypting only the fields that need to be encrypted, setting up a well secured internal data center network that allows your servers to talk to each other over secure but unencrypted connections, or even segregating your systems into PHI and non-PHI systems and only applying these higher security standards to the PHI systems.

As I mentioned, the more conservative and easier to certify approach is to have all connections between all parts of the system be over HTTPS/TLS 1.2 or later secured connections regardless of whether they are outside your firewall or within and to always encrypt all data stored to database or file system as well, whether to your local mobile device or to your relational or NoSQL databases. The major relational and NoSQL databases all support encrypted options, so that should be straightforward and there are Cypto APIs you can use in your mobile apps to do the same. As for browser based encryption, as of this writing it is safest to assume TLS 1.2 is available across your customer base, but since TLS 1.3 was recently announced and launched it is not supported yet by all the major browsers. In time, it should become commonplace, but probably not until 2018.

Stay tuned for 7 more big ideas to come...