On 15/12/2010 11:40, Hugh Leslie wrote:
> Hi Koray
>
> One way that we are handling this kind of issue is with a separate 
> exclusion archetype.  So for adverse reactions for instance, if you 
> want to say that this person has no known allergies, you use a 
> separate archetype called an exclusion archetype.  For data, this has 
> the advantage of enabling an easy query for "no allergies" rather than 
> pulling up an adverse reaction instance and having to look inside it 
> for "no allergies".   This works for many different types of content 
> and means that you don't have to hack archetypes to try to add the 
> negative.  So in your use case, you could have a specific "No polyps" 
> exclusion archetype which models the location.
>
> This is a common clinical pattern and problem.
>
> regards Hugh*
> *

I think the problem here is that the need for expressing exclusion is at 
a fine grain level, i.e. it is not an exclusion of a whole-of-patient 
condition or sign or symptom, but a sign (I guess that's what polyps etc 
are) or its absence within a physical examination that looks at all 
sorts of things. I would have guessed (I know this is naive - Koray has 
spent years on these models and it is some time since I saw them!) that 
'absence', 'indeterminate' etc would be possible values among other sets 
of values indicating presence.

E.g. following your scheme Koray, I would expect to see another ELEMENT:

CLUSTER occurrences {0..*} [Tumour] (note that this whole sub-tree can 
repeat as a whole for defining same finding with a different set of 
qualifiers)

    *ELEMENT {0..1} [Presence] --- DV_ORDINAL : present, absent, ...
    other values?*
    ELEMENT {0..1} [Type] --- values
    ELEMENT {0..1} [Stage]  --- value
    ELEMENT {0..1} [Extent]  --- values
    ELEMENT {0..*} [Sites] --- values (note that this can be multiple
    with occurrences set to 0..*)


This means that any feature can be recorded as absent within the same 
structure as the existing data. I imagine you must have thought about 
this and have a reason for not doing it.... but I don't know what it is 
at this stage...

- thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20101215/837af331/attachment.html>

Reply via email to