On 23/09/2011 13:35, Daniel Karlsson wrote:
> Hi Everyone,
>
> a problem with Ian's score is that it's not an ordinal scale, but a
> partial order. E.g. for the skin type variable, "healthy" is ordered
> in relation to the other elements, but "tissue paper"* is not ordered
> in relation to "dry" or "oedematous". In the openEHR Archtype Profile
> the VCOV rule disallows DV_ORDINALS with identical values in the
> C_DV_ORDINAL list, thereby only allowing total orders. This could be
> changed though!
I wonder about this. I would understand an 'ordinal list' as a set of
symbols each given a unique numeric value (preferably an integer, but
the Braden or whatever scale broke that).
A list of symbols in which some distinct symbols have the same ordinal
value is not in my view a proper list, it is a 'map', indicating for
each symbol from a source value set which target value it maps to, in a
proper ordinal list.
So the target list is notionally defined as something like (doing it
properly presumably needs Waterlow's input!)
* 0 - at00yy - '0' type skin risk for ulcer formation
* 1 - at00yy - '1' type skin risk for ulcer formation
* 2 - at00yy - '2' type skin risk for ulcer formation
* 3 - at00yy - '3' type skin risk for ulcer formation
the 3 values 'tissue paper', 'dry' and 'oedematous' map to the '1'
ordinal above. The meaning of the '1' ordinal is something to do with
the same kind of severity of ulcer formation due to certain types of
skin condition. So according to this scale, 'tissue paper', 'dry' and
'oedematous' are equally mild risk factors for ulcers, while
'discoloured grade 1' is a worse risk.
For practical archetype modelling, the above approach is probably going
to be to heavy, because it means formalising the 'map' notion somehow.
E.g. it would mean creating a value set:
* at00xx - healthy
* at00xx - tissue paper
* at00xx - dry
* at00xx - oedematous
* at00xx - clammy, pyrexia
* at00xx - discoloured grade 1
* at00xx - broken/spots grade 2-4
and an ordinal list like the one above, but with proper definitions for
each value.
Then we would need away of associating more than one input value from
the value set to each ordinal value, i..e defining the map. This could
be done by defining the map in the ontology section:
maps = <
[id_zz] = <
[at00xx] -> [at00yy]
[at00xx] -> [at00yy]
etc
>
>
Then in the main structure we would need:
* attr1: a DV_CODED_TEXT attribute whose value was taken from the
value set above, i.e. the actual 'dry', 'oedematous', value from
inspection
* attr2: a DV_ORDINAL attribute whose value was defined by the proper
ordinal list above, in a functional relationship to the other
attribute, defined by a rule, e.g.
o attr2.value = list.item (maps[id_zz].item (attr1.value))
This is pretty heavy-going! I think we would only do this if we wanted
to make archetypes really do this job properly, and it was going to be
used a fair bit.
We can do as Daniel says, and just get rid of the uniqueness
requirement, and make life easy. But we might create downstream
computational problems for any software / DSS that doesn't expect to
find more than one meaning with the same ordinal value...
>
> Don't know how this scoring system is used, but "oedematous" and "dry"
> can not reasonably be seen as terminological synonyms!
exactly - see above.
- thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.openehr.org/mailman/private/openehr-clinical_lists.openehr.org/attachments/20110923/f7e6da24/attachment.html>
