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>