The current definition of the date/time data types include 7 classes,
providing the following functionality:
partial forms of the first 3 of these
Since openEHR is now aiming to be 100% compatible with ISO8601,
we should merge the partial types into the non-partial types
making 4 classes, corresponding directly to the 4 types of
ISO8601 and their functionality. This will also simplify
implementation, since the representation of the openEHR date/time
classes is already an ISO8601 string; and also because implementers
will use external libraries such as joda that implement ISO8601 in
a fairly faithful way.
A related issue is that all ISO8601 date/time types are in teh Gregorian
calendar, and there may be a need to accommodate date/times from other
calendars somewhere in the health record, e.g. where Islamic date/times
are mentioned with respect to festivals, eating etc.