A pubmed search for electronic sign out (or hand off) yields 42 results. I wrote recently about secure patient health information and have been thinking more about what it takes to have a secure, physician-to-physician electronic sign out system. To begin, we’ll assume two things: 1) no integration with existing systems. This is not a small assumption but I would like to work on a high level and ideally a hand off could be generated by proprietary EMR X and submitted in a secure way via the following system. 2) The system and interface should be as simple as possible to achieve the minimum required security. The definition of minimum security when it comes to signing out patient information is murky at best. Here is my solution in infographic form.
Secure Electronic Sign Out
Immediately, you probably assume I have broken assumption #2 from above. The above diagram describes a system of accessing (and sharing) encrypted data through 3 layers of encryption. Three layers are not more beneficial from a data security standpoint but the process of changing over patients assumes multiple providers accessing the data, changing passwords, etc. Also, we should address problems like session hijacking, database hacking, and password compromise.
The Need For a Complex Electronic Sign Out System
To the provider, the system could be implementing very simply and the only thing that might be noticeable would be needing to type your password again for any data entry or edit. For those of us practicing in the era of computerized physician order entry (CPOE), this is common place.
Primary data key – this is a random key that is generated for each unique data field to be encrypted. This key is used to encrypt the data itself. If the key is compromised only one unit of data are revealed. An encrypted version is stored in the database.
Secondary data key – this is a random key that is generated for each method of accessing each unit of encrypted data. Since each primary data key will be accessed by two ways per user, the total number of database entries is at least data units x 2. If the key is compromised only one unit of data are revealed. An encrypted version is stored in the database.
Master user key – this is a random key that is generated once on creation of a user account and serves to be the initial key by which a secondary data key is encrypted. If the key is compromised all the user’s data are revealed. An encrypted version is stored in the database.
Salted password hash – a salted password hash is used as the key to encrypted the master user key. In the event that a user needs to change his or her password, the only object that requires updating is the encrypted signature of the master key. This eliminates any lag as a result of changing passwords.
Session key – this is not mandatory, but may reduce exposure to session hijacking. Instead of placing the master key in the session to decrypt data, a session-specific key is created (along with a new set of secondary data keys). At conclusion of the session or after an expiratory period, the session key and secondary data keys can be removed.
Temp data key – in order to share information, a secondary data key can be cloned and encrypted using a temporary data key. This key can then be transmitted to the second user. Upon accessing the data, the second user will automatically create a secondary data key encrypted with their own mater key. At this point, two users can access hand off (or sign out) data which is encrypted with a single, unknown, primary data key.
It is probably not ideal yet, but this process is superior to sending changeover via email or simply using whole disk encryption.