How to future-proof shared concepts?

Implementing Terminology
1

Mwariri and I were just talking through some real-life concept management examples that the OHRI team is trying to solve right now. I think this connects with our vision of having a trusted Source that countries/orgs could pull from, but then they’d need to be able to tweak those concepts based on their local needs.

@ball @akanter @paynejd @ssmusoke what do you think of the scenarios and ideas described in this video? Any thoughts / advice?

2

@grace Thank you for starting this thread, I think the examples you have provided are still very complex, and not easily relatable since they are a mix of different items - Locations, etc

An example that the OHRI team discussed is below

  1. New concept Favourite colour: Red, Yellow, Blue (default codes in OHRI Concept dictionary)
  • Kenya wants Green.
  • Uganda doesn’t want Red.
  • Much later, Nigeria also wants Green.
  • This is such a strange concept which cannot be accepted into CIEL so remains in the OHRI concept dictionary
  1. OCL baseline HIV Test Result has Reactive/Non-Reactive, but countries want Positive/Negative and Indeterminate (new concept to set). CIEL cannot be updated to change the names, how do we do this?

I am not very sure about the coded vs set usage, I know coded has validation (HTML form Entry), but not sure if sets do

I think my question is at the level of how will such scenarios be supported (at a business level) even if they are not yet available in OCL

3

@grace and Mwariri, can you describe what those tweaks are anticipated to be?

What typically happens to us is the need to quickly rename or localise further than what CIEL does. We do that typically with Iniz, and this will be still possible even after OCLOMRS-950 is in the box, since we’re leaning towards loading the ‘concepts’ domain after the new ‘ocl’ domain. More here on this.

4

Not sure how I missed this thread. Sorry for the delay in responding :frowning:

First, it really matters whether you plan on actually doing anything with the data collected in the field specified by the concept dictionary. For example, a patient identifier field is unlikely to be a shared data element. Therefore, having a concept for this helps with sharing of forms or reports, but doesn’t it doesn’t really matter the format of the answer (since they are not shared across country implementations, etc.). This one reason that text answers are acceptable.

For other question/answer combinations, it also matters whether you are trying to ensure that the data is interoperable. For certain concepts, the concept itself might be at a higher level of specificity than the actual variable you are trying to analyze. For example, you might need to identify locations based on the ART example in the video, or let’s say location broken down by medical ward, surgical ward, etc. A given location might have concepts for 2nd floor and 3rd floor. These correspond to the Medical ward and Surgical ward, respectively. It may be possible for local synonyms to be added for the floor numbers, or a standard code could be attached to the concept at the dictionary level allowing for several different local locations (floor numbers) to be mapped to the same standard location (medical ward).

One of the dangers of simply allowing implementations to pick from a central source, but then add custom concepts to varying degrees, is that there is no common set of shared concepts among the implementations. If MDS is for meta data sharing, then the video is correct. If it stands for minimum data set, then it would be expected at all implementations include ALL of the data elements in the minimum data set, adding additional concepts as required for additional use cases. I would think that enforcing a minimum data set, but allowing answers to be customized (but mapped to standards) would be a good approach. Perhaps we can get some specific use cases up in a google spreadsheet so that we can work through this asynchronously?