How to future-proof shared concepts?

Tags: #<Tag:0x00007f6002f7d8c0>

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?

@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

@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.