Data Model
Introduction
At the heart of any enterprise electronic medical record system lies a robust, explicit representation of how care information is stored. The structure of this data model dictates the scalability and flexibility of a system. The OpenMRS collaborative therefore invests continuous effort into shaping the OpenMRS data model using knowledge and experience gleaned from practical experiences from the Regenstrief Institute, Partners in Health, and all of our developmental partners around the world. The core of this data model addresses the who, what, when, where, and how of medical encounters. You may view a current image of the data model used in OpenMRS 1.9.0. Data models of previous releases are given below. This model is divided into ten basic domains.
There is a browsable & searchable view of several OpenMRS data models available at http://om.rs/dm
Domains
Concept: Concepts are defined and used to support strongly coded data throughout the system
Encounter: Contains the meta-data regarding health care providers interventions with a patient.
Visits: ___
Location: _____
Form: Essentially, the user interface description for the various components.
Observation: This is where the actual health care information is stored. There are many observations per Encounter.
Conditions: ________
Diagnosis: ____
Order: Things/actions that have been requested to occur.
Patient: Basic information about patients in this system.
User: Basic information about the people that use this system.
Person: Basic information about person in the system.
Groups/Workflow: Workflows and Cohort data.
See also OpenMRS Implementer's Guide - Data Information Model.
Data Model Frequently Asked Questions (FAQ)
What is the difference between retire and void columns?
Metadata within OpenMRS (information used to configure & support data entry such as concepts, locations, encounter types, etc.) can be marked as retired when it should no longer be used. Data (actually clinical data about patients) within OpenMRS is marked as voided when it has been deleted or otherwise invalidated by a user. Tables with retire attributes contain metadata; tables with void attributes contain data.
What are the conventions for changing the OpenMRS data model definition?
Changes to the model are discovered during development and are discussed within Design Forums and/or on OpenMRS Talk. Changes are typically applied via Liquibase.
We really like your data model image. How does OpenMRS make it?
Historically, we've used MySQL Workbench to make images; however, it is a laborious task to make the model legible.
Data Model Versions
The data model used in each of the OpenMRS releases can be viewed from the following attachments.
OpenMRS 2.x
See: Platform Releases
Note: As a community, our backwards commpatibility/support policy is to support 2 versions back.
For example, as of July 2025, the last version release was Platform 2.7. This means that we actively support back to Platform v2.5, but not past that.
Platform versions 1.10 and 2.2 were particularly important releases as they both included updates to the data model itself. This is part of the reason we no longer actively support these older versions.
OpenMRS 1.9.0
Download a MySQL Workbench version (requires MySQL Workbench)
OpenMRS 1.8.0
Download a MySQL Workbench version (requires MySQL Workbench)
OpenMRS 1.7.0
Download a MySQL Workbench version (requires MySQL Workbench)
OpenMRS 1.6.0
Download a MySQL Workbench version (requires MySQL Workbench)
Many tables in the data model have columns like created_by, retired_by, voided_by, etc. which have foreign key relationships with user.user_id. These links are not shown in the diagrams for the sake of clarity.