You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're mapping an OBX.5 Observation Value. It is a decimal value that requires lossless precision when converting to FHIR. The value we have in HL7 is 1769.859285 and it gets rounded to 1769.8593 when transformed to FHIR. We need to preserve decimal precision without rounding when transformed.
We found out that the rounding is happening because hl7v2-fhir-converter is using Java's Float when mapping OBX.5, which is single-precision and represents a very limited range of values.
The problem is, AFAIK there is no support for a decimal type with higher precision (like Double or BigDecimal)
To Reproduce
We're trying to convert the following OBX segment in an ORM_O01 message: OBX|1|NM|8339-4^BIRTH WEIGHT MEASURED^LN|1|1769.859285|g^gram^UCUM|||||O|||20230506050000-0500|||||||||||||||QST|AOE
Where DECIMAL would map to BigDecimal, which would preserve the value without rounding. Double could also work
Desktop (please complete the following information):
OS: macOS
Version: Ventura 13.4.1
Additional context
We can volunteer to create a PR to add an additional decimal type if that makes sense
The text was updated successfully, but these errors were encountered:
basiliskus
changed the title
Not able to represent decimals with type other than Float
Not able to represent decimals with higher precision than Float
Jul 21, 2023
Describe the bug
We're mapping an
OBX.5
Observation Value. It is a decimal value that requires lossless precision when converting to FHIR. The value we have in HL7 is1769.859285
and it gets rounded to1769.8593
when transformed to FHIR. We need to preserve decimal precision without rounding when transformed.We found out that the rounding is happening because
hl7v2-fhir-converter
is using Java'sFloat
when mappingOBX.5
, which is single-precision and represents a very limited range of values.The problem is, AFAIK there is no support for a decimal type with higher precision (like
Double
orBigDecimal
)To Reproduce
We're trying to convert the following
OBX
segment in anORM_O01
message:OBX|1|NM|8339-4^BIRTH WEIGHT MEASURED^LN|1|1769.859285|g^gram^UCUM|||||O|||20230506050000-0500|||||||||||||||QST|AOE
And we get the following
value
as a result:Expected behavior
We expect the conversion to return
"value" : 1769.859285
instead of"value" : 1769.8593
The type for the value is defined in
Quantity.yml
as follows:We'd like to be able to have something like:
Where
DECIMAL
would map toBigDecimal
, which would preserve the value without rounding.Double
could also workDesktop (please complete the following information):
Additional context
We can volunteer to create a PR to add an additional decimal type if that makes sense
The text was updated successfully, but these errors were encountered: