SNOMED-CT as a source?

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?

1 Like

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

1 Like

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.

1 Like

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.

1 Like

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:

  1. India member since 2014: https://www.snomed.org/our-customers/member/india
  2. 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 :slight_smile:

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.

2 Likes

Hello All,

A few points I would like to add:

  1. IPS Set: There is a free (Creative Commons License) terminology set released by SNOMED called: IPS (International Patient Summary). The IPS Terminology is the next evolution of the IPS free set, providing advanced terminology features for non-Affiliates to use in their IPS implementations. The full content of the IPS Terminology can be browsed here: SNOMED International IPS Browser. Read more about IPS here: https://www.snomed.org/international-patient-summary-terminology. I feel this set, should be in OCL (since this is the one that SNOMED encourages non-affiliated member countries to use).

  2. The IPS set is also a good choice for low-resource settings which want to run a mini version of the SNOMED Terminology Server (since terms are about 50K in IPL).

  3. Bahmni has done first cut integration of both OCL (using OCL Subscription module), and of SNOMED TS (over FHIR), which means any member country that wants to try Bahmni with SNOMED CT (snowstorm) can now browse diagnosis, reports, form-fields by configuring Bahmni to point to opensource Snowstorm server. Demos for this will be online soon here: https://bahmni.atlassian.net/wiki/spaces/BAH/pages/3132686337/SNOMED+FHIR+Terminology+Server+Integration+with+Bahmni

  4. It would be a good idea if OCL could ship with complete SNOMED-CT, but I agree with @akanter – from an interface perspective, many SNOMED terms will make the EMR complicated for data entry, and from past experience, it seems most facilities want to use a small set of terms in their facility. Also, it is better to use terms on the screen that people are familiar with, and instead use reference-term mappings to display SNOMED/LOINC/ICD-10 codes. It will also slow down the UI experience, because huge number of terms will match the entered sub-string. Also, legally, it is complicated for sure. In this case, the IPS mentioned above is better. It has been created keeping in mind the most commonly used terms across SNOMED CT deployments.

  5. By default, currently Bahmni has chosen to ship with CIEL out-of-the-box, because it offers the best balance between, ease-of-interface-use, mappings to multiple reference, opensource, and first class maintenance by OpenMRS community+OCL. We find that most implementations choose to use their own custom concepts, and we hope with CIEL, people will adopt it and make minor additions at max.

@kai – Maybe you can provide some perspective to this discussion from SNOMED International perspective. Thanks!

I very much agree with this (PARTICULARLY POINT 5). I would include some additional points:

  1. I believe the IPS does not include the hierarchies or relationships between the codes (just the reference term and code). I am not sure how CDSS can be performed without a full SNOMED license unless it is hard coded to the IPS codes.

  2. SNOMED is designed to be post-coordinated. Not all concepts are present as single terms. 50% of CIEL concepts are not SAME-AS a single SNOMED code. 33% of PIH concepts are not SAME-AS. I was not able to document “sore throat” or “dry cough”.

  3. There are use cases for multiple code maps from a single data element. ICD-10/SNOMED, ICHI/SNOMED, RxNORM/SNOMED, etc. Capturing data only with SNOMED then depends on maintenance of cross-map tables which are never as accurate as interface terminology mappings (CIEL to SNOMED, CIEL to ICD-10).

  4. Rolling up of specificity to broader SNOMED concepts may be fine for reporting, but is not likely to be fine for CDSS like SMART guidelines. SAME-AS concepts are required for proper sensitivity and specificity of CDSS. CIEL provides a bridge between the concept and the multiple SNOMED code(s) or ICD codes required.

I would very much value a presentation of the current work on an upcoming PAT call when we can evaluate what has been achieved, and whether the value of directly using SNOMED rather than using the concept dictionary maps TO SNOMED is workable.

I just wanted to jump into the conversation and provide some further information from the team here at SNOMED International to inform the discussion hopefully. We are working with the Bahmni team to understand how SNOMED CT can be used in OpenMRS more directly through FHIR, partly to help us learn more about how we can continue to enhance SNOMED CT to better help EMR implementers but also to provide access to SNOMED CT to those who may not have considered it previously.

Whilst there is a license when using the full SNOMED CT International Edition, we have several products available under a Creative Commons (CC BY 4.0) license that are made up of parts of the full terminology. Of these, the IPS Terminology mentioned earlier in this thread is likely to be the most interesting here as it is a standalone terminology, with all the relationships and hierarchies for those concepts in the IPS.

With regards to postcoordination, SNOMED CT is designed for post-coordination, and we have a helpful guide on when postcoordination is beneficial, but there is also extensive medical knowledge coverage across the ~360,000 pre-coordinated concepts and more than 1.5 million terms, including those listed in the thread. However, we always look to work with the wider community to add missing terms, and we would be very grateful for any of your feedback on missing content.

SNOMED International publishes updated maps, including maps to ICD-10, ICD-O, MedDRA, etc, although we cannot speak for maps in the other directions, so the CIEL may be more appropriate today in that scenario. Our experience has shown that SNOMED CT’s frequent updates can sometimes make intermediary maps hard to maintain, hence our recommendation to use SNOMED CT natively with a FHIR terminology server, but we also understand that not every situation warrants SNOMED CT as the native coding solution.

We were a little confused about the statements that SNOMED CT might not be fit for CDSS-like SMART guidelines, as we know of CDSS deployments that use SNOMED CT specifically. However, we would be grateful for feedback that will help us fill any gaps we have missed.

We are early in our work with Bahmni and OpenMRS, and we hope and intend to contribute to the community as well as learn from you all, so please excuse any missteps on our part, and please do give us any feedback on the use of SNOMED CT in OpenMRS.

2 Likes

Thanks, Rory! Appreciate the feedback and was unaware that the IPS contains the appropriate hierarchies and relationships (not just to codes and descriptions). I need to update my understanding! As for the use of SNOMED as a point-of-care terminology service… as someone who has been working with SNOMED and pushing SNOMED use for 25 years, I have yet to be convinced that it makes sense for a reference terminology like SNOMED to be pushed directly to the point of care, particularly for unique environments like LMICs. I guess that is what we will learn from this experiment (but I want us to be fully transparent with lessons learned). Maps from single concepts within a reference terminology to another reference terminology (or admin terminologies like ICD-10) will always underperform conceptual mappings from pre-coordinated interface terms. I am concerned that tying users to a reference-based terminology server (rather than OCL or other server which allows for the sort of customizations which I have outlined before) will either lose clinical specificity or frustrate users.

I want to be clear that I am a strong supported of SNOMED CT and have been personally involved in getting the majority of the US using SNOMED through their EHRs. I need to be convinced that my implementation experience is wrong when it comes to my other passion… OpenMRS.

Lastly, on the CDSS front, my recent experience has been with the WHO SMART guideline efforts where there are substantial numbers of concepts that do not have SAME-AS SNOMED primitive representation (single codes).

See my latest comments/questions after seeing the demo part 1: Bahmni PAT call on 17-May-2023 - #22 by akanter

And in regards to triggering CDSS see: Bahmni PAT call on 17-May-2023 - #24 by akanter