FHIR Chat · CodeSystem Supplements with SNOMED · terminology

Stream: terminology

Topic: CodeSystem Supplements with SNOMED

Richard Kavanagh (Jul 24 2020 at 14:48):

I'm trying to create some CodeSystem supplements to add some properties to certain SNOMED concepts. So far, I don't seem to be able to get this to work (using OntoServer)

So a few questions:

• Should CodeSystem supplement work with SNOMED ?
• Would the CodeSystem to supplement be "http://snomed.info/sct", or would it need a full canonical URL (including version)?
• If yes to the above, what does that look like for SNOMED?

thanks

Robert McClure (Jul 24 2020 at 18:42):

@Michael Lawley Thoughts?
Interesting question regarding what to put into the version identifier. I'm not sure... WRT, the canonical url I would think that it would be the standard SCT url. This once again highlights that for terminology artifacts the canonical url is not sufficient to identify the artifact. For code systems it seems you need to look at version and codesystem.content to understand what you are looking at. And even then, how can you tell the various supplements from each other based on elements you can reliably find? @Grahame Grieve @Rob Hausam

Grahame Grieve (Jul 24 2020 at 20:38):

@Robert McClure I don't understand your comments.

Grahame Grieve (Jul 24 2020 at 20:42):

@Richard Kavanagh

• in principle a code system supplement should work with SNOMED but it's up to the system whether it supports that. tx.fhir.org doesn't - I don't (yet?) allow supplements for code systems not defined using a code system resource
• the codesystem to supplement is a canonical URL. So the URL is http://snomed.info/sct.
• if you want a version specific supplement, then you'd use the canonical URL version form: http://snomed.info/sct|[ver] where [ver] is a full URL of an edition or an edition/version, as specified in the snomed page

so:

 "supplements" : "http://snomed.info/sct|http://snomed.info/sct/999000021000000109/version/20200731",

Richard Kavanagh (Jul 24 2020 at 21:38):

Thanks @Grahame Grieve I'll see what the CSIRO folk have to say next week. I tried various options on CodeSystem.supplements including the options you suggested. So either I'm doing something wrong (possible :grinning: ) or OntoServer does not support this for SNOMED.

Grahame Grieve (Jul 24 2020 at 21:40):

probably the second. Part of my rationale for not supporting it is that I expect snomed supplements to be distributed in RF2. (not that I support that either right now :sad:). But it's certainly not wrong to do what you're trying to do

Michael Lawley (Jul 24 2020 at 22:08):

Ontoserver 6 does support supplements (even for SNOMED and LOINC), but currently requires you to specify the version, as per the syntax Grahame shows above.

Richard Kavanagh (Jul 24 2020 at 22:15):

Thanks @Michael Lawley clearly I am doing something wrong then.

Richard Kavanagh (Jul 24 2020 at 22:16):

Great news that it supports it though.

Michael Lawley (Jul 24 2020 at 22:18):

You also need to use https://www.hl7.org/fhir/extension-valueset-supplement.html in your ValueSet so that Ontoserver knows that it should use the supplement

Grahame Grieve (Jul 24 2020 at 22:19):

you should be able to also ask for that in the expansion/validation parameters, and languages should be picked up automatically if you specify the right language

Michael Lawley (Jul 24 2020 at 22:21):

What is the parameter to $expand for this?

Richard Kavanagh (Jul 24 2020 at 22:22):

So a general question re the supplements then. I have a need to add some properties to various SNOMED concepts. TO do this I am doing the following

• Create several VS with ECL expressions
• Expanding each VS to get the concepts
• For each expanded VS then create a CodeSystem supplement, listing each concept code from the previous step

It seems slightly long-winded but as you cant use ECL in the definition of the supplement I'm not seeing a quicker way

Grahame Grieve (Jul 24 2020 at 22:22):

I don't think we've defined one yet

Michael Lawley (Jul 24 2020 at 22:24):

Are you trying to add a property(ies) to each concept that matches some ECL?
Supplements really are just a static list if concepts with their additional properties / designations; there's no mechanism to do "rule-based" things

Richard Kavanagh (Jul 24 2020 at 22:24):

Michael Lawley said:

You also need to use https://www.hl7.org/fhir/extension-valueset-supplement.html in your ValueSet so that Ontoserver knows that it should use the supplement

Ah - that's thrown me. I clearly misunderstand how the supplements are designed to work. I thought that if I created a supplement that added a property, then did a codesystem $lookup on the concept I would see the property.

Grahame Grieve (Jul 24 2020 at 22:25):

I think that's true, yes

Michael Lawley (Jul 24 2020 at 22:26):

The problem with that is then every supplement would compete/combine with every other supplement

Grahame Grieve (Jul 24 2020 at 22:27):

why is that a problem?

Grahame Grieve (Jul 24 2020 at 22:27):

for $lookup specifically?

Michael Lawley (Jul 24 2020 at 22:30):

probably not so bad for $lookup, but you would probably also want to know which properties came from which supplements, and I can see it sewing confusion when $lookup says something about a property but then a ValueSet doesn't match because the appropriate supplement isn't in scope.

Grahame Grieve (Jul 24 2020 at 22:30):

agree that the supplement source of a property should be clear

Michael Lawley (Jul 24 2020 at 22:34):

Until there's more experience with using them, requirements, use cases, etc we've gone for a (conservative) approach of requiring an explicit signal to bring a supplement into scope.

Peter Jordan (Jul 24 2020 at 22:38):

An individual CodeSystem resource can only have one Content Mode. My questions is that if a $lookup request is made in relation to a resource whose Content Mode is 'supplement' what properties should be available - just the supplementary ones, or the default properties for other Content Modes as well?

Grahame Grieve (Jul 24 2020 at 22:42):

what's the explicit signal for a look up? (that's why it should be automatic for that operation - unlike value set operations)

Grahame Grieve (Jul 24 2020 at 22:42):

we haven't talked about what it means to do a look up against the supplement itself

Michael Lawley (Jul 24 2020 at 22:42):

You're not allowed to use the supplement's URI as the value for system, and instance-based $lookup is not defined, so I don't think you can legally do a lookup agains a supplement directly

Michael Lawley (Jul 24 2020 at 22:44):

There is no explicit signal for $lookup, but if we had a parameter for $expand to indicate the supplements to use, then we could also use that for $lookup

Richard Kavanagh (Jul 24 2020 at 22:48):

Well that's scuppered my plans :grinning: @Michael Lawley perhaps I could drop you a note next week to say what we are trying to achieve and you can let us know whether OntoServer can do it. If not time to rustle up a plan B..

Michael Lawley (Jul 24 2020 at 22:49):

absolutely

Robert McClure (Jul 25 2020 at 17:55):

@Grahame Grieve My point aligns with the questions you all noted below: How can you tell supplements from each other? What is the unique element that allows you to say "use this supplement"? In part because I assumed that you would need to specify when a supplement is to be used for an expansion, and for a lookup. So you'd need to identify the specific supplement when asking to do anything with the code system - expansion, lookup, etc. I think assuming that a TS would always use every available supplement (how about fragments?) with every use of a code system would be very confusing to receivers.

Michael Lawley (Jul 27 2020 at 00:27):

Supplements have a unique URI, so that (or the canonical including version) can be used to identify them.
For us, it is the use of http://hl7.org/fhir/StructureDefinition/valueset-supplement that allows them to be brought into scope, but this means that the operation requires a ValueSet, so pure CodeSystem operations are not able to make use of supplement content.

Robert McClure (Jul 28 2020 at 14:42):

@Michael Lawley & @Grahame Grieve Big head-slap for me as I forgot the specifics noted in the supplement spec. Now that I'm back on the bus, seems we need to allow all code system uses and operations to incorporate specified supplements. Perhaps this means that we can declare "a version" of the code system that includes specific supplements and then refer to that versioned code system for use "in all things." I understand that is not how the value set extension was envisioned, but perhaps we could consider a more global use of cs supplements. Is there any sense to this? If not, how do we more globally make use of cs supplements?

Grahame Grieve (Jul 28 2020 at 22:15):

well, I'm not sure. Here's where I think we are:

• language specific code system supplements - actually, displays defined in supplements for different languages - are automatically in scope of the appropriate language is requested
• for value set operations ($expand, $validate-code) properties defined in supplements are only in scope if the value set says that they are

What we haven't agreed to:

• what happens for code system operations ($lookup, $validate-code, $subsumes)
• what happens for the concept map operation $translate

Grahame Grieve (Jul 28 2020 at 22:22):

I think that a linear extrapolation of previous committee deliberations would be:

$validate-code: displays from supplements are automatically in scope based on the language of context. properties from supplements are only in scope if they are explicitly referenced (I think that properties are only relevant for the evalution of the abstract parameter)

$subsumes: properties for supplements are only relevant when supplements are explicitly referenced. (Actually, I think we haven't discussed whether supplements can define is-a / parent / child relationships; I think they should be able to to, but I can see that being controversial since you could certainly do some bad things doing that, as well as doing good things)

$translate: given the looseness of this operation, we should allow server discretion for whether to consider supplements. This certainly matters since a key use of supplements is to serve the $translate operation

$lookup: I don't come to clear answer by extrapolating on this one. I think that it would be one of:

• properties and displays from supplements are only includes if they are explicitly referenced
• properties and displays from supplements are automatically included by clearly labelled with their supplement source

I prefer the second approach, on this one

Grahame Grieve (Jul 28 2020 at 22:22):

I'm open to the idea that we could define a 'version' but I suspect it makes a mess of how versions work?

Rob Hausam (Jul 28 2020 at 22:46):

I think I'm generally in agreement. Can you restate (or revise) the second bullet for $lookup (it's not particularly clear as is)?

properties and displays from supplements are automatically included by clearly labelled with their supplement source

Maybe this is also something we should have some discussion on during the Tracker call on Thursday this week so we can get something ready for voting on the Main call.

Michael Lawley (Jul 28 2020 at 23:02):

$translate: given the looseness of this operation, we should allow server discretion for whether to consider supplements. This certainly matters since a key use of supplements is to serve the $translate operation

Can you elaborate? $translate is basically a table lookup operation so I don't quite follow how supplements are relevant.

Grahame Grieve (Jul 28 2020 at 23:45):

@Rob Hausam

properties and displays from supplements are automatically included and clearly labelled with their supplement source using a sub-property

Grahame Grieve (Jul 28 2020 at 23:46):

@Michael Lawley

I supplement may define properties with type Coding, which are effectively translations to other code systems, and a server could choose to include these in scope when it does the $translate operation

Grahame Grieve (Jul 28 2020 at 23:46):

the base code system can do this too

Grahame Grieve (Jul 28 2020 at 23:47):

$translate is basically a table lookup

I don't think that is true based on the definition in the specification

Michael Lawley (Jul 29 2020 at 02:19):

What CodeSystem properties define implicit maps?

Michael Lawley (Jul 29 2020 at 02:21):

table lookup
depends gives you a multi-valued key for the lookup, unmapped is the complexity (where you need to look at the internal group-structure of the map). What parts of the spec are you considering?

Grahame Grieve (Jul 29 2020 at 03:10):

There's no standard code system properties that define maps, but properties of code systems frequently do define maps. That's why. for $translate, we don't say how it's done or mandate it, but we don't prohibit it

Grahame Grieve (Jul 29 2020 at 03:11):

What parts of the spec are you considering?

Translate a code from one value set to another, based on the existing value set and concept maps resources, and/or other additional knowledge available to the server

Robert McClure (Jul 29 2020 at 16:57):

@Grahame Grieve I see through your suggestions you assume the operations can work "when supplements are explicitly referenced" and I'm not sufficiently technical to comment on how hard that will be, if all users can determine what they need to reference, and that servers can respond clearly identifying what was used. I'll leave others to comment on this, but for me simply addressing this, I do think we should discuss that a version of the code system could be used to specify what collection of supplements is included. Seems to me this is very similar to what we already do with SNOMED CT. Granted SNOMED manages that complexity, we don't, but perhaps we can support it by crafting an extension that clarifies the dependent supplements. Granted it's new work so only useful if the other approaches you've noted are too hard.

Lloyd McKenzie (Jul 29 2020 at 19:54):

Code systems generally won't know about their supplements. In many cases, they won't even want supplements to exist. (However they will exist because the code system publisher also won't want to add the properties, relationships and alternate designations desired.) Supplements should be (and can be) referenced by the value sets that rely on them. And that's generally the only place they need to be.

Grahame Grieve (Jul 29 2020 at 20:03):

@Robert McClure I think that the key difference between what happens with snomed and supplements is that the snomed versioning system applies to fragments of the official snomed space, not to supplements. And I think that makes a real difference

Robert McClure (Jul 29 2020 at 23:33):

@Lloyd McKenzie I'm not sure how your comments wrt only value sets use supplements squares with the issues of needing code system operations on supplement content, as noted in the thread above.

Lloyd McKenzie (Jul 30 2020 at 02:06):

If you were calling $lookup and wanted properties included from a supplement, you'd have to list the relevant supplements as an argument to the call. You can't expect the referencing code system to know about any of them. You could, perhaps, use a shortcut that simply says "use all supplements associated with the code system that the terminology service is aware of".

Grahame Grieve (Jul 30 2020 at 02:33):

there's every reason to expect that the server is aware of them

Lloyd McKenzie (Jul 30 2020 at 03:35):

The server can be (though different servers may vary in what they have stored locally). The Code system won't be aware.

Michael Lawley (Jul 30 2020 at 21:06):

For CodeSystem/$lookup we either need to

1. add an extra parameter for explicitly mentioning additional supplements to use,
2. automatically include all known (to the server) supplements for the code system, or
3. relax the restriction on the supplement's URI being used as the system parameter.

These are not (all) mutually exclusive options.

In any case, it would be very useful to have a sanctioned, consistent, and clear mechanism for including supplement-sourced properties in the $lookup result so that the client can determine the provenance of the additional values. This should probably also work for supplemented designations.

Grahame Grieve (Jul 30 2020 at 21:29):

do we have a task for that?

Michael Lawley (Jul 30 2020 at 21:38):

We do now - J#28172

Last updated: Apr 12 2022 at 19:14 UTC