Currently in concrete entry types, only Observation has a fixed attribute to record when an entry is made. We need similar attributes in Evaluation and other entry classes in the context of CDS.
Normally the timestamp of the Composition where the entries are included will be used, but when building CDS rules (using GDL) one does not want to go to the Composition level in order to figure out what is the latest evaluation or observation of a given archetype.
Using an archetype-specific element isn't a good solution because then this element will need to be added to all archetypes and the paths point to this element will be all different from archetype to archetype. It really is a generic requirement that should be dealt with on a RM level.
I would like to add some support for Heath and Rong in this. Outside of CDS use there are two clear areas in primary data recording to be able to capture the composition type 'context' data but at the level of Entry.
1. Where data has been sourced from an external system or is a historical record e.g. it is common for surgical records to ask for the name of the responsible healthcare facility.
2. As others have said, where an Entry ends up being copied into another composition - persistent problem list, discharge letter, referral, meds reconciliation report, it essentially 'loses' its composition event_context, without some kind of querying (as per Bjorn's example). This is problematic, and the main reason why we have been adding 'Date last updated' to recent published Evaluations. The same is probably true of Instructions, though less commonly.
One option would be to add some sort of 'evaluation_date' attribute at ENTRY level, which would be deliberately vague in an effective_time sort of way! As Rong says , this does actually reflect real world usage in many other systems.
However I think I prefer Thomas's argument that composition/context/start_time captures this effectively, and my suggestion would be to look at the possibility of making EVENT_CONTEXT potentially optionally available at ENTRY level as a concrete structure, along with a function that pulls that data from composition level where the ENTRY level event_context is empty. i.e Composition context is assumed as the default for an ENTRY but can be overriden at ENTRY level.
Just to compare, ISO13606 has an optional obs_time attribute at CLUSTER level to store a different time than the general document (which makes sense in 13606 as aggregation is one of the use cases). However this attribute has been removed in latest renewal proposals for simplification (it is assumed that this attribute has to be included in the archetypes if it is really needed).
Maybe this second approach is enough for Rong use case?.
I had forgotten about the case of the real world meaning of 'last updated time', which Heath notes, and is probably what Rong originally meant. I had been thinking system time, not real world time.
So do we agree that the 'last updated time' we are talking about covers 'latest clinical update to a diagnosis or other assessment'? Is it meant also to cover the case of exclusions or other changes in health status, e.g .smoking etc?
I think it would help if you can supply a definition of exactly what 'last updated time' means in the context of CDS.
1. previous surgery / procedures - I think that the original facility in which the procedure was done, and other details would be in the archetype for 'previous procedure'. Of course FEEDER_AUDIT will capture the system the information came from, if it was imported, but I would think that in most cases we are talking about patient-elicited information such as 'I had I hip replacement at Leeds infirmary in 1985'.
2. I think we need to be very careful on the requirements of 'copying' Entries anywhere. I've done some requirements work and modelling based on a workshop some of us did last year, which I will try and publish on openEHR.org. I think this could be a useful basis for properly modelling many of these cases. The work is based on the original discussion raised by Bjorn about 'reports'.
Re: "One option would be to add some sort of 'evaluation_date' attribute at ENTRY level, which would be deliberately vague in an effective_time sort of way!" - I don't think we want to be adding 'vague things to the model. This has proven to be a huge problem in HL7 and somewhat in 13606 (and for us, in a few cases). I have no problem if we can convince ourselves that something new is needed (I think it probably is), but I don't want to simply avoid doing the proper modelling work and analysing the issues properly, so that we end up not being able to document model changes properly.
At the moment, I am convinced that there are multiple issues, and that it is unlikely that only one fix will solve them. My current list based on the above is:
a) inconvenience in querying the owning COMPOSITION of an EVALUATION, in order to get at context.start_time
b) lack of an RM attribute to put a 'last updated' date/time for Evaluations, meaning the clinical time last updated
c) inconvenience at obtaining a time that means roughly 'last updated time' or 'effective time' for any ENTRY
d) lack of an attribute in (some/all?) EVALUATIONs that means 'when this assessment was made'
e) a way of representing HCF and other meta-data for 'past procedures'
f) (need for CDS to depend only on ENTRY level archetypes - I'm still unclear about this, but Rong seems certain on it.
g) the problem of synthesising context.start_time from feeder systems / EMRs?
I am not clear enough on the problem description - is it just what I have in g) above?
BTW - I had forgotten this WIKI page with openEHR RM times and tracking clinical process:
Maybe it is useful to update this - if needed?