Protecting Healthcare Data in and Beyond an HIE
Print This Post
Share this Post
HIEs must secure patient data to ensure trust and success
In this series, we’ve discussed planning an HIE and briefly covered some of the critical components necessary. Those critical components allow us to manage and answer questions about a patient's identity and discover what information is shareable for the patient, no matter where it is stored.
All of this is well and good but, if patients, physicians, or anyone involved with the healthcare ecosystem, doesn't "trust" the system or have confidence their data is protected, it won't be used, and we won't realize any of the potential benefits of the HIE.
Security isn't just about protecting an individual's personal information from hackers and fraud, nor is it merely about complying with new regulations. Security is about ensuring the proper privacy of patients' data while improving the quality and accuracy of care.
This really means that not only should the right patient data be available to the right care giver or care system at the right time, but the system must reliably and continuously build trust for all parties involved.
There are numerous national and state regulations, products, experts and blogs dedicated to creating and fostering security of healthcare data. I believe that, at a minimum, a good HIE will address;
- Authentication and Authorization
- Secure Communications
- Encrypted Data
- Auditing and Reporting
Authentication and Authorization
Authentication refers to a person or system having the approval to be on or use a solution. Authorization is the next step, when this person or system has the rights and permissions to execute this program or see this data.
There are numerous companies who provide solutions to these requirements, but the underlying technology standard that is widely adopted is LDAP (Lightweight Directory Access Protocol).
IHE provides a "cookbook" to address common healthcare privacy issues related to Patient Privacy and Patient Data Authorization with the Basic Patient Privacy Consents (BPPC) profile. This profile has been well-received by the vendor community and is influenced by requirements from HITSP that specifically address this issue.
Secure Communications
Whenever any person or any system talks to any other person or system, the channel on the inter/intranet on which this conversation is occurring is 1-to-1 and cannot be broken into or overheard by others.
In effect, we should answer the question "Why can't our health networks be as trustworthy as our belief in the banking networks?" Within IHE, the NA of the ATNA (Audit Trail and Node Authentication) profile addresses exactly this and is required by all participating vendors.
Encrypted Data
Basically encrypting data means rendering data into a form that cannot be read in a "clear text" mode. Data encryption has three components:
- At creation
- In--flight
- At rest
Government policies and procedures require protecting patient data and reporting potential intrusions. Therefore encrypting data is and continues to be challenge.
Database vendors can encrypt data at rest in their databases, and products are now available to encrypt data on file systems. However, using these products comes at a cost. Many solutions must "wait" while de-encryption occurs before they can process data from these systems.
Encrypting data in-flight is more common today; this is the use of HTTPS or SSL which has been around for years.
Again, the NA part of ATNA from IHE addresses a "cookbook" requirement for all vendors to encrypt communications. Recently, "keyboard encrypting," or encrypting data as it is being entered, has begun to gain prominence. Today there are discussions about this requirement, but no concrete use cases/requirements in healthcare or at the HIE.
Auditing and Reporting
Auditing really is the ability to capture and examine all transactions, events, or changes and create a way to inspect and report on them. Within IHE, this is the AT portion of the ATNA profile.
Additionally, many vendors can also enhance ATNA with their own proprietary solutions. With new requirements for security and reporting with the government, this requirement is gaining prominence.
Finally, within the US and other countries there is a push to "certify" a vendor’s ability to be secure. Some of these certifications require the vendor to remove specific PHI (Personal Health Information) data from their messages while others deal with "Transaction Packages" that cover multiple requirements like encryption and PHI.
Where are you going to go to make sure your vendors are meeting these requirements? One suggestion is through IHE, HITSP and other government-sponsored agencies that are using IHE Connectathons to advance adoption of these security requirements.
Of course, there are many other opinions. John Halamka recounted his top five security and privacy lessons that he’s learned during his various tenures as a healthcare CIO. He reminds us that security isn’t just about standards – it’s about infrastructure – and that security is a process rather than a product.
On his blog, John Moerhke asks, “What has HITSP done to protect confidentiality with a suite of implementable security standards?"
What’s your view?
This is part of Bill Klaver's series, Building a Health Information Exchange Through International Standards. For other posts in the series, visit the Table of Contents.
Leave a Response
Entries(RSS)