Stream: terminology
Topic: SNOMED srt
Grahame Grieve (Nov 23 2017 at 23:58):
@David Clunie has very kindly encoded up the DICOM value sets in a FHIR format (yay!)
Grahame Grieve (Nov 23 2017 at 23:58):
ftp://medical.nema.org/medical/dicom/Resources/valuesets/fhir/xml
Grahame Grieve (Nov 23 2017 at 23:58):
DICOM use the old Snomed identifiers (I believe that this ok for a little while longer)
Grahame Grieve (Nov 23 2017 at 23:59):
I've just been checking them, and I see this:
<compose>
<include>
<system value="http://snomed.info/srt"/>
<concept>
<code value="R-40819"/>
<display value="Internal"/>
</concept>
Grahame Grieve (Nov 24 2017 at 00:01):
according to http://build.fhir.org/snomedct.html:
Grahame Grieve (Nov 24 2017 at 00:01):
The following SNOMED CT artifacts are valid in the code element for the http://snomed.info/sct namespace: Concept IDs , Expressions (grammar ) and SNOMED Legacy codes .
Grahame Grieve (Nov 24 2017 at 00:02):
So I think that the system value should be http://snomed.info/sct not http://snomed.info/srt
Grahame Grieve (Nov 24 2017 at 00:02):
does anyone disagree?
Grahame Grieve (Nov 24 2017 at 00:16):
@David Clunie - other than this.... all looks good
Jim Steel (Nov 24 2017 at 00:31):
It would be great to get zips of the files (or bundles)
Michael Lawley (Nov 24 2017 at 01:03):
I don't think it's helpful to re-use http://snomed.info/sct for these codes. They are deprecated by SNOMED International and are not SCTIDs or UUIDs (the only valid component identifiers). I think it would be more useful to define http://snomed.info/srt for these and include 900000000000498005 as one of the implicit concept maps
Grahame Grieve (Nov 24 2017 at 01:14):
they are unique. has snomed defined http://snomed.info/srt?
Michael Lawley (Nov 24 2017 at 01:21):
No, but I'd be happy to facilitate that
Michael Lawley (Nov 24 2017 at 01:25):
I'm kind of torn on this to be honest. I think this https://confluence.ihtsdotools.org/display/DOCCMG/4.6.2+Migration+from+SNOMED+International is saying that they're still valid concept ids and that they are enumerated in the 900000000000498005 map refset. But it then raises the issue of what their location in the hierarchy is, what their display and designations are, etc etc
Michael Lawley (Nov 24 2017 at 01:29):
But...it is called something different (both SNOMED International and SNOMED RT) as distinct from SNOMED CT
Michael Lawley (Nov 24 2017 at 01:31):
And this language from the SNOMED Change Management Guide also suggests they are distinct:
This section contains specific advice related to migration to SNOMED CT from previous SNOMED CT code systems including SNOMED RT and SNOMED International.
So both pragmatically and justifiably I believe a formally separate code system is reasonable.
Grahame Grieve (Nov 24 2017 at 01:40):
well, from my point of view, the most useful part of differentiating them is that I don't think that people area aware that a value set that includes http://snomed.info/sct includes the RT codes as well (even though we do specifically say that)
David Clunie (Nov 24 2017 at 01:55):
Just to be clear these identifiers do refer to SNOMED CT concepts, i.e., are different codes for the same concepts.
Grahame Grieve (Nov 24 2017 at 02:07):
that's true
Grahame Grieve (Nov 24 2017 at 02:07):
thought not all concepts have these codes, right?
Michael Lawley (Nov 24 2017 at 02:18):
@David Clunie I'm not really sure that's true. It depends what you mean by "concept". Certainly the map is a statement of (I believe) equivalence, but I'm fairly convinced that the codes belong to different code systems.
Grahame Grieve (Nov 24 2017 at 02:18):
in what way do they not represent the same concept?
Michael Lawley (Nov 24 2017 at 02:19):
Not all SNOMED CT codes have a corresponding SNOMED International code. Not quite sure about the reverse.
Grahame Grieve (Nov 24 2017 at 02:19):
(deleted)
Michael Lawley (Nov 24 2017 at 02:28):
I note that at the Bratislava SNOMED meeting last month one of the agenda items was formally deprecating these codes
Michael Lawley (Nov 24 2017 at 02:29):
http://www.snomed.org/news-articles/timetable-for-the-withdrawal-of-legacy-snomed-codes
http://www.snomed.org/snomed-ct/what-is-snomed-ct/previous-versions-of-snomed-ct
Michael Lawley (Nov 24 2017 at 02:32):
So, since April 26 this year, it is not legal to create new data using SNOMED RT codes (decision was made & announced in 2009)
Grahame Grieve (Nov 24 2017 at 02:33):
irrespective, legacy data isn't going go away in any hurry.
Michael Lawley (Nov 24 2017 at 02:33):
@Grahame Grieve Are you proposing (what I would like) that RT codes are no longer included in http://snomed.info/sct valueset?
Grahame Grieve (Nov 24 2017 at 02:34):
no, on balance, after thinking about this discussion I'm not.
Michael Lawley (Nov 24 2017 at 02:35):
Yes, legacy data remains a valid use-case. I'm not convinced the SNOMED International plans for content distribution are going to be helpful :weary:
Michael Lawley (Nov 24 2017 at 02:43):
Ok, so what does this mean for terminology servers. e.g., $lookup should treat these RT codes how? What display text do they have (eg for $validate-code), do they have parent/child properties, etc
David Clunie (Nov 24 2017 at 02:50):
All of the SNOMED CT concepts used in DICOM do have old-style RT codes (there is absolutely no question that they are the same "concepts") and for the time being we (DICOM) haven't figured out how to switch to the new style codes without invalidating without invalidating the installed base of DICOM devices that depend on them, regardless of SNOMED policy. That does not mean, of course, that FHIR implementations have to do the same ... the value sets could include the SCT mappings too (or instead).
Grahame Grieve (Nov 24 2017 at 02:53):
well, it is an interesting question whether the imaging type FHIR resources should contain concept ids or RT codes. But it's principally a NEMA question, I think. Resources should be able to contain RT style codes irrespectively, and the terminology infrastructure should be able to cope.
Grahame Grieve (Nov 24 2017 at 02:54):
my take on the lookup question:
Grahame Grieve (Nov 24 2017 at 02:55):
GET [base]/CodeSystem/$lookup?system=http://snomed.info/sct&code=R-40819
Grahame Grieve (Nov 24 2017 at 02:55):
should work, and return:
Grahame Grieve (Nov 24 2017 at 03:04):
{
"resourceType" : "Parameters",
"parameter" : [
{
"name" : "name",
"valueString" : "SNOMED CT"
},
{
"name" : "version",
"valueUri" : "[whatever]"
},
{
"name" : "display",
"valueString" : "Internal"
},
{
"name" : "code",
"valueString" : "260521003"
},
{
"name" : "http://snomed.info/sct/900000000000498005",
"valueCode" : "R-40819"
}
]
}
Michael Lawley (Nov 24 2017 at 03:26):
So you have an implicit conversion to the SCTID happening?
Grahame Grieve (Nov 24 2017 at 06:16):
it's just another code for the concept
Rob Hausam (Nov 24 2017 at 06:36):
I want to point out that these legacy SNOMED identifiers were not introduced in or specifically dependent on SNOMED RT, so I don't think that http://snomed.info/srt really makes sense to use as the url for them. The legacy identifiers were originally from SNOMED International, prior to the introduction of SNOMED RT (the SCTID was introduced in RT), but they also continued to be generated and were included in both SNOMED RT and CT (until RF2 was introduced). I'm not sure what the best url for them is, but maybe it could be something like http://snomed.info/snm.
Michael Lawley (Nov 25 2017 at 01:45):
Given that the artifact that supports these legacy codes is called "SNOMED RT ID simple map", it does seem reasonable to call them http://snomed.info/srt (and may be very confusing if the link to the name "SNOMED International" is retained since that is now overloaded as the new name for the IHTSDO)
Eric Haas (Nov 25 2017 at 02:05):
I like the idea of a separate code system. Since is avoids equivalent codes issue, but then GG would have to change is answer above.
Rob Hausam (Nov 29 2017 at 11:21):
@Michael Lawley, I hadn't actually picked up that the name of the refset for the legacy ids is 'SNOMED RT identifier simple map'. I'm not entirely sure why they call it that, but since they do I agree that it is a good argument in favor of using http://snomed.info/srt for the url.
Michael Lawley (Nov 29 2017 at 22:09):
I'm hoping that @Linda Bird or someone else from SNOMED International may provide input on this now that I've raised it in the SNOMED on FHIR group
David Clunie (Nov 30 2017 at 13:00):
I will go back to using http://snomed.info/srt rather than http://snomed.info/sct for now, until advised otherwise.
Jeremy Rogers (Dec 11 2017 at 15:10):
Nope. Not OK: use of all SNOMED antecedent versions - including SNOMED RT - to support new clinical data capture is formally unlicensed since April this year, except for research purposes and to enable the interpretation of historical data already captured using those antecedent versions.
See https://www.snomed.org/snomed-ct/what-is-snomed-ct/previous-versions-of-snomed-ct
https://www.snomed.org/news-articles/timetable-for-the-withdrawal-of-legacy-snomed-codes
Jeremy Rogers (Dec 11 2017 at 15:43):
The 900000000000498005 refset no longer ships as part of current international RF2 data releases. It used to, until the Jan 2017 release, but is now withdrawn entirely as part of SI trying to drive through the withdrawal of the antecedent versions. So, if you have a SNOMED RT identifier from historical data and you now want to work out what the equivalent SNOMED CT identifier is, this operation has now already become an extremely complex piece of archeology: even with the last published version of that refset (from within der2_sRefset_SimpleMapSnapshot_INT_20170131.txt) , you'll find that 106,341 of the 432,470 SNOMED RT IDs listed therein (24.6%) were last seen attached to a SNOMED CT conceptId that has already become inactive in today's SNOMED CT, meaning that your ability to taxonomically report on these direct 'mapped' SNOMED CT equiv codes is in fact seriously compromised, unless and until you also unravel the historical SAME_AS relationships etc etc.
Jeremy Rogers (Dec 11 2017 at 16:22):
And no, not every SNOMED ID even ever had a 'map' to SNOMED CT. 5223 of the 132,517 SNOMEDIDs published in the very last SNOMED RT release don't appear in the 900000000000498005 refset at all.
[The particular code at the start of this thread - R-40819 - wasn't even ever a SNOMED RT identifier, there having never been a single code that was part of SNOMED RT (or SNOMED II, 3 or 3.5) beginning with an 'R-' character sequence.]
Jeremy Rogers (Dec 11 2017 at 16:35):
There IS an entry in the old Jan 2017 release of the 900000000000498005 srefset, asserting that 'R-40819' has some kind of correspondence with 260521003|Internal (qualifier value)|. 87,927 other rows in that same srefset also claim to state a map or code equivalence between an 'R' series SNOMED ID and some modern day SNOMED CT conceptId. But none of those R-series SNOMEDIDs appear in the final release of SNOMED RT itself that Kent Spackman gave me way back (there having never been a Chapter R, as I said...) and so they don't validate as bona fide SNOMED RT codes depending on what SNOMED RT reference you have. I note that many of them were only added very recently - long after SNOMED RT development stopped - and so I suspect they are actually ALL fake SNOMED RT identfiers that SI were in the habit of adding in order that the SNOMEDID slot in the old RF1 tables still contained a string and not a null, even though the strings being inserted were never officially SNOMED RT codes at all. Similar to all the CTV3 codes beginning XU furnished by another refset shipped as part of the same release file, none of which are legit CTV3 codes despite what the relevant refset is called.
Grahame Grieve (Dec 11 2017 at 19:40):
well, that's a mess, but doesn't really clarify whether to use a new system or not?
Jeremy Rogers (Dec 12 2017 at 10:33):
I would expect SI to politely decline to support a http://snomed.info/srt URI, since this isn't compatible with their signalling almost a decade ago that could no longer support the antecedent terminologies on grounds of clinical safety. But assuming they agreed, you would then expect it to only recognise/validate the official final set of SNOMED RT identifiers, and not also the >300k pseudo-SRT identifiers - such as all those beginning with an R - that you can find populating the SNOMEDID column of Ye Olde RF1 sct1_concepts distro, or listed in the now withdrawn 900000000000498005 srefset that was, in truth, never a 'map' despite its name.
The full set of 432k SNOMEDID identifiers previously listed within 900000000000498005, which have now bled over into specifications like DICOM, are clearly not exclusively IDs derived properly from SNOMED RT. Only 127,294 of them are true equivalence/mapping references to identifiers that actually do belong primarily to that external antecedent terminology (which only ever contained 132,517 different concepts) and within which those external codes also originally had a different extensional definition (parents, children, siblings in the SRT taxonomy). The huge majority of them - 305,176 - are actually true, simple, alternate concept identifiers within SNOMED CT itself and that never had any other meaning in any other scheme.
Given this split, what identifiers would you expect to validate against <system value="http://snomed.info/srt"/> ?
Grahame Grieve (Dec 12 2017 at 13:18):
well, firstly, we are talking about legacy data here. There's a little bit of it. So there's no reason for SI to not support an srt namespace. We're not making any difference to policy.
Grahame Grieve (Dec 12 2017 at 13:19):
I don't know the answer to which sub-set of identifiers we are talking about; you've very effectively muddied the waters, and it's not my data that contains the codes in question
Rob Hausam (Dec 12 2017 at 14:28):
Yes, Jeremy's points are well taken. I agree that SI should provide some means of supporting legacy data, and hopefully they will. I think that namespaces and urls could be created for the relevant sets and versions. That would be mostly legacy SNOMED II/Int., I think. I don't think that SNOMED RT itself was ever used much, but some of it's legacy ids and the other new "legacy" ids created in SNOMED CT possibly could be in use. The UK and NZ can worry about the Read codes and CTV3. :)
Peter Jordan (Dec 12 2017 at 19:01):
In our case, just the Read Codes.:simple_smile:
Grahame Grieve (Dec 12 2017 at 19:12):
and DICOM which used SRT codes for ever, including the R- codes with the problems. @David Clunie might want to comment
David Clunie (Dec 13 2017 at 14:22):
The legacy IDs are definitely in use in the installed base of DICOM devices. There are estimated to be tens or hundreds of billions of DICOM images in archives globally, for what that is worth (though not all include SNOMED codes). E.g., every mammogram in the world includes at least T-04000 Breast, as well as view codes, etc. (R-10226 medio-lateral oblique). So for FHIR ImagingStudy ...
Michael Lawley (Dec 13 2017 at 23:26):
My understanding of the SNOMED position is that the codes in image archives are perfectly fine (i.e., it is a valid, non-licence-breaching use), but the creation of new images with these codes is the problem. Certainly this would be true for new devices, which would be subject to the newer licence conditions. I have no knowledge of the licence conditions for older devices and whether they allowed the terms to be varied in the future (ie now, or even as far back as 2009 when the retirement plan was first announced)
Michael Lawley (Dec 13 2017 at 23:27):
Just noticed this thread is moving to https://chat.fhir.org/#narrow/stream/snomed/subject/SRT
Rob Hausam (Dec 15 2017 at 01:46):
yes, let's continue it there
Last updated: Apr 12 2022 at 19:14 UTC
