Stream: terminology
Topic: Specifying additional properties for ValueSet
Paul Lynch (Jun 22 2018 at 22:56):
Here is one possible solution for how ValueSet might be modified to handle additional properties that would meet the need I have for selecting additional properties to be returned and to be searched (when filtering):
On ValueSet, under "contains" add a new "properties" key:
contains:
properties: 0..*
name: string
value[x]: *
Then, to request that these properties be retrieved or searched, use two new optional parameters for ValueSet $expand:
- "properties": list,of,additonal,properties -- returned with above "properties" section
- "filterProperties": list,of,properties filtered by "filter"
If the properties are not specified, the server would just use a default value.
Robert McClure (Jun 24 2018 at 16:21):
I am intrigued by this possibility now that we have decided to do away with expansion profile. I do think it would be useful to be able to identify specific code system concept attributes within the compose that would then end up as included in the $expand. We'd also want a default.
Michael Lawley (Jun 24 2018 at 21:58):
There is work in progress to allow the output of $expand to be passed into $lookup (and $translate) which will resolve this issue.
It also leaves it to the client to decide what the desired properties are, which is where the decision should lie.
Grahame Grieve (Jul 05 2018 at 07:18):
so. I've been thinking about this and playing around with approaches. There's not really any generic way to pipe operations to each other.... but there's a way to resolve this.
Grahame Grieve (Jul 05 2018 at 07:19):
at present, the lookup operation takes a code + system to look up. We could add another option, to pass a value set. if you do this, the server expands the value set, and then returns the result of lookup for all the members of the value set
Grahame Grieve (Jul 05 2018 at 07:22):
GET [base]/CodeSystem/$lookup?valueset=http://hl7.org/fhir/ValueSet/doc-classcodes&property=definition
Grahame Grieve (Jul 05 2018 at 07:22):
this same approach works for translation:
Grahame Grieve (Jul 05 2018 at 07:23):
GET [base]/ConceptMap/$translate?valueSet=http://hl7.org/fhir/ValueSet/composition-status &source=http://hl7.org/fhir/ValueSet/composition-status &target=http://hl7.org/fhir/ValueSet/v3-ActStatus
Michael Lawley (Jul 05 2018 at 07:24):
So another use case came up today which was chaining $translate eg to do AMT -> SCT -> RxNorm
Grahame Grieve (Jul 05 2018 at 07:24):
in both cases, you get back a Parameters with a series of parameters, each of which contains a set of parts that is the normal set of output parameters for the operation, one for each code in the expansion
Grahame Grieve (Jul 05 2018 at 07:25):
that's one way to do this ... it probably works well for translate, but maybe not so much for lookup
Grahame Grieve (Jul 05 2018 at 07:27):
an alternative approach which is more value set centric - and probably better for getting properties, is to add to value set (probably extensions for now) a column : string 0..* for each contains, and a column: {name, uri, type} to the expansion that defines the columns. and some kind of column= parameter in the $expand
Grahame Grieve (Jul 05 2018 at 07:27):
I can prototype either of these, but I thought I'd see what people said
Grahame Grieve (Jul 05 2018 at 07:28):
the 3rd option I spent the most time pursuing is the most complicated... extending batch to allow feeding outputs from one batch entry into a subsequent batch entry
Grahame Grieve (Jul 05 2018 at 07:28):
that is powerful, but rapidly gets really messy....
Rob Hausam (Jul 05 2018 at 13:56):
the first option looks pretty good to me - if the "not so much for lookup" isn't too big an issue
can you elaborate on that?
Paul Lynch (Jul 05 2018 at 15:25):
In the first option, would it be possible to specify a "filter" parameter to control what parts of the ValueSet are returned by the $lookup? My use case for this is matching against what the user is typing in a field.
Grahame Grieve (Jul 05 2018 at 19:04):
well, all the parameters for expand would become relevant
Grahame Grieve (Jul 05 2018 at 19:05):
$lookup on an expand would obscure the value set expansion itself
Paul Lynch (Jul 05 2018 at 19:56):
I'm not entirely sure what you mean by "obscure the ...expansion", but I like the idea that the $expand parameters would be available. I took a quick look at the $expand and $lookup parameter lists, and it looks like the only overlap is displayLanguage, which I don't think would be an issue.
So, this idea would allow extra properties to be specified and retrieved, but still leaves it up to the server to decide which properties should be searched. I really think that should be a client-side decision, but as I recall from a previous phone call, reaching a consensus on how to do that was difficult for some reason. Anyway, I am happy to have half the problem solved, and if the other half (specifying which properties should be searched) needs to be considered separately or put off for now, that is fine.
Peter Jordan (Jul 05 2018 at 20:36):
My preference would be to create a new $lookup operation for the ValueSet resource, rather than pass ValueSet resources to the $lookup operation on the CodeSystem resource.
Michael Lawley (Jul 05 2018 at 22:10):
I see two different use cases here:
1. perform an $expand but allow specified properties to be returned in the expansion rather than than just the code/designations, and
2. perform a $lookup on a set of codes in a single request - a ValueSet might be the way to specify that set of codes.
Then there is the extension of this idea to other operations, e.g., $translate:
3. perform a $translate on a set of codes in a single request - again, a ValueSet might be the way to specify that set of codes, and
4. link a series of $translate calls where the initial input is either a single code, or a set of codes (3)
Note:
- the key difference between 1 & 2 is that 1 still returns an expansion where as 2 does not (or probably does not), and 1 really just needs an upgrade to
$expandandValueSet.expansionto allow for request and return of properties. - neither
$lookupnor$translatecurrent tell you what the input code was so they will both need some mechanism to indicate this when used in a "multi-input" context
An approach to 2&3 I have been toying with involves extending $lookup and $translate to allow a ValueSet (with expansion) as an input parameter and to extend $expand with a new parameter chain (or pipe or...?) that takes a URL as a value. That URL would be either /CodeSystem/[id/]$lookup?... or /ValueSet/[id/]$translate?... without the code, system input parameter values.
What I don't like about this approach is that it expand-based which suggest the result should be a ValueSet with expansion. The alternative would be to extend each of $lookup and $translate with a new parameter input (or from or ...?) that takes an $expand URL as a value - /ValueSet/[id/]$expand?... - instead of the code, system input parameter values.
Michael Lawley (Jul 14 2018 at 09:24):
No feedback? @Grahame Grieve @Peter Jordan
Grahame Grieve (Jul 16 2018 at 00:16):
I don't know - I'm hoping to get back to this later this week
Brian Postlethwaite (Aug 11 2018 at 04:27):
Was there a tracker for this functionality going through, I can see that the ValueSet expansion doesn't have the properties of the codes in it.
Grahame Grieve (Aug 11 2018 at 04:49):
no this was always going to miss the boat but I will get back to it... there's just too much to do right now
Paul Lynch (Aug 28 2018 at 19:25):
The tracker I had submitted was #GF17324. (I just noticed that this conversation had updates.)
Paul Lynch (Nov 02 2018 at 19:44):
@Grahame Grieve Is it still on your list to propose something further on this?
Grahame Grieve (Nov 02 2018 at 21:13):
yes still on my list
Last updated: Apr 12 2022 at 19:14 UTC
