Here’s an attempt to represent the common scenario @ball described…
Let’s say CIEL defines a coded concept:
|Fully specified name
||Civil Status ← preferred name
||Single, Married, Divorced
PIH uses this concept 123 in their forms, but makes some local changes:
- Add French translations
- Make “Marital Status” the preferred name
- Add “Separated” as an answer
None of these are breaking changes (i.e., they don’t change the meaning of the concept). Some of the changes might eventually make it back into CIEL (translations, other possible answers), but other changes will remain specific to PIH needs (changing the preferred name).
It’s important to note that PIH doesn’t want to clone/fork the concept to a new local concept, because they’re already using CIEL 123 in all their forms, they want to incorporate future updates of this concept from CIEL, and they don’t want the headache of tracking a PIH-specific concept that is effectively the same CIEL concept with local adaptions.
For now, PIH manages their local changes to CIEL concepts within an instance of OpenMRS, forcing them to cherry pick updates from CIEL and limiting the likelihood of getting updates from CIEL. Also, the process for getting their local changes back into CIEL is a manual review process with Andy.
I’m assuming we’d want to work through steps something like:
- Explicitly enumerate/document what are breaking vs. non-breaking changes to a concept.
- Add a feature to OCL to allow local, non-breaking adaptations to concepts in a collection.
- Once supported by OCL, add this ability to the OCL for OpenMRS client.
- Verify that OCL and the OCL subscription module properly handle updates to CIEL concepts (e.g., merge CIEL updates without losing local adaptations)
- Create an import process to onboard OpenMRS dictionaries into OCL where any changes to CIEL concepts are stored as local adaptations during the import.