Stream: terminology
Topic: Custom properties for a CodeSystem
Paul Lynch (Nov 13 2018 at 21:46):
If wanted to add additional properties to a known code system (for example http://loinc.org), because the additional properties are useful for my application, would I just create my own local CodeSystem resource, basing it on the standard one, and reference that custom one in my ValueSet definitions? In the expansion, I would still want the canonical URL (http://loinc.org) in the contains.system.
Grahame Grieve (Nov 14 2018 at 02:42):
you're describing a supplement- read what the build.fhir.org/codesystem.html has to say abotu that
Paul Lynch (Nov 15 2018 at 16:07):
Is a supplement CodeSystem obligated to support all of the properties and filters of the original CodeSystem?
Lloyd McKenzie (Nov 15 2018 at 16:14):
There'd be no point to supporting any of them - they're already defined for all the codes by the base code system. The wole point of the supplement is to define new properties and filters for the existing codes. (Remember, supplements can't define any new codes or concepts.)
Paul Lynch (Nov 15 2018 at 16:19):
But, if none are supported, then someone doing a $lookup on a code to get additional properties would need to do two lookups (probably at different servers), first to get the standard properties, and then to get the supplemental ones.
Lloyd McKenzie (Nov 15 2018 at 20:54):
Yup
Lloyd McKenzie (Nov 15 2018 at 20:56):
They're separate objects. If you query the supplement, you'll only see the codes that are supplemented and only see the supplementary properties and designations. You have to have a copy of the original code system to know what's in the original code system. In some cases, the supplement won't even have permission from the original system to publish its information.
Paul Lynch (Nov 15 2018 at 21:20):
For our Clinical Table Search Service we have a number of standard code systems to which we have (in some cases) added additional fields. This is an autocompletion service; we do not make users first hit us for the extra fields and then go away somewhere else to get the standard fields. We have the standard fields indexed together with our extra ones. What I'm trying to understand with these questions is what type of ValueSet and CodeSystem resources we'll need to serve in order to make this usable via FHIR.
I was assuming the supplement type of CodeSystem would not only allow us to provide additional fields, but also the standard ones. Is that not the case?
Lloyd McKenzie (Nov 15 2018 at 21:24):
A CodeSystem supplement should only expose the additions. There's no way in the resource to distinguish what's yours vs. what comes from the original code system, so if you declare everything, it looks like the supplement is defining all of those things. In practice, only terminology services would ever need to query code system supplements - and they'll always query both the supplement and the code system. Clinical systems will generally not care about code systems or supplements. They'll just care about the value set expansions provided by the terminology service - which will include information from both the code system and the supplement(s).
Paul Lynch (Nov 15 2018 at 21:26):
If a clinical system cares about the extra properties defined in a code system, doesn't it need to do a lookup on the CodeSystem currently?
Lloyd McKenzie (Nov 15 2018 at 21:41):
We should probably make the $lookup operation code system supplement aware...
Paul Lynch (Nov 15 2018 at 21:59):
I think what you're suggesting is that $lookup on a supplement could include properties from the original code system, and not just the supplement. Correct?
Lloyd McKenzie (Nov 15 2018 at 22:08):
More that when you invoke lookup on a code, you can include a valueset or list of supplements so the terminology server knows what code system supplements to incorporate when determining the properties
Paul Lynch (Nov 15 2018 at 22:41):
What would the ValueSet be for, and what would be in it?
Lloyd McKenzie (Nov 15 2018 at 22:59):
The ValueSet would be the ValueSet associated with the element that the code was found in - and it would indicate the supplements that were relevant for doing an expansion.
Rob Hausam (Nov 15 2018 at 23:17):
Since $expand operates on a value set I'm not sure if anything further is needed there, but we may want to be able to control whether information from code supplements in included in the output for both $lookup and $expand.
Grahame Grieve (Nov 16 2018 at 06:56):
$lookup on a code to get additional properties would need to do two lookups (probably at different servers), first to get the standard properties, and then to get the supplemental ones.
I don't agree that this is true
Michael Lawley (Nov 16 2018 at 12:18):
Neither do I.
Xiaocheng Luan (Nov 16 2018 at 14:25):
Hi everyone, I work in Paul's team, new to FHIR. Guess my main confusion is what exactly a supplement is. I could imagine two extreme views:
(1) A supplement is a "patch" to the code system it references, it's not a code system by itself (and thus can't be used in a Coding). A supplement-aware terminology server considers it to be part of the code system it "supplements".
(2) A supplement is a code system of its own right, it "inherits" the definitions from the code system it references and adds extra, much like a subclass in the context of object oriented modeling. It thus has its own code system URL (e.g., loinc.org-ext1) and can be used in "Coding".
For the "patch" view in (1), there could be issues of local vs. global/standard, and consistency issues across terminology servers on specific code systems (with/without different supplements defined).
For the "subclass" view, it may obligate terminology servers hosting such "supplement/subclass" code systems to be fully aware of/support the filters, properties, etc., defined in the original (parent) code system?
This "subclass" view was what I thought it should roughly be but it does not appear to be the case based on the conversations in this thread?
Lloyd McKenzie (Nov 16 2018 at 15:27):
A code system supplement is absolutely constrained to be #1. It cannot define new codes, nor can it define new meanings for codes. However, it can define new properties, new display values and/or new relationships for codes defined in another code system.
Lloyd McKenzie (Nov 16 2018 at 15:28):
If you have something that defines new codes, it's a code system.
Lloyd McKenzie (Nov 16 2018 at 15:28):
(not a supplement)
Xiaocheng Luan (Nov 16 2018 at 18:45):
Thanks for the clarification, Lloyd.
Paul Lynch (Nov 16 2018 at 19:11):
Just to clarify-- no one is takling about adding codes. The "extra' Xiaocheng mentioned was a reference to extra properties.
@Lloyd McKenzie So, if I understand you correctly, for the form field autocompletion scenario, with each keystroke, the clinical system would first send an $expand request on the ValueSet, and then for each returned code (but together as a batch) there would be a $lookup request, with every lookup request also sending the VallueSet and a list of code supplements? That seems a lot to ask to be sent for each keystroke in a field.
Lloyd McKenzie (Nov 16 2018 at 19:41):
If you need the properties to be displayed instead of just the display names and you need properties provided by supplements, there isn't much choice unless we revise $expand to be able to include properties
Michael Lawley (Nov 16 2018 at 23:19):
although you might not want to do it as a batch because that require POST and POST cannot be cached (at the HTTP layer)
Grahame Grieve (Nov 17 2018 at 02:28):
I’ve given this a lot of thought and tried various complicated ways to pipe expand and lookup together. The simplest way to solve this is to add the property parameters from $lookup to $expand, and then say that properties you ask for come back as extensions (for now)
Rob Hausam (Nov 17 2018 at 12:31):
Agree. This makes sense.
Last updated: Apr 12 2022 at 19:14 UTC
