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 <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 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 <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 > > > > _______________________________________________ > 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: <http://lists.openehr.org/pipermail/openehr-clinical_lists.openehr.org/attachments/20130715/6e27be81/attachment.html>
