OpenMRS Academy

LEVEL 1: OpenMRS Fundamentals

Module 4: OpenMRS Technical Overview

Learning objectives

• Explain key technical terms used in OpenMRS
• Describe the basic information structure of the OpenMRS data model
• Explain the structure and concept behind the OpenMRS concept dictionary.

​

Topics to be covered

1. Overview

Overview

• What is OpenMRS?
• Java-based, web-based electronic medical record. In the backend of this web based application is a robust data model, an API and concept dictionary which are fundamental components of the application.
• Key terms to understand here are:
• Data model: abstract model that organizes elements of data and standardizes how they relate to one another and to the properties of real-world entities.
• Backend: website or software program that users do not see.
• Application Programming Interface (API): software intermediary that allows two applications to talk to each other
• User Interface (UI): is the set of controls and sensory channels through which a user can interact with software.
• Concept dictionary: list of all the medical and program-related terms.

​

​

2. OpenMRS Data Model

OpenMRS Data Model

​

​

​

​

​

​

• 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.

​

OpenMRS Version 1.11 Data Schema: https://docs.openmrs.org/datamodel/#

​

​

​

OpenMRS Data Model: Topics

​

​

​

​

​

​

​

• Data vs Metadata
• Key components
• Visits, Encounters, Observations
• Person, Patient, Users
• Other: Location, Address, Programs, Forms, Reports
• Practical Exercise

​

​

​

Data vs Metadata

​

​

​

​

​

​

​

​

​

​

​

Visits and Encounters

Visits

• Time period when a patient is actively interacting with the healthcare system, typically at a single location
• Visits can be short and include a single encounter (medication pickup), or include hospitalization extending over days, week, or longer
• Visit type defines the time for patient care and treatment (ie. Home visit, Clinic visit)

​

Encounters

• Brief time when patient has a single provider and location
• Every form creates an encounter
• Encounters could belong to a visit, but they can stand alone

​

​

​

Visits, Encounters, and Observations

Visit:

(1 day)

Encounter:

Registration

Encounter:

Vitals

Encounter:

Clinical Exam

Encounter:

Pharmacy

obs: occupation, marital status

obs:symptoms, labs, diagnosis,

prescriptions

obs: dispensed drugs with dosage

obs: weight, height, temperature

Multiday Visit with Encounters

Visit:

(over multiple days)

Encounter:

Registration

Encounter:

Vitals

Encounter:

Clinical Exam

Encounter:

Discharge

Encounter:

Vitals

Encounter:

Vitals

Encounter:

Clinical Exam

Encounter:

Surgery

Day 1

Day 2

Day 3

Encounters

Every encounter includes:

​

• Patient (patient_id)
• Location (location_id)
• Date/time (encounter_datetime)
• Provider (creator): Nurse, doctor, pharmacist, archivist, lab tech
• Type (encounter_type): vitals, COVID intake, checkin
• Visit (visit_id) (optional)

​

​

​

​

​

​

​

​

Primary keys and schema

​

​

​

​

​

​

​

​

​

Visit

Encounter

Obs

encounter_id

visit_id

Obs and Obsgroup

Observations (obs)

• single piece of information that is recorded about a person at a moment in time.

​

​

​

​

Observation groups (obsgroup)

• Sometimes a single observation is not sufficient to capture an entire piece of patient information. Multiple observations that are meaningful that are grouped together.

​

Person (A)

Person

​

​

​

COVID-19 antigen test: positive

Person

Person

User

Provider

Patient

Name

Attribute

Address

A person in OpenMRS is an individual.​

Patient

Patient

Patient Identifier Medical record number

National ID

Paper file number

Program

HIV, NCD

Outcome

Workflow/

State

A patient is a person in OpenMRS who receives medical care.​

Relationship

Person (A)

Person (B)

A Relationship is a bidirectional link between two persons

​

Examples of relationships:

• Parent / Child
• Patient / Doctor
• Patient / Community Health Worker
• Siblings

Users, roles, and privileges

• User:
• Account that a person may use to log into the system with a password

​

• Role:
• Represents a group of privileges in the system
• Roles may inherit privileges from other roles
• Users may have one or more roles

​

• Privilege:
• Authorization to perform a particular action in the system.
• Privileges are defined by the core system and by add-on modules (e.g. Enter Consult Note, View Reports, Modify User Information), but we need to configure which privileges to assign to each Role when configuring the system.

​

​

​

Provider

Provider

• Person who provides care or services to patients
• Any healthcare worker that a patient can have an encounter with is a provider
• Examples:
• clinician --doctor or nurse
• receptionist/data clerk
• social worker
• lab tech
• pharmacist
• community health worker

​

​

​

​

​

​

​

Location and Address

Location

• Place where services are provided
• Choices of granularity:
• Health facility (ie. Neno hospital, Dambe health center)
• Specialty within health facility (ie. Outpatient clinic, Women’s health center, COVID isolation ward, Emergency department, Laboratory, Radiology, Pharmacy)

​

Address

• Home address for person
• Person can have multiple addresses
• Configure address format for your country
• Address hierarchy module can be used to autopopulate sublevels
• 101 Market St | Downtown | Harper | Maryland County | Liberia

​

​

​

​

​

​

Program enrollment

Program:

• Administrative clinical area or study that a patient may be enrolled in
• Examples: Child Nutrition Study, HIV, Prenatal
• Enrolled with a start date and location

​

Workflow/State:

• Used to categorize discrete status for the patient during program
• Examples: Waiting for education or On treatment; Group or individual support

​

Outcome:

• Patient end program with an end date and the result of the program
• Examples: Treatment completed, Patient lost to followup, Study ended, Patient died

​

​

​

​

​

​

Orders, Allergies, and Conditions

Orders

• An instruction by a provider to another department within the health facility
• Includes labs, medications, radiology

​

Allergies

• Manage allergies, including the allergen, reaction, and severity
• Includes allergies to drugs, food, or other

​

Conditions (“Problem list”)

• Manage chronic diseases and important diagnoses for a patient with start and end date
• Includes diabetes, hypertension, HIV, sickle cell, malaria

​

​

Deleting data

• Data is not deleted on the system; data is voided​

​

• OpenMRS is designed to ignore voided data

​

• Users will not see voided data

​

• Administrator can “un-void” if needed​

Forms (data in)

Electronic forms used for entering or viewing data

​

• Basic system does not specific a single technology for entering forms
• Community-developed form entry modules
• htmlforms
• xforms
• custom MFE (micro front end)
• bahmni

​

​

​

Patient Dashboard and Reporting (data out)

An EMR is only useful if patients and users get something from the system. Key benefits are point-of-care patient information and data export and analysis for reporting. All are provided with OpenMRS

.

​

​

​

Practical Exercise

Activity: Match form elements with data model

​

Instructions:

1. Participants will be given a paper form (COVID19 Daily Progress Note).
2. Participants complete the top section of the form (name, gender, age, ID, date/time, pulse, pain).
3. Participant will be expected to match form elements with components of the data model.

Practical Exercise: Fill in paper form

Practical Exercise: Match data

Exercise: Match the OpenMRS data model (table and field) with the highlighted data on the paper form.

Practical Exercise: (answer key)

Exercise: Match the OpenMRS table and field with the highlighted data on the paper form.

3. OpenMRS Concept Dictionary

Why have a Concept Dictionary?

• Clinical users of EHRs resist the constraints of structured documentation

​

• Users and administrators underestimate the complexity and difficulty of data mining

​

• Data is dirty, misplaced, and/or incomplete

​

• Humans think conceptually, systems store data literally

​

• Everything we want to do depends on how meaning is recorded in the information system.

​

• Clinical intent is paramount and you get one chance to capture it correctly!

Terminology is the Foundation

Terminology

Clinical Data Model

Reporting/Analytics

Decision Support

Clinical Workflow

How to Start Building a Concept Dictionary

• Terminology is hard to do well!

​

• Standardization is essential!

​

• Take advantage of what others have done.

​

• Columbia International eHealth Lab (CIEL) is �preferred source… use it!

​

• Standalone appliance/Reference App, Dropbox and Open Concept Lab.

OpenMRS Concept Dictionary

Introduction

It defines “the name, code, and appropriate attributes for any observations or data collected (including medical tests, drugs, results, symptoms and conditions).”

​

It is also a “collection of coded, unique concepts used to generate forms and encode data within the system.” Every medical concept that will be used in the electronic health record system must be defined within the dictionary. This ensures that an idea/data element can be captured in the system in a way that can be shared and understood by others. Below are some of the elements of the OpenMRS built-in concept dictionary:

​

Concept: An idea. The question being asked, the answer being given, the diagnosis, procedure, drug, or other specific “thing” that needs to be captured. Concepts are individual pieces of data collected from a patient.

​

Fully-Specified Name: An unambiguous, unique label for the concept in a language.

​

Preferred Name: The preferred label to be used for the concept in a particular language.

​

​

​

OpenMRS Concept Dictionary (2)

Synonym: Other names for the concept which are not necessarily unique.

​

Short Name: A shortened version of the preferred name, which might be required for showing in a table where space is severely limited. These may not be unique.

​

Description: A clear and concise description/definition of the concept, as agreed upon by the members of the organization or the most commonly referenced source.

​

Concept Class: The classification of a concept. Currently, a concept can only have one class.

​

Concept Datatype: The structured format you desire the data to be represented as.

​

Version: A method to keep track of the number of updates applied to a specific concept.

​

Mappings: These are relationships between the concept and other codes or terms. These can be to standard or reference codes or to local codes or references such as modules.

​

​

OpenMRS Concept Dictionary (3) - Mappings

OpenMRS Concept Dictionary (4) - Example

Fully Specified Name

Acute respiratory distress syndrome (ARDS) due to severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2)

Short Name

ARDS due to SARS-CoV-2

​

Synonyms

Acute respiratory distress syndrome (ARDS) due to 2019 novel coronavirus

Acute respiratory distress syndrome (ARDS) due to COVID-19 virus

Acute respiratory distress syndrome (ARDS) due to 2019-nCoV

​

OpenMRS Concept ID

165867

​

UUID

38726ad5-e19f-48cb-8718-f21b18c51b9e

OpenMRS Concept Dictionary (3) - Mappings

OpenMRS Concept Dictionary (5) - Example

OpenMRS Concept ID

165867

​

UUID

38726ad5-e19f-48cb-8718-f21b18c51b9e

ICD-10-WHO

U07.1

ICD-10-WHO 2nd

J80

ICD-11-WHO

RA01.1/CB00

SNOMED CT

674814021000119106

Narrower-Than

Same-As

From Concept to Reference term

Searching for a Concept in OpenMRS

1. Includes search
2. Include retired
3. Show results
4. Show details

​

[1]

[2]

[3]

[4]

Searching for a Concept in OpenMRS

1. Fully specified name
2. OMRS Concept ID
3. Description
4. Add new concept if not found

​

[1]

[2]

[3]

[4]

Creating a Concept in OpenMRS

1. Must have unambiguous, unique fully specified name in each language
2. Use sentence case
3. Synonyms do not have to be unique
4. Search terms are for indexing only (misspellings)
5. Data type driven by what is being collected. N/A is for answers only
6. Coded answers can be created before or after the question concept and added later.

​

Creating a Concept in OpenMRS (2)

1. Switch between languages
2. Add a synonym
3. Select datatype
4. Edit a list of answers (this section changes depending on the chosen datatype)
5. Add mappings

​

​

[5]

[1]

[2]

[3]

[4]

Practical Exercise

Activity: Creating concepts

​

Instructions:

1. Participants to create a concept to represent Pain severity (level) as a coded value.
2. Participants to then create the concepts None, Mild, Moderate, Severe/Intense of Class Misc and Data Type N/A. After creating four new concepts, participants to edit Pain severity and add them as answers.
3. If you have time, create a numeric/finding concept for Heart Rate/Pulse.

​

Exercise:

Exercise Explained

1. Add FSN and preferred
2. Add a synonym
3. Add description
4. Select class
5. Select datatype

​

​

​

Exercise Explained (2)

1. Create coded answers if necessary
2. Add answers
3. You can come back and edit concept before publishing

​

​

​

Exercise Explained (3) - Add mappings

Exercise Explained (4) - Add mappings

1. Select Source and Code
2. Select mapping relationship
3. If Code does not appear as typing, add reference term by clicking Create New Term
4. Remember to Save Concept

​

​

​

​

Exercise Explained (5) - Final view

Emerging solutions: OCL for OpenMRS

Common Problems in OpenMRS Concept Management

• “We had to start our dictionary from scratch for new sites.”
• “To share forms & concepts across sites, we’ve had to manage painful liquibase migration scripts.”
• “I just learned that Organization B created almost exactly the same form as us!! We duplicated work that we could have shared!”
• “We have a standard set of concepts most of our sites use. We wish it were faster to use and adopt these for each site.”

​

​

The OCL for OpenMRS webapp tool aims to solve these problems.

​

Re-use your previous work

No migration scripts needed for content - import in moments

See public work done by other organizations

Set up “baseline” source(s) that sites can use to quickly pull together a trusted dictionary

1

2

3

4

OpenMRS - 2021

Summary

The OCL for OpenMRS webapp at openmrs.openconceptlab.org enables:

• Public sharing of concept work
• Manage content regardless of the version of OpenMRS
• Reduced duplicated effort both at and across organizations
• Easier concept set-up across OpenMRS systems
• Incorporating recommended concepts is fast
• Create and share recommended sets that can be reused across sites and orgs
• E.g. Once patient-level data elements and codes published - could be available to implementers
• Handle customization needed by sites, while not losing the connection to Curated Sources

​

​

OCL for OpenMRS Webapp tool

openmrs.openconceptlab.org

​

• front-end interface (UI) web-app
• goal: manage concepts more easily for OpenMRS

1. See public work of other orgs

​

OpenMRS - 2021

2. Re-use previous work

​

OpenMRS - 2021

3. Pull together with shared sources

(don’t have to create from scratch)

​

OpenMRS - 2021

4. Import in moments

Just add the Open Concept Lab module

​

1

2

3

OpenMRS - 2021

Case Study for reference

This case study has walk-through videos of how to use OCL for OpenMRS.

4. OpenMRS Quality Assurance Framework

Topics to be Covered

• Introduction to quality assurance and background on OpenMRS QA
• Community Sustained Quality assurance.
• Quality assurance framework
• Cucumber Framework
• OpenMRS Quality Assurance process steps

​

Just Works

Reliable

Bug Free

Stable

Meets Requirements

Meets Users Needs

Fitness for Use

Quality is a Customer Determination

Trust + Satisfaction

On Time

On Budget

Supports My Work

Available

What Is High Quality?

Supported

Role of QA in Digital Health

• Health care products and system require maximum accuracy in order to provide precise care to patient /clients .
• Promote safety and quality of the healthcare industry.

​

​

​

Establishing a continuous and sustainable QA process.

“QA at the beginning, not at the end”

Solution to QA objectives and gaps Identified

Background on the OpenMRS QA Work

Cucumber Framework

Proposed solution

Community Sustained Quality Assurance

For the OpenMRS Community

Provide QA support and guidance to the OpenMRS community to:

• Use community tools and processes
• Integrate QA processes into Platform, Ref App, and modules development cycles

For the OpenMRS ecosystem

Provide QA support and guidance to OpenMRS implementers to:

• Use community tools and processes
• Extend community tools and processes for use with specific distributions/custom modules
• Integrate QA processes and tools into implementers’ development processes

For Global Goods

• Collaborate to apply OpenMRS QA tools and processes to interoperability use cases
• Share lessons learned on implementing community-sustained QA processes

Quality Assurance Framework

What is Cucumber Framework?

• Opinionated testing methodology
• Behavior-driven development (BDD)
• Feature description in plain English-like language (Gherkin).
• Gherkin uses the key words : Given – When – Then
• Libraries for any language

What is Cucumber Studio?

OpenMRS Quality Assurance process steps

​

Step 1: Review and assess available community QA processes and tools

​

Step 2: Prioritize test cases for automation

​

Step 3: Create a QA plan

​

Step 4: Build your team’s QA capacity

​

Step 5: Trial a sub-set of test cases

​

​

More information: How-to: Integrate Community QA Processes and Tools into the Development Process

​

​

Future of QA is Automation

All tests could be automated! Benefits of automated tests: Greater confidence in releases, Catch bugs earlier, Less team time spent doing painful manual testing. To learn more, join the OMRS QA Support Team for support and training.

Quick demo on automation

Practical Exercise

Activity: Creating a login test case

​

Instructions:

1. Participants to list possible scenarios to a login in feature.
2. Participants to create a login test case/scenario to be used for manual testing.

​

Sample Test Case

​

Below is an example of a successful Log-in test case:

Answer Key to exercise

​

Thank you!