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
