Recording absence of (clinical) information

Koray Atalag k.atalag at nihi.auckland.ac.nz
Wed Sep 18 00:11:30 EDT 2013


A an optional RM attribute of CODE_PHRASE type with the three enumerations...
Not sure if this would makes sense on OBSERVATION only or apply to other ENTRY subclasses.

Cheers,

-koray

From: openEHR-clinical [mailto:openehr-clinical-bounces at lists.openehr.org] On Behalf Of Thomas Beale
Sent: Tuesday, 17 September 2013 8:15 p.m.
To: openehr-clinical at lists.openehr.org
Subject: Re: Recording absence of (clinical) information

On 15/07/2013 10:17, Koray Atalag wrote:
Hi Gerard, thanks for your response.

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:


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

Hi Koray,

how could there be a single presence / absence / unknown flag on an openEHR ENTRY? An ENTRY can contain numerous data items...

- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20130918/c77b8c02/attachment.html>


More information about the openEHR-clinical mailing list