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"
<openehr-technical-boun...@lists.openehr.org on behalf of bert.verh...@rosa.nl> 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"
<openehr-technical-boun...@lists.openehr.org on behalf of bert.verh...@rosa.nl> 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
> openEHR-technical@lists.openehr.org
>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
_______________________________________________
openEHR-technical mailing list
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
