Have you implemented OpenMRS? Please participate in the Implementation Site Survey. If you already have, thank you!
Moderator: Andrew Kanter
Note Taker: Evan Waters
Is there criteria we need to follow when we are modeling concepts?
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.
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:
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:
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.
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.
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?
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.
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).
Provide feedback to the developers.