Add "last modified" date/time attribute for ENTRY classes in RM

We are now routinely adding 'Date last updated' to the majority of Evaluation archetypes, as this is a common requirement.

Will it work like this then?

At t1: Dr. Naess find that the patient is a light smoker. He commits a Composition with uid = CID1 containing an EVALUATION archetype with a value "ligth smoker"
At t2: Dr. Beal confirms that the patient is a light smoker by committing a Composition with uid = CID2 containing an ENTRY with a ASSERTION_STATUS that links to the original EVALUATION by Dr. Naess

This kind of use-case I would have modelled with a persistent composition. Then for each new confirmation or attestation there will be a new version. The new version will be packaged in a contribution with audit_details. Given that the version is just to confirm the information already present in the composition we would use the audit_change_type 666 - attestation.

By doing it this way we will have a history of the developement of the smoking habits of the patient. There will at a given point in time only be one valid edition/issue of the patients smoking habits.

Does this sound right or weird?

I was originally thinking that it sounded like versioning as well. But we need to keep in mind a basic philosophical distinction between 'system time' and 'world time' (i.e. 'clinical time'). The time attribute in AUDIT_DETAILS represents the time of changes to the system (i.e. to the data).

Time attributes in ACTION and OBSERVATION record real world times; this makes sense since they record things that happened in the past.

As you say, INSTRUCTION and EVALUATION don't really have a time other than the time of the Composition.context.

What I believe Koray and others are asking for is a time and status that indicates that a clinician has asserted (checked) some clinical datum, like 'is the patient still smoking'. So the time here is a real world time. E.g. 'Dr Jensen confirms that Maria Jameson is a light smoker on 14/jan/2015'. At the moment the way to do this seems to be to create a new ENTRY that contains the same data as some previous ENTRY, at some later point in time, e.g. every year the question gets asked. I am not sure that this is a problem actually.

We could potentially add the 'assertion_status' to ENTRY as above, and a special 'assertion' archetype used with it. It would also need to have a link to some previous ENTRY that contained the original data. I.e. the model would be:

class ENTRY
...
assertion_status: ASSERTION_STATUS
...
end

class ASSERTION_STATUS
status: CODE_PHRASE [1]
date_time: ISO8601_DATE_TIME [1]
comment: String [0..1]
original_statement: LINK [0..1]
end

With respect to 'COMPOSITION-centric' nature of the RM, it is COMPOSITION-centric for data committal. What we have talked about for querying is a kind of query result that wraps an ENTRY with its flattened COMPOSITION context elements, i.e. something like:

class ENTRY_RESULT
item: ENTRY – the main statement
context_start_time: DV_DATE_TIME
context_end_time: DV_DATE_TIME
context_xxxx: etc
version_audit_time: DV_DATE_TIME
version_audit_xxxx etc
end

The thing you have designed in DIPS should probably look something like this, and it is something we should standardise.

I am not sure if I like this idea.
This smells like some kind of versioning and versioning should be done by the existing mechanism for versioning.

For ACTION and OBSERVATION there is specific time attributes which tells where the entry is located in timline. And of course the Composition.context.start_time tells when the clinical session was and the VERSIONED_OBJECT tells when the entry was commited into the EHR.

INSTRUCTION and EVALUATION have no timing information. They are weak passengers of the Composition. When querying you need to sort or order by Composition.context.start_time to know where the entry belongs in the timeline.

We have implemented functionality let the user know who created and when a ENTRY or data_value was added. This is useful for the end-user to tell if the ENTRY has relevance and to do some quality assessments on the entry. The user may then navigate (open) the containing Composition to read the entry in its proper context. We think this is the best way to handle this situations. You must always see the context that the entry was created in to tell something about the clinical meaning behind.

I think this change is triggered by the thinking that openEHR should not be so bound to the Composition. Put another way: Do we need another container (than Composition) for transactions into a EHR?

I am not sure. But I think we can mange with Compositions for now.

Hi Koray, I specifically want to avoid a clinical name, since the openEHR EHR is non-clinical, except arguably the 'setting' attribute in EVENT_CONTEXT. The name doesn't matter in the RM in terms of how it appears to clinical modellers.

If we want more data, it could be done as follows:

class ENTRY
...
assertion_status: ASSERTION_STATUS
...
end

class ASSERTION_STATUS
status: CODE_PHRASE
date_time: ISO8601_DATE_TIME
comment: String
end