Stream: terminology
Topic: multiple snomed versions
Grahame Grieve (Sep 27 2016 at 07:56):
An issue has come up for me updating my server to support multiple snomed editions, and I'm not sure how to handle it
Grahame Grieve (Sep 27 2016 at 07:57):
the issues comes up with closure tables. I maintain an implicit closure table in my server for each search parameter that refers to a codeable data type
Grahame Grieve (Sep 27 2016 at 07:59):
so if one user posts a condition with a code:
<code>
<coding>
<system value="http://snomed.info/sct"/>
<version value="http://snomed.info/sct/731000124108"/>
<code value="39065001"/>
</coding>
</code>
Grahame Grieve (Sep 27 2016 at 08:00):
and someone else posts this:
<code>
<coding>
<system value="http://snomed.info/sct"/>
<version value="http://snomed.info/sct/32506021000036107"/>
<code value="39065001"/>
</coding>
</code>
Grahame Grieve (Sep 27 2016 at 08:00):
are they the same?
Grahame Grieve (Sep 27 2016 at 08:01):
more particularly, are they both subsumed by the code 404684003?
Grahame Grieve (Sep 27 2016 at 08:02):
does it matter what edition you specify when you provide the code 404684003?
Grahame Grieve (Sep 27 2016 at 08:03):
and note, btw, that my server runs across jurisdictions... like other patient focused servers will.... and it's IHTSDO who want me to support multiple editions....
Michael Lawley (Sep 27 2016 at 08:28):
I would argue that since you are 1. comparing timestamp-less versions (a SNOMED special case) and 2. you are testing for equivalence (not subsumption), and 3. SNOMED supports concept permanence, then they are the same.
In fact, because this is a special case of same-ness and point 3 applies, then that's all you need.
On the other hand, of your test depends on the relationships in any way (ie is_a / subsumption), then concept permanence doesn't make any difference and you need to resolve to a specific version of the code system.
Michael Lawley (Sep 27 2016 at 08:31):
A work-around for this would be to maintain a "union version" such that all the versioned editions that it includes are based of the same International version (and thus they are all supersets) of that version, and therefore compatible.
Grahame Grieve (Sep 27 2016 at 08:54):
is such a union version alllowable? (I mean, under licensing terms). And if it is, does someone ... IHTSDO... maintain it?
Michael Lawley (Sep 27 2016 at 22:56):
As long as you have a valid licence for all the included versions, then yes.
To do this in an RF2-conformant manner you would need to create a new concept to represent the union edition (this would be an SCTID for a new module) and thus you'd need to have a namespace allocated to you so you can allocate the SCTID.
Note that this is essentially a heavyweight approach and obviously has limitations around cross-version comparisons when they fall into different union-version scopes.
Michael Lawley (Sep 27 2016 at 22:59):
There are some simple rules that might be considered that cover more cases, such as if the same subsumption relationship holds in each version independently, then it can be assumed to hold across the versions. i.e., if subsumes(A,B) is true in version X and subsumes(A,B) is true in version Y, then we can assume that subumes(<A,X>, <B,Y>) is true.
Grahame Grieve (Sep 28 2016 at 03:33):
I think there's a market for a tool that combines Rf2 distributions like this
Grahame Grieve (Sep 29 2016 at 20:09):
I am adding support for multiple SNOMED editions to the FHIR publication tools. THe main FHIR publication tooling will be fixed to the international edition of SCT. Implementation Guides will have to explicity nominate the edition they are based on
Grahame Grieve (Sep 29 2016 at 20:09):
within a module, I'm going to ignore the version attribute, and use the latest version of the edition I have available
Grahame Grieve (Sep 29 2016 at 20:09):
does anyone think that's a problem?
Michael Lawley (Sep 29 2016 at 23:58):
That sounds reasonable - will the output indicate the specific version that was used?
Alexander Henket (Sep 30 2016 at 11:17):
I always hear Rob McClure on C-CDA where they fix versions for certain ValueSets. We have always been fine with "the latest version" though.
Reuben Daniels (Sep 30 2016 at 13:20):
GG: I agree – that sounds reasonable. I would also like to know whether the output would indicate the specific version that was used.
Steve Emrick (Sep 30 2016 at 13:57):
@Grahame Grieve - the values of the <version> element you reference are what I would call RF2 Module IDs. I think of version as something like The July 2016 International Edition of SNOMED CT. Which thing are we talking about here?
Grahame Grieve (Sep 30 2016 at 15:58):
so there's 2 levels, the edition and the version. Edit ion = US Version or International Version etc. Within each edition is a version stream e.g. July 2016.
Grahame Grieve (Sep 30 2016 at 15:59):
Within editions, I'm going to ignore versions and use the latest version of whatever I support. (for the FHIR build tooling; this is not a rule for other usage)
Grahame Grieve (Sep 30 2016 at 16:00):
and the version used, both expand and lookup specify the version used, and I need to update the generated expansions to convey this information
Michael Lawley (Oct 04 2016 at 02:14):
@Steve Emrick The URIs GG is talking about are defined in the SNOMED CT URI Specification as identifying an Edition of SNOMED CT. The FHIR spec then says that if you use an Edition URI as a version string, then the terminology server can treat that as the latest (that it knows about) version of that Edition.
Grahame Grieve (Oct 04 2016 at 03:15):
can we make a variance to the URI string?
Grahame Grieve (Oct 04 2016 at 03:16):
http://snomed.info/sct/900000000000207008+731000124108+32506021000036107
Grahame Grieve (Oct 04 2016 at 03:16):
means combination of the 3 identified modules
Grahame Grieve (Oct 05 2016 at 02:34):
I have upgraded fhir3.healthintersections.com.au/open
Grahame Grieve (Oct 05 2016 at 02:34):
it now supports the international, US and AU releases of SCT. If you don't specify which version, it uses the international version. For now, it's not doing cross-edition reasoning
Grahame Grieve (Oct 05 2016 at 02:35):
This version also supports post-coordination with SCT
Rob Hausam (Oct 05 2016 at 02:37):
Thanks, Grahame. That's a great upgrade.
Peter Jordan (Oct 05 2016 at 03:42):
Any specifics on how you're supporting SCT post-coordination, Grahame - filtering expansions by query expressions? Any news on the $Compose operation?
Lloyd McKenzie (Oct 05 2016 at 04:45):
If you were able to get permission to host US, are you able to get permission to host other nations' releases too?
Grahame Grieve (Oct 05 2016 at 07:21):
i can host content for any nation that grants me a license. So far, I've asked for Intl, US and AU licenses, and I have permission for all 3. I will ask for other nations as people ask me to host them
Grahame Grieve (Oct 05 2016 at 07:21):
I support post-coordination in
- Coding.code
- $lookup
- $subsumes
- $validate-code
- $closure
Grahame Grieve (Oct 05 2016 at 07:22):
I do not support post-coordination in ValueSet.compose.include.filter.value, nor do I intend to
Grahame Grieve (Oct 05 2016 at 07:23):
with regard to $expand, I allow post-coordinated expressions in ValueSet.compose.include.concept.code, but I do not intend to start generating post-coordinated expressions to meet filter conditions
Lloyd McKenzie (Oct 05 2016 at 12:58):
Canada would be nice :)
Grahame Grieve (Oct 05 2016 at 16:34):
where do I apply?
Lloyd McKenzie (Oct 06 2016 at 00:27):
I'll try to make the necessary connections by email.
Grahame Grieve (Oct 06 2016 at 00:28):
ok
Michael Lawley (Oct 06 2016 at 05:02):
Re http://snomed.info/sct/900000000000207008+731000124108+32506021000036107 -- What does this actually mean?
Does it identifier just the content of (some version of) those three modules, or does it mean the content of those three editions (what versions of each, and what if they are incompatible)?
Michael Lawley (Oct 06 2016 at 05:04):
What does $lookup of a post coordinated code return?
Grahame Grieve (Oct 06 2016 at 05:05):
for now, the normal form, and a recommended display
Grahame Grieve (Oct 06 2016 at 05:05):
I intend to do decomposition next week
Grahame Grieve (Oct 06 2016 at 05:06):
that url means I am reasoning across all those editions e.g. expansion
Grahame Grieve (Oct 06 2016 at 05:06):
I'm not specifying versions, true.
Michael Lawley (Oct 06 2016 at 05:06):
Do you treat the expression as close-to-user form and apply all the implicit grouping transformations?
Grahame Grieve (Oct 06 2016 at 05:09):
Grahame Grieve (Oct 06 2016 at 05:09):
I believe that the answer is yes
Michael Lawley (Oct 06 2016 at 05:12):
I explicitly avoided defining such a URI form for two reasons:
1. (technically trivial) the need to define an explicit comparison method to allow for the modules to be specified in any order
2. (technically hard) the need to define the compatibility rules for mixing editions together. For example, how to deal with a US and AU verion that depend on different International versions. It also implies the need to be able to combine arbitrary things together on the fly, which is computationally expensive.
I'm more inclined to the utility of defining rules for cross-version reasoning.
Grahame Grieve (Oct 06 2016 at 05:14):
well, the problem for me is (a) I have to implement the rules (basically my business) and (b) I have to tell people what I'm doing
Grahame Grieve (Oct 06 2016 at 05:15):
it's been deemed wrong for me to create a moduleId for cross-version reasoning..... but I really don't know how to do this....
Grahame Grieve (Oct 06 2016 at 05:15):
e.g. if you ask me for an expansion, and you don't specify an edition, I'll do the expansion across all the editions
Michael Lawley (Oct 06 2016 at 05:19):
Having a cross-version edition seems like the standards-compliant way to do it. How would it be "wrong"?
Michael Lawley (Oct 06 2016 at 05:19):
We allow configuration of a default edition for the last case
Grahame Grieve (Oct 06 2016 at 05:23):
well, I asked IHTSDO how to go about getting a module Id - and I basically got outright refusal to accept the use case as grounds for a moduleId
Michael Lawley (Oct 06 2016 at 05:38):
First you need to get a namespace, then you can mint all the SCTIDs you need
Michael Lawley (Oct 06 2016 at 05:48):
On a pragmatic note, how often do you actually need cross-edition subsumption as opposed to International + a single extension? If it's just this special case, then you can just ignore the international edition since everything is (should be) a superset of it.
Grahame Grieve (Oct 06 2016 at 07:01):
well, to get my international server actually *correct*, I need to do it across all the editions I have loaded
Grahame Grieve (Oct 06 2016 at 07:01):
currently, intl + au + us, I've been asked to host CA too
Michael Lawley (Oct 07 2016 at 01:16):
Am I right in thinking you'll only ever be doing pair-wise comparisons? ie code A from edition X to code B from edition Y
Grahame Grieve (Oct 07 2016 at 01:27):
I don't know. what else might you do? most likely, pairwise comparisons will be part of some greater operation... how do you count them?
Michael Lawley (Oct 07 2016 at 07:23):
If A subsumes B in edition X and separately in edition Y, then you're ok.
If A & B both only exist in one edition (so one of them is a local extension concept), then just do the subsumption in that edition
Grahame Grieve (Oct 07 2016 at 09:28):
yes, true, but first I have to scan my various snomed editions to figure that out... and I'd rather not scan the editions, and reason across the correct mix each time, when that's work I'm going to do constantly. As an internal optimization, I choose to build a single snapshot
Grahame Grieve (Oct 08 2016 at 02:31):
why would different national releases report different module ids for concepts and descriptions?
Grahame Grieve (Oct 08 2016 at 02:48):
that is, for concepts and descriptions defined in the international release
Michael Lawley (Oct 08 2016 at 06:53):
Extensions are not supposed to change the international release (one exception being the Relationships file).
You might get the odd change where a national release decides to retire a concept they deem problematic, or correct a typo in a description, but this should be pretty rare.
Are the rows otherwise identical?
Grahame Grieve (Oct 08 2016 at 11:04):
here's an example:
Grahame Grieve (Oct 08 2016 at 11:04):
intl: 11000119105 20150131 0 900000000000207008 900000000000074008
au: 11000119105 20150131 0 900000000000207008 900000000000074008
us: 11000119105 20150301 0 731000124108 900000000000074008
Grahame Grieve (Oct 08 2016 at 11:05):
it's retired in all of them it looks like
Michael Lawley (Oct 08 2016 at 11:10):
These are SNAPSHOTS I presume. Technically the US one is not "wrong" because it's also got a different effectiveTime.
However, it seems both unnecessary and in technical violation of the licence which says you can't change the Int'l
Grahame Grieve (Oct 08 2016 at 11:11):
yes, snapshots
Grahame Grieve (Oct 08 2016 at 11:11):
well, I have a list of 21 concepts and about 120 descriptions where this has happened
Grahame Grieve (Oct 08 2016 at 11:12):
does it matter to anyone? I can't think of any reason I actually care?
Michael Lawley (Oct 08 2016 at 11:37):
Are they all otherwise identical (except for effectiveTime)? If so, then I can't imagine anyone cares except ppl like you & me when we're trying to get some kind of sanity around cross-edition/version reasoning
Michael Lawley (Oct 08 2016 at 11:38):
But still worth a query back to US national release center asking why
Grahame Grieve (Oct 08 2016 at 12:20):
AU does it too
Module SNOMED CT USA changes module of concept 11000119105 from 900000000000207008 to 731000124108
Module SNOMED CT USA changes module of concept 441000119109 from 900000000000207008 to 731000124108
Module SNOMED CT USA changes module of concept 601000119109 from 900000000000207008 to 731000124108
Module SNOMED CT USA changes module of concept 1111000119100 from 900000000000207008 to 731000124108
Module SNOMED CT USA changes module of concept 1561000119105 from 900000000000207008 to 731000124108
Module SNOMED CT Australia changes module of concept 246089008 from 900000000000207008 to 161771000036108
Module SNOMED CT Australia changes module of concept 246221002 from 900000000000207008 to 161771000036108
Module SNOMED CT Australia changes module of concept 260670006 from 900000000000207008 to 161771000036108
Module SNOMED CT Australia changes module of concept 263512003 from 900000000000207008 to 161771000036108
Module SNOMED CT Australia changes module of concept 263513008 from 900000000000207008 to 161771000036108
Module SNOMED CT Australia changes module of concept 384612007 from 900000000000207008 to 32506021000036107
Module SNOMED CT Australia changes module of concept 384613002 from 900000000000207008 to 32506021000036107
Module SNOMED CT Australia changes module of concept 396174004 from 900000000000207008 to 32506021000036107
Module SNOMED CT Australia changes module of concept 447564002 from 900000000000207008 to 161771000036108
Module SNOMED CT Australia changes module of concept 449609005 from 900000000000207008 to 161771000036108
Module SNOMED CT Australia changes module of concept 700043003 from 900000000000207008 to 161771000036108
Module SNOMED CT Australia changes module of concept 11000119105 from 731000124108 to 900000000000207008
Module SNOMED CT Australia changes module of concept 441000119109 from 731000124108 to 900000000000207008
Module SNOMED CT Australia changes module of concept 601000119109 from 731000124108 to 900000000000207008
Module SNOMED CT Australia changes module of concept 1111000119100 from 731000124108 to 900000000000207008
Module SNOMED CT Australia changes module of concept 1561000119105 from 731000124108 to 900000000000207008
Michael Lawley (Oct 08 2016 at 12:31):
Strange, although some a spurious; 731000124108 is not an AU or Int module so "Module SNOMED CT Australia changes module of concept 11000119105 from 731000124108 to 900000000000207008" is misleading
396174004 is mg/m2 and is interesting because AU made it inactive in March this year, but then later made it active again
Grahame Grieve (Oct 08 2016 at 19:11):
and then there's this; Module SNOMED CT USA changes value of description 891000119115 from "Lesion of skin of face (finding)" to "Lesion of skin of face (disorder)"
Last updated: Apr 12 2022 at 19:14 UTC
