A Calendar datatype.
Nothing restricts you to create a “data type pattern”/specialized cluster that has exactly this semantics
That is true, but I think it would be good if it would find its way in the RM, for two reasons
- misusing the duration does not seem right, and I think the ISO string representing a duration must change. That is, I know, a long way, so the part before the ‘T’ should represent a calendar datatype, and the other part should be a duration. It is also worth considering to split the DV_DURATION type in the same way.
- If it find its formal way in the RM libraries will support it also, which will help implementers to do it the right way.
Bert
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
Gerard Freriks
+31 620347088
gfrer@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
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
just to give some background, ‘Duration’ was always intended to represent a data type that could be considered like the ISO601 Duration type (also the ISO8601 Date type etc), which is also a W3C type (duration, gdate etc) - regardless of internal representation. For Java programmers, the joda library provided this; recent Java and C# have more modern things built in. The Foundation Types spec now has a . No guarantee it is correct 
we are moving away from this terminology ‘assumed types’, and just using ‘primitive types’, but the idea is the same - that it is assumed that the programming environment has some equivalent that can be connected to e.g. Duration, String etc, as they appear in the openEHR specs. it is now - in the . right - that xref table referred to above is an attempt to do this. We can expand that table to include more languages/technologies, or do it some other way. If we can use this table, it means we can avoid publishing another separate spec. - thomas
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
> 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
we don’t really use Duration to represent 3 times / day. There are . It seems that noone uses these. THere have been many other attempts to define either types or structures, like iCal and other calendar-related structures. But I don’t see a clear winner in terms of standards. THe medication archetypes solve it by using multiple fields, and in Task Planning we had to create some . - thomas
although ‘month’ is not a scientific notion (it’s not constant), we do treat it as a data type or unit in social date time types, which is what we are mostly dealing with, and what the types DvDuration, DvDate etc correspond to.
For scientific durations, use DvQuantity, and then you have a Real + units, e.g. 205ms, 89ns, 4.5min etc
So I think it is quite right to standardise these two notions in the RM, and also if we can, a standard model of ‘time specification’ which is the ‘3 times/day’ kind of idea. We still don’t have a good solution for this last one.
- thomas
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
You can need Duration for many purposes Which comes to mind. How long was the patient feeling bad? How long did the patient sleep? How long was he staying in the hospital. These are all Durations. How long was the pregnancy time, How much time is their between two named phases of a heartbeat
What is the problem with the Calendar type?
You gave proof that there are different kinds of time.
Chrono-time as used fro time stamping at one exact point in time.
And Chairos-time used for imprecise relative time as used by humans,
Chrono-time is one primitive data type.
Chairos-time is defined using archetype/patterns
Gerard Freriks
+31 620347088
gfrer@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
I don't mind how you call it, programmers call it Duration and Calendar, both are well known datatypes, but they have other semantics.
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
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
Sorry for my unpleasant tone, I guess we are talking about the same things.
Bert
Pieter, the problem are the conflicting semantics. You should avoid having conflicting semantics in one class, that is confusing.
I think that is why Java and Golang have both in their standard libraries because of the conflicting semantics
There is no good reason to have months and hours in one class.
I must admit, days is a bit in between, although, when looking exact at it, one specific day can have in some years one second more or less.
I believe this is always December 31th. So days is more right to put in the Calendar class.
But I must leave this discussion, I notice I get involved too much. I have given my opinions, and others should give theirs
Best regards
Bert
When I’n not mistaken:
Duration is not the same concept as Calendar.
IsoTime and Calendar are both data types defining an absolute point on the time line, but in different ways.
Duration is the difference between points on the time line.
My point is that some times we can not/want not use points on the time line but use fussier terms like: begin of an event somewhere in 2015, or a duration of one month, or
Gerard Freriks
+31 620347088
gfrer@luna.nl
Kattensingel 20
2801 CA Gouda
the Netherlands
Which can be modelled as
<point in time> +/- <interval of uncertainty>
such as
<June 1st 2015> +/- <3 months>
Karsten
In the Java and Golang classes Calendar is also to indicate durations, it is in fact, to do Calendar calculations. You can calculate the first day (example 2004/1/1) and say, this date + 3 months, and then you get a new Date, which is a different number of days away then when the first date is 2005/1/1 + 3 months (because of Leap year) For example, see here the Add function to Add months or weeks or years to a date That is what is needed when you calculate in the date range of the ISO8601 string. When you do calculations in the time range, then you need to calculate with a Duration (which does in background everything in nanoseconds, but has convenience methods to use it for hours and minutes, etc)