There seems to be some confusion regarding the concept of a ISO8601 Duration. You can definitely define a duration of 2 months in ISO8601 Durations. It has separate fields for years, months, weeks, days, plus an optional time with hours, minutes and seconds. All these fields are optional and can all be combined. It cannot be fully modelled using a single nanosecond field - you would run into trouble with years, months, and even days, plus you cannot express for example a duration of 1 hour with no precision in the minutes and seconds fields mentioned. I think https://en.wikipedia.org/wiki/ISO_8601#Durations has a good explanation of the concept.
The golang Duration type in the time package is _not_ an ISO8601 duration, but just a duration in nanoseconds, explicitly omitting the definition of days. There are libraries available for golang that do model the full iso8601 duration. Of course, I agree that we should not have a far too big reference model. There is a point at which it no longer makes sense to add something to the reference model because it is better modelled in an archetype. But I think the concept of a duration can be very useful. You could use it to model the examples Gerard Freriks mentions for example: - 24 minutes, 5 seconds can be modelled as a single Element with a DV_Duration value. The ISO8601 text representation of the dv_duration.value field would be PT24M5S. - For 2 hours past midnight can be modeled with two Elements, for example a 'duration after a specific time' archetype with two elements, one with a DV_DURATION value and one a DV_TIME value, if that is what you want to express. - A duration after a specific clinical event can be modelled as however you want to model the reference to the clinical event, plus a single DV_DURATION field. In the first example the value field of the DV_DURATION would be P2M, the second PT2H Say you want to model the duration after which to resume a specified daily activity after a specified clinical event . You could model it by creating an archetype with a reference to the clinical event, a model of a description of the activity, and then a single DV_DURATION field, describing the time between the event and the start of the daily activity. The person entering the data with this archetype now has the freedom of choosing any detail level he or she wants - whether that is in terms of years, months, weeks, days, hours, minutes, seconds, or any combination of any of these terms. And the nice thing is, you would use a standards based duration concept that is readily available in many off the shelf languages, libraries, serialization tools, UI components and databases, instead of defining your own. And it's already defined in the OpenEHR models, so you can start using it right away. Regards, Pieter Bos Nedap Healthcare On 21/03/2018, 12:25, "openEHR-technical on behalf of Bert Verhees" <[email protected] on behalf of [email protected]> wrote: On 21-03-18 10:50, GF wrote: > Does including Duration in the RM fit with the scope for the RM? > > Why do we have archetypes? > Why not include every thing in the RM? > Do we want the HL7v3 Reference Model as it existed many years ago and > that could not be inspected without a magnifying glass on a sheet of > paper that was 2 by 1 meters? > > Is there one kind of duration? > 24 minutes, 5 seconds? > For 2 hours past midnight? > For 2 hours after (clinical) event x > For 2 months after (clinical) event y 2 months cannot be technically represented in a duration, because month is not a stable time-definition. It is a Calendar definition. It is therefor that most major programing languages have a Duration and a Calendar class. Or you say that OpenEhr has no valid Duration-datatype, so always express Duration in an archetype (your way), or say that OpenEhr has a valid Dv_Duration type, and do it right (I prefer this way), or express months as if it is a stable time-indicator and ignore it is not (like it is now) Those are the three possible ways to solve this problem, I think I am curious to learn what the community will decide. Bert _______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org _______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
