Stream: implementers
Topic: search parameter naming
Josh Mandel (May 12 2016 at 12:25):
Do we have guidance on how these are named (e.g. something like "if a resource property has a camel case name like someThing, then the search param for it should look like some-thing)?
In Condition I see two params following apparently different conventions:
date-recordedclinicalstatus
and that seems inconsistent. (It has also led to real-world confusion.)
Grahame Grieve (May 12 2016 at 12:49):
guidance is here:
Grahame Grieve (May 12 2016 at 12:50):
Josh Mandel (May 12 2016 at 13:12):
Thanks Grahame ―so this is an error in the name of clinicalstatus, right?
Grahame Grieve (May 12 2016 at 13:15):
that'd be my reading yes
Michelle (Moseman) Miller (May 12 2016 at 22:11):
Depends on how you read the first bullet of "use the element name"
In Feb, I asked @Grahame Grieve and @Lloyd McKenzie about this...Back then, the rule was search parameters names could be element names (all lower case - no dash) and other compound search parameter names needed the dashes to pass spell checker. (Element names were added to spell checker, so they didn't need the dashes.)
If we make this rule consistent to always use dashes for compound word search parameters, then Lloyd ran some stats to assess impact. Back in Feb, those numbers were:
51 names (63 total occurrences) all lowercase
72 names (101 total occurrences) dash-separated
I don't recall a final communication/decision to go add dashes to the search parameters in all lower case, but seems like it would be beneficial to have a common pattern.
Danielle Friend (May 15 2017 at 19:27):
Did we ever reach a consensus on this?
It still appears to be inconsistent: http://www.hl7.org/implement/standards/fhir/appointment.html has "appointment-type" and "inocmingReferral"
Grahame Grieve (May 17 2017 at 05:57):
I thought we did - can you make a task to ensure that the build generates appropriate warnings please
Chidamber Kumar (Apr 02 2020 at 19:54):
Hi
I have question around date search parameter. Isn't gt2013-01-14T and sa2013-03-14 holds same meaning ? Any case where these could have different meanings ?
Lloyd McKenzie (Apr 02 2020 at 20:01):
My belief is yes. gt2013-01-14T would include 2013-01-14T05:00:00+00:00, while sa2013-01-14T would not. That's because gt allows overlap in the imprecise range, while sa does not. However, ccing @Grahame Grieve and @Josh Mandel to confirm
Grahame Grieve (Apr 02 2020 at 20:10):
agree
Chidamber Kumar (Apr 02 2020 at 20:18):
Thanks @Grahame Grieve @Lloyd McKenzie for confirming that.
Chidamber Kumar (Apr 02 2020 at 20:30):
One more here from date search parameter:
Going by the overlapping in the imprecise range, I am assuming 'eq' allows it.
Would 'eq2013-01-14T10:00' include '2013-01-14T15:00' or '2013-01-14T09:00 ?
ryan moehrke (Apr 02 2020 at 20:32):
Starts After (SA) and Ends Before (EB) are to be used in searches on periods where there is a start and end to compare with. So SA compares the value in the search (2013-01-14 in this case) with the start value of the resource in the same manner that GT would in a non-period search and EB compares the value in the search with the end value of the resource like LT would would in a non-period search. Also to note, when searching on periods GT acts as an "ends after" while LT acts as a "starts before" following the same logic.
SA and EB can also be used on non-period dates and decimals where there is an implied period based on the precision and I think that's what Lloyd was referring to.
So yes, they are different but they can be equivalent in most cases.
ryan moehrke (Apr 02 2020 at 20:43):
also as for your followup EQ question: you're close, but not specifically the situation you asked.
Since you asked about 2013-01-14T10:00, the implied range of that value only covers the seconds. 2013-01-14T10:00:00 to 2013-01-14T10:00:59
so eq2013-01-14T10:00 would not include '2013-01-14T15:00' or '2013-01-14T09:00 because they are all at their own distinct times. On the other hand, eq2013-01-14 (without the time) would include both, because the 15:00 and 9:00 times are fully contained in the implied range of 2013-01-14T00:00:00 to 2013-01-14T23:59:59 (all day on the 14th)
Chidamber Kumar (Apr 02 2020 at 20:50):
Okay! that's a lot of clarity. Got the sense now . :+1:
Thanks @ryan moehrke
Chidamber Kumar (Apr 02 2020 at 20:54):
and ap2013-03-14 would be an exact match (as the example suggest). No implied range. Am I on-point on this ?
ryan moehrke (Apr 02 2020 at 21:03):
Honestly I haven't done too much with AP yet, but from what I know it's meant to be an approximate match and the "range" is based on some arbitrary precision instead of the normal implied range. Are you looking at this table? https://www.hl7.org/fhir/search.html#prefix
Chidamber Kumar (Apr 02 2020 at 21:05):
No, actually I am looking at the one present here http://build.fhir.org/search.html#date
Chidamber Kumar (Apr 02 2020 at 21:09):
the table you have send is detailed. I was about to ask if the range details are mentioned anywhere.
ryan moehrke (Apr 02 2020 at 21:11):
Also you can see the same table on the CI build here http://build.fhir.org/search.html#prefix if you wanted to look at CI instead of R4
Lloyd McKenzie (Apr 02 2020 at 22:17):
Be aware that '2013-01-14T10:00' isn't actually a valid FHIR data value - though some servers might choose to support it. If you specify time, you must specify it down to the second and provide a timezone. @Grahame Grieve, I'm pretty sure this applies when searching too - we haven't said it doesn't, though obviously it'd be nice to allow imprecision to the hour or the minute if possible.
Grahame Grieve (Apr 02 2020 at 22:20):
we can allow it there, so we do, though it's kind of a pyrrhic victory
Chidamber Kumar (Apr 02 2020 at 22:27):
Well, the website does have a mention about it.
"the minutes SHALL be present if an hour is present, and you SHOULD provide a time zone if the time part is present"
Last updated: Apr 12 2022 at 19:14 UTC
