Data protection

What about the legal and ethical issues concerning patient data? How will the data be protected and used internationally?

METEOR is password protected and patient identifying information is encrypted and complies with data protection legislation. Ethical and legal issues have been considered and strategies implemented.

Encryption

Why is it necessary to encrypt personal data from local sites?

Security guidelines dictate that no person identifying data about patients can be stored on the central hosted application.  All person identifying data needs to be encrypted before it is stored on the central site.

All person identifying data needs to be encrypted before it leaves a local system(e.g. a hospital) as security guidelines forbid the transportation of unencrypted data outside the local site. 

The encryption / decryption process for personal data must therefore be carried out at local system level, that is - in javascript in the browser.

The basic encryption model

The class AppControl owns an implementation of iEncrypter, which provides a simple interface for encryption and decryption of data. Data has to be encrypted only in the central installation, but AppControl is used in all kinds of installations of the Meteor Application. For simplicity AppControl can associate one of two implementations of the iEncrypter depending on the installation. A nonEncrypter is used for installations where encryption is not necessary, and an Encrypter is used when encryption is nessasary. As the name suggests,the NonEncrypter does nothing; it just leaves the data as it is, while the Encrypter actually encrypts or decrypts data according to the algorithms explained below. The AppControl provides the rest of the application with functionality to encrypt and decrypt data, by implementing the encryption operations specified in the interface HasUserSession.

Every functional unit needing to present or store personal identifying data about patients uses operations provided by the class AppControl to encrypt or decrypt the data when necessary

The basic model for encryption utilizes The Rijndael encryption algorithm which is a standard for encryption together with a 256 bit Strong Encryption Key.

To encrypt personal information the system uses the 256 bit key in conjunction with the Rijndael encryption algorithm on the text that has been entered via the User Interface and the resultant encrypted data is passed to the database for storage.

When a user at a local site wishes to reference data that has been encrypted at their site via the user interface, the system reverses the process and the text is decrypted through the use of Rijndael and the 256 bit password.

The detailed site encryption process

The encryption process utilizes a 256 bit Strong Encryption Key; however, there are issues around the use of this key.  It is impossible for users to remember this key but there are also security risks around users having knowledge of the Strong Encryption Key (referred to as SEK).

It was therefore deemed necessary to have a Site Encryption Password (referred to as SEP) for each site, which can be remembered by users. The Strong Encryption key should be protected by this password, and reconstructed from this.

Every site is granted a unique Strong Encryption Password. 

On first login at a site the administrator enters a SEP

  • The application then randomly generates a SEK
  • It is not possible to store the SEK in the database as there is a risk that it could be accessed by anyone with access to this database.  For this reason an encrypted version is stored in the database, The rijndaelEncrypt algorithm is used for this purpose, and the the SEP is used as the symmetric key
  • For validating purposes the application also stores an encrypted version of the SEP in the database using SHA1 Digest (password). This enables a validation of the SEP when a user tries to login to the system.
  • Therefore an rijndaelEncrypted version of the SEK (referred to as encSEK) and a SHA1Digest encrypted version of SEP (referred to as encSEP) is stored in the database

The next time a user logs in to the system

  • The user enters the SEP together with a normal username and password get access to the system
  • The application gets the encSEP from the database and encrypts the entered SEP
  • The application now validates that the SHA1 Digest (password) of the entered SEP is equal to the encSEP stored in the database
  • If they are equal this means that the user entered the correct SEP and once this has been confirmed the system can use the entered SEP to recreate the SEK using rijndaelDecrypt on the stored encSEK. This restored SEK can be used to encrypt and decrypt data
  • If this is not the case the system will error and the user will not be able to proceed.  The user will be denied access to the application.
  • Once  the user is granted access to the system the application uses the SEK in conjunction with the Rijndael encryption algorithm to encrypt person identifying data entered via the user interface at the local site so that it can stored in the database

The encryption algorithm involves, in addition to the rijndaelEncrypt step, 3 additional steps:

  • Step 1: Different implementations of UTF exist, and to ensure that UTF texts can be restored in any implementation, UTF is always transformed to an independent format before encryption.
  • Step 2: The Rijindael algorithm used does not have the ability to handle strings which contain a zero byte as part of the string. Therefore the bytes are transformed using a base64 algorithm before rijndael is used. This ensures that no zero bytes is is present.
  • Step 3: Th Rijndael encryption.Step 4: The output of Rijndael encryption can contain any combination of bytes, and to make sure that the encrypted data can be transported to/from and stored in the database without being manipulated a process to transform Bytes to a Hex string is finally used. 

The decryption algorithm is the inverse operation of the 4 step encryption algoritm.

 

 
   
 
Laatst bijgewerkt op: 24-11-2011 15:53:46