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:

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 

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.