Stream: terminology
Topic: Terminology Capabilities Statement
Peter Jordan (Aug 05 2019 at 22:43):
Picking up the thread from the Implementers Thread - I'm not sure that I agree with @Rob Hausam that this resource should list all the Value Sets available on a Server: this can already be done by a simple GET [base]/ValueSet request. To my mind, it's designed for expressing capabilities in terms of the terminology operations and (Code System) properties supported by a server - i.e. specialist information beyond that available in the 'vanilla' CapabilityStatement resource. This is, probably, more likely to be useful with regard to the more widely-used, and fully-featured, Code Systems (SNOMED CT, LOINC, RxNorm, etc.), so I'm also not certain if one would expect a Server to include all the Code Systems it supports in this Resource; again, a simple GET request on CodeSystem can achieve that. However, as Rob states, this is a level 0 Resource and, doubtless, there will be varying use cases and opinions on how it might be used.
Michael Lawley (Aug 05 2019 at 22:55):
I think one of the key distinctions is that you might have a server that stores CodeSystems (& ValueSets) and allows searching (so [base]/CodeSystem returns a long list), but that only supports $expand on a subset of these CodeSystems (or only supports a subset of the declared filters for a CodeSystem). So TerminologyCapabilities is about advertising available behavioural aspects.
Now, for a limited Tx server, saying what it can do on a CodeSystem-by-CodeSystem basis might be okay, but for a capable Tx server it would be much more efficient to only state the exceptional things (i.e., along the lines of this server supports all declared filters for all CodeSystems it stores except for ...) -- we have customers with multiple thousands of (small-ish) CodeSystems and it needs to be workable for them.
Rob Hausam (Aug 05 2019 at 23:02):
I don't necessarily disagree at all with Peter or Michael on this. I do agree that just listing the supported code systems and value sets isn't likely the best use and justification for having TerminologyCapabilities. I think we need to decide (after sufficient time and input) how we want it to be. And we can, as we do with other things, consider leaving many of the decisions on specific behaviors to server discretion (if we decide that it's best not to "lock it down" for everyone). If I would happen to decide to list every single code system and value set that I have in my terminology server (not that I actually would do that) and Peter or Michael for their use cases and clientele prefer to take a more selective approach for the capabilities of their servers that they want to expose, both approaches could potentially be considered acceptable.
Michael Lawley (Aug 05 2019 at 23:36):
Agreed. We also need to take care that clients can usefully interpret what is being said by a server.
Put another way, we need to understand what questions a client is trying to ask, and how a client might adapt its behaviour based on the response.
Peter Jordan (Aug 06 2019 at 01:15):
One question that quickly comes to mind is... 'which versions and editions of SNOMED CT does the Server support?'...but a good deal of information about an individual Code System can already be obtained from the CodeSystem resource.
Last updated: Apr 12 2022 at 19:14 UTC
