Patient Data Transfer Module

1. Patient Data Transfer Module Frank Buonarota, Alex Hieronymi, John Horgan, Rob Williams, Peter Zafonte April 19th, 2012 Clients: Dominic Duggan Edward Friedman

2. Topics Covered Background OpenMRS Introduction Problem, Solution, and Our Module Requirements Design and Implementation Conclusion

3. The Need for Healthcare Systems in Developing Countries Source: E. A. Friedman. (2009). "Computer-Assisted Medical Diagnosis for Rural Sub-Saharan Africa", IEEE Technology and Society Magazine, Fall 2009 pp18-27 One physician for every 25,000 people. Computer assisted diagnostic systems provide an opportunity to help meet the physician shortage. Opportunities for exploration of new paradigms for rural healthcare delivery in rural Sub-Saharan Africa.

4. What is OpenMRS(Open Medical Record System) Created in 2004 for developing countries Open-source medical record platform Nurses and clinicians can develop custom forms and workflows with no programming knowledge Common platform upon which medical informatics efforts in developing countries can be built In many cases, replaces MS Access databases Funded heavily by Rockefeller Foundation

5. OpenMRS Use in Central Africa Source: http://www.einstein.yu.edu/home/news.asp?id=705 “Our teams hope to contribute to the global understanding of HIV/AIDS treatment, while also helping to improve the care – and lives – of their residents." Dominic Duggan, Ph.D., of Stevens Institute of Technology, is designing the IT component. In clinics around Central Africa, the team will deploy and extend OpenMRS.

6. OpenMRS Use in Rwanda Rwanda is implementing OpenMRS as the country-wide medical records system. Due to political landscape, Rwanda is often the staging ground for initiatives that spread throughout Central Africa. Therefore, whatever they do with OpenMRS will likely be the example that is followed.

7. What’s the Problem? • Patients move among rural clinics • Commonly due to relocation to job or to medical specialist (e.g. HIV/AIDS) • Their medical data needs to move with them • Rwanda’s current solution is a centralized model • Big hospitals sync all patient data from satellite clinics into a large central repository, may soon be country-wide repo • Lacks security, accountability • Doesn’t enforce patient consent • Securely transferring patient data is not addressed by this centralized model

8. The Solution: PDT Module(Patient Data Transfer Module) • Develop an add-on module for OpenMRS which: • Allows secure peer-to-peer transfer of patient data between clinics • Follows BMA healthcare privacy principles (published after learning from problems with UK’s centralized model) • Benefits: • Confidentiality and integrity of patient data • Accountability for clinicians managing patient data • Availability of patient records even as they move among clinics • If proven useful and adopted by Rwanda, would likely be adopted by the rest of Central Africa

9. PDT Module Integration • How to build in this functionality to OpenMRS? • OpenMRS allows runtime loadable modules • Access to API • Written in Java • Can provide enhancements to frontend, backend, or both

10. PDT Module Integration JSP for form creation Spring MVC framework to link forms to the object model Hibernate connects the object model to the database

11. Project Goals With patient consent, securely transfer patient records between clinics Provide an access-control system to prevent unauthorized usage Non-repudiable log and audit trail of patient information movements

12. Project Phases • Phase I • GUI creation • Basic data model and controller functionality • Phase III • Secured communication • Packaging and end-to-end testing • Phase II • Finalize local controller functionality • Send unencrypted data between clinics

13. Security Requirements • Encrypted communication • Confidentiality and Integrity of patient records Tx/Rx • Secure auditing • BMA Principle 5 and 6 • Attribution – deletions remain in DB • Role-based access control and separation • Approval procedure • BMA Principle 4 and 8 • Total adherence to BMA is difficult to achieve

14. Scoped-Out Requirements • Total Adherence to BMA • Impossible within timeframe since we are using a pre-existing system • Would require full security audit of OpenMRS, including changes to core functionality • Communicating over SMS • 2G networks are common in Africa and could be a useful fall-back option for network communication • Secure distributed backup • Resilient/redundant logging

15. Scoped-Out Requirements (cont’d) • Directory Service • Assume DNS or LDAP-like system already in place • Can list all clinics • Provide name resolution • Public Key Infrastructure • Properly maintained CA • Issue certs to pre-validated clinics • Revoke compromised certificates • Although a CA is indeed a central system, the anti-centralization goal is focused on patient data, not all aspects of the system

16. Scoped-Out Requirements (cont’d) • Physically securing OpenMRS servers • Physical problem; important, but out of our control • Breaks BMA Principle 9 • Implement a trusted computing platform • Diverse hardware and OS currently deployed • Left as a problem for OpenMRS in general, not our module • Also breaks BMA Principle 9

17. Module Pre-Requisite: HTTPS(Secure Socket Layer + Certificate Authority Infrastructure) • Communication between clinics must be secure • Confidentiality • Integrity • TLS is used to fulfill this requirement • Client authentication ensures requesting clinic is valid

18. Module Pre-Requisite: HTTPS

19. Module Pre-Requisite: HTTPS

20. Module Pre-Requisite: HTTPS • X.509 Certificates • Created either within our module or separately via OpenSSL • Signed by the “OpenMRS Certificate Authority” • Clinics are each issued a unique certificate • cn=chicago-wrigley.unitedstates.omrs • cn=province-title.country.omrs

21. Module Pre-Requisite: HTTPS Certificate Generation and Signing Procedure(modeled after Verisign’s enrollment procedure) Generate certificate key-pair and CSR CA CA verifies request and signs certificate Install signed certificate key-pair

22. Module Pre-Requisite: OPDS(OpenMRS Patient-Data-Transfer Directory Service) Problems Addressed: • Clinics need to find each other • Hostname or IP • Port number & Instance • Addressing information may change • Dynamic public IPs • Clinics created and closed

23. Module Pre-Requisite: OPDS Possible Solutions: • Conventional DNS • Not flexible enough • LDAP • Overkill + Overhead • Full RDBMS • Unnecessary

24. Module Pre-Requisite: OPDS Our Solution:Apache +Python CGI +SQLite • Simple to setup and use (proof-of-concept) • Extract and store TLS session information • Extract and store HTTP GET/POST parameters • Allow clinic to update its own record • Verified by HTTPS client authentication

25. Module Pre-Requisite: OPDS Connection Process • Clinic starts OpenMRSor loads the PDT module[we assume the proper TLS certificates have been installed] • PDT Module looks up directory server address in local database • PDT Module securely connects to directory server’s “check-in” page • Updates clinic information in directory

26. Module Pre-Requisite: OPDS

27. Module Pre-Requisite: OPDS Connection Process (continued) • PDT Module connects to directory page • Downloads latest directory • Caches to local DB

28. Module Pre-Requisite: OPDS

29. Life of a Request To give a clearer idea of the workflow and system we created, let us walk through the life cycle of a basic request from creation to completion.

30. 1. Request Creation • Only privileged users can create requests • Patient consent is enforced by the physical consent form

31. 2. Request Approval • All requests must be approved by a local user other than the one who created it. • Ensures two local users have verified the consent form • Prevents one corrupt user from requesting patient data • Patient Consent is enforced by separation of roles via RBAC and application logic.

32. 3. Sent to Remote Clinic Request Requesting Clinic Remote/Original Clinic SSL Encrypted Connection The request, now approved locally, is sent to the appropriate remote clinic. Patient privacy is enforced in this step by SSL.

33. 4. Approved Remotely • RBAC ensures only certain users can do the approving • Patient consent is enforced in this step by: • Verification of the consent form • Verbal communication with patient

34. 5. Data Returned to Requesting Clinic Patient Data Request Requesting Clinic Remote/Original Clinic SSL Encrypted Connection The request is augmented with the Patient data records themselves, and returned to the requesting clinic. Patient privacy is enforced in this step by SSL.

35. 6. Request Complete Upon receipt of the request, the requesting clinic de-serializes the Patient records and saves to the local DB. This completes the transfer of data.

36. Future Work • SMS patient alerting • Inform of request progress (BMA Principle 4) • Direct patient verification • Patient Authentication via technological means, e.g. biometrics • Enforcing roles across clinics, and read/write access for specific patient records • Secure system backup, especially of request history and audit logs

37. Closing Remarks OpenMRS is already widely used around the world. This module shows that patient privacy and consent can be maintained within OpenMRS. If adopted in Rwanda, and then throughout Central Africa, it would revolutionize healthcare privacy.

38. Any Questions?