Stream: terminology
Topic: Implicit ValueSets for Codings in EHR data
Paul Lynch (Feb 10 2022 at 21:57):
At Monday's Vocabulary work group call, as we were discussing FHIR-24834, @Rob Hausam had an alternative suggestion using implicit ValueSets, which seemed to have more acceptance among on those on the call. For details and discussion, see https://chat.fhir.org/#narrow/stream/179166-implementers/topic/.22distinct.22.20search/near/271494419
Paul Lynch (Mar 14 2022 at 22:21):
I was asked to summarize progress on this issue from today's call, because although we made progress on it, there are more details to be worked out. This is the current state of the discussion about how to get a filtered list of Codings from a field with a search parameter of type token (e.g., Observation.category):
- Not using implicit ValueSets
- new parameter: contextMode, with values "is" and "couldBe" (or something like that, to indicate whether the values are the ones on the server or the ones that would be accepted by the server; "couldBe" is not really needed for this use case)
- new parameter, like context, but would only be for fields with search parameters of type token. Name: TBD. (Question: Why not just use context and limit its scope when contextMode is present?)
How we got here:
@Grahame Grieve preferred to use the idea of context & contextDirection rather than implicit ValueSets. However, since specifying "contextDirection=existing" (to indicate the values from the stored instances on the server) doesn't fit well semantically, it was decided to introduce contextMode instead. Then, when I pointed out that servers would likely only index fields that were search parameters, it was decided that context was too general to be used to specify that.
Michael Lawley (Mar 15 2022 at 05:05):
This doesn't seem to be a terminology operation to me, but rather a _search operation with customised representation of the result (the domain of GraphQL) -- there's no "terminology semantics" going on here as far as I can see.
Paul Lynch (Mar 15 2022 at 21:23):
It returns a list of Codings selected by a "filter" parameter, and a ValueSet expansion is convenient way to return that, as it allows tools that already handle ValueSet expansions (e.g. tools showing Questionnaires with coded list questions) to also be able handle this use case of a lookup for stored values.
Michael Lawley (Mar 16 2022 at 01:18):
It seems I am naive wrt graphql -- it appears not to have "distinct" as a standard operation/filter.
I am coming around to the idea of contextDirection=existing (rather than introduce yet another parameter and have to detail what the constraints / interactions are between contextDirection and contextMode).
I'm not sure what the issue is wrt indexing fields that are search parameters? I can see a couple of options here: a server only supports this for some limited set of contexts, or it only supports "fast" results for some limited set of contexts (those that are indexed), and whether something is indexed may/may not be affected by the set of supported search parameters. Also, it might be useful for a server to be able to indicate which contexts are supported for this "mode" / ask a server to support a given context.
We will also need to clearly work through the boundaries around invalid codes in the data.
Paul Lynch (Mar 30 2022 at 18:58):
Michael Lawley said:
I'm not sure what the issue is wrt indexing fields that are search parameters? I can see a couple of options here: a server only supports this for some limited set of contexts, or it only supports "fast" results for some limited set of contexts (those that are indexed), and whether something is indexed may/may not be affected by the set of supported search parameters. Also, it might be useful for a server to be able to indicate which contexts are supported for this "mode" / ask a server to support a given context.
HAPI's implementation of this only works on search parameters of type token, because they only index things that are search parameters. I think without an index, the server would have to just page through the data looking for unique codings, which would be quite slow-- too slow to be useful except for very small datasets.
We will also need to clearly work through the boundaries around invalid codes in the data.
The question of validating the codes was discussed on the call as well, but this operation would just return the data the server has, without checked the status of the codes or validating them.
Last updated: Apr 12 2022 at 19:14 UTC
