2009 Implementers Group Meeting Program Concept Management

Owned by Former user (Deleted)
Last updated: Aug 18, 2010Version comment
7 min read

Moderator: Andrew Kanter

Note Taker: Evan Waters

Creating Concepts/Modeling

16 votes

Is there criteria we need to follow when we are modeling concepts?

  • Some basic principles:

    • Be very clear about what the concept "is".

      • Use the description field to help. Be explicit. Write down a definition of the concept. Describe the context and even include the text of the question which was included on the form if appropriate.

      • Think about how the concept can be reused to be used elsewhere. It is not only for your use. Build up the concept from reusable blocks if possible.

      • Be sure the default name is also clear and unambiguous and includes units if relevant.

      • Concepts should not overlap

      • Concept answers affect the concept definition. For example, Yes/No versus Yes/No/Unknown are different.

    • Mapping to reference terms helps exchange concepts (maps to SNOMED CT, RxNORM, LOINC, ICD terms/codes)

    • Be consistent. If you use model concepts using one technique, such as Symptom: {cough, fever, etc.} versus Cough: Y/N; Fever: Y/N, be consistent. Also be consistent with use of units, phrasing, capitalization). Now with new concept_names tables, it is possible to have different "names" for the same concept that show in the medical record.

What is a concept?

A concept is not just a name, it is a paragraph of text that you are trying to describe. The labels on the form that you are going to attach to it are going to change.

Example: I want to know how long it takes someone to travel to a location, and be able to specify the units.

  • Could say 'HOW DID THE PATIENT TRAVEL TO THE CLINIC', but then you would have to ask the same question for every type of location.

  • Could use a concept set with

    • HOW DID THE PATIENT TRAVEL? (By foot, by car, by bus, etc..)

    • LOCATION (Clinic, Hospital, etc.)

Is this a data dictionary or a phrase dictionary so that you are saying the same thing the same way?

The current concept page is sort of limited, it doesn't track the actual question that was used on the form. Possible recommendations for additional structured meta data for concepts:

  • Concept "flags"- additional ways to tag concepts or categorize concepts for subsets, etc.

  • Strict definition field

  • Actual question used on the form (this could appear in the concept_name table and be flagged as preferred question in a certain language, etc.

  • Visual properties (how large the text field should be, etc... similar to what Daniel showed for the Xform module).

Who should be involved in modeling concepts?

The people making the forms are usually not the people asking for them, recording the data, and using the reports. Within an organization it is imperitive that you have good communication with someone in the field who is using the forms. On the other side, how as a larger group do we want to do it? How will the data be reused.

Is there something in the concept that specifies the formatting?

You can define if it is a question, a diagnosis, etc, and then define the datatype. You can't categorize the concepts with other metadata such as 'primary care'. You can't specify the length of the text field. What is the appropriate input? We should develop some specific use cases.

An imporant point is that you need to specify the units for the concept (ie, WEIGHT (KG), or have a numeric field for WEIGHT and a UNITS field for kg). For example, recording a concept like "How long has the patient had a cough?" Could be modeled:

  • Concept Set: Symptoms Duration

    • Concept: Symptom (coded list including cough)

    • Concept: Duration (numeric)

    • Concept: Duration units (coded list: minutes, hours, days, weeks)

Concept Names

0 votes

In the new system it allows you to have multiple names for a single subject. We could have a concept name flag for a question to reference it to a language.

Reference Terms

16 votes

ICD is used for encoding data and is used for medical and insurance purposes in many places.

These numbers are important for reporting and billing. They are not good for clinical use or for more specific questions such as: 'How many different sexual partners did you have in the last two months?'

SNOMED has a whole hierarchy tree of information that is more detailed than ICD. It is standardized for countries for their information systems. There is an attempt to use these terms to move concepts from one place to another. If I have hypertension in my database with concept number 12 and you have hypertension in your database with concept number 69, but they are both mapped to SNOMED, we can potentially share data across even with different IDs.

As we elaborate these concepts a bit more, we hope that a master server would have a SNOMED or an ICD code with each concept. So the reference id could be used at the high level. At Columbia University, they have a namespace identifier which allows them to make additions or request changes to the SNOMED reference terms so if people want to make recommendations, contact Andy.

A proposal for a data model changes for OpenMRS has been made that is similar to concept and concept name tag, that should have a source table which has the reference terms and is mapped to concepts. For hypertension, you could have multiple maps to a LOINC code, a SNOMED code, etc.

As a developer, when I take a form that is coded to a set of concepts, I can't use it unless I have those concepts in my database. But if we have SNOMED mapping in place, theoretically we could all use the same form and just let the mapping take care of assigning the correct primary ids for the concepts, as long as we also have concepts in the database.

So you still need a way to pull concepts down.

Are you using existing metadata in concepts such as RDF?

There are different ways to model concepts such as HL7 and OWL. These are useful to maintain relationships and manage merging. One of the questions to the community is, do we have tools that help us merge in this process.

The proposal we have now on the wiki (http://forum.openmrs.org/viewtopic.php?f=2&t=326 and http://n2.nabble.com/Re-Proposal-for-updating-source-reference-table-structure-for-OpenMRS-td2959617.html#a2959617) is to have a series of additional tables for SNOMED, ICD, etc, and a source mapping table that is a link between the internal concept and the reference. There can be primary and secondary mapping keys, and also hierarchy keys.

Sharing Concepts

14 votes

  • We need to address sharing concepts within and without OpenMRS implementations.

  • OpenMRS Concept Collaborative will help manage this (see later session notes).

When concept fields are different on each server, are you starting to think of how you are going to merge them back together?

In Malawi, PIH and Baobab are doing their best to maintain a common concept dictionary that would be managed by the MOH. We need to find a way to propose, review, create and distribute concepts in a way that effectively involves all parties.

You have your sites, but are you standardizing the other sites?

Isaac is working at a CHAM site (Christian Health Association of Malawi, 35% of locations in Malawi). Loves the idea of using reference terms to share concepts. The more immediate use case is to have the MOH or a center of excellence have an approved concept dictionary. They may or may not have models of care that the concept dictionary is particularly appropriate to. From the implementer's perspective it is easier to provide standardized care.

Is there a way for the MOH not to have to manage the entire dictionary?

CHAM has to use the MOH reporting system even though it is independant.

It is a matter of the tools that the MOH has to use. What tools do we need developers to make?

In 1.4 the migration can assign new concept ids in different places. This is important if you are migrating. Different servers will receive different concept_name_ids for each entry! So, plan to standardize or overwrite the concept_name table after migration so that all servers are receiving the same concept_name_ids (if you need to have the same ids, just like concept_ids).

There is a simple concept proposal feature that can help send requests up the chain. In version 1.4+, concepts can be proposed from server in addition to the data entry screen. In this way, "child" clients can use the concept proposal structure to send requests up to a "parent" server. Currently, not much meta data included. What structured data would help?

  • Same fields on the add concept page.

  • What was the question for which the "answer" was being added?

  • Preferred name, etc.

In synchronization, the primary keys are not the same in different locations. So concept ids would not be the same across different sites if they were exchanged with synchronization. You can turn off sync for the concept tables and push these down only from the parent server (and not allow changes on the child servers).

If Partners in Health and Baobab want to share concepts and exchange data, they will either have to use the same primary keys or use reference terms.

Main Point

  • We have master server pushing concepts down to the sites.

  • The terminology service bureau (TSB), run by Columbia allows anyone on the web to edit the concept names and the properties files used for the user interface (spanish, russian, portuguese, kiswahili, etc.).

  • Problem is that it is tied to the MVP database so you have to use all or at least part of it.

  • The OCC would allow a country like Malawi to push its concepts up to the TSB and then pull standardized concepts down.

Is the TSB in touch with the WHO and other organizations so that the terms tie in?

The idea is, Yes. The TSB hopes to facilitate the creation of standard interface terms and provide a link to the reference bodies (like SNOMED).

Goal

Provide feedback to the developers.

  1. It would be helpful to be able to specify additional metadata for a concept, including

    1. Project or form (ie, Primary care, ART)

    2. Field parameters (ie, text length, number of decimals)

  2. We need a richer way to propose new concepts (including adding additional metadata)

  3. We need an easy way to tie into reference terminology for mapping from within the UI

  4. We need a way to package concepts and for distribution

  5. We need a better way to model concept name tags (we might want a tag to specify names that are used as questions on a form)

  6. We need a concept import feature that can map concepts from reference terminology and, ideally, create a new concept if it doesn't already exist.

References