Stream: implementers
Topic: Decimal searches
Steve Munini (Aug 13 2018 at 01:19):
I'm trying to better understand the intent of the implicit range concept for decimals described here: http://build.fhir.org/search.html#number
Three examples are provided:
[parameter]=100 Values that equal 100, to 3 significant figures precision, so this is actually searching for values in the range [99.5 ... 100.5)
[parameter]=100.00 Values that equal 100, to 5 significant figures precision, so this is actually searching for values in the range [99.995 ... 100.005)
[parameter]=1e2 Values that equal 100, to 1 significant figures precision, so this is actually searching for values in the range [95 ... 105)
Q1: I can't seem to locate anywhere (except in the examples) the definition of the size of the implicit range. It seems to be dependent on the number of digits of the provided search parameter, but limited to 1 for the exponential form?
Q2: I don't think that the prefixes sa and eb apply to the decimal data type - they only apply to date-oriented searches, correct? The spec is a little confusing here because right after the definitions of sa and eb, it talks about implicit and explicit ranges, and provides an example "2.0 has an implicit range of 1.95 to 2.05"
Q3: What is the value/intent of an implicit range on decimals for searching? It seems to confuse things. If someone wanted to find a value in that range, wouldn't they create a query similar to this: .../RiskAssessment?probability=gt99.5&probability=lt100.5
Lloyd McKenzie (Aug 13 2018 at 01:53):
The number of significant digits is the number of digits specified, excluding leading zeros. So 100 and 1.00e2 both have the same number of significant digits. We'd assumed that would be understood, but sounds like we need to make it explicit. Can you submit a change request for us to make it so?
Steve Munini (Aug 13 2018 at 02:19):
I would be happy to, Lloyd, but I guess I have a 4th question now... If someone is searching for [parmeter]=100 on a decimal, they are going to get values in the range of 99.5 to 100.5, and not an exact match? Isn't that going to cause a mess for clients? They will need to iterate through results to find the exact match. In the notes section of the datatypes page, it says "Implementations SHALL handle decimal values in ways that preserve and respect the precision of the value as represented for presentation purposes" Why doesn't the same apply to search parameter values?
Lloyd McKenzie (Aug 13 2018 at 02:22):
The logic is that with decimal, there's no such thing as "exact match". All decimal values are expressed to some level of precision based on the capabilities of the system or individual making the measurement. So when you have a systolic blood pressure of "110 mmHg", that's not *exactly 110.0000000000" It's some value that was greater or equal to 109.5 and less than 110.5. If you do a search on 110 mmHg, you certainly wouldn't want to exclude a measurement that was 110.1 or 110.02.
Lloyd McKenzie (Aug 13 2018 at 02:22):
(Though in practice, doing exact searches on decimal values is a rather uncommon thing to do - generally you check for things in a range.)
Steve Munini (Aug 13 2018 at 02:27):
I see your point, however the counter argument is that .../RiskAssessment?probability=100 is going to return a lot of values that are not 100.
Steve Munini (Aug 13 2018 at 02:29):
Lloyd, can you answer Q2 above too, please? I'm still confused on that. sa and eb do not apply to number search types, only dates, correct?
Lloyd McKenzie (Aug 13 2018 at 02:34):
If you want to narrow your range, just specify a large precision. E.g. RiskAssessment?probability=100.000000
My read is that sa and eb are only for date and time-related data types. If you think this needs clarification, you can submit a change request for that too :)
Steve Munini (Aug 13 2018 at 02:55):
Thanks Lloyd.
Significant Figure item: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=17668
sa and eb item: https://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=17669
Patrik Sundberg (Aug 13 2018 at 06:01):
a follow-up to this because now i'm confused: https://www.hl7.org/fhir/datatypes.html#decimal states that a decimal is defined as "xs:decimal, except that decimals may not use exponents, ..."
so why would a search for 1e2 or 1.00e2 be allowed?
Lloyd McKenzie (Aug 13 2018 at 06:05):
Look at build.fhir.org - we've changed the rule
Last updated: Apr 12 2022 at 19:14 UTC
