OpenMRS – A Community Developed, Open Source Medical Record System for Developing Countries

1. Paul Biondich, MD MS Burke Mamlin, MD …and the OpenMRS collaborative OpenMRS – A Community Developed, Open Source Medical Record System for Developing Countries

2. Overview • Our start • What OpenMRS is • Our progress to date • Where we hope to go • Guiding principles

3. Introduction • Regenstrief Institute / IU – 30+ year of clinical informatics development in US, building large scale clinical information systems • February 2004: Asked to be “consultants”: give advice about how pre-existing HIV data repository (Access-based) could be extended / given more functionality -> supposed one week trip to Eldoret, Kenya

7. 95% 40,000,000 5%

8. February, 2004 • AMPATH: example of successful HIV comprehensive care system in developing country… huge information needs • Significant growth ahead: rapid ramp up to 20+ geographically disparate sites • Immediate Observations: • No “quick fix” or “retro-fit” of old system • We were “hooked” and became very engaged after visiting Eldoret

9. Silos

10. Existing Efforts • Multiple “silos” of disparate efforts • Focus on user interface • Minimal opportunity for collaboration or interface • Non-coded, unstructured data • Lack of standards • Aren’t directly helping clinicians

11. Design Dogma • Follow the lead of the 30+ year experience of our mentors • Graceful evolution towards enterprise-worthy systems • We must enforce deep structure in the database to improve data integrity / quality • Use of informatics standards throughout

12. OpenMRS - API • Three code layers • Database Layer • Service Layer • Presentation Layer • Hibernate, Spring, AJAX

13. OpenMRS – Data Model • In continuous development for 3+ years • It simultaneously defines and directly stores clinical data • Robustly defined concept vocabulary • Form hierarchies • Versioning system, public debate/input • Data Repository vs. “Business” tables

14. OpenMRS - Standards • HL7: Method of bulk data input/output and reporting to national centers • Local vocabulary can and will be mapped to ICD10, LOINC, and SNOMED where applicable • Arden Syntax: logical constructs • Liberal use of open source programming paradigms/standards

15. AMPATH Medical Record System (AMRS)

16. Model-view-controller based data entry

19. Concept Statistics

20. Cohort Builder

21. Building Enterprise EMRs • Difficult (if not impossible) to fully sustain internally within our environment • Grant/contract money for development limited • Difficult local hiring climate • Inconsistent with priority of academic culture • Human resource needs only scale over time (everyone wants a new feature)

22. Open Source Communities – A Solution? • Open Source • Instruction code made freely available to public • Nurture environment that encourages outside developers to work with your code • Open source licensing ensures that those who add to your core code must also give it away • Community • Give everyone stake in decision making process • Make it fun/easy to participate

23. Open Source License in Place • License formalized • Essentially Mozilla Public License 1.1 with extra clause related to medical liability • Main ideas: • Core vs. Modules: all core will adhere to base license, modules are encouraged to do so • Core managed by OpenMRS Management Group (Paul, Burke, Hamish, Chris)

24. Types of Participants • Large HIV programs throughout the world • Partners-in-Health • Medical Research Council • Millennium Village Project • Family AIDS Care and Services (FACES) • Clinton Foundation • Programmers with philanthropic leanings • CS students • Professionals with spare cycles • Other large FOSS communities

25. What this community “costs” us • Time • Initial education on our design • Building web portal / information content • Constant fielding of questions • Guiding the design towards the right direction • Slower progress on our own work

28. What this community gives us • Development scale • Cohort builder example • Fresh sets of eyes to strengthen design • Daniel Kawiya from Uganda • Implementation “cushion” • Chris Seebregts and implementation group • Sponsor “gravitational pull”

30. Where we want to go… • Evolution of core development group into mentorship “team” – scaling development, educate in medical informatics, FOSS • Continue to foster OpenMRS Implementation Group (Chris) • Fundamental additions to OpenMRS (team) • “deep” decision support functionality • completion of research query tools / reports • encourage tools that facilitate clinical care • synchronization between OpenMRS instantiations

32. OpenMRS Principles • Serve care providers/patients first, reuse data • Develop based on active implementations • Be transparent • Reduce redundancy • Collaborate broadly • Apprenticeship – Learning by doing

33. It’s amazing how profitable it can be to give something away.

34. Regenstrief Institute, Inc. paul@openmrs.org