Stream: implementers
Topic: Question on search on a quantity param
Michael Calderero (Jul 17 2017 at 14:28):
Hi,
I'm a bit confused about the examples and their corresponding descriptions in http://hl7.org/fhir/STU3/search.html#quantity:
Example1: GET [base]/Observation?value=5.4|http://unitsofmeasure.org|mg
Example1 Description: Search for all the observations with a value of 5.4 mg where mg is understood as a UCUM unit (system/code)
Example2: GET [base]/Observation?value=5.4||mg
Example2 Description: Search for all the observations with a value of 5.4 mg where the unit - either the code or the stated human unit (unit) are "mg"
My understanding of Example1 is that when the 'system' part is provided in the search url, the the FHIR server will only use Quantity.code and not use Quantity.unit. However when 'system' is not provided then the FHIR server will also use Quantity.unit along with Quantity.code.
Is this the correct interpretation? Or should all searches use both Quantity.unit and Quantity.code regardless of the 'system' part present?
Eric Haas (Jul 17 2017 at 15:28):
"My understanding of Example1 is that when the 'system' part is provided in the search url, the the FHIR server will only use Quantity.code and not use Quantity.unit. However when 'system' is not provided then the FHIR server will also use Quantity.unit along with Quantity.code."
Yes that is how I interpret it as well. But it is not explicit. Can you submit a tracker to clarify the syntax?
Lloyd McKenzie (Jul 17 2017 at 15:29):
Yes. I'm not sure whether the intention is to diverge from how token works or not. We definitely need to make that clear, so please raise a tracker
Michael Calderero (Jul 17 2017 at 17:53):
Thanks. I reported GF#13646.
Michael Calderero (Jul 17 2017 at 20:12):
Some more questions I have regarding this topic:
The description for http://hl7.org/fhir/STU3/datatypes.html#Quantity says: "If the unit can be coded in UCUM and a code is provided, it SHOULD be a UCUM code". Why is it not a 'SHALL' given that the system clearly indicates the UCUM namespace?
And it isn't clear to me whether case-sensitive or case-insensitive comparison should be done on Quantity.unit or Quantity.code for FHIR servers that don't have a sophisticated UCUM engine or the cases where 'system' is not provided. I'm assuming case-insensitive comparison is done if it is intended to be similar to the token param type?
Lloyd McKenzie (Jul 18 2017 at 02:46):
Quantity doesn't require that the code system be UCUM - it's allowed to use alternate code systems, but we prefer to use UCUM. UCUM is case-sensitive.
Lloyd McKenzie (Jul 18 2017 at 02:47):
The token param type is also case sensitive unless the underlying code system indicates explicitly that codes should be handled in a case-insensitive manner.
Michael Calderero (Jul 18 2017 at 12:21):
"Quantity doesn't require that the code system be UCUM - it's allowed to use alternate code systems, but we prefer to use UCUM. UCUM is case-sensitive."
A bit confused here especially your last sentence because http://unitsofmeasure.org/ucum.html section 2.1 contains notes about case sensitive and case insensitive symbols. However, I did some more digging in the FHIR spec and came across this: http://hl7.org/fhir/STU3/ucum.html with the note that the code is a " Valid expressions using the case sensitive symbols".
So do you actually mean that even though UCUM allows for case insensitive symbols, the FHIR spec only uses the case sensitive symbols hence FHIR servers should only do case sensitive comparison for UCUM codes?
Michael Calderero (Jul 18 2017 at 12:35):
"The token param type is also case sensitive unless the underlying code system indicates explicitly that codes should be handled in a case-insensitive manner."
I'm looking at these in the FHIR spec: http://hl7.org/fhir/STU3/search.html#token and http://build.fhir.org/search.html#token.
As per my interpretation, the first sentence of the first paragraph supports what you say regarding exact matches. But the first sentence of the second paragraph threw me off. From the spec:
"For tokens, matches are literal (e.g. not based on subsumption or other code system features), but not case sensitive."
The ending phrase of that sentence lead me to believe that token searches are case insensitive e.g. a search for Patient?identifier=someurl|someval will match [SOMEURL/sOmeVAL].
Lloyd McKenzie (Jul 18 2017 at 13:40):
Yup, that wording isn't consistent and is potentially problematic. Can you submit a change request?
Michael Calderero (Jul 18 2017 at 14:00):
Which one are you referring to? The wording on token or the wording on UCUM?
Lloyd McKenzie (Jul 18 2017 at 14:36):
The wording on token. If you're using UCUM with FHIR, you're required to use the case-sensitive version
Michael Calderero (Jul 18 2017 at 15:36):
Thanks @Lloyd McKenzie I filed GF#13655.
Eric Haas (Jul 18 2017 at 16:42):
I am now confused what needs to be clarified.... As I understand it the token search is case insentive but the code system determines whether the codes need to be case sensitive. they are two different things.
I can search UCUM using mg/l which will matchmg/L
On the other hand mg/l will fail validation as a UCUM code in quantity.code and mg/L will pass
Jorge de la Garza (Jul 27 2017 at 17:56):
Hi, I have a question about how a quantity search is supposed to work when the target value has a comparator (<, <=, >, >=) and the search value has a prefix (gt, ge, lt, le, etc.). (All of this assumes the units either match or can be converted to match.) So my interpretation of the spec is that when a quantity value has a comparator, for search purposes it is a range with either an upper bound or a lower bound, but not both. So if an Observation.valueQuantity has comparator=">" and value="180", for search purposes that is a range from 180 to infinity. The "range" interpretation of the "gt" search prefix is: "the range above the search value intersects (i.e. overlaps) with the range of the target value". So it seems that any search of the form "/Observation?value-quantity=gt[value]" will select this resource, because no matter where "[value]" lies in relation to 180, the range "[value] to infinity" always intersects "180 to infinity". Am I understanding all that correctly?
Grahame Grieve (Jul 27 2017 at 20:41):
I think so
Last updated: Apr 12 2022 at 19:14 UTC
