@binduak & @sivareddy & @gsluthra: Thanks for walking me through your concept import conflicts on today’s PAT call. Awesome to see how you are using the Initializer ocl domain to import the latest version of CIEL into Bahmni! (Kudos to @suruchi & @ruhanga & @mseaton for adding the ocl domain to begin with! And FYI @akanter. Context: They are using the CIEL zip from OCL, and importing it from the /ocl/ folder in initializer. Other custom concepts that they create are being managed in /concepts.csv (and imported from initializer). Not yet editing any concepts via OCL right now. See config here.)
Actually I have even made a tiny PR for you here that should fix this issue for you, at least for now and until you are fully on OCL (you just need someone to merge this). (Burke noticed per the Standard HL7 Code list that LOINC should be LN so changed that in the PR as well.)
bahmni-core creating a concept source SNOMED with HL7 name as SCT where as CIEL import creating the concept source SNOMED-CT with HL7 name as NULL. We are retiring the concept source SNOMED and updating HL7 name for SNOMED-CT. Changes are here
When you say “CIEL import”, your actually referring to the Subscription Module, which is different from CIEL. It’s important to be clear about this: the OCL Subscription Module is designed to load concepts and mappings from Open Concept Lab. It is not designed to handle managing all of the things that might be in the OpenMRS Concept Dictionary.
One of those things that it doesn’t manage is concept sources. I would recommend using the Initializer concept source domain, as was done in Grace’s PR, instead of using a Liquibase changeset for this. Managing data via Liquibase tends to be a bad idea over the long term (this is different from managing schemas, which is more or less what Liquibase is designed to handle).
From OCL’s perspective, SNOMED is an external source (i.e., there isn’t a “SNOMED CT” source in OCL to attach that metadata to). Even if we solved this for SNOMED CT, we’d have similar issues come up when we had any external source referenced from OCL. Even if we added that metadata in, we’d then need to change the subscription module to understand how to consume that metadata. By which I mean to say, yes this is solvable, but it’s creating a lot of work to do something we already have a mechanism for doing without a lot of clear value (maintaining the HL7 code for sources referenced from CIEL seems a bit beyond the scope of what CIEL has been doing).
If we make this “configurable”, what would the suggested way in which we do so? (I.e. what are we configuring?).
That change looks right to me (though I’m not sure why you describe it specifically as a duration source. It is the source OpenMRS uses to understand durations, yes, but also has many other non-duration terms. The alternative to liquibase would be to use the conceptsource domain in Iniz, per the PR that @grace raised, but liquibase works if that’s the pattern you have been following.
That said, this might have been better solved with an enhancement to the OCL subscription module ( the openconceptlab module) to consider a mapping with a source in the OCL export json named SNOMED-CT to match any Concept Source in OpenMRS with an hl7_code = “SCT”. This would essentially fix the originally problem you were facing, and is actually a reasonable enhancement that might have broader benefit. @ibacher and @burke - thoughts on this ?
Can you describe why you think this is necessary? OpenMRS did not hard-code this SCT string accidentally. It is the standard HL7 code for SNOMED-CT as @burke pointed out on the platform call. Burke put a link in the zoom chat at the time that documented this from HL7 - I can’t access that chat anymore, but @burke or @grace could likely add a link to that document here. From OpenMRS’s perspective, having an implementation indicate which concept source has hl7_code = “SCT” is a standards-based way to identify this source and is not arbitrary or implementation-specific.