Side thread from the discussion from Bahmni: SNOMED vs SCT conflict:
@jamlung & @paynejd this doesn’t feel quite right. I realize we may need a paywall etc for SNOMED CT, but it should have a source in OCL, right? So that eg folks with license to use SNOMED CT can pull in codes, from that source, to their collections? Otherwise seems we’re running into issues, like the Bahmni team in the thread linked above. (In their case, I believe India has a license for SNOMED-CT, which I believe is driving their plan to leverage it. @gsluthra correct me if I’m wrong.)
Do you envision having SNOMED-CT as a source the same way as SNOMED-GPS is already a source?
If not a paywall, maybe a license acknowledgement similar to what SNOMED has on their browser?
(p.s. LMK if there’s a new OCL-specific discourse I should use; I’ve lost track of whether there’s a new forum for OCL)
I’m all in favour of having SNOMED CT in OCL if the licensing can be figured out, but from a purely OpenMRS perspective, I don’t know that we can support people directly pulling SNOMED CT codes into a collection and importing that into OpenMRS, because I’m not sure we can guarantee that SNOMED content matches the OpenMRS Validation Rules.
Hey @grace, we actually have already started to do some exploration and testing with SNOMED-CT in OCL. We have the ability to load that content into OCL, but because of the risk that may come with licensing restrictions, we ended up loading SNOMED-GPS into OCL instead. This seemed like a safe compromise until we could work more closely with SNOMED International to get their blessing, so to speak, for SNOMED-CT. In the future, I could see OCL doing something similar to what OHDSI does where we could display a disclaimer about licensing.
Given Ian’s input about whether OpenMRS can actually intake SNOMED-CT codes, it sounds like there may be other complications to work through too, but if the need is there to get SNOMED-CT into OCL, then we might want to discuss either pushing forward the SNOMED/OCL licensing talk OR talk about alternative options.
Also, though I am not entirely tuned in to this project and use case, I just wanted to note that mapping to SNOMED-CT can still occur, even if we don’t have the concepts in OCL. Even if the current state of OCL, you theoretically could create local concepts that could then be mapped to SNOMED-CT concepts.
Thanks this is a good point to re-iterate.
Yikes. This concerns me. This would be a big deal for many OMRS stakeholders - eg some big funders, some Ministries - who have occasionally mentioned to me that they have chosen SNOMED CT as their terminology of choice (though CIEL and ICD seem to be more common choices). @suruchi or @burke could you look in to whether this is the case, that OMRS can’t intake SNOMED CT concepts? If this is the case we should at least know.
India is a member country of SNOMED and hence use of SNOMED CT is free (although I am not sure of all legal details here).
See these two links:
- India member since 2014: https://www.snomed.org/our-customers/member/india
- NRCES slides about member benefits and how to apply: https://www.snomed.org/our-customers/member/india
In general, we want Bahmni to have an optional SNOMED CT addon and support, so that adoption by countries/facilities that are SNOMED aligned is easy. Therefore Bahmni team is working on OCL and SNOMED related integrations, and if OCL by-default supports SNOMED – it makes life for us easier
I would like to point out that CIEL provides SNOMED on almost every concept. SNOMED is not designed to be an interface terminology. There are many, many clinical concepts which do not map 1:1 to SNOMED. I recommend that we frame the CIEL source as a bridge to SNOMED and that SNOMED as a source is primarily for carrying the metadata linked to the mapped code IDs from CIEL. For example, CIEL does not provide SCT-SCT relationships which are critical for subsumption queries and reporting. You would need the SNOMED source to do that. CIEL is SNOMED from an implementation perspective and should not be seen as competitive or an unacceptable alternative.