Personal health information (PHI) is very sensitive and is therefore subject to many regulations around the world – most notably, GDPR in the EU and HIPAA in the US. We have covered both regulations in depth (GDPR articles, HIPAA articles), but the specifics of each legal text don’t give the full picture over protecting healthcare records / PHI.
Why PHI is sensitive?
While that may be seen as obvious, it has its nuances. While not all diagnoses, lab results, or prescriptions are sensitive, an overview of one’s health status can be used against them in many scenarios. The obvious examples are STDs, but any disease or even a test or scan can be used against an individual within some context. We can’t predict all these contexts and edge cases, and so we have to assume all health information is protected. Philosophically, our health is part of our private lives and even who we are, and our privacy is protected by many constitutions around the world. Leaking some medical records may seem benign, but no organization is in the position to decide that.
How is PHI stored currently?
Unfortunately, even despite the various regulations in place, healthcare data is often at risk, and data breaches are common. Various reports about information security in the healthcare sector paint a picture that is not as bright as we would like.
Data is often stored unencrypted, with improper access controls, without proper backup procedures. Software is unpatched and proprietary, industry-specific software products don’t always follow best security practices. PHI usually resides in standard relational databases, alongside other, non-sensitive data. That’s because the applications that are used for input and retrieval need it unencrypted in order to work properly.
How should data be stored?
Encryption is the primary recommended technique but what does it mean? “Encryption at rest” is now mostly a marketing term – it means the data is encrypted on disk. What this protects you against is an attack that involves someone physically stealing the hard drive – an unlikely scenario for data breaches nowadays. “Encryption in transit” means that data traveling through the network should be encrypted. Usually, that means “data between the user and the application” as rarely the connection between the application and the database is encrypted (although it should). Both these types of encryption must be in place, but they are the bare minimum.
Record-level encryption is an additional measure that must be taken when it comes to sensitive data. That allows only the application that needs the data to be able to read it, ideally via several layers of cryptographic keys, ultimately protected by secure hardware modules. That way curious database admins, or an attacker that manages to steal their credentials, can’t do anything with their raw database access. Backups done that way contain only encrypted information. Even leaking a few keys (e.g. via memory analysis) doesn’t lead to a significant data breach.
Why record-level encryption is not widely used?
Because it’s hard. Making strong, granular encryption work with the requirements for flexible queries, analytics, reports, and other functionality that everyone expects, is often a task of academic complexity. Encrypting data is easy; making use if it is a real challenge. That’s why even diligent vendors try to protect the data in other ways – by monitoring access to it, and blocking suspicious activity; by monitoring multiple channels, through firewalls and email security solutions or by installing agents on endpoints that combined with “magic AI” are supposed to prevent breaches.
What is EHRVault
EHRVault is a PHI-specific implementation of our SentinelDB product family. It’s built with the “privacy by design” philosophy and allows organizations to store personal health information in a secure and compliant way. The point of applying technical measures is to go away from checklist-based security and provide actual breach protection.
EHRVault can be deployed on-premise or in the cloud and allows organizations to store, search, and retrieve PHI. Data itself is stored with record-level encryption (each record having a separate key). Data is accessed through APIs and each access and modification result in an audit trail entry that is protected by our SentinelTrails product.
A typical implementation of EHRVault would include migrating and centralizing sensitive data, letting all applications within the organization to consume the same, properly secured data. Organizations have the flexibility to define their own schemas or import existing ones and provide access either via a RESTful API or directly via a user interface.
We believe that we can eliminate not only much of the risk for data breaches but also a significant portion of the costs associated with ensuring security and compliance.