DV_DATE_TIME and DV_DATE are data types which are often required to be used interchangeably. Currently, if I’ve understood correctly, they are siblings sharing a common parent, but they can’t be constrained into each other like for example DV_TEXT can be constrained to DV_CODED_TEXT.
Finding out this limitation was a surprise to several modellers I talked to about the problem, as it was assumed that one could for example constrain a DV_DATE_TIME to a DV_DATE in a template. There are several use cases, such as onsets of symptoms or problems, where you need to be able to use either a date/time or just a date, depending on the context.
Could these data types be made more flexible for modelling?
There are discussions about a missing DV_PLAIN_TEXT that would allow the similar modeling to DV_TEMPORAL types. Then you wouldn’t use DV_TEXT but only one of DV_PLAIN_TEXT or DV_CODED_TEXT (removing the interchangeably). That would make them less “flexible” like the dates.
I guess it is a question of flexibility vs. exactness.
Longer answer: not without causing a cascading set of (very expensive) changes to existing software based on openEHR. Which is the reason for the rude ‘no’ above
Leaving indirect financial consequences aside, we’re also possibly looking at a quite subjective view of how RM should represent reality in this specific case, a.k.a. a can of worms.
With my software person hat on, I’d say it’s better that the modellers live with the inconvenience of extra work in exchange for semantic accuracy, so RM should stay as it is in this case, and gleefully open that can of worms I was talking about above (sneaks away as others start typing furiously…)
Well you can constrain a DV_DATE_TIME value to only be a date value, since it will be a ‘partial date time’ in ISO 8601 speak.
The structure of the RM cannot be changed in respect of this however; DV_DATE_TIME is not a special kind of DV_DATE (in deed, if you wanted to do this, you would need to make DV_DATE_TIME inherit from both DV_DATE and DV_TIME, and I have seen libraries that try to do this; it doesn’t work and causes a lot of problems).
The main thing to consider in modelling is whether the value you are working on could ever have a time in it or not; if so, then the type should be a DV_DATE_TIME, even if in other circumstances the value might just be a pure date with no time supplied - e.g. because different institutions only collect dates for certain fields while others collect date/times.
Actually we did this deliberately, but it is a bit of an anti-pattern, and it wasn’t the modelling I would have personally used (indeed old versions of pre-openEHR models had DV_TEXT / DV_PLAIN_TEXT / DV_CODED_TEXT).
ANyway, the thread on this topic points to some solutions.
It has to be remembered that an archetype-based architecture relies heavily on the quality of the Reference Model. I think we did pretty well, but of course, no-one can make something 100% correctly. So we live with a few annoyances - at least until openEHRv2 (i.e. when we can have some breaking changes).
Well it kind of implies that values could be things like 2020-04-01T, i.e. with a trailing ‘T’ but no time part after that. I would guess that is not legal ISO8601, but we are just purchasing the latest version of the standard from Evil Standards Org Inc (aka ISO) as we speak, so we’ll find that out quickly enough.
I’ll have to go and check, but I think our specs assume that a ‘partial date/time’ does have to have at least hours in it, i.e. 2020-04-01T17 or similar. We could relax that in the specs easily enough, once we know what the rule is for ‘T’, but then it’s really a case of fixing various tools.
@JillRiley if you could let us know when we get the ISO spec that would be a great help. We can then create appropriate PR/CRs to sort this out and let the tooling people know what to do (probably just copy LinkEHR
Hi Thomas – Following the okay to go ahead, I’ve looked at setting up an account to make purchase but ISO are currently experiencing IT infrastructure outage, which is impacting applications and websites.
Would you mind if I left this with you (much to sort before next week)?
There is a difference between the class hierarchy and the value that you can set for date/datetime types.
The class hierarchy is as you say: a DV_DATE_TIME can’t be a DV_DATE and viceversa.
Then the value a DV_DATE_TIME can hold, could be:
YYYY-MM-DDTHH:MM:SS.SSSSSSZ
YYYY-MM-DDTHH:MM
YYYY-MM-DDTHH
YYYY-MM-DD
YYYY
And everything in between, so technically the DV_DATE_TIME can hold a date value, which is NOT related with the types, is related with the precision of the datetime, a date is a lower precision datetime.
The possible values come from ISO8601.
Then if you consider the DV_DATE, the biggest precision you can have is YYYY-MM-DD, and the lowest is YYYY.
(i.e. when we can have some breaking changes).
