I don't understand. You can implement a single class ISO8601 Duration, containing all the different fields, all optional, that directly maps to and from the string representation. You can also easily use it to model both P30D and P1M, which are indeed different things. Depending on the fields set, it's either very exact or a bit less exact notion of duration.
You should not expect to always to the same calculations with all recorded values. How you should exactly handle durations, or dates, or date times, or intervals of date times, and if and how you need to split classes, depends on the context (archetypes are a very nice tool to define and standardize context). The standard ISO8601 types are very useful for having a standard way to record date, time, date+time, duration and intervals between fixed points in time, with varying precision. And I don't think we need anything else and certainly not anything less in the RM. Also days are not always 24 hours. Next weekend in our time zone we have a 23 hour day... That is one reason why some libraries make a different split between the concepts than what you call 'calendar' and 'duration'. Also every library and standard has its own term for those concepts. Regards, Pieter Bos On 21/03/2018, 14:42, "openEHR-technical on behalf of Bert Verhees" <[email protected] on behalf of [email protected]> wrote: No Duration type is a ISO8601 duration, ISO8601 is just a string representation of a duration. No programming language can, from its standard library safely express an ISO8601 in a class, because the ISO8601 is a combination of two types. Unless you are wiling to have an uncertainty of 10%, you cannot express a month in a Duration type. For many software, this uncertainty is not acceptable. Maybe it is for medical purposes, but OpenEhr also has an Admin_Entry, and there this uncertainty is not always acceptable. How do you bill someone who was one month in a clinic? Make it 28 days or 31 days? And the solution is easy, and it has advantages. If we split the Dv_Duration in a Calendar part and in a Duration part, then both have their own merits. If you want to bill a stay of a month in a clinic, you express it by days (which are always 24 hours) P30D (represented by the Duration class) and if you want the patient to return every month, you can use the first part, P1M (represented by the Calendar class). I don't think this is complex or requires complex algorithms, even opposite, it makes it more simple and more certain to process and all the troubles and bad feelings when converting a month to 30 days, and then find out it was 28 days, are gone. I think Joda was a complex solution for a simple problem. Bert On 21-03-18 13:47, Pieter Bos wrote: > 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 _______________________________________________ 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
