Stream: implementers
Topic: Observation search parameters issues
Eugene Lubarsky (Sep 03 2018 at 04:47):
I think there could be some issues with the standard Observation search parameters that could be by design but if so could use some explanation in the text.
1. Some parameters are missing (those for values of type bool, integer, range, time), others are for the top-level code-value but not for the components (values of type string and date)
2. The FHIRPath expression for some parameters isn't fully consistent with the description unless I'm just unaware of some standard FHIRPath conversions: for value-quantity the description includes searching the bounds of SampledData, for value-string the description includes searching CodeableConcept.text (which is inconsistent with the description for code-value-string)
I've made a spreadsheet: https://docs.google.com/spreadsheets/d/19OhoT0EBAiB4XASsEXmcEemue8NnUoEyOT4P7l_XDGA/edit
Lloyd McKenzie (Sep 03 2018 at 15:50):
I think you're right. Boolean should be searchable with all of the value-concept ones, integer and range should be searchable with the quantity ones. May need a new one for time. @Eric Haas ?
Eric Haas (Sep 04 2018 at 00:07):
We didn't do all the permutations - just those that we thought would be the most common. Make a change request for adding more. In the meantime, you can always make your own SP and if you have please share with us so we don't have to reinvent the wheel.
Eugene Lubarsky (Sep 04 2018 at 03:43):
Including booleans in *value-concept and Ranges in *value-quantity sounds good, but for integers doesn't the value-quantity parameter require a unit as per http://build.fhir.org/search.html#quantity ?
Lloyd McKenzie (Sep 04 2018 at 04:12):
The unit can't be required as not all quantities will have units. However it'd be good ot have an example showing that - can you submit a change request?
Eugene Lubarsky (Sep 04 2018 at 07:04):
Ah okay. Sure, I've added GF#17789 for the Observation parameters, and GF#17790 for the Quantity parameters.
Re. the corresponding FHIRPath expressions it would be nice if these search parameters could have a machine-processable definitions in the spec, but if that's not currently possible I think at least the definition of SearchParameter.expression should note that conversions via "as" may also have custom logic.
Eric Haas (Sep 04 2018 at 14:55):
what do you mean by "machine-processable definitions" we usually have both a FHIRPath and XPath expression ( I have been lobbying to get rid xpath of since its a pain to maintain both manually !! )?
Eugene Lubarsky (Sep 05 2018 at 04:03):
I mean enabling servers to extract search parameters for indexing via general-purpose code that loads SearchParameter resources. Currently for something like Observation.value-string the description says to also search in valueCodeableConcept.text whereas the FHIRPath is only "Observation.value as string".
Eric Haas (Oct 30 2018 at 02:01):
@Lloyd McKenzie looking at GF#17789. there are couple of issues here. I think @Eugene Lubarsky is right and the expression don't match the description. Correcting this either by removing the text or expanding the xpath will be a breaking change. Extending the other search parameters expressions would be breaking change in the expressions as well. If OO were to agree and add for example boolean to value-concept - I would need help with the fhirpath and xpath expressions.
Lloyd McKenzie (Oct 30 2018 at 02:36):
You can define additional "STU" search parameters, but you can't fix the ones that exist unfortunately. @Grahame Grieve, do we have the ability to differentiate STU search parameters?
Grahame Grieve (Oct 30 2018 at 09:33):
not at the moment - we've never really talked about trial-use for search parameters
Eric Haas (Oct 30 2018 at 14:59):
Well I will defer this to R5 and deal with it then. 1) add new search parameters. 2) deprecate the text description for existing parameters?
Lloyd McKenzie (Oct 30 2018 at 15:25):
I don't think you can deprecate a text description...
Eric Haas (Oct 30 2018 at 15:29):
Ideally in a non-normative world, to correct the error either the text needs to be changed or the expressions fixed to match or.. rip and replace the whole thing. What do you suggest?
Eric Haas (Oct 30 2018 at 15:30):
lemme see the source first...
Eric Haas (Oct 30 2018 at 15:40):
There were no expressions explicitly defined so it looks like the expression are generated base on the path. The error lies in the description, which might have predated the xpath part and we didn't catch until the commenter noticed it.
Lloyd McKenzie (Oct 30 2018 at 15:58):
The text is considered normative. Fixing the computable expressions to align is a technical correction.
Lloyd McKenzie (Oct 30 2018 at 15:59):
If the descriptions are wrong, we could choose to leave the expressions right and try to fix the descriptions in R5.
Eric Haas (Oct 30 2018 at 16:39):
Well then we could try to fix the computable but I am not sure that we can do for
Eric Haas (Oct 30 2018 at 16:40):
"The value of the observation, if the value is a Quantity, or a SampledData (just search on the bounds of the values in sampled data)"
Eric Haas (Oct 30 2018 at 16:41):
This one seems like its fixable: "The value of the observation, if the value is a string, and also searches in CodeableConcept.text"
Eric Haas (Oct 30 2018 at 16:46):
with (Observation.value as string) | (Observation.value as CodeableConcept).text
Eric Haas (Oct 30 2018 at 16:52):
procedureally what do I need to do to make this a technical correction for R4? (vote on tracker today and apply? even though have no clue how to fix the one?) defer?
Lloyd McKenzie (Oct 30 2018 at 16:55):
You can vote on it and make a decision on whether to apply in R4 or R5 later if you want
Eric Haas (Oct 30 2018 at 17:18):
as a technical correction... right.
Grahame Grieve (Oct 30 2018 at 19:58):
you can make technical corrections to expressions on search parameters after this week
Eric Haas (Oct 31 2018 at 00:36):
@Grahame Grieve how about right now? and do you know if there is an expression for "The value of the observation, if the value is a Quantity, or a SampledData (just search on the bounds of the values in sampled data)"
Grahame Grieve (Oct 31 2018 at 00:46):
Observation.value as Quantity | Observation.value as SampledData
Eric Haas (Oct 31 2018 at 00:46):
Thanks and should I wait until next week to apply?
Grahame Grieve (Oct 31 2018 at 00:46):
And document in narrative that
(just search on the bounds of the values in sampled data)
in this section: build.fhir.org/search.html#quantity - but I think that's procedurally a problem
Eric Haas (Oct 31 2018 at 04:17):
I am interpreting " but I think that's procedurally a problem " that I should hold off adding this text to the search page
Grahame Grieve (Oct 31 2018 at 04:18):
yes, that's normative now. We could consider adding a trial-use note about SampledData, or just putting on Observation.. oh, that's normative too....
Grahame Grieve (Oct 31 2018 at 04:18):
or we could leave it to implementer... discretion....
Grahame Grieve (Oct 31 2018 at 04:19):
@Lloyd McKenzie @Ewout Kramer @Josh Mandel @Rick Geimer FHIR-I co-chairs have an opinion?
Lloyd McKenzie (Oct 31 2018 at 04:27):
We can add a note that a couple of the search parameters may not be optimally defined, that implementers are free to use their own search parameters and that they may want to monitor the CI build for guidance. That wouldn't interfere with normative.
Grahame Grieve (Oct 31 2018 at 04:29):
add a note where?
Lloyd McKenzie (Oct 31 2018 at 04:33):
Observation, near the search params
Grahame Grieve (Oct 31 2018 at 04:34):
we can define the search paraneters optimally. It's the search on SampledData that is procedurally tricky
Lloyd McKenzie (Oct 31 2018 at 04:40):
We can't change the definitions of any of the search parameters from what went to ballot unless it's a very obvious technical correction.
Grahame Grieve (Oct 31 2018 at 04:43):
this case it is
Grahame Grieve (Oct 31 2018 at 04:43):
that we dsicussed earlier in this topic
Eric Haas (Oct 31 2018 at 04:44):
I am making the technical correction now, adding extra words somewhere is the tricky part
Lloyd McKenzie (Oct 31 2018 at 04:45):
I don't read adding in SampleData to the existing search criteria as an obvious technical correction?
Eric Haas (Oct 31 2018 at 04:46):
the description already says: "if the value is a Quantity, or a SampledData (just search on the bounds of the values in sampled data)" in the search criteria
Eric Haas (Oct 31 2018 at 04:48):
the search page says... "SampledData ...Not used in search"
Eric Haas (Oct 31 2018 at 04:50):
so I believe we are stuck or just say that a search expression on sampled data is server dependent?
Josh Mandel (Oct 31 2018 at 15:29):
It's honestly not even clear to me yet what the important ways to search on Sample data are -- so leaving this behavior as not entirely defined, then later introducing more targeted parameters seems not horrible to me.
Grahame Grieve (Oct 31 2018 at 19:59):
seems to me that we will need to say something about it somewhere
Eric Haas (Nov 01 2018 at 15:34):
for a little more background the search text "or a SampledData (just search on the bounds of the values in sampled data) " has been around since DSTU1. Since the issue was never raised until now - either it has been completely ignored or everybody is doing it ( which I doubt very much)
Is removing the text from the search definition a substantive change if nobody every followed it in the first place?
Eric Haas (Nov 01 2018 at 15:41):
We actually do say something about sampled data serach - we say is it not used in search
Eric Haas (Nov 01 2018 at 15:41):
I have an immediate issue of what to do in Observation... the bigger issue is how do you search Sampled data
Lloyd McKenzie (Nov 01 2018 at 15:43):
Yes, it's a substantive change. Substantive change (from the ANSI perspective) isn't based on what implementers do, it's based on how someone reviewing the specification would have interpreted it. We might well choose to allow breaking change between versions if we're confident it won't impact implementers, but it would still be a substantive change from an ANSI perspective - with all of the balloting impacts that implies.
Grahame Grieve (Nov 01 2018 at 18:14):
if you make an example - which isn't a breaking change - then that will trigger everyone to run into it
Lloyd McKenzie (Nov 01 2018 at 18:22):
How does an example help with search?
Grahame Grieve (Nov 01 2018 at 18:25):
it triggers all the server providers to get around to handling it
Eric Haas (Nov 01 2018 at 21:19):
how can we make a search example using sampled date when we say "sampled data is not used in search"
Grahame Grieve (Nov 01 2018 at 21:25):
that's the procedural issue, because Observation quite clearly says that we do.
Grahame Grieve (Nov 01 2018 at 21:25):
so I think we should add a trial-use clarification about how SampledData searching works
Eric Haas (Nov 06 2018 at 19:21):
- Who task is this?
- Do we need a new Tracker?
- How does this resolve the Observation tracker - we still have an expression that is technically incorrect. do we add
Observation.value as Quantity | Observation.value as SampledData?
Grahame Grieve (Nov 06 2018 at 20:15):
yes add this
Eric Haas (Nov 06 2018 at 21:47):
this = new tracker or add the expression to observation?
Grahame Grieve (Nov 06 2018 at 23:02):
add the expression
Eric Haas (Nov 07 2018 at 06:03):
done
Last updated: Apr 12 2022 at 19:14 UTC
