Stream: terminology
Topic: Final call for description ids
Richard Kavanagh (Jan 31 2020 at 14:37):
Having read(and re-read) the various topics pertaining to the use of SNOMED descriptions ids, and their relevance in semantic interop. I thought it was worth one final call to see if there is a way to solve my use case within the realms of a FHIR based terminology server, if not then I guess I'll need a more bespoke approach.
Within the UK, we are receiving data that was originally coded using Read2. As part of the move towards SNOMED,m the majority or Read2 codes have been mapped to SNOMED concepts, more specifically via a specific description Id.
As such when we receive the data from a 3rd part it has both the Read code and SNOMED Description Id. as a precursor to us processing via SNOMED's ECL capabilities, we need to find the corresponding concept Id.
We can get close to finding the concept it, but the final hurdle involves us looking up the target concept id to discover its associated synonyms. Using the $lookup operation we can retrieve the synonyms but not the description ids.
I think we have hit a brick wall and now need to stray outside of FHIR - unless I have missed something.....
Kevin Mayfield (Jan 31 2020 at 16:36):
Out of curiosity. why do we need descriptionId's. I've not used synonyms in SNOMED, only READ (and we'd often go from synonym to code with no Id's)
Grahame Grieve (Jan 31 2020 at 19:12):
There's something I don't understand here. You said:
we need to find the corresponding concept Id.
ok. I understand that, and why. Then you said:
the final hurdle involves us looking up the target concept id to discover its associated synonyms.
can you explain why you need to look up associated synonyms?
Using the $lookup operation we can retrieve the synonyms but not the description ids
But why does that matter? you're looking up concept its, not description ids?
Michael Lawley (Feb 01 2020 at 01:11):
I too am confused. It sounds like you already have a READ2 -> SNOMED DescriptionId map and you need to go from SNOMED DescriptionId to ConceptId. My inclination for this would be to transform the SNOMED RF2 Descriptions file into a FHIR ConceptMap (and only for the subset of DescriptionIds that are referenced in the READ2 map). Then you can do a two-step $translate to go READ2 -> SCT Description -> SCT Concept.
You'll need to invent your own CodeSystem & ValueSet URIs for the "code system" of DescriptionIds (because they are NOT part of http://snomed.info/sct as far as FHIR is concerned), but you shouldn't need (at least with Ontoserver) to create explicit CodeSystem & ValueSet resources for them just to use the ConceptMap.
Richard Kavanagh (Feb 04 2020 at 08:48):
@Grahame Grieve @Michael Lawley Thanks for your responses - I should have been clearer. We have a situation whereby we receive SNOMED description ids from a source. We need to get back to the concept id so we can use ECL.
.
There are three scenarios that we have:
1) The description id is the one published as part of the RFead2->SNOMED map. For this as @Michael Lawley suggest we can construct a concept map to assist.
2) The description id we receive is not the one from the published map, but instead another synonym. For example, the user may now be using the preferred term rather than the "official" mapped term.
3) The user may send through a description id for a concept that has nothing to do with the Read2->SNOMED as their systems move to more "native" use of SNOMED.
Richard Kavanagh (Feb 04 2020 at 08:51):
I appreciate that the root cause is that they should not really be sending the Description Id (at least not on its own) - but as a 3rd party, there is little I can do to change that.
Last updated: Apr 12 2022 at 19:14 UTC
