VCOV rule is in the openEHR archetype profile, page 17. /Daniel -----Original Message----- From: Ian McNicoll <[email protected]> Reply-to: For openEHR clinical discussions <openehr-clinical at openehr.org> To: For openEHR clinical discussions <openehr-clinical at openehr.org> Subject: Re: Multiple values in C_DV_ORDINAL constraints Date: Mon, 26 Sep 2011 19:22:39 +0200
I still cannot find the reference to the VCOV rule in the specifications - can someone point this out? I agree that we seem to be mixing up 2 somewhat different ideas here. One is the 'true' ordinal, where there is a set of ordered terms to each of which some sort of ordered but otherwise arbitrary integer value is assigned. If all we are doing is asserting the correct order of the terms then it is questionable whether anything other than the index position in the list is necessary e.g 0..n. However there are many examples of ordered lists in clinical use which have at least some sort of score attached to each list member. As Daniel has pointed out, it is somewhat dubious if these really qualify as ordinals and I agree with Tom's idea that these are really term->value mappings. I would vote for taking the simple option of removing the 'uniqueness' requirement. I doubt very much if this would cause any downstream problems with decision support, in that if unique constraints are required, these will be fully defined by the archetyping itself e.g a GCS or Apgar score. Ian 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 openEHR Clinical Knowledge Editor www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care www.phcsg.org On 23 September 2011 15:00, Thomas Beale <thomas.beale at oceaninformatics.com> wrote: > 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. > > 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 > > > _______________________________________________ > openEHR-clinical mailing list > openEHR-clinical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical > _______________________________________________ openEHR-clinical mailing list openEHR-clinical at openehr.org http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
