Data Model & Information Model
- Neha Verma
Since the Intelehealth platform primarily uses OpenMRS as a backend database, its important to understand the data model and information model. In this section we will learn about how information is stored in OpenMRS, the database schema and key tables that are used by the Intelehealth platform. An easily searchable version of the data model can be found here. In addition to this page, we also recommend you read this section from the OpenMRS Implementer guide that explains the same concepts in further detail. This page assumes a base level knowledge of relational databases.
Person
Anybody with a record within the system is a person. A person may be a patient, a user of the system like a receptionist or a doctor. The following tables store data about persons like the person’s name, address, date of birth, gender, etc.
If there are additional pieces of information that need to be captured about persons that are not included in the above tables, we can define a person_attribute_type (for example educational status or race). The values of the attribute for each person is stored in the person_attribute table.
Patient
A Patient is a child of the Person class. All entries within the person table who are patients are mapped in the patient table with the person_id.
The person_id and patient_id are always the same. These are the primary keys for the person table and patient table respectively.
A patient may have multiple identifiers, the default identifier in OpenMRS is the OpenMRS ID.
The OpenMRS Identifier is an automatically generated identifier by the Idgen Module. It is a 6 digit alphanumeric ID, the 6th digit is a checksum digit (eg: 1004D-3). From OpenMRS Platform version 2.1.4 the identifier is 7 digits where the 7th is the checksum digit. This wiki post provides more information about administering patient identifiers.
Users, Providers
A user is anyone with a login into the system who directly works with the system. Users may perform medical functions that involve directly providing patient care such as a doctor, or nurse. These are called as Providers. Other users who are not providers may be performing ancillary functions like a receptionist or registration clerk. A User who has complete access to the system is an administrative super user.
Similar to person_attributes, the Providers class can also be extended by using the provider_attribute_type and provider_attribute tables that can be used to describe more information about a provider. Some examples of provider_attributes used in the Intelehealth platform are storing a provider’s signature, their license number.
Roles, Privileges
Based on the actions a user needs to perform, they can be granted access to or restricted access from other sections. For example, a receptionist should not be able to order medications for a patient. These are defined in the following tables. The role table defines various roles such as a doctor, nurse. The privilege table defines privileges such as ordering medications, deleting patients, adding users. The role_privilege tables map privileges to roles. Roles can also inherit from other roles (mapped in the role_role table). The user_role table maps users to roles.
Location
Locations in OpenMRS are typically used to define departments within the hospital, such as the inpatient department, outpatient department, pharmacy, ICU. However in the Intelehealth platform, the locations refer to various primary health care clinics that report to the same central EHR systems. Users are tagged to locations. On the Android application, a user can only see all the patients from the particular location they have logged into. All users at a location can see all patients at that location. Similar to person_attribute and provider_attributes, the location_attribute table extends information about the location.
Visits
Patients who come to the clinics have visits. Every time a patient comes to the clinic, a new visit is created in the system. Visits may be of different types such as a screening visit, or a follow up visit, or an NCD Consultation, or an ANC visit.
Encounters
During the visit, patients may have different “encounters” with different providers. For example, after they are registered, a health worker may first take their vitals, then a nurse may do a preliminary assessment, then a doctor could put in a visit note. Each of these different steps in the workflow of a patient visit is called an encounter.
Observations
The most granular unit of information is an observation. During an encounter, various data is collected about the patient such as their blood pressure, height, weight, presenting symptoms. Each of these are individual observations stored in the obs table.
The obs table therefore contains the bulk of patient data. In order to describe observations and provide a consistent definition, OpenMRS uses a concept dictionary.
Concepts
This wiki section describes the Concept dictionary in detail. We recommend reading this section in detail since the concept dictionary is an important core of the platform.
In order to make an implementation easier, we provide a Data Dictionary with each new release of the Intelehealth platform that contains basic data needed in the above mentioned tables (such as encounter types, person_attributes and all the concept tables.)
Metadata
Metadata means data about data. For each data entry in the OpenMRS tables there is a uuid (encounter_uuid, visit_uuid, obs_uuid, person_uuid), this uuid is used in the REST API to request for resources. Data can be voided or unvoided, a better practice than deleting data. Each entry also contains metadata like the creator, date_created, date_updated, date_started, voided_by, date_voided, void_reason.
This is one of the most important sections of the wiki to understand since the data and information model drive the platform’s flexibility.