@Pablo Pazos thank you for exposing my incipient Alzheimers! I would say that is a perfectly good solution. We would need to document it though, so still needs a spec change. And we should say what querying should do as well.

@Ian McNicoll Any reason not to do it like this?

I like it, pretty elegant solution and you can store some approximated date, not just null

Small note, if the imported data doesn’t have the datetime for the ACTION, then it is valid IN THE CURRENT IM to have a date for now() with magnitude_status = '<', which means the date is older than now but uncertain. magnitude_status is inherited by DV_DATE_TIME from DV_QUANTIFIED.

https://specifications.openehr.org/releases/RM/Release-1.1.0/data_types.html#_dv_quantified_class

https://specifications.openehr.org/releases/RM/Release-1.1.0/data_types.html#_overview_4

Note there is also the accuracy field that could be used https://specifications.openehr.org/releases/RM/Release-1.1.0/data_types.html#_accuracy_and_uncertainty

In terms of what we currently support, I don’t see this is a real issue, since it’s perfectly supported without a null datetime in the ACTION.

What do others think?

A query can only return Actions with Instruction State Machine (ISM) states - including aborted or pending (scheduled, I guess?). This is well known, so I can’t see any problem here. Applications dealing with Instruction+Action always need to be designed for the ISM.

I agree we probably don’t really want a new class. So we re stuck with putting in a special ‘null’ attribute for missing times? W could instead add a flag for ‘past_reported’ (think of a better name) or similar, and allow an Action to have either the time attribute, or that past_reported flag set.

Because (in a recent case) most of the imported data did have a date and was a very good fir for Procedure.v1, and then we got the null dates for some items. I don't see Thomas’s example as a major issue, Much much more likely to ask for all procedures than those in the past 5 years (and if/when the nulls appear, these are not likely to be clinically critical and a tweak to the query will fix that. There are times when an integration archetype is needed but this seem a placewhere we may be over-engineering the constraints. As I said before there are likely to be many more safety concerns about accidentally picking up aborted or pending actions, but there is nothing to stop that in the RM. It is equally left to implementers to understand the initicracies of ACTION querying.