Concept Dictionary Basics

Introduction

At the heart of every OpenMRS implementation is a concept dictionary that defines the medical concepts (questions and answers) used as the building blocks for forms, orders, clinical summaries, reports and almost every aspect of the data. Most OpenMRS implementations have an open concept dictionary - one that is considered incomplete and evolves over time. Therefore, as clinicians document conditions, the OpenMRS concept dictionary must be expandable to accommodate meaningful clinical data. To get to the OpenMRS concept dictionary, navigate to the Configure Metadata block and click Manage Concept Dictionary.

What follows is an introduction to the Concept Dictionary, OpenMRS's unique foundation, and how it provides flexibility for the implementation.

Definitions

Concept Dictionary

The concept dictionary represents a fundamental building block of OpenMRS. Similar to a dictionary defining the function, meaning, and relationships of the words, the concept dictionary defines the name, code, and appropriate attributes for any observations or data collected (including medical tests, drugs, results, symptoms and conditions). To even further simplify the concept dictionary, one could compare it to an infinitely large Excel spreadsheet, where patients are represented as rows and concepts are represented by columns.

Concept

The concept is the basic element of flexibility in OpenMRS. Concepts are the individual data points collected from a population of patients. Concepts include both questions and answers.

For example, blood type data is collected for a patient. The question is "What is the blood type for the patient?", with a set of discrete answers of "A, B, AB or O". To implement this in OpenMRS with concepts, the question is a concept ("blood type") and each response ("A", "B", "AB" and "O") is also a concept. For this one question, a total of 5 concepts are required.

What about a question where the answer is not a discrete answer? If the question is "What is the name of your first pet?", the answer would be expressed in a text box. It would not be possible to provide a complete list of every possible name for your pet. In this example, there would be one concept -- "name of first pet".

The bottom line is, if you need a medical word within your electronic records system, it needs to be defined within the concept dictionary. More detail about all the possible concepts in a later section.

Encounter

A single, specific interaction between the patient and a provider. An encounter can be any interaction and includes doctor visits, laboratory tests, food distribution, home visits, counselor appointments, etc. Encounters are typically represented as a form (consisting of hundreds of observations), but could also be a touch-screen patient registration or a single lab test for CD4. For example, a patient visits a health center or hospital. For each electronic form completed for that patient, a new encounter is created. Each will have a unique encounter_id and encounter_type. Forms could be completed by different departments (ie. drug pickup, visit with an HIV clinician, Diabetes visit, food package received), and will have an associated encounter_type (ie. ART Drug Regimen Pickup, Adult intake, food assistance, lab test, etc). Each encounter has an encounter type, date/time, location and provider.

Observations

Anything actively measured or observed during an encounter. As an example, patients' weights, heights, blood pressures, and BMIs are observations, as well as qualitative facts including the number of years a patient smoked, the activities in which the patient experiences shortness of breath, and finding on an X-ray. Although typically an observable question, demographics are an exception, and are recorded as separate concepts. Each observation has a unique obs_id.

These are possible scenarios for encounters and observations:

One visit with one encounter without observations – Touch screen patient registration in Haiti
One visit with one encounter with one observation – Touch screen patient registration in Rwinkwavu, Rwanda with weight recorded
One visit with one encounter and many observations – HIV followup form
One visit with multiple encounters and many observations – HIV followup form along with ART drug regimen pickup. This would show 2 encounters, where each encounter would have a different encounter id and encounter type.

Demographics

Demographics are any descriptive characteristic of a person. This includes: name, address, date of birth, age, and any other social construct involvement.

Fully-Specified Name

A fully-specified name is a term that fully describes the concept in an unambiguous way. A concept must have at least one fully-specified name (in any locale).

Locale-Preferred Name

This is the preferred name to use within a locale. By default, this is the fully-specified name; however, full-specified names are sometimes long and more detailed than necessary for day-to-day use. In those cases, a synonym can be defined to be the locale-preferred name. There can only be one preferred name within a locale. The primary term should be the word(s) used most often by those who will have access to the records to prevent duplicate concept creation.

Short Name

A shortened version of the primary name for use in space-constrained contexts (e.g., a column header in a spreadsheet). OpenMRS does not enforce a length limit on the short name, but a target of eight (8) or fewer characters is suggested (to work as a column header for programs like SPSS or SAS).

Description

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

Synonym

Any valid, alternative names for the concept. This includes acronyms, abbreviations, and other names that reference the primary name. You can include your organization's more informal names for concepts here.

Index Term

Index terms are names that should never be displayed as the name of the concept, but are useful for indexing (helping users find concepts). Examples would be common misspellings of names (allowing users who enter the misspelling to still find the concept) or a barcode value for a vaccine (allowing users to scan the bottle when creating an observation and find the appropriate concept).

Concept Class

The classification of a concept. This classification details how a concept will be represented (i.e. as a question or an answer). The current list of classes include:

Test – lab tests(e.g. CD4 Count) or physical exam maneuver (e.g. Babinski)
Procedure – spinal tap, lumbar puncture, etc.
Drug – medications, prescriptions and over the counter
Diagnosis – defined medical conclusion (usually in ICD), e.g. diabetes, AIDS
Finding – physical or exam findings (shortness of breath, systolic murmur, LLL infiltrate)
Anatomy – body part, e.g. right arm, frontal lobe, abdomen.
Question - query to which there are either open-ended or coded responses
LabSet – a group of several test concepts, e.g. I-Stat Chem8+
MedSet – a group of several medications, e.g. cardiac medication
ConvSet – a group of concepts, typically questions, assembled for convenience, e.g. vital signs
Misc – unclassifiable concepts, typically general descriptions of location or rankings, e.g. left, severe, positive
Symptom – any sign or indication of a possible conclusion, e.g. chills, increased heart rate
Symptom/Finding – any sign or indication, not specifically linked to one conclusion
Specimen – a sample of any larger part, e.g. tissue, blood sample
Misc Order – orders typically not utilized by the organization
Program – a specific plan, or set of plans, that a patient may be enrolled in, e.g. first line TB treatment
Workflow – a process, as described by the organization
State – a general description of a patient or body’s status, e.g. comatose

More on concept classes at this wiki page.

Concept Datatype

The structured format you desired the data to be represented as. The current types are as follows:

Numeric – any data represented numerically, also allows you to classify critical values and units, e.g. age, height, and liters consumed per day.
Coded – allows answers to be only those provided, e.g. Blood type can only be “A,” “B,” and “O”
Text – Open ended responses
N/A – the standard datatype for any non-query-like concepts, e.g. symptoms, diagnoses, findings, anatomy, misc, etc.
Document
Date – structured day, month, and year
Time – structured time response
DateTime – structured response including both the date and the time
Boolean – checkbox response, e.g. yes or no queries
Rule
Structured

Version

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

I get all the definitions, now why does this apply to me?

Imagine attempting to graph the trend of a patient’s weight over time, and having several different concepts which refer to recorded weights - you’re looking at a lifetime of rummaging through non-standardized paperwork and measurements. If one properly uses the concept dictionary, they will be able to analyze any concept, no matter what encounter and form it was recorded in. The Concept Dictionary guarantees that all weights will be recorded as weights, and not under various headings.

As simple as it can be explained, OpenMRS is an infinitely large filing cabinet. Within that cabinet, each patient has a file. Within that file are a series of encounters, each consisting of hundreds of observations. As the patient continues to utilize the healthcare system, they will become associated with a limitless number of observations. Each of these observations consists of a question (what is the patient’s weight) and an answer (140lbs); the Concept Dictionary easily links these two concepts together. Because of this automatic correlation, there is a necessity for all concepts to be properly crafted.

Where do I start? What do I do?

So, you’re not exhausted from the descriptions, and you want to create a concept? Before you create your concept in OpenMRS, contemplate these three steps:

Make sure the concept doesn’t already exist in the dictionary. When searching the dictionary, use partial names (e.g. "Kale" or "Kalet" instead of "Kaletra"). Looking for partial names will help catch misspelled entries. Think about what your organization most generally refers to this concept as – consider all possible synonyms! You may be surprised what concepts already exist.
Make sure that you can describe/understand the concept that you're getting ready to enter! Say for example, that you're asked to create a new term for the retroviral drug eliminatehivudine. Knowing that it's a retroviral drug is insufficient, as you're going to need to detail eliminatehivudine's differences from all other antiretrovirals within the term's description. Don’t be too sure of yourself - double check with the person requesting the new concept that you have the correct, specific definition.
Make sure that you include and standardized representation of the concept, e.g. LOINC or ICD10. If you have no idea what this is – go to the internet or a coworker and find out!

Do you have all of the information ready? Then it's time to walk through a primary concept definition, and the basic attributes this includes.

Primary Name
- The name should begin be completely specific. It is "Hepatitis B immunization", not "Immunization, Hepatitis B".
- Use sentence case (Malignant cancer) or title case (Malignant Cancer)
- Use only alphanumeric characters! (If this was a concept, there would be no exclamation point.)
- NO ACRONYMS – Abbreviations and acronyms are only used as synonyms!!
- When necessary, always refer to the generic form (e.g. Ibuprofen, not Advil ©)
- When referring to organism or virus, the full taxonomic name is used (e.g. Human immunodeficiency virus, not HIV)
- Adhere to complete granularity! "Right upper quadrant abdominal pain" refers to too many observations. This can be tricky in practice – if you’re unsure, refer to a geek or someone who can identify mini-clauses within your proposed primary name.

Short Name
- Be smart – only use alphanumeric characters, avoid long phrases, and acronyms that may have several meanings

Synonym
- Again, be smart! Use any other phrases or acronyms that people within your organization may search for when attempting to use this concept. If you’re at a loss, conduct a survey of possible end users.

Description
- Without question, at the end of reading this statement, a lay person should have a decent idea of the concept’s meaning. This is always REQUIRED – no exceptions.

Data Class
- Is the concept a question that requires responses? If so – label it as a question!
- Is it a list of questions that are related? If so – label it as a CONVSET!
- Is it a list of lab procedures that are related? If so - label it as LABSET!
- Is it a list of medications that are related (e.g. Antiretrovirals)? If so – label it as a MEDSET!
- If you’ve gotten through the above questions, be smart, and choose the best fitting of the remaining classes.

Is it a set?
- If you answered yes to either question 2,3, or 4 above, check this box! Otherwise you won’t be getting much functionality out of the concept.

Datatype
Is your concept a question that requires responses?
- If yes, select the type that best represents the form that you wish to view your data as.
  - If yes, and there are only a few possible answers, select CODED, and choose those possible answers.
  - If yes, and the class is numeric, make sure you enter any critical values. Also, select PRECISE if you desire decimal answers.
- If no, select N/A.

Version

This is completely up to you.

- Use any method you think works for you.
- Use a method that will be easily recognized and utilized by all other OpenMRS users.
- Be consistent with your method across all concepts.

A few things to remember!

AVOID ALL DUPLICATES – CONDUCT AMAZINGLY THOROUGH SEARCHES BEFORE CREATING CONCEPT
ONLY USE ALPHANUMERIC CHARACTERS.
1. You can use non-alphanumeric characters in the description only.
ALWAYS WORK WITH THE END USERS OF OPENMRS TO GUARANTEE DATA IS BEING COLLECTED IN AN APPROPRIATE MANNER FOR YOUR NEEDS

Documentation