Stream: terminology
Topic: ValueSet/$lookup
Michael Lawley (Feb 05 2019 at 00:54):
I'm currently prototyping ideas around /ValueSet/$lookup and am looking for input on what it should return:
1. A Parameters resource
2. A Bundle of Parameters
3. A Valueset with extension elements in the ValueSet.expansion.contains
4. Something else
I'm currently tending towards 2 for symmetry with CodeSystem/$lookup
Peter Jordan (Feb 05 2019 at 01:13):
Option 1 - a single Parameters Resource containing 0...* individual parameters. Isn't that actually what the CodeSystem $lookup operation currently returns, rather than a Bundle of Parameters Resources? I don't see the word 'Bundle' mentioned in the definition of that operation.
Michael Lawley (Feb 05 2019 at 02:26):
The down-side of 1 is that you can just take a Parameters and nest it inside a Parameters. Code that works for /CodeSystem/$lookup can be trivially generalised to work for this case; this is much simpler when Bundle is used (although both require the actual code to be included in the Parameters response as well)
Peter Jordan (Feb 05 2019 at 04:51):
Not quite sure how a Bundle of Parameters resources is any simpler than an individual Parameters resource with multiple parameter elements.
Michael Lawley (Feb 05 2019 at 07:45):
If you already have code that consumes the output of CodeSystem/$lookup, then it's simple to re-use that code by passing in each member of the Bundle. However, if you get back a Parameters, then it contains Parts, not Parameters, so you need to re-work your original code (and we need to decide on a name for those parts).
Peter Jordan (Feb 05 2019 at 08:37):
I suggest providing an example of how Parameters-->parameter-->part is improved by Bundle-->Parameters-->parameter. If the complexity in the first alternative is the part.name, how is that is that reduced by the second? Using the second structure would mean that I couldn't re-use the code from my CodeSystem $lookup operation without significant re-factoring.
Yunwei Wang (Feb 05 2019 at 14:42):
What is the purpose of ValueSet/$lookup and what is the difference compared to CodeSystem/$lookup?
Jim Steel (Feb 05 2019 at 22:56):
A ValueSet $lookup is a bit like a batch of CodeSystem $lookups for all of the codes in the expansion of the ValueSet
Peter Jordan (Feb 06 2019 at 00:02):
Ah....so the use case is to lookup ALL of the codes in a ValueSet expansion? Now, I understand the desire to return a Bundle of Parameters resources. I'm now wondering what the Request Parameters might look like in cases where a ValueSet contains concepts from more than one code system?
Michael Lawley (Feb 06 2019 at 00:03):
the result Parameters needs to include the code itself (currently not included in the CodeSystem/$lookup) as well as the system (and version)
Michael Lawley (Feb 06 2019 at 00:28):
As a concrete example, I have [base]/ValueSet/$lookup?url=http://example.com/act-pi&property=display&property=inactive returning the following
{ "resourceType": "Bundle", "entry": [ { "resource": { "resourceType": "Parameters", "parameter": [ { "name": "code", "valueString": "387067003" }, { "name": "display", "valueString": "Lopinavir" }, { "name": "property", "part": [ { "name": "code", "valueCode": "inactive" }, { "name": "valueBoolean", "valueBoolean": false } ] } ] } }, { "resource": { "resourceType": "Parameters", "parameter": [ { "name": "code", "valueString": "710109003" }, { "name": "display", "valueString": "Cobicistat" }, { "name": "property", "part": [ { "name": "code", "valueCode": "inactive" }, { "name": "valueBoolean", "valueBoolean": false } ] } ] } }, { "resource": { "resourceType": "Parameters", "parameter": [ { "name": "code", "valueString": "428318002" }, { "name": "display", "valueString": "Darunavir ethanolate" }, { "name": "property", "part": [ { "name": "code", "valueCode": "inactive" }, { "name": "valueBoolean", "valueBoolean": false } ] } ] } }, { "resource": { "resourceType": "Parameters", "parameter": [ { "name": "code", "valueString": "372529006" }, { "name": "display", "valueString": "Indinavir" }, { "name": "property", "part": [ { "name": "code", "valueCode": "inactive" }, { "name": "valueBoolean", "valueBoolean": false } ] } ] } }, { "resource": { "resourceType": "Parameters", "parameter": [ { "name": "code", "valueString": "736536005" }, { "name": "display", "valueString": "Voxilaprevir" }, { "name": "property", "part": [ { "name": "code", "valueCode": "inactive" }, { "name": "valueBoolean", "valueBoolean": false } ] } ] } }, { "resource": { "resourceType": "Parameters", "parameter": [ { "name": "code", "valueString": "386896009" }, { "name": "display", "valueString": "Ritonavir" }, { "name": "property", "part": [ { "name": "code", "valueCode": "inactive" }, { "name": "valueBoolean", "valueBoolean": false } ] } ] } }, { "resource": { "resourceType": "Parameters", "parameter": [ { "name": "code", "valueString": "108701009" }, { "name": "display", "valueString": "Saquinavir mesylate" }, { "name": "property", "part": [ { "name": "code", "valueCode": "inactive" }, { "name": "valueBoolean", "valueBoolean": false } ] } ] } }, { "resource": { "resourceType": "Parameters", "parameter": [ { "name": "code", "valueString": "387006009" }, { "name": "display", "valueString": "Amprenavir" }, { "name": "property", "part": [ { "name": "code", "valueCode": "inactive" }, { "name": "valueBoolean", "valueBoolean": false } ] } ] } }, { "resource": { "resourceType": "Parameters", "parameter": [ { "name": "code", "valueString": "714420001" }, { "name": "display", "valueString": "Paritaprevir" }, { "name": "property", "part": [ { "name": "code", "valueCode": "inactive" }, { "name": "valueBoolean", "valueBoolean": false } ] } ] } }, { "resource": { "resourceType": "Parameters", "parameter": [ { "name": "code", "valueString": "419409009" }, { "name": "display", "valueString": "Tipranavir" }, { "name": "property", "part": [ { "name": "code", "valueCode": "inactive" }, { "name": "valueBoolean", "valueBoolean": false } ] } ] } } ] }
Peter Jordan (Feb 06 2019 at 00:37):
If this is to be based on an expansion of a ValueSet, I'm wondering if that (expanded) ValueSet would have to be passed as an input parameter to the lookup operation?
Michael Lawley (Feb 06 2019 at 14:05):
Yes, that's the url parameter in the call above
Peter Jordan (Feb 06 2019 at 20:13):
...but that's a reference to a ValueSet Resource, not the Resource itself.
Michael Lawley (Feb 06 2019 at 21:39):
oh, sorry, I misread your question. no, the expanded valueset doesn't need to be supplied; it is the job of the terminology server to do the expansion. Of course, you could POST a valueset definition that enumerates the set of codes you want to look up (a common use-case), but the operation would not rely on being supplied an existing expansion.
Yunwei Wang (Feb 07 2019 at 16:22):
If the purpose is to include designation in valueset expansion, why not just add property parameter to $expand operation.
Michael Lawley (Feb 08 2019 at 04:38):
The purpose is to access arbitrary properties of many concepts in a single call. Designations are already supported by $expand.
One option is to perform many $lookup operations in a batch request but this has performance issues:
- complex to optimise because the batch may consist of many things, not just $lookup and you can't rely on all the $lookups only varying in the code/system being targeted
- batch is always a POST and that can't be cached (at the HTTP layer)
Accepting that special support for this use case is needed, it seems like a ValueSet is a reasonable way to identify the set of concepts that you're interested in; you can enumerate them in the compose or specify inclusion/exclusion criteria or use implicit ValueSets (great for SNOMED & LOINC)
Extending ValueSet/$expand with property parameters would be one option, but there's no obvious place to put the resulting property values (they are not designations) so an extension would be needed.
Instead, defining ValueSet/$lookup, as above, has an appealing symmetry
Rob Hausam (Feb 08 2019 at 15:11):
There is something about it notionally that still is asymmetric, I think (although I don't know how much, if at all, that matters). When we do a $lookup on CodeSystem we are not looking up the properties for all concepts in the code system, but only for a single specified concept. The reason for that likely is that we don't (yet) have a Concept resource, which if we had it would seem to be the logical place to attach a single concept lookup, plus from a practical standpoint looking up the properties for all of the codes in a code system in a single operation often wouldn't be useful and for many large code systems would almost certainly be intractable. But I think it's something to keep in mind.
Yunwei Wang (Feb 08 2019 at 15:13):
ValueSet expansion already has designation in it. I don't see any problem add "properties 0..*" to valueSet.expansion.contains. This also simplifies the returning format.
Last updated: Apr 12 2022 at 19:14 UTC
