Two of the most critical characteristics of electronic medical record systems are complete flexibility and adaptability. Without an easy way of altering or adding to the system, its applicability may diminish extremely quickly. What follows is an introduction to the Concept Dictionary, OpenMRS's unique foundation, and how it can provide the utmost flexibility for your organization.

The Basic Definitions

Concept Dictionary (C.D.)
The fundamental building block of OpenMRS. Similar to a dictionary defining the function, meaning, and relationships of the words, the C.D. 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 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, the question of blood type is a possible concept, but the responses, A, B, AB, O, would be considered concepts as well. The bottom line is, if you have a medical concept of any sort, and it is needed within your records system, it needs to be defined within the dictionary.

Encounter

• A single, specific interaction between the patient and the provider. An encounter can be any interaction, including doctor visits, home visits, counselor appointments, etc. Encounters are typically represented as a form, consisting of hundreds of observations.

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, demographic s are an exception, and are recorded as separate concepts.

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

Primary Name
The most basic label for a concept. Each concept has one, and only one. 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. Primary names should not include any abbreviations or acronyms.

Short Name
A shortened version of the primary name, possibly a word or phrase that people around the office typically use.

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

Synonym
Any label or name that refers to a primary 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.

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 love, 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. vitals 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 status, e.g. comatose

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+, A-, B+, B-, AB+, AB-, O+, 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:

1. 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 and consider all possible synonyms! You may be surprised what concepts already exist.
2. 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 terms description. Don't be too sure of yourself - double check with the person requesting the new concept that you have the correct, specific definition.
3. 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 be completely specific. It is HEPATITIS B IMMUNIZATION, not IMMUNIZATION, HEPATITIS B.
  • Use all CAPITALS
  • 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 virri, 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 and if you're unsure, refer to a geek or someone who can identify mini-clauses within your proposed primary name.

• Short Name
  • Be smart and 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 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!

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

Additional Assistance

...

Concept creation

Since OpenMRS 1.7, duplicate concept names are not allowed for the same locale. Validation checks for this and will prevent addition of new duplicates or saving a concept with a duplicate name. It is still possible to have duplicate names for different locales (ie. Leprosy could be the concept name for 'en' and 'gb' locale).

Avoid Duplicates!  Avoid Duplicates!

When creating a new concept, use the "similar concepts" resources and/or search your dictionary carefully to be certain that there is not already a concept that meets your needs.

• Create synonyms when you create a concept, to avoid re-creating a duplicate of that concept in the future. This helps avoid duplicate concepts with different phrasings.

Concept Naming

• Only use alphanumeric characters (letters and numbers) and simple punctuation sparingly – e.g., comma (","), parentheses ("(" and ")"), and forward slash ("/").

  • Descriptions may contain non-alphanumeric characters

• Sentence-case is recommended. This is either all lowercase or uppercase first letter (ie. 'Blue suede shoes').

  • Avoid using all uppercase.

  • Make exceptions for well known names (ie. EKG, HIV, pH)

• For drug names, some people use Tall Man Lettering to uppercase certain parts of drug names that are confused by providers, since this has been proven to reduce medication errors.

• Be consistent. Having a consistent naming convention for concepts is a must.

• Add standard SNOMED, ICD10, or RxNORM maps to concepts. Do this as part of creating the concept.

  • Consistency in naming helps users predict concept names and makes the dictionary much easier to manage.

• Always work with your end users to ensure the your concept names make sense to them and match their workflows.

• Avoid changing names of concepts that have been used to store clinical data. After the point of data collection, concepts shouldn't be changed as you're then altering retrospective data. It is fine to continue to add synonyms to concepts, where applicable. 

Describing Concepts

Every concept should have a description (at least within the system locale) that unambiguously describes the concept and, ideally, explains how it is intended to be used.  For example, for a concept like "NUMBER OF CHILDREN", the description could clarify the concept with a statement like "A question asked of the patient and representing the number of their biological children, whether or not the children are alive, living at home, or living elsewhere."

Classes and datatypes

• Don't create boolean concepts for things like "Cough for last 3 weeks" = Yes/No. Instead have Symptom Present (coded), Symptom Absent (coded), and "Cough for last 3 weeks" (as an answer)
  Consider importing concepts (e.g. from CIEL/MVP) when suitable <https://openmrs.atlassian.net/wiki/x/ywRYAQ>

Design for Re-use

Well-designed concepts can be used in several different contexts (e.g., multiple, different forms).

• Avoid making your symptoms & diagnoses concepts boolean; rather, use datatype N/A for these and use them as answers (not questions).  This promotes re-use of these concepts.

  • POOR DESIGN: a boolean "HIV" concept answered yes/no based on whether or not the patient has HIV.

  • GOOD DESIGN: a coded  "DIAGNOSES" or "PROBLEM ADDED" concept that is answered with the concept HIV (the HIV concept has datatype N/A)

Modeling diagnoses

Here are some notes/conversations related to concept modeling that may be helpful resources when confronting modeling issues.

Hamish wrote:

I would use DIAGNOSIS or PATIENT REPORTED DIAGNOSIS or similar generically and then record the diagnoses as answers (e.g. MALARIA) for most cases. That gives you the choice of recording the date of diagnosis into the obs date (probably simpler) or creating a DATE OF DIAGNOSIS observation to link dates to diagnoses through an obs_group_id.

If someone wants multiple choice answers for 1..n diagnois, then you are collecting two observations in each case: a multiple choice answer and the diagnosis for which the answer applies. There are a several ways to skin this.

Flat by diagnosis (add coded answers for each diagnosis)

PRO
simple, MALARIA/etc could still be used as answers

CON
not scalable, ties you to one model of answers to diagnoses and these must be replicated/managed for every diagnosis in the system.

Fully abstract (one concept for diagnsosis and a 2nd for answer to multiple choice question)

PRO
easily scalable

CON
needs tools/knowledge to convert back to one complex data point, diagnoses stored in a questionnaire-specific manner

Abstract, but use existing DIAGNOSIS concept

PRO
re-use of DIAGNOSIS, so you can still search DIAGNOSIS concept for all known diagnoses

CON
application must know to treat TRUE answers differently

Flat by answer (one concept per answer for questionnaire)

PRO
scalable, could re-use DIAGNOSIS concept or have a separate concept for diagnosis = true on questionnaire

CON
requires search for multiple concepts (could be facilitated by concept_set)

Additional information

• The MVP-CIEL concept dictionary is a valuable resource (either as a starting dictionary or to look for best practices)

• Handling Missing Information is a guide for designing better forms and concepts so as to avoid missing information.

• Notes or recording from the 2012-Sep-12 OpenMRS University forum, where concept management experts discussed best practices.