Case Study - Medical Records Transcription

The following case study documents solving security requirements for medical records transcription.  It describes the initial architecture that was developed to solve it, identifies problems that were not understood by the users when the problem was initially specified and how the final result was developed.


The business problem

Medical notes, associated records, including scans and test results needed to be sent from three different hospitals to a single organization in another country for transcription.  When transcription has finished, the transcriptions are returned and the original records must be securely stored or permanently deleted in the other country.

The information is transferred by storing it on a publicly accessible website over the Internet so that each side can upload or download information as soon as it becomes available.

Observance of practices consistent with HIPAA requirements must be met by the solution.

Other constraints that had to be met - An existing process is already in place taking the records and uploading them to the website.  That is in place for all the parties using the service.  All the groups use different products for uploading/downloading and for creating the records that are sent for transcription although a common system is used for creating the transcriptions.


The initial solution

ArticSoft FileAssurity is implemented across all the sites.  On each hospital site an administrator is tasked with setting up the keystores for the individual users and e-mailing the keystore once created and a secret password separately.  FileAssurity is pushed onto the users desktops using Citrix and is installed through a script.  FileAssurity automatically recognizes the user’s keystore which has been shipped separately.

Nothing has to be activated until the user receives their keystore through the mail and the password.  A script transfers the keystore to the user’s personal location in the Windows system.  FileAssurity is loaded by Citrix.  As soon as this happens the user makes only the following change to their procedure for sending notes to the transcription service.  They keep FileAssurity running in the background on their PC.

When the user has assembled the information ready for the transcription service (this may be voice dictation or files from other sources)  they look in the FileAssurity view.  They select the files to be protected, check that they are digitally signing them personally and that they are protected for the transcription service.  If there are a group of files that should travel together they check the archive box so that those are grouped together for convenience in transmission.  Where archives are selected they choose a name for the archive file.

When the files are ready the user uploads them to the web site.  (In each case a different upload utility is used).  Because the files are already fully encrypted no extra protection is needed such as SSL or VPN. The web site upload area is password protected to prevent casual access.

If the user wishes something to be sent urgently they send it by e-mail by right clicking on the protected file or archive and sending it directly to the transcription service.

Once it is on the web site the transcription service are able to access the site and download the protected files.  Only when they are actually on the desktops of the people who are going to do the transcription work are they unprotected.  As that is done the transcription agent can see which person the information is from and therefore who it must go back to.  This is because not only do they see the user name, but they can check the authorized e-mail address – not just where they received it from (which could be forged anyway).

Since the transcription service have all the keys (identities) that are authorized to send material to they can never make a mistake about receiving (or sending) information incorrectly.

Once transcription has taken place the files are protected for the authorized recipient (taken from the protection of the original files and not from any other source) and uploaded or sent by e-mail as required. Since the transcription service digitally signs their work (one click) the recipient is certain who the work is from and knows that nothing can have been disclosed to any other party.


What went wrong?

Having a single key for individuals at the hospitals and at the transcription service actually made it more difficult to operate the security part of the system.  This was because at each end it was not a single person who would need to be able to access the information being transferred, but one of a group.

Normal PKI is not set up for groups but just for individuals and trying to organize collections of keys so that you can address groups is difficult to set up both for administrators and users.  However, the ArticSoft system is more flexible.  ArticSoft is able to use multiple key sets, not just those of a single individual.


How was the problem solved?

ArticSoft provided a series of special keys for the hospitals and the people doing the transcription work to allow for specific groups to exist.  This was done by issuing the keys to specific members of each group.  They imported the group keys to their keystores.  As a result they could then read any information intended for that group.  Individuals in the hospital could then decide when information should be transcribed for a group, and if so, which group, or if it should remain personal.  

Similarly the transcription service would always know who the recipient should be.  They did not need to know if that was an individual or a group.  From their perspective it did not matter.  Nor did the fact that the group could exist across hospitals when necessary, or that the transcription data could be downloaded to several locations.  Their legal liability was controlled because they knew that no-one who was not authorized could ever read the work.  The legal liability of the hospitals was still fine because they could be certain who could access the information and that they were authorized.  


Lessons learned

PKI technologies are still immature and need more thoughtful development.  ArticSoft FileAssurity proved to be flexible enough to cope with a very different model from classical PKI.  As a result the organizations are able to operate an very secure system that prevents any information from being viewed by anyone that is not authorized.