Thanks Peter / Thomas,
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 at 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
On 18 March 2011 11:48, Thomas Beale <thomas.beale at
oceaninformatics.com>wrote:
> On 18/03/2011 11:10, Moretti Leonardo wrote:
>
> 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
> <value xsi:type="DV_DATE_TIME">
> <value>2011-03-18T11:01:28</value>
> </value>
>
> but also
>
> <value xsi:type="DV_DATE_TIME">
> <value>2011-03-18</value>
> </value>
>
>
> this is illegal in ISO 8601 (and therefore openEHR)
>
>
>
> and
>
> <value xsi:type="DV_DATE_TIME">
> <value>11:01:28</value>
> </value>
>
>
> 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)?
>
>
>
> you can technically do the following:
>
>
> ELEMENT[at0061] occurrences matches {0..1} matches { -- Date/Time element
>
> value matches {
> DV_DATE_TIME matches {*}
> DV_DATE matches {*}
> DV_TIME matches {*}
> }
> }
>
>
> but I would suggest that allowing DV_TIME only would be very unusual if not
> an error.
>
> - thomas beale*
>
>
> *
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110318/0a324b8f/attachment.html>
