I think I rather prefer the change already made 6 months ago - it looks simpler (although not simple), or in the future v2 that Interval solution.

Can we conclude on this ticket so that be can give (or not) acceptance?

I’m having a new look at the solution that is currently in review, which is that proposed by , but doesn’t like. Maybe a better variant is to add a dedicated new field meaning ‘exact date unknown’, and make the rule that the time field is just set to today’s date when the data were imported or reported. The documentation of that new field will say that if it is set, the time field means ‘when reported’.

Not knowing the exact date of some previous procedure is probably common enough, e.g. adults wouldn’t generally remember exactly when a childhood tonsilectomy was done. So we have to solve this reality anyway, regardless of any import question.

The alternative is to do the same thing, but allow the time field to be null when that new field is True. The danger of this is that it allows bad data to be routinely created.

From a technical perspective I do agree with the solution, and although I can imagine this might complicate querying, I am curious to hear what tooling or use-case is concerning about, and if we can (also) do something about that it.

Pablo’s solution does represent the reality though - some action A occurred in the past, and all we know is that it happened before timepoint T (which might be ‘now’).

Having no date-time at all creates data that is unreliable. Imagine that some such Action is committed on 01-08-2019, relating to a previous procedure (hip replacement or whatever). If there is no date at all on that Action, a query that is run on 01-01-2031 doesn’t even know to discount the decade 2020-2030 (I’m just choosing the dates to make it easier to understand). The only way it can work out the latest date the Action might have been performed is to interrogate the commit_time from the audit - highly unsatisfactory.

I get that it might be annoying in tools. But Actions with no time associated with them are really bad data, and they are going to cause issues if we have to allow them into the EHR.

The only better solution - which is an openEHRv2 change - is for ACTION.time to be a Interval<Iso9601date_time>, meaning it would allow intervals like |<01-08-2019|.

I’ll be honest (for once!), although Pablo’s suggestion is technically correct, it is going to be really difficult to explain and use in both tooling and querying. It is also synthesising a date which never existed, so I’m afraid I can't support the idea of using magnitude_status - just too complex and counter-intuitive.