time asserted already implemented in EVALUATION RM

[tarabonet (Tara Bonet Chinillach)]

Hi all,

We have noticed that when persisting archetypes of type EVALUATION, there is an option to persist an attribute called ‘time asserted’.

We know that some time ago there was a request to include this attribute as part of all evaluations. However, in the current specifications we cannot find any explicit reference to ‘time asserted’ as a mandatory or defined attribute within EVALUATION.

Should this attribute be formally included in the openEHR specifications?
Or is its use currently implementation-specific?

Thanks in advance for your clarification.

[pablo (Pablo Pazos)]

@tarabonet

when persisting archetypes of type EVALUATION, there is an option to persist an attribute called ‘time asserted’.

where is that persistence? I’m not sure what tools are you using.

[damoca (David Moner)]

I think Tara is talking about this conversation. The last message suggest that this was already accepted in the SEC in October 2024:

RM Change request: Add time_asserted to EVALUATION class?

During today’s SEC meeting, I asked for this issue to be picked up in its most simple form for the sake of time. So we decided to only add the “time_asserted” field to EVALUATION for now. If people need this field in other places as well, it would be great to create a new issue for those. Adding it to other classes (or to Entry) later, would probably not be technically complicated.

[sebastian.iancu]

It was indeed discussed in the past and decided to be added to EVALUATION - see Jira.
This is not yet formally released (in the specification RM 1.2.0), but it could be that is already implemented on the vendor side.

[pablo (Pablo Pazos)]

@tarabonet

We have noticed that when persisting archetypes of type EVALUATION, there is an option to persist an attribute called ‘time asserted’.

@damoca this is saying she is actually persisting something, just need the connect to understand what she’s doing. I know about the conversation and the proposal to add the new attribute. It’s just not clear if she is taking about that proposal or is talking about an actual told that implemented the proposal already.

Tal vez es un tema del idioma

[tarabonet (Tara Bonet Chinillach)]

Hello, this is exactly what I mean. We are using EHRBase and have seen that this attribute can already be persisted in this type of archetypes. However, when we checked the OpenEHR specifications, we couldn’t find any information about it.

[pablo (Pablo Pazos)]

It could happen that an implementer goes ahead the updates of the spec.

IIRC that change was agreed by the SEC, @sebastian.iancu might now better, though we need to wait for a spec release to have it written in stone.

There is nothing wrong with the software going ahead of the spec, though if something changes in the final release of the spec, implementers might need to change the software too to keep compliance (I’m talking in general not in this specific case).

[ian.mcnicoll]

@tarabonet taraboneti suspect you are just seeing that some evaluation archetypes have a date last updated or data asserted element but the are added to the archetypes individually not part of the underlying RM.

However we recognised that it would be better if date asserted was added to the RM EVALUATION class and then available to every Evaluation so that we do not need to add a new element for every new archetype.

I’d be surprised if ehrbase has added the new RM attribute to their implementation but I’ll check.