OpenMRS is both software and a community. This page will provide an introduction to the OpenMRS software: our electronic medical record and the platform supporting it. If you are interested in learning more about the OpenMRS community, you may try starting here.
OpenMRS is a Java-based, web-based electronic medical record. We started from a simple (at least it used to be simple) data model, wrapped that into an API, and then built a web-based application that uses the API. The OpenMRS API works like a "black box," hiding the complexities of the data model beneath it and ensuring that applications and modules using the API work with a similar set of business rules for managing the electronic medical record system data. See our technical overview page for more details.
Initally, OpenMRS was built to support HIV care in a couple of settings (in Kenya and Rwanda); however, from the very beginning we knew that it would be artificial to create a vertical HIV-specific solution, since patients with HIV also have other medical problems. We also knew that the same programs trying to treat HIV were simultaneously confronting malaria, tuberculosis, maternal health, primary care needs, and many other issues. Therefore, we designed OpenMRS to be a generic medical record system that can support the care of patients, gathering observations, encounters, notes, and other data from the healthcare system and rendering those in summaries, reports, and data views that would improve the effectiveness of the people using the system.
At the heart of OpenMRS is a concept dictionary. This dictionary, much like a typical dictionary, defines all of the unique concepts (both questions and answers) used throughout the system. Using combinations of questions and answers, we can define observations (observable data) as well as forms that gather multiple observations within a single encounter. Our first systems were built by taking very carefully considered paper forms and turning them into electronic forms by cataloging all of the concepts on the forms (questions and answers) and then organizing these into an electronic schema (hierarchy) that represented all the data on the paper forms. By doing this, we could easily capture all of the data from the paper forms into the computer system as discrete, coded data that the computer could understand and then begin using those data to improve patient care. Over time, we are seeing more cases where data are being directly entered into the system through web-based forms or mobile solutions.
OpenMRS is constructed to support modules. Using modules, implementations are able to modify the behavior of the system to meet their local needs without everyone having to agree on a single approach (i.e., allowing us to avoid the failure-prone "one hammer to fit all nails" approach). You can see the list of available modules in our module repository. Modules have full access to the system, so they can add tables in the database, alter behavior of the API, and/or add or change web pages in the web application as needed to meet their needs.
Feel free to browse our wiki and don't hesitate to let us know where things can be improved. More importantly, consider rolling up your sleeves and help us improve. Join a mailing list or hop into IRC or discover our Q&A site and share your questions/concerns. If you're a developer, check out our New Developers' Guide. If you are interested in implementing OpenMRS, check out our Implementors' Guide and How to get support. We're all in this together!