Adding decimal time to age/adjusted age

Clinical
1

I’m working with the RCPCH Growth Chart and building a template. Within this there is a section in the response as follows:

        "chronological_decimal_age": 8.167008898015059,
        "corrected_decimal_age": 8.139630390143736,
        "chronological_calendar_age": "8 years and 2 months",
        "corrected_calendar_age": "8 years, 1 month and 3 weeks",
        "corrected_gestational_age": {
            "corrected_gestation_weeks": null,
            "corrected_gestation_days": null
        },
        "comments": {
            "clinician_corrected_decimal_age_comment": "Correction for gestational age has been made.",
            "lay_corrected_decimal_age_comment": "Because your child was born at 38+4 weeks gestation, an adjustment has been made to take this into account.",
            "clinician_chronological_decimal_age_comment": "No correction has been made for gestational age.",
            "lay_chronological_decimal_age_comment": "This is your child's age without taking into account their gestation at birth."
        },
        "corrected_decimal_age_error": null,
        "chronological_decimal_age_error": null

I navigated to the Age.v0 archetype but has a query before submitting a CR. There’s clear duplication here and I believe the API response is just being comprehensive. But we don’t really need both. However, I could not see a way of including the decimal without modification of the Chronological age and adjusted age.

Happy to submit a CR but wondered if the current archetype should do the job anyway?

Including the decimal age is straight forward however (thank you @ian.mcnicoll for being my spectacles…)

image
image1144×965 64 KB

Note: API POST for reference:

{
    "birth_date": "2020-04-12",
    "observation_date": "2028-06-12",
    "observation_value": 115,
    "sex": "female",
    "gestation_weeks": 38,
    "gestation_days": 4,
    "measurement_method": "height",
    "bone_age": 10,
    "bone_age_centile": 98,
    "bone_age_sds": 2.0,
    "bone_age_text": "This bone age is advanced",
    "bone_age_type": "greulich-pyle",
    "events_text": ["Growth hormone start", "Growth Hormone Deficiency diagnosis"]
}
2

I’m not sure my advice to use the Quantity datatype and time unit was actually correct, as this is supposed to capture ‘scientific elapsed time’ - think stopwatch rather than calendar with months / leap years etc, especially as the RCPCH definition of Decimal Years is based on a Year being 365.25 days i.e it blurs the difference between days in a year. That makes sense in the growth chart context but I’ can’t find it used elsewhere.

Decimal age is expressed as a decimal fraction in units of years. It is calculated as the number of days / 365.25. The extra 0.25 is to account for the leap year which comes round every 4 years.

So, we might have to add these as a very specific kind of age expression, or just capture them more locally as a wee cluster extension if they are very RCPCH specific, or perhaps a custom UCUM unit @siljelb ??

What do other places do?

@johnmeredith - BTW I don’t like using the custonm label - you are not changing the stored ‘a’ unit so could get mixed up.

Or maybe I’m overthinking this!!

3

Aha!! Found it in UCUM

“mean Julian year” time aj a_j ANN_J no 365.25

a_j is the UCUM unit

https://ucum.org/ucum#para-31

4

I’ve clearly misunderstood what that is for - sorry!

5

I’ve looked into this a bit, and I think Ian’s suggestion to add a Quantity data type with the unit ‘a_j’ (mean Julian year) is correct. My only concern is that this unit is listed everywhere as a unit used almost exclusively in astronomy, even though the definition seems to be identical :woman_shrugging:

6

Personally I have never seen decimal years used in practice, even in my relatively limited paediatric experience at a major teaching hospital, but I can see that there may be occasions where recording very precise age data can be critical, especially in research.

As we explicitly train modellers to record age using DV_DURATION rather than other time-related data types, perhaps we should add decimal age as an option in DV_DURATION rather than DV_QUANTITY.

1 Like
7

Internally the Growth Charts centile/SDS calculations use decimal age since it is a better way of handling age in years - when we are then using cubic interpolation to generate LMS values for the child at that exact age and calculate SDS/centile from there.

But we don’t know of a strong reason that the data should be persisted by the implementer as a first-class data item in the EHR. What we do recommend is that the entire JSON response from the API is persisted so that the array of API responses can be fed back into the Chart Component, which natively ‘understands’ that JSON blob and will plot the points on the chart compnent for you.

3 Likes
8

Thanks, Marcus. A helpful perspective.

The more I think about it, the notion of an exact age (chronological and adjusted/corrected) is useful to record, probably more so for research than direct clinical use, but especially in newborn/premature infants where the hours/days/minutes may be critical in treatment decision-making.

In my mind now, what is the best way to model it… Adding another unit to DV_QUANTITY is a relatively easy option. Does adding another unit to DV_DURATION require specs committee consideration/approval or is it primarily a tooling issue?

Cheers

Heather

1 Like
9

IIRC DV_DURATION is based on ISO 8601, which prescribes using the Gregorian calendar.

10

Darn. Where is the ‘dislike’ button!

1 Like
11

Does that imply amending DV_QUANTITY then?

12

That option woukd just mean adding the new unit to the ucum list. Just needs to have the codelist updated

I could not find any references to other growth estimate susing juilan years this way or indeed alternative decimal age options, so personally i woukd just go with julian years. Duration will just not work.

1 Like