eConsent with End-to-End Encryption
End-to-end encryption is the most secure and efficient method for storing identifying patient information.
Fascinating Research
Today is a major day for the entire OpenEDC team. We are releasing full support for on-site and decentralized eConsents and, as the first EDC system, end-to-end encryption for personally identifiable information.
The Problem with Identifying Patient Information
Storing identifying patient information along with clinical data is a significant issue in research and clinical trials. On one hand, personal data such as names and birthdates are necessary to link adverse events and informed consents to a natural person. On the other hand, this contradicts data minimization according to GDPR and poses the risk of sensitive health data along with identifying information falling into the wrong hands.
For this reason, pseudonymization is often used, as recommended by the GDPR and provided by OpenEDC as a standard. In this approach, instead of names, only an alphanumeric identifier for each subject is stored in the computerized system. In another system or sometimes even on paper, a list that maps these identifiers to the respective names of individuals is maintained.
While this approach allows for strict data separation, it also comes with several downsides. It requires two independent organizations to operate two independent systems, so that one potentially vulnerable organization does not have access to all data. Two systems result in significantly higher costs for configuration and maintenance and a more complicated as well as error-prone operation for all users in a study. Moreover, it often means to have another organization storing personal information in plain text.
Simpler and Safer: End-to-End Encryption
With end-to-end encryption, data is encrypted on a users device before being sent to a central server. The data remains in this state until retrieved by another user from the server and then decrypted locally with an appropriate key. Only a few selected users have keys, and never the software or infrastructure operators. This means that even we as a system provider have no technical means to decrypt the data. The keys are solely held by the users.
Biometrics ensure the highest possible security.
This principle provides a highly secure and user-friendly way to store identifying patient information. These can only be decrypted by a small number of selected individuals. Unauthorized decryption is technically infeasible – a feature that an external pseudonymization list generally does not offer. At the same time, all users still only need to operate one system. If encrypted data needs to be read or entered, usually a fingerprint is sufficient.
Even Safer with Passkeys and Biometrics
Although end-to-end encryption is the most secure type of encryption, its security depends on the security of the selected key. If users choose an easy-to-guess key, the data can also be relatively easily decrypted. For this reason, OpenEDC requires the use of Passkeys for key creation – optionally with biometrics. These are also recommended by the Federal Office for Information Security (BSI).
Encryption in eConsents
End-to-end encryption also significantly simplifies informed consents or eConsents. Since it must be clear at a later point who gave consent to process medical data, identifying data usually needs to be stored. If this is done encrypted, it can be ensured that only a few selected individuals can read the data. The following video shows an exemplary process.
Exemplary encryption and decryption of an identifying name and signature.
Printing PDF/A with Encryption
A particular challenge is printing and archiving consent documents when using end-to-end encryption. Typically, PDF/A documents are server-side generated and then offered to a user for download. With true end-to-end encryption, however, the server has no way of decrypting the data. Therefore, OpenEDC offers a purely client-side method for creating PDF/A files – without any decrypted data ever leaving the computer.
Note: Browser support
For the implementation of this feature, we use the new PRF extension of the Passkeys standard. Currently, this is supported on Windows by Chrome and Edge since version 116 (late 2023). With Safari, support is currently only available in the beta of macOS Sequoia (final release expected in fall 2024).
If you want to learn more about the implementation or implications of these features, please feel free to email us.