Stream: implementers
Topic: Decimal Precision Limitations
Grahame Grieve (Sep 03 2019 at 22:04):
GF#22655 discusses problems with decimal precision - in this case, the limits of precision. There are implicit limits from the underlying definitions in json and xml, but we haven't formalised any restrictions or requirements in regard to the FHIR data type itself
We could say things like:
- the number can't have more than 18 digits.
- the number can't have an exponent with more than 4 digits
- systems must support at least 10 digits of precision
But what should say? Does anyone have any thoughts about this?
Btw, the only place I know of where highly precise decimals really matter in healthcare is actually GPS locations.....
Pascal Pfiffner (Sep 04 2019 at 09:26):
Are you sure about GPS? On the 30th latitude, 7 digits, i.e. 0.000001 degrees of longitude, is accurate to about 1 cm. I don't think we need to be this precise, nor is any of the commercial GPS systems able to deliver such accuracy. :grinning:
Grahame Grieve (Sep 04 2019 at 20:36):
yes, that's the only place I've ever seen 7 digits matter. elsewise....2-3 digits is the norm
Grahame Grieve (Sep 04 2019 at 20:36):
the actual computational limits are far outside that
John Silva (Sep 05 2019 at 13:17):
@Grahame Grieve - are there any use cases for genomic data that require more precision?
Lloyd McKenzie (Sep 05 2019 at 15:24):
@John Silva Good point. The primary numbers involved in genomics are locations and read counts. Both are integers, but they can be outside the range supported by FHIR Integer. In humans, the longest chromosome is 249 million base pairs. I'd have to presume that some organisms can have chromosomes longer than that. And, to identify variant location, we need absolute precision. (Precision on read counts isn't so important.) So in genetics, we'd need 9 digits for sure. For some weird species maybe 10 or even 11 - I'm not sure what the longest chromosome in nature is and Google wasn't much help. @Bob Freimuth @ Bob Milius ?
Bret H (Sep 05 2019 at 15:37):
@Lloyd McKenzie That is an impossible question, choose 11 as a practical number. There is a physical upper limit (as evidenced here: https://www.cell.com/fulltext/S0092-8674(00)81891-7) but one cannot be sure that we've evaluated every species existent. If some future organism is found with a trillion nucleotides in a chromosome we'll have to reevaluate then. Additionally, positional information can be given respective to a reference. If 11 is not enough, one can always create reference sequences with less than a trillion nucleotides, and thus not need the extra precision. Make sense? I recommend 11 and moving on.
Grahame Grieve (Sep 05 2019 at 20:43):
this is decimal or integer? Surely this is an integer question?
Lloyd McKenzie (Sep 05 2019 at 20:47):
Integer can't go that big. The FHIR spec says if you need numbers that exceed a 32 bit integer, use decimal. And a 250 million is more than a 32 bit integer can handle :)
Grahame Grieve (Sep 05 2019 at 20:49):
not so. max is 2,147,483,647
Lloyd McKenzie (Sep 05 2019 at 20:53):
You'd think I should know that... Even read the spec and my brain twisted it. Ok. So that's enough for humans, but perhaps not quite big enough for the theoretical max. As Bret H notes, there are potential workarounds for unusual organisms. And the MolecularSequence does use integer for location information. So I withdraw my concern.
Alexander Kiel (Sep 06 2019 at 08:13):
I would refer to IEEE decimal64 as the decimal datatype FHIR uses. It offers 16 significant digits and an exponent range of −383 to +384. The advantage is, that most programming languages have full support for decimal64. In Java one can use BigDecimal with MathContext.DECIMAL64. Besides a defined maximal precision, IEEE decimal64 also defines a rounding mode with is essential for correct computations.
CQL uses a rather special fixed-point decimal format with max 20 digits in front of the point and max 8 digits after the point. On top of that the rounding mode isn't defined precisely. I understand part of the reason for this, but it is a pain to implement it correctly. FHIR shouldn't go the CQL route in my opinion. @Bryn Rhodes
Bryn Rhodes (Sep 06 2019 at 13:43):
The FHIR spec requires precision to be represented and preserved: http://hl7.org/fhir/datatypes.html#primitive, and the FHIRPath/CQL Decimal type is consistent with that. Precision is important in the operations defined for FHIRPath and CQL, so the datatype has to support precision, at a minimum as specified in the base FHIR spec.
Last updated: Apr 12 2022 at 19:14 UTC
