Decimal values lose precision during serialization — Decimal('19') becomes 19.0 in both model_dump() and model_dump_json()

[ralili]

When a FHIR resource contains a Decimal value with no fractional part (e.g., Decimal('19')), both model_dump() and model_dump_json() serialize it as 19.0. This is problematic because FHIR assigns semantic meaning to decimal precision: 19, 19.0, and 19.00 are clinically distinct values.

Reproduction:

from decimal import Decimal
from fhir.resources.observation import Observation

observation_dict = {
    "resourceType": "Observation",
    "status": "final",
    "code": {"coding": [{"system": "http://loinc.org", "code": "12345-6"}]},
    "component": [
        {
            "code": {"coding": [{"system": "http://loinc.org", "code": "12345-6"}]},
            "valueQuantity": {
                "value": Decimal("19"),
                "unit": "mg/dL",
                "system": "http://unitsofmeasure.org",
                "code": "mg/dL",
            },
        }
    ],
}

observation = Observation(**observation_dict)

# Model stores the value correctly
print(repr(observation.component[0].valueQuantity.value))
# Output: Decimal('19')

# But both serialization methods convert to float
print(observation.model_dump_json())
# Output: ..."valueQuantity":{"value":19.0, ...

data = observation.model_dump()
print(type(data["component"][0]["valueQuantity"]["value"]))
# Output: <class 'float'>

Expected behavior:

Decimal('19') should serialize as 19 in JSON output, Decimal('19.0') as 19.0, etc. The original precision should be preserved.

Actual behavior:

All whole-number Decimal values are converted to float, resulting in a trailing .0. Additionally, model_dump() returns float instead of Decimal, making it impossible to recover the original precision downstream.

Impact:

• FHIR precision semantics are lost. Per the FHIR spec, the number of significant digits conveys measurement precision.
• Downstream FHIR consumers may interpret 19.0 differently from 19.
• There is no clean workaround using model_dump() / model_dump_json() options (including round_trip=True and mode="json").

Suggested fix:

Add a custom field_serializer for DecimalType fields that preserves the original Decimal representation, e.g.:

from pydantic import field_serializer
from decimal import Decimal

@field_serializer('value', mode='plain')
@classmethod
def serialize_decimal(cls, v):
    if isinstance(v, Decimal):
        return int(v) if v == v.to_integral_value() else float(v)
    return v

Or ideally, a serializer that fully preserves FHIR precision semantics by writing the Decimal as a JSON number with the exact original significant digits.

Environment:

• Python version: 3.12.7
• pydantic version: 2.12.4
• fhir.resources version: 8.1.0

[cmodevcodes]

Is anyone working on this issue. Happy to take a look if there is still a need.

[nazrulworld]

You are welcome to make PR.

[cmodevcodes]

Thank you, I will take a look. Assume this issue doesn't belong to pydantic/ we cannot touch model_dump() or model_dump_json() so your proposed custom field_serializer fix should go into Observation class definition/ observation.py?

[nazrulworld]

you might need to work here https://github.com/nazrulworld/fhir-core/blob/main/fhir_core/types.py#L398

[cmodevcodes]

Thank you. Very helpful. Is the intention to add a @field_serializer in class Decimal? A few quick thoughts, may/may not be on point
#1. If we add the following line to your Reproduction code: print(type(observation.component[0].valueQuantity.value)), the output is <class 'decimal.Decimal'>. My suspicion is pydantic could bypass customized serializer and use its default serialization approach under core schema if the data type is python's built in Decimal. Another proof is "01." gets accepted as "1" currently, something expected for default python decimal.Decimal but not based on the RE pattern (assume that is FHIR standard) defined in _validator in class Decimal.

#2 The current serializer in class Decimal seems to also instruct pydantic to turn any data type into float/assume pydantic won't take type hints, but as mentioned above I don't know if it is even get called.
def _serialize(
value: typing.Union[str],
info: core_schema.SerializationInfo,
) -> typing.Union[float]:
"""Encodes a Decimal as float."""
return float(value)

#3 I am not sure if adding just another @filed_serializer would work as we already have core schema and _serialize... Need to reconcile serializers. Also does @filed_serializer work under a custom data type class/does it need to be part of a model class that is based on the BaseModel?

#4 Do we need to call it class Decimal? Can it be class FHIRDecimal? Also does it need to be stored as decimal.Decimal? Can it be store as str?

Interesting problem to implement FHIR while bridging python and json....

[nazrulworld]

Upgrade fhir-core version would solve this issue.