Thomas,
value xsi:type=DV_DATE_TIME
value2011-03-18/value
/value
this is illegal in ISO 8601 (and therefore openEHR)
[HKF: ] This is actually legal in openEHR as it is also in HL7 V2 (well the
non-extended 20110318 is legal), it is a documented variation of ISO-8601.
and
value
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
Leonardo Moretti wrote:
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
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
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
I think it is because of parsing collisions. I don't really see
another point to obligate the hours in a date_time
2011/3/18 Ian McNicoll Ian.McNicoll at oceaninformatics.com:
Thanks Peter / Thomas,
This is quite important and I had not appreciated the limitations on the use
of partial dates
On 18/03/2011 12:04, Ian McNicoll wrote:
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
7 matches
Mail list logo
