When we define a C_DATE_TIME element like this
ELEMENT[at0061] occurrences matches {0..1} matches { – Date/Time element
value matches {
DV_DATE_TIME matches {*}
}
}
we said that element at0061 can contains a Date/time value, a date only or a time only (indeed Archetype Editor show the label “Allow all”).
From the point of view of RM instances, this means we can have
2011-03-18T11:01:28
but also
2011-03-18
and
11:01:28
Or for the latter we need to use DV_DATE and DV_TIME rescpectively (remember we have defined a C_DATE_TIME constraint in archetype)?
ELEMENT[at0061] occurrences matches {0..1} matches { -- Date/Time
element
value matches {
DV_DATE_TIME matches {*}
}
}
...
Or for the latter we need to use DV_DATE and DV_TIME rescpectively
(remember we have defined a C_DATE_TIME constraint in archetype)?
That would not be possible, Leonardo, because DV_DATE and DV_TIME do
not inherit from DV_DATE_TIME.
When we define a C_DATE_TIME element like this
ELEMENT[at0061] occurrences matches {0..1} matches { – Date/Time element
value matches {
DV_DATE_TIME matches {*}
}
}
we said that element at0061 can contains a Date/time value, a date only or a time only (indeed Archetype Editor show the label “Allow all”).
not quite right - it can only contain a DV_DATE_TIME. Valid DV_DATE_TIMEs include instances with no time, e.g. ‘2011-03-18T11’. According to ISO 8601:2004, date/times with ‘reduced accuracy’ must contain a complete date, and at least the hour part of the time. So you can’t have just a date, nor just a time.
From the point of view of RM instances, this means we can have
2011-03-18T11:01:28
but also
2011-03-18
this is illegal in ISO 8601 (and therefore openEHR)
and
11:01:28
also illegal.
Or for the latter we need to use DV_DATE and DV_TIME rescpectively (remember we have defined a C_DATE_TIME constraint in archetype)?
This is quite important and I had not appreciated the limitations on the use of partial dates with DV_DATE_TIME. I would agree that DV_DATE_TIME + DV_TIME would be very unusual but it is a very common requirement in clinical systems to be able to supply a vague date - year only or year + month and from what you say DV_DATE_TIME will not allow this, unless an hour is also supplied.
I am struggling to understand the reason for this restriction in ISO 8601:2004 - if the date is vague, what is the point of having any time at all!! Though I suppose the use case might be - “It was a cold dark December night and the clock has just struck 23:00”.
Having to add a DV_DATE constraint seems horribly clumsy. Perhaps we just need to make it clear than in implementation, some sort of dummy time is added. In clinical terms this will always be meaningless except in exceedingly rare circumstances.
Ian
Dr Ian McNicoll
office +44 (0)1536 414994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll ian.mcnicoll@oceaninformatics.com
Clinical analyst, Ocean Informatics, UK
openEHR Clinical Knowledge Editor www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
BCS Primary Health Care www.phcsg.org
This is quite important and I had not appreciated the limitations on the use of partial dates with DV_DATE_TIME. I would agree that DV_DATE_TIME + DV_TIME would be very unusual but it is a very common requirement in clinical systems to be able to supply a vague date - year only or year + month and from what you say DV_DATE_TIME will not allow this, unless an hour is also supplied.
I am struggling to understand the reason for this restriction in ISO 8601:2004 - if the date is vague, what is the point of having any time at all!! Though I suppose the use case might be - “It was a cold dark December night and the clock has just struck 23:00”.
I guess the idea is ‘I had a migraine at about 10am on Sunday 1st Feb’…
Having to add a DV_DATE constraint seems horribly clumsy. Perhaps we just need to make it clear than in implementation, some sort of dummy time is added. In clinical terms this will always be meaningless except in exceedingly rare circumstances.
I am not sure. I think that if one investigates closely the questions whose answers could really be a time-point (i.e. DV_DATE_TIME), they would not intersect that much with questions that could be answered with just a date - partial or not. I think that where the questions are like:
doc: so what date was this?
patient: last monday, so,… hm… the 14th March
doc: and what time?
patient: oh, just after feeding the baby, about 2pm
I would guess that the ‘what time?’ question is only asked if the time is relevant to the problem, or recurrent patterns of it; most likely because it is linked to some real world event (e.g. feeding baby, drinking alcohol). So I think that the actual data points here are something like:
date of occurrence: DV_DATE
time of occurrence: DV_TIME
linked event: DV_TEXT
I had better go back on that one - I had forgotten that we have an exception with respect to this in openEHR (Support IM section 3.4.4) - I was considering ISO 8601 only. Reasons for this are explained in the date/time part of the openEHR data types IM. It appears that on close inspection (by Heath) the invariants do not properly match the intended exception to 8601. HL7v2 also supports this exception. Apologies for any confusion I caused…