Stream: terminology
Topic: Properties in an expansion
Lloyd McKenzie (Apr 19 2018 at 23:04):
Question came up on SDC today about whether it's possible for an expansion to include code system properties. (Presumably the desired properties would be identified in the expansion profile.) When displaying codes to choose from in questionnaires we sometimes want to expose properties other than just the display names.
Lloyd McKenzie (Apr 19 2018 at 23:16):
Based on offline feedback from Rob, GF#15979
Rob Hausam (Apr 19 2018 at 23:20):
I added my earlier reply to Lloyd to the tracker.
Rob Hausam (Apr 19 2018 at 23:24):
(deleted)
Michael Lawley (May 01 2018 at 12:11):
My comments are on the tracker, but they're broader than the specific issue so I'm including them here for greater visibility.
We faced a similar problem when implementing Shrimp (https://ontoserver.csiro.au/shrimp) and Snapper (https://ontoserver.csiro.au/snapper2). We've found that doing a set of $lookup
calls in a batch is pretty (very) fast, although the use of POST
means no HTTP-level caching.
What we struggle more with is doing a $translate
of a set of codes from an expansion.
One could think of these problems in a general form like: "map an operation ($lookup
/ $translate
) over the results of an expansion". Alternatively, $lookup
& $translate
could support a ValueSet
as an alternative input(s) to the code (src/target), or be defined as additional operations for the ValueSet
resource.
Grahame Grieve (May 02 2018 at 08:06):
why is this related?
Michael Lawley (May 02 2018 at 08:25):
$lookup is the normal path to getting properties
Grahame Grieve (May 05 2018 at 04:32):
umm so?
Michael Lawley (May 05 2018 at 04:49):
So, one way to get properties into an expansion is to extend how $expand
works and have a mechanism to request that properties (default, listed, or all) are included in the expansion.
An alternative would be to extend how $lookup
works and allow it to operate on (the expansion of) a ValueSet
. This would probably be more complex to define, but perhaps result in a more regular mechanism to compose terminology operations. For us this is attractive because we also have use cases where we need to perform a $translate
on a (large) set of codes. It would be nice if one extension could solve what I see as two related problems.
Last updated: Apr 12 2022 at 19:14 UTC