Stream: terminology
Topic: TerminologyCapabilities vs OperationDefinition
Yunwei Wang (Aug 21 2018 at 17:09):
I want to restrict operation parameters for $expand operation. Currently, I create a OperationDefinition instance and set other parameters as 0..0. With introduction of TerminologyCapabilities resource, I can also do this in TerminologyCapabilities.expansion.parameter. Which one is the correct/expected way to achieve this?
Rob Hausam (Aug 21 2018 at 17:21):
I'm not sure if I understand exactly how you are using OperationDefinition here, so if you could elaborate on it a bit that would be good. TerminologyCapabilities is used to declare and reflect what the server can and will do, but it isn't used to control the behavior of the server. Let me know if I'm misunderstanding part of what you are saying or asking
Yunwei Wang (Aug 21 2018 at 18:05):
Let's say my server only process filter parameter for $expand operation. All other $expand parameters are ignored by server. I can create a instance of OperationDefinition, "filter-only-expansion", which has base url as "base": "http://hl7.org/fhir/OperationDefinition/ValueSet-expand" and all other parameters with max = 0 except filter. Then in CapabilityStatement, I put this instance in the place of Valueset-expand operation:
"operation":[
{
"name": "Valueset-expand",
"definition": "fileter-only-expansion"
}]
In this way, I can define my operation for $expand.
TerminologyCapabilities can do the same with expansion.parameter whose summary says "Supported expansion parameter".
My understanding is that CapabilitiesStatement is required. So I have to define my own filter-only-operation. Then what is the use case for TerminologyCapabilities.expansion.parameter ?
Rob Hausam (Aug 21 2018 at 19:28):
I probably should study this a bit further, but I understand better now what you are asking and I agree that these "capabilities" do overlap, and that it is required to have the reference to the OperationDefinition in CapabilityStatement to declare the supported API. TerminologyCapabilities does not describe the API, but it does declare all of the terminology capabilities together in one place. It seems to me that both could be useful.
Peter Jordan (Aug 21 2018 at 20:30):
Obviously, the Terminology Capabilities resource is still experimental, but I don't think that it should replicate operation definitions that are already mandated elsewhere, and I note that it's only the expansion element that contains a parameter element.
Grahame Grieve (Aug 21 2018 at 20:48):
I can't think what I was doing there. The only thing that would be useful at terminology capabilities level would be to declare expansion parameters per code system
Peter Jordan (Aug 21 2018 at 21:29):
Maybe everything in the resource definition from expansion downwards should be placed within the codeSystem element?
Grahame Grieve (Aug 21 2018 at 21:31):
well, strictly, none of them should. what would it mean to expand a value set that cross code systems, if the server claims the parameters are different for the code systems?
Michael Lawley (Aug 21 2018 at 21:52):
Isn't this about what parameters are returned in the expansion, not about operation parameters
Grahame Grieve (Aug 21 2018 at 22:09):
no. it's about what parameters the server actually implements. To Yunwei's point.... the server might describe parameters it doesn't implement, but this is a pretty edge case thing to do
Last updated: Apr 12 2022 at 19:14 UTC
