DV_DATE_TIME and DV_DATE

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?

Yes, they have a common parent DV_TEMPORAL (making them siblings):

This is different to DV_CODED_TEXT which is not a sibling to the DV_TEXT but is its direct descendant (so every DV_CODED_TEXT is also DV_TEXT):

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.

1 Like

Yes, but since DV_TEMPORAL is abstract, we can’t use it for archetype modelling. So that doesn’t help us.

Yes, and DV_TEXT should also be abstract. You are able to use DV_TEXT because of a slip made in modeling it (and not including DV_PLAIN_TEXT).

Not the answer you would like, but we need the exactness when models are validated and get converted into forms,…

Opinionated short answer: No.

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 :slight_smile:

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…)

2 Likes

I suspected as much :joy: :sob:

I guess we’ll start adding both data types as choices then :woman_shrugging:

1 Like

Yep. Also, a puppy gets a treat every time you do that.

2 Likes

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 :wink: (i.e. when we can have some breaking changes).

Well - I would recommend to consider what the true meaning of the fields you are modelling is. If it is:

  • this field can have a time part, even if it is often not supplied by a lot of data sources

then you are talking DV_DATE_TIME.

If it is:

  • this field can never have a time part - e.g. ‘date of birth’

then it can only be DV_DATE.

1 Like

A possible solution could be using the patterns for Date/Time, although it may have some problems.

You can use a DV_DATE_DIME in the archetype, and then constrain it to a specific pattern as described in the documentation:

One problem is that, according to that documentation, they do not consider valid a constraint with just the date and without time, and don’t know why.

A second problem is that the Archetype designer only allows three of those patterns.
image

In LinkEHR Studio we added all possible combinations with a rather simple interface:
image

But in that case, I’m not completely sure that it leads to a valid representation of the data according to the programming language data types:
image

I think I have raised more questions than solutions :sweat_smile:

2 Likes

This is interesting, and possibly what we were originally looking for!

Yeah, that’s weird. Is that list intended to be exhaustive? Would the pattern yyyy-mm-ddTXX:XX:XX be invalid? @thomas.beale ?

This may also be a contributor to our confusion, as we have a tendency to assume tooling is complete.

@borut.fabjan, could something like the LinkEHR interface be implemented in AD?

2 Likes

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 :wink:

2 Likes

That’s what I meant that I was not sure if it would be a valid pattern. But we could think of some workaround for that case.

2 Likes

See email snip below…
From: Jill Riley comms@openehr.org
Sent: 31 January 2022 14:00
To: ‘Thomas Beale’ thomas.beale@openehr.org
Cc: ‘Pablo Pazos’ pablo.pazos@cabolabs.com
Subject: RE: ISO 8601 Standards - please confirm

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)?

2 Likes

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.

2 Likes

Have a look at AD 1.23.18. Added more patterns. :wink:

Screenshot 2022-09-26 at 15.28.20

4 Likes