This is to do with my long standing issue about recording absence of info. In endoscopy models the “Presence” of endoscopic findings was represented as a CLUSTER where a special ELEMENT (that is internally referenced many times for each finding thereafter) captured ”Presence” of a finding and also if/why information about a particular finding was not available. This I thought was a quick and dirty fix to a larger problem which I reckon applies to all data structures and types including ENTRY Class itself.
I came across this in NEHTA medication archetypes:
COMPOSITION.Medication_List has “Absent Info slot filled by openEHR-EHR-EVALUATION.absence.v1 (and specialisations) that has only one ELEMENT which captures absence (free or coded text)
Description says: Positive statement that no information is available about medication use.
While this approach solves the current problem in the long term and in order to enable a global scale interoperability it seems to be another quick & dirty fix. To me this is a crystal clear pattern for clinical information (and potentially administrative too) - shouldn’t this be handled in RM?
Sorry if this has already been dealt with – I haven’t been able to read all discussions for a while.
Cheers,
-koray
Koray Atalag, MD, PhD, FACHI
Senior Research Fellow
School of Population Health, The University of Auckland
Hi koray,
how do you want to do this? We decided against absence / exclusion in th RM a long time ago,
because it is not a simple negation in general, but a complex (i.e. archetyped) statement.
-thomas
This is to do with my long standing issue about recording absence of info. In endoscopy
models the "Presence" of endoscopic findings was represented as a CLUSTER where a special
ELEMENT (that is internally referenced many times for each finding thereafter) captured
"Presence" of a finding and also if/why information about a particular finding was not available.
This I thought was a quick and dirty fix to a larger problem which I reckon applies to all data
structures and types including ENTRY Class itself.
I came across this in NEHTA medication archetypes:
COMPOSITION.Medication_List has "Absent Info slot filled by openEHR-EHR-
EVALUATION.absence.v1 (and specialisations) that has only one ELEMENT which captures
absence (free or coded text)
Description says: Positive statement that no information is available about medication use.
While this approach solves the current problem in the long term and in order to enable a global
scale interoperability it seems to be another quick & dirty fix. To me this is a crystal clear pattern
for clinical information (and potentially administrative too) - shouldn't this be handled in RM?
Sorry if this has already been dealt with - I haven't been able to read all discussions for a while.
Any thing can be negated (or better it is declared that something is absent.
Since each ENTRY archetype is a named process that is: ordered, executed, assessed or summarised after termination, we can describe:
that there is no order, no execution, no assessment or perception of the summary after termination of a specific named Action, Protocol, Clinical Pathway.
in addition it is possible that as the result of a query specific data is not found. (e.g. No recording of any Blood Glucose, no recording of Blood Glucose: > 12 mMol/L)
This Presence/Absence indicator is NOT a boolean data type but a fixed text: Present/Absent
In addition, after long debates, it had been decided in the CEN/ISO Task Groups that in the RM we have one flag that indicates that something is ‘fishy’.
It is the ‘Attention’ attribute in the ENTRY class.
I recognise the issue but it is not simple to reconcile three differing requirements
To ensure that negative/absence statements are not inadvertantly picked up by default querying. e.g if we simply put a present/absent on ‘diagnosis’ we either have to explicitly set ‘present’ on every data entry. The SNOMED approach IMO is risky since it has an implicit default ‘present’ via its context mechanism. This is perfectly sensible in s omr reespect but does mean that the queries have to be very carefully constructed to ignore negated entries, and even then ‘absence of information’ is something quite different from ‘absent’. The reason for the current approach of having specific Absenc of Information and Exclusion archetypes is to make these quite clearly separate entities from a querying perspective.
However, and I think this is your perspective, from a clinical visualisation / implementation/review perspective this is an artificial separation. Negation and absence statements do feel as if they are statements about ‘diagnosis’ or ‘adverse reaction’ and belong visually and hierarchially in the same place with a yes/no/no information radiobutton being a perfectly good visualisation. The use of exclusion and absence archetypes seriously complicates things esp when building a simple questionnaire. I do think that it is the ‘right’ thing to do but agree it feels clumsy, especially for simple yes/no use cases. We have the same problem when conduction archetype reviews where inevitably we are asked why the archetype does not include ‘absence’ and exclusion statements.
As Thomas says, other information associated with the key diagnosis present / absent’ statement is different. The contents of a positive diagnosis archetype and an exclusion are completely different.
So while I think it would be enormously helpful to try to bring positive,exclusion and absence statements inside the same archetype for visualization/review purposes, the simple use of a boolean flag or present /absent status code is risky from a querying perspective IMO, and does not give the flexibility of data structures that Thomas alluded to.
I have started to wonder if we might get the best of both worlds by thinking in terms of a top-level ‘negations’ attribute in the ENTRY class, similar to protocol, below which archetyped content could be added to capture negated and absence data.
This would allow quite different data structures to be carried for exclusions/ absences (perhaps with a simple default), which would be on a completely different path from a querying perspective, with no chance of a positive statement being inadvertently being mixed up with a negation. It would carry the significant advantage of having everything ‘under the same roof’ for viewing/development/reviewing purposes and is also somewhat self-documenting.
Hi Tom, has anyone come across an example where "Unavailability of certain information" requires more than a single TEXT item to represent? I'm not talking about positive statements about exclusion of certain information - just "Unknown" cases.
I agree that a simple Boolean data type is not suitable – that’s why we used a TEXT item (called Presence) with Present, Absent, Unknown values. The reasons why information is not known can further be specified (I reckon with great diversity) if required which we chose not to implement. We have a tri-state checkbox that corresponds to the three values of the Presence item and on GUI when first initialised the checkbox is clear (e.g. does not have any of the three states). User can select any of the three values and it is also possible to ‘clear’ the control – which means that item has never been captured. I think (just my opinion) this is a pattern which can be applied to a wider range of clinical findings. I won’t dare to say it would apply to all ENTRY types but probably a majority of OBSERVATION and perhaps EVALUATION type data items.
To further elaborate on Ian’s comment which just came as I am typing this I think there are two things here:
(1) generic that can better be represented consistently at RM level;
(2) that can be quite specific as per clinical context and requirements.
Along the lines of Ian’s proposal I think the current method of representing negation/exclusion and absence/why information is not available with two different archetypes might be transformed into a pattern like:
RM Attribute to denote/flag/draw attention at ENTRY class level of CODED_TEXT type which has the three enumerations as I described above. I don’t think a fourth one indicating “Null” will be required as this would be implicit by its appearance in instance data. Obviously this is related to both Negation/Exclusion and Absence – but this is the point
When above attribute has been set with Negation/Exclusion or Absent then an Archetype further describing this can be slotted. There will never be a case where both will appear in instance data.
I reckon the differences in archetype design might further complicate matters and limit above proposal.
don't know if this helps, but in a project a few years ago when we
represented "questionnaire" style Y/N/Unknown-scale values we could not
use any existing openEHR archtype but instead we chose to make a new
(simplistic) "review of condition" evaluation archetype. In this use
case the information collected was not the primary source but
aggregation/assessment/evaluation/etc. of possibly several parts of the
record. We used the SNOMED CT context model (and default context) for
binding the allowed values, e.g. Y="Fever", N = "Clinical finding absent
& associated finding=Fever". Being a separate archetype and distinct in
meaning, it could not be confused with a corresponding problem or
diagnosis archetype. As the archetype represented a crude, context-less
assessment of the condition, reusability of information (i.e. instances)
was probably limited.
Totally agree with all your points Ian, including your proposal. But that is some way in the future.
I’ve done quite a bit of work on exclusions for use in Northern Territory recently – updating the openEHR exclusion suite considerably based on implementation experience. There is an admin issue and I haven’t been able to upload them to the NEHTA CKM yet.
And in addition I have developed an archetype for absence and this is being used in the Northern Territory. My first opinion had originally been that there was no need to make explicit statements about absence. In a closed system the application can query for any positive statements of presence (ie Adverse Reaction, Problem etc) and positive statements of exclusions (exclusion Adverse Reaction, exclusion Problem etc) and if neither existed then it could be inferred that there was an absence of information ie no information available about adverse reactions or problems – presence or exclusion. However as soon as a shared environment occurred, especially involving messaging, then it became apparent that an explicit statement of absence of information became useful. You can view the EVALUATION.absent_information archetype on the NEHTA CKM.
