Personal Data Protection - Anonymizing John Doe

I got invited to attend a strategic meeting at a company specializing in medical software (For sake of confidentiality, let's call them Medic ACME).

Medic ACME needed a strategic position on the requirements presented by a customer for very stringent data protection. According to the presented requirements, the customer wants all patients history in a common database, but insists on minimizing the possibility of a leakage of confidential medical histories. The requirements are as follows:

  1. Their general staff (non-MD) must track all procedures and all diagnosis for logistical purposes, but should not see the names, SSNs and addresses of patients corresponding to the diagnosis.
  2. IT personnel should have no access to patient personal data (names, SSNs and addresses of patients) even if they dump the database.
  3. Upon request of an MD, the staff should be able to type in personal data of a patient to retrieve all medical history for the patient
  4. Actual personal patient data must be retained and usable for billing and administration purposes, but only to a very limited number of authorized persons

This set of requirements reminded me of the Payment Card Industry - Data Security Standard (PCI-DSS) requirements for protecting Credit Card data.

Medic ACME proposed to use a reversible encryption of all patient personal data. However, this method requires that the encryption key is common knowledge or at least distributed to a very large number of employees. Also, each access will require decryption of data, and an audit log of each access, thus increasing the load on the database and on the application.

My proposition, which is currently under consideration by Medic ACME was as follows:

  1. Copy all original personal data from the Medical database into a separate Patients database together with a reference number to maintain the connection between all medical interventions for that patient in the original database. All data in this database will be encrypted with an asymmetric key (public key encrypts, private key decrypts)
  2. Create a unique ID string of data from each patient's name, surname and SSN. In the original Medical database, create an SHA1 hash from each ID string, and replace the original personal data with this hash. The Medical database will now contain a nondescript hash and the internal reference number, so there is no personal data in the database to be stolen or read.
  3. Contact a public trusted PKI to issue a strong key pair for encryption. Store the public key in the system, and use it to encrypt all data in the Medical database. Store the private key on several smart cards issued to authorized personnel according to requirements.

This method will permit admission of new patients, with immediate encryption and hashing of their personal data. Also, with this method, it is possible to retrieve patients history by entering it's name, surname and SSN

For billing purposes, a special program needs to be written which will require using the private key for decryption of personal data, in order to correlate them with the medical history.

Talk back and comments are most welcome

No comments:

Designed by Posicionamiento Web