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 2) 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. Cheers, -koray From: openEHR-clinical [mailto:[email protected]] On Behalf Of Gerard Freriks Sent: Monday, 15 July 2013 8:00 p.m. To: For openEHR clinical discussions Cc: For openEHR technical discussions Subject: Re: Recording absence of (clinical) information 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<mailto:gfrer at luna.nl> On 15 jul. 2013, at 09:41, Thomas Beale <thomas.beale at oceaninformatics.com<mailto:thomas.beale at oceaninformatics.com>> 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 __________ Information from ESET NOD32 Antivirus, version of virus signature database 8567 (20130714) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20130715/e1b4c4d1/attachment-0001.html>
