Stream: implementers
Topic: Cardinality of OperationDefinition.parameter.type
Zach Smith (Aug 02 2019 at 00:59):
Hi, I'm curious why the cardinality of OperationDefinition.parameter.type is 0..1 instead of 0..*, similar to ElementDefinition.type, to allow for type choices?
The docs for CodeSystem$find-matches (which, admittedly, is maturity level 0), defines the property.value parameter as a type-choice, but it's encoded as type code in the OperationDefinition.
Thanks!
Lloyd McKenzie (Aug 02 2019 at 01:02):
I expect because a lot of RPC mechanisms don't support polymorphic types. The solution is multiple optional parameters each with an appropriate type
Zach Smith (Aug 02 2019 at 01:04):
I see. If that's the case, then shouldn't the $find-matches OperationDefinition have multiple parameters? i.e.property.valueCode, property.valueCoding, etc.
Grahame Grieve (Aug 02 2019 at 01:09):
there's a task to do something about that parameter
Michael Lawley (Aug 05 2019 at 05:57):
and the operation ;-)
Michael Lawley (Aug 05 2019 at 05:59):
@Zach Smith can you provide some detail as to what you're wanting to use $find-matches for?
Zach Smith (Aug 05 2019 at 16:58):
No concrete plans for using $find-matches just yet. I'm just working on implementing the full Terminology Services spec, and this was the last operation on my list. So this isn't a super high priority issue for me, I was more just curious if the choice to not allow for polymorphic types in extended operations was intentional.
Michael Lawley (Aug 05 2019 at 23:40):
Ah, thanks. I'm still on the hunt for people who want to use $find-matches :-)
Do you have a public endpoint for your server that I could point https://ontoserver.csiro.au/vstool at, and if so, are you interested in me adding it to the list of servers?
Grahame Grieve (Aug 05 2019 at 23:57):
@Davide Sottara
Last updated: Apr 12 2022 at 19:14 UTC
