Hi all,
We have always expressed the clinical notion ‘age’ as DV_DURATION. It was one of the first things I remember Sam telling me… ie the duration of time since birth.
BUT there is a clinical situation where you can have a negative ‘adjusted age’ where there is a premature infant, now chronologically 2 months old but born 3 months premature - they are said to have an adjusted, or corrected, age of -1 month. Clinically this is important when related to expected development/behaviour/functional capacity. If they were 3 months premature then you would only worry about their development related to their adjusted age, not their chronological age. By the age of 2 or 3, the difference has usually disappeared and adjusted age becomes less relevant.
So a negative (type of) age, which is clearly not permitted with DV_DURATION, is clinically necessary. And it should be able to be expressed in a combo of weeks, months +/- years.
It makes sense for both the chronological age and adjusted age to use the same data type and I suspect that loosening the DV_DURATION constraints is not feasible.
Thoughts, advice?
Heather
1 Like
Indeed, an clinically relevant issue.
An adjusted age is a kind of derived data that could be modelled as a data point in a archetype or template. Reaonable?
BTW little bit like a negative price of the crude oil futures. 
Hi Lin,
Yes & No! 
Adjusted age can be derived if we record the gestational age at birth.
And we will often need to view it alongside chronological age, so at the moment it makes most sense to me to model in the same archetype.
But the problem remains - which data type to allow for a relative, negative age.
Yeah, negative oil prices. Whodathunk it?
Maybe we could use two positives to derive it in the same archetype. So no need to modify the basic data type.
For DV_DURATION it says in the spec:
A sign may be used to indicate the duration is backwards in time rather than forwards.
But then it insists on being ISO8601 which in its pure version at least doesn’t allow negatives as far as I know.
What I have seen is that negative durations are supported in various places, e.g. “-P1D”
This is what the xml duration is doing as well (base on ISO8601 but allow negative), see XML Schema Part 2: Datatypes Second Edition . Java and I believe .NET as well are doing similar things.
Seems like there is a little inconsistency in the spec, which in my view should be fixed by formally allowing a negative as well - from the wording of the DV_DURATION description this seems to have been the intention all along, @thomas.beale ?
1 Like
Hm… good catch. I would say that we should fix the spec:
- to indicate ISO8601 plus a ‘deviation for negation, in line with W3C etc etc’;
- add Heather’s example somewhere in the text to indicate the negation possibility;
But the real change presumably needed is for the various modelling tools which I assume don’t currently allow for a negative duration?
2 Likes
Time related things need a thorough thinking thru.
Time can be real, absolute and relative.
Real time: is what is measured using a clock. Data types dealing with time are used. (technical timestamp on a data artefact, the technical Datatype DV_Duration is used to calculate with Real times. Here the XML duration described in the links can be used.)
The Absolute en Relative times use archetypes. These are times with a specific context.
The Absolute time archetypes describes a time measurement and its context. (a person making a statement on for instance an Observation, or Order, Action, etc.)
The Relative time is an archetype describing a point in time relative to a base time, but also things like seasons, days of the week, notions like 1 day after an event, etc. Here Durations come to play but they will not use the Datatype Duration.
1 Like
Agree, this seems to be the right thing to do…and yes, unfortunately, some of the tooling will need to be changed for sure to support this.
Actually, the original Java Parser has a pattern for this which allows an optional minus: (-)? which means this partly works for 1.4 archetypes in CKM…but display and conversion to adl2 or usage in templates fails where a pure ISO8601 duration is expected.
@sebastian.garde could you please raise a CR (don’t bother with a PR) for this in RM with fix_version = Release 1.1.0 - might as well get it done in the earliest release.
1 Like
I believe I read somewhere (but I can’t find the source) that the 8601-2 allows for negative durations. Perhaps somebody has access to this? Might be a good idea to check out the specs and see if more of the extension should be implemented in OpenEHR spec.
2 Likes
