Patient Data Transfer Module

Overview

The Patient Data Transfer Module was developed by a small group of undergraduates at Stevens Institute of Technology in Hoboken, NJ during the 2011-2012 school year. The completed module, as of May 2012, is a prototype proof-of-concept that shows that peer-to-peer transfer of patient data between OpenMRS instances is possible even while maintaining patient consent and privacy. The module enables the following six-step process to transfer data between two clinics that have the module installed (an important assumption to note is that both clinics must have the exact same Concept Dictionary, meaning that even on the database level the rows have the same primary keys):

1. A requester creates a new "Patient Data Transfer Request" using the web interface of the module. This involves filling out a form with information such as the patient's name, birth date, and gender -- all used later to look up the patient data on the remote end. The user also chooses the "Original Clinic", which is where the patient data will be originating from. This list of clinics is populated by a directory service -- our module includes one implementation of a DirectoryService, but anyone using the module will likely have to implement their own to interface with their own directory system (e.g. LDAP, Active Directory). The understanding here is that in addition to filling out this web form, the requester will also have the patient sign a physical consent form. If the clinic is able, they should scan in this document and upload it as part of the web form as well. In this step, patient consent is enforced through this consent form.
2. After the request is created, it must be approved by a second local user of the OpenMRS system. This "signer" will navigate to the "Outgoing Requests" page within the module and verify all the patient information. The idea here is that this user is responsible for double-checking that the consent form was properly filled out and that the patient was consulted. This sign-off is meant to further enforce patient consent, to prevent one corrupt user from bypassing the paperwork.
3. After the request is locally approved, it is sent to the remote clinic via HTTPS. TLS encryption is used here to ensure the patient data request is encrypted. Client and server certificates are also used to provide bi-directional authentication of the clinics communicating (the requesting clinic and original/remote clinic).
4. On the other end, the request becomes an "Incoming Request". A user on that end will be able to see all the information in the request, including the patient consent form if it was uploaded. The idea here is that this remote user will have had verbal communication with the patient to ensure their consent. For example, if a patient knows they will be moving from Clinic A to Clinic B, they will inform someone at Clinic A that Clinic B will soon be requesting their information. The user approving the incoming request will have the responsibility of ensuring that this took place and that the patient really wants their information released to the requesting clinic.
5. After the request is remotely approved, the data of the patient who is referenced in the request is retrieved via the traditional OpenMRS API. Currently only the Patient along with their addresses, encounters, observations, allergies, and problems are included in this package of data. This data is packaged up with the request, which is then returned to the requesting clinic. Again, HTTPS is used with TLS and client-authentication to ensure patient data privacy.
6. On the receiving end, the module unpacks the patient data and persists in the local database. At this point, the request is complete and the patient's data is accessible to the requesting clinic.

Further Information

Please refer to this external document, which contains the requirements for the module which are met by the prototype, in addition to the Installation and User's Manual.