Data Storage & Transfer Security Practices

This article covers a high-level overview of MPOG’s database security practices. 

Local Instance of MPOG Database

In order to allow contributing institutions to best comply with their internal IT security policies, MPOG does not specify any technical security requirements regarding a local MPOG database instance. Nonetheless it is strongly recommended that the following guidelines are adhered to.

Physical Security

In order to join MPOG an institution must acquire a local dedicated database server that is not shared by other departments or initiatives. Physical access to this server should be restricted to IT staff only and should be maintained within a secure datacenter or server room. If the server is acquired through institutional IT services this should not be an issue.

Data Security

Several forms of PHI are stored in the MPOG database, including patient name, date of birth, and social security numbers. As such database access should be limited to individuals with approved research projects. A number of database roles are included with the MPOG install that make it easier to constrain user rights.

  • MPOG Researcher – This role’s permissions is chiefly comprised of read-only access to EMR data and some stored procedure execution.
  • MPOG Importer – This role grants rights for inserting, updating, and deleting rows in most tables as well as the ability to use configuration applications in the application suite.
  • MPOG Exporter – Individuals must be a member of this role to use any of the export utilities within the application suite. They will be responsible for sending data outside your institution. 

It is recommended that Windows Authentication is used to connect to the database. SQL Authentication should be avoided if at all possible.

Please note that data stored in the MPOG database is not encrypted by default. This follows from the fact that most records are stored or transmitted in plain-text within the hospital network. However, institutions can choose to use the Transparent Data Encryption (TDE) feature of SQL Server to protect at-rest data. Note that this feature requires Enterprise 2012 or later.

Finally the server should be contained within institutional firewalls. This is necessary to prevent protected patient data from being exposed to external networks.

In-Transit

There are two main requirements for submitting to the MPOG central repository. They are as follows:

Patient Records

The majority of the contribution to MPOG is the subset of the patient record (e.g. medications, vital signs, labs, etc.). It is important to note that transmitted data does not include patient identifier fields. Additionally, all free-text fields are required to be scrubbed for PHI prior to transmission.

Records are submitted to MPOG’s central repository using the transfer utility included in the application suite. This utility sends data over HTTPS, encrypting the communication with TLS 1.0.

Blinded Record Index

The Blinded Record Index (BRI) is a process through which patients can be matched to each other without directly using protected identifiers. This ability to match patients from different data sources is useful for (1) identifying records that belong to the same patient and (2) finding dates of death.

While described in more detail elsewhere, the process of adding patients to the BRI is summarized in the following steps:

  1. Patient identifiers (e.g. name, date of birth, SSN) are hashed many times using a local-side key with the hospital firewall.
  2. These hashes are encrypted and sent over HTTP to a central service.  Messages are authenticated using both client and server certificates. 
  3. The central service hashes them many more times using a central-side key.
  4. These hashes are then stored in a database at University of Michigan with the associated MPOG patient identifier.

After this process, it is computationally infeasible to transform the hashed data back into the original patient identifiers. Doing so by brute force would take a period of time measured in millions of years. In addition to this technical hurtle, data use agreements stipulate that no party including MPOG itself is to attempt re-identifying patients.

Central Instance of MPOG Database

Physical Security

MPOG’s central repository is kept within a high-security data center owned by the University of Michigan. Building access is strictly controlled and servers are maintained by University of Michigan IT staff.

Data Security

Data stored in the central repository is considered a “limited dataset” which means that there is a minimal but non-zero risk regarding PHI. As mentioned earlier, patient identifier fields are not included and free-text is scrubbed for PHI prior to being received by MPOG. However it is not considered de-identified as date of service is included.

Aside from missing PHI fields, the same security practices for a local instance of the database apply to the central one. It should be noted that MPOG does not encrypt the central repository as it does not contain the PHI fields and performance is critical for large-scale research queries.