Recording absence of (clinical) information

[Heather Leslie]

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
<http://dcm.nehta.org.au/ckm/#showArchetype_1013.1.1234_3>  on the NEHTA
CKM.

 

Regards

 

Heather

 

 

 

From: openEHR-technical [mailto:openehr-technical-boun...@lists.openehr.org]
On Behalf Of Ian McNicoll
Sent: Monday, 15 July 2013 6:36 PM
To: For openEHR clinical discussions
Cc: For openEHR technical discussions
Subject: Re: Recording absence of (clinical) information

 

Hi Koray,

 

I recognise the issue but it is not simple to reconcile three differing
requirements

 

1. 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.

 

2. 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.

 

4. 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.

 

Thoughts?

 

Ian

 

 

 

 

On 15 July 2013 08:59, Gerard Freriks mailto:gfrer at 
luna.nl>
> wrote:

Dear Koray,

 

According to SIAMM:

 

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 executio

Recording absence of (clinical) information

[Thomas Beale]

> Hi everyone,
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.
> 
> Cheers,
> 
> -koray
> 
> Koray Atalag, MD, PhD, FACHI
> 
> Senior Research Fellow
> 
> Description: Description: Description: cid:image001.png at 01CD2460.A69C1680
> 
> School of Population Health, The University of Auckland
> 
> Private Bag 92019 Auckland 1142, New Zealand
> 
> Email: k.atalag at nihi.auckland.ac.nz nihi.auckland.ac.nz> | Web: 
www.nihi.auckland.ac.nz
> 
> Skype: atalagk  Mob: 021 02412096  DDI: +64 9 923 7199



-- 
Thomas Beale
Chief Technology Officer Ocean Informatics

Recording absence of (clinical) information

[Thomas Beale]

> Hi everyone,
> 
> 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
> 
> Description: Description: Description: cid:image001.png at 01CD2460.A69C1680
> 
> School of Population Health, The University of Auckland
> 
> Private Bag 92019 Auckland 1142, New Zealand
> 
> Email: k.atalag at nihi.auckland.ac.nz nihi.auckland.ac.nz> | Web: 
www.nihi.auckland.ac.nz
> 
> Skype: atalagk  Mob: 021 02412096  DDI: +64 9 923 7199



-- 
Thomas Beale
Chief Technology Officer Ocean Informatics

Recording absence of (clinical) information

[Thomas Beale]

> Hi everyone,
> 
> 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
> 
> Description: Description: Description: cid:image001.png at 01CD2460.A69C1680
> 
> School of Population Health, The University of Auckland
> 
> Private Bag 92019 Auckland 1142, New Zealand
> 
> Email: k.atalag at nihi.auckland.ac.nz nihi.auckland.ac.nz> | Web: 
www.nihi.auckland.ac.nz
> 
> Skype: atalagk  Mob: 021 02412096  DDI: +64 9 923 7199



-- 
Thomas Beale
Chief Technology Officer Ocean Informatics

Recording absence of (clinical) information

[Gerard Freriks]

Dear Koray,

According to SIAMM:

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.

Gerard Freriks
+31 620347088
gfrer at luna.nl

On 15 jul. 2013, at 09:41, Thomas Beale  
wrote:

>> Hi everyone,
> 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

-- next part --
An HTML attachment was scrubbed...
URL: 

Recording absence of (clinical) information

[Ian McNicoll]

Hi Koray,

I recognise the issue but it is not simple to reconcile three differing
requirements

1. 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.

2. 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.

4. 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.

Thoughts?

Ian





On 15 July 2013 08:59, Gerard Freriks  wrote:

> Dear Koray,
>
> According to SIAMM:
>
> 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.
>
> Gerard Freriks
> +31 620347088
> gfrer at luna.nl
>
> On 15 jul. 2013, at 09:41, Thomas Beale 
> wrote:
>
> Hi everyone,
>
> 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
>
>
>
> ___
> openEHR-clinical mailing list
> openEHR-clinical at lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-clinical_lists.openehr.org
>



-- 
Dr Ian McNicoll
office +44 (0)1536 414 994
fax +44 (0)1536 516317
mobile +44 (0)775 209 7859
skype ianmcnicoll
ian.mcnicoll at oceaninformatics.com

Clinical Modelling Consultant, Ocean Informatics, UK
Director openEHR Foundation  www.openehr.org/knowledge
Honorary Senior Research Associate, CHIME, UCL
SCIMP Working Group, NHS Scotland
BCS Primary Health Care  www.phcsg.org
-- next part --
An HTML attachment was scrubbed...
URL: 

Recording absence of (clinical) information

[Koray Atalag]

Hi everyone,



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

Description: Description: Description: cid:image001.png at 01CD2460.A69C1680

School of Population Health, The University of Auckland

Private Bag 92019 Auckland 1142, New Zealand

Email: k.atalag at nihi.auckland.ac.nz 
| Web: www.nihi.auckland.ac.nz

Skype: atalagk  Mob: 021 02412096  DDI: +64 9 923 7199



-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 4493 bytes
Desc: image001.jpg
URL: