IHE now has full coverage on how to Encrypt sensitive data.
The following table comes from the IHE-Document Encryption (DEN) profile. It was created in that supplement as a way to verify the need for the parts of the DEN profile. This table recognizes that IHE-ATNA already covers most of the encryption needs, especially network transactions. However there is a need for encrypting a single Document at a time, and for encrypting XDM removable media. These needs are covered in the DEN profile.
The following table uses a large “X” to indicate the best solution, the solution that is recommended and optimal for that use-case. The use of “(x)” is an indication of where there is support in a sub-optimal way; usually this choice is more complex and doesn't fully handle key management. Multiple solutions can be used as well. For example one can use Document Encryption, and also XDM media encryption.
Note that there are other uses of encryption, but they fall outside the scope of Interoperability. For example there is Whole-Hard-Drive-Encryption, but in that case the same software that is encrypting is decrypting and thus there isn't an Interoperability need. Yes there still is a need to use good quality encryption algorithms, but this need is based on staying away from bad encryption algorithms, which is a standards issue but not an interoperability standards issue. Any whole-hard-drive-encryption solution will work just fine as long as it uses quality encryption algorithms. This is different than the need to have an interoperable solution for removable media, which the new DEN profile provides.
Additional Information
The following table comes from the IHE-Document Encryption (DEN) profile. It was created in that supplement as a way to verify the need for the parts of the DEN profile. This table recognizes that IHE-ATNA already covers most of the encryption needs, especially network transactions. However there is a need for encrypting a single Document at a time, and for encrypting XDM removable media. These needs are covered in the DEN profile.
The following table uses a large “X” to indicate the best solution, the solution that is recommended and optimal for that use-case. The use of “(x)” is an indication of where there is support in a sub-optimal way; usually this choice is more complex and doesn't fully handle key management. Multiple solutions can be used as well. For example one can use Document Encryption, and also XDM media encryption.
Use-Case
|
XDM
Email option | |||||
Point-to-point network exchange between machines
|
(x)
|
X
|
(x)
| |||
Network exchange between machines in different trust domains
|
(x)
|
X
|
(x)
| |||
Online exchange of documents where partially trusted intermediaries are necessary
|
X
|
X
| ||||
Exchange of medical documents using person-to-person Email
|
(x)
|
X
| ||||
Media data (DICOM) exchange between healthcare enterprises using physical media
|
(x)
|
(x)
|
X
| |||
Exchange health records using media
|
X
|
X
|
(x)
| |||
Media to media transfer
|
X
|
(x)
| ||||
Patient Carried or
Medical Records File clerk import
|
X
|
X
| ||||
Unanticipated work-flows
|
X
|
(x)
| ||||
Clinical trial
|
X
|
X
| ||||
Multiple recipients of secure document
|
X
|
X
| ||||
Sharing with receivers only partially known a priori, a group or a role
|
X
|
X
|
(x)
| |||
Partial encrypted XDM submission set
|
X
|
Additional Information
- IHE - Privacy and Security Profiles - Document Encryption
- Encryption is like Penicillin
- Critical aspects of Documents vs Messages or Elements
- Using both Document Encryption and Document Signature
- Document Encryption
- Securing RESTful services
- Healthcare use of X.509 and PKI is trust worthy when managed
- SSL is not broken, Browser based PKI is
- Meaningful Use Stage 2 :: SHA-1 vs SHA-2
- Trusting e-Mail
- S/MIME vs TLS -- Two great solutions for different architectures
- Healthcare Provider Discoverability and building Trust
No comments:
Post a Comment