# Multiple values in C_DV_ORDINAL constraints **Category:** [Clinical (archive)](https://discourse.openehr.org/c/clinical-archive/153) **Created:** 2011-08-01 15:17 UTC **Views:** 2 **Replies:** 17 **URL:** https://discourse.openehr.org/t/multiple-values-in-c-dv-ordinal-constraints/15083 --- ## Post #1 by @ian.mcnicoll I have come across an interesting example of where we might want to model an ordinal constraint where the values associated with each term are not unique\. The example is the Waterlow Score http://www.judy-waterlow.co.uk/downloads/Waterlow%20Score%20Card-front.pdf If you look at the bottom\-right corner "Major surgery / Trauma" you will se that two terms have identical values\. Currently the openEHR Archetype Editor will not let me add duplicate values with separate terms\. It is not clear \(at least to me\) from the specifications that this behaviour is correct\. Is this a CR for the Archetype Editor, a CR to the Ref Model, or a clever alternative modelling suggestion to me? Regards, 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@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 --- ## Post #2 by @thomas.beale If we consider this an ordinal based model, in which numbers which have multiple possible values, e.g. skin type: 1 is for tissue paper dry, oedematous, etc - this would be modelling using terminological synonyms for a notional term whose meaning was something like 'waterlow skin type 1'. - thomas [details="(attachments)"] ![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg) [/details] --- ## Post #3 by @ian.mcnicoll Hi Thomas, I am not quite sure what you are saying here, though I agree, in essence, the scoring system, like most others, is flattening a variety of patient findings into a single term which also then carries a score. The problem is that whilst the ordinal terms are unique, the related values are not and can have duplicates. So is this a valid ordinal ? ordinal constraint? 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@oceaninformatics.com](mailto:ian.mcnicoll@oceaninformatics.com) Clinical Modelling Consultant, Ocean Informatics, UK openEHR Clinical Knowledge Editor [www.openehr.org/knowledge](http://www.openehr.org/knowledge) Honorary Senior Research Associate, CHIME, UCL BCS Primary Health Care [www.phcsg.org](http://www.phcsg.org) [details="(attachments)"] ![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg) [/details] --- ## Post #4 by @system Hi Ian, I my opinion either the ordinal nor ordinal constraint prohibit ordinal terms with duplicated values in the same ordinal constraint. It's probably the editor that needs to be fixed to cope with this requirement. Cheers, Rong [details="(attachments)"] ![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg) [/details] --- ## Post #5 by @Daniel_Karlsson 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! Don't know how this scoring system is used, but "oedematous" and "dry" can not reasonably be seen as terminological synonyms! Regards, Daniel *what does "tissue paper" really mean in this context, especially in relation to dry?? Fri 2011-09-23 klockan 13:58 +0200 skrev Rong Chen: [details="(attachments)"] ![OceanInformaticsl.JPG|183x82](upload://2lcnRHcC3QqDv6AeaDZuo8M9Qlv.jpeg) [/details] --- ## Post #6 by @thomas.beale > 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 --- ## Post #7 by @ian.mcnicoll 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@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 --- ## Post #8 by @thomas.beale can someone please put an issue on the [SPECPR tracker](http://www.openehr.org/issues/browse/SPECPR)? It should quote this and Daniel's posts. - thomas --- ## Post #9 by @Daniel_Karlsson VCOV rule is in the openEHR archetype profile, page 17\. /Daniel --- ## Post #10 by @system Hi\! Just to clarify, these archetype validity rules are not part of the stable releases\. So you need to go to the latest draft specs to find this VCOV rule, see http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/am/openehr_archetype_profile.pdf. In this particular example, these scores seem to be more like quantities than ordinals\. The numeric value each term maps to is perhaps more important than its actual order in the list since what matters is the total sum of the scores\. Cheers, Rong --- ## Post #11 by @ian.mcnicoll SPECR\-72 posted http://www.openehr.org/issues/browse/SPECPR-72 Dr Ian McNicoll office \+44 \(0\)1536 414 994 fax \+44 \(0\)1536 516317 mobile \+44 \(0\)775 209 7859 skype ianmcnicoll ian\.mcnicoll@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 --- ## Post #12 by @heather.leslie Hi Ian, I'd be very interested to see the extent of these examples and make some assessment whether an ordinal is the most appropriate way to model this content. Few thoughts: · The natural instinct is definitely to use an ordinal but is it because of the layout/display in the requirements document or based on the data itself? We could equally suggest that these values could be modelled as a coded text list and assigned a value mapping in the same way you suggest. · Should the values simply be described, or actually assigned, in the archetype (via the data type itself) and how much of this should be left in the application GUI/workflow/logic? · Is the clinical content reasonable - we have certainly found that there are many instances of commonly used clinical content that is 'munged' together for historical reasons, and that when we model, needs to be teased out into subtlely difference concepts. That these values are directly related or of similar granularity etc might need further discussion. · Or do we have a simple need to emulate the current practice (rather than best practice/modelling) in the models, perpetuating any historical practice without any further consideration? I recognise that there is always a pragmatic argument for this too. Cheers Heather --- ## Post #13 by @Heath_Frankel3 Hi Heather, Good analysis. The key thing for me is how fluid these values are, will they change requiring an Archetype change? If so, then they shouldn’t be modelled as an Ordinal and maintained externally. The other things is that when we using the term mappings, are we talking about the DV_TEXT mappings? DV_TEXT mappings don’t support numerical values, only coded values and hence not able to support this requirement. Heath --- ## Post #14 by @ian.mcnicoll Hi Heather, Comments inline below \.\.\. 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@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 > Hi Ian, > > I'd be very interested to see the extent of these examples and make some > assessment whether an ordinal is the most appropriate way to model this > content\. \[IAN\] I have only come across a couple of examples so far, the Walterlow Scle being the best example but mongst the many thousands of scales and scores out there, I bet there are other examples\. > Few thoughts: > > · The natural instinct is definitely to use an ordinal but is it > because of the layout/display in the requirements document or based on the > data itself? We could equally suggest that these values could be modelled as > a coded text list and assigned a value mapping in the same way you suggest\. > \[IAN\] The requirement is to map a set of terms to a set of values\. The ordinal is currently the only way we have of doing this\. It could be argued that the Apgar and GCS are actually examples of mappings which happen to be ordinal\. > · Should the values simply be described, or actually assigned, in > the archetype \(via the data type itself\) and how much of this should be left > in the application GUI/workflow/logic? > \[IAN\] Wel,, yes\. But surely the point of archetypes is to formally document as much of this knowledge as possible, rather than leaving it to application logic\. I have managed to workaround the current restriction for the Waterlow Scale archetype but it is pretty counter\-intuitive\. The strength of the RM is that it should be rich enough to capture these sort of clinical ideas in a way that is clear ot both clinicians and developers\. The idea of a termset mapped to numeric values is, I thikn, valid\. The only issue is whether it makes sense to adapt the DV\_ORDINAL for these non\-unique uses\-cases, or whether a new datatype is required > · Is the clinical content reasonable \- we have certainly found that > there are many instances of commonly used clinical content that is 'munged' > together for historical reasons, and that when we model, needs to be teased > out into subtlely difference concepts\. That these values are directly > related or of similar granularity etc might need further discussion\. > \[IAN\] I absolutely agree in principle but these requirements will come mostly from 'formal' scale and score instruments\. Many of them will be poorly evidenced or only very locally used but we do not really have much choice but to model them 'as is'\. > · Or do we have a simple need to emulate the current practice > \(rather than best practice/modelling\) in the models, perpetuating any > historical practice without any further consideration? I recognise that > there is always a pragmatic argument for this too\. > \[IAN\] I agree that there are areas where we are in as good position to define 'best practice' in information recording \(and the discussions about 'severity' are a good example\) but I do not think it is realistic for us to argue e\.g\. that the Waterlow Scale is 'wrong' because it does not fit our idea of a 'proper ordinal'\. --- ## Post #15 by @ian.mcnicoll Hi Heath, >> The key thing for me is how fluid these values are, will they change requiring an Archetype change? If so, then they shouldn’t be modelled as an Ordinal and maintained externally\. The assumption is that the values are not fluid\. A change in the values would imply a revision of the underlying scoring instrument, which would non longer be compatible with the previous version\. The Waterlow Scale has been revised a couple of times since its original development, with changes in terms and values but these are infrequent >> The other things is that when we using the term mappings, are we talking about the DV\_TEXT mappings? DV\_TEXT mappings don’t support numerical values, only coded values and >> hence not able to support this requirement No we are definitely talking about the current arrangement in DV\_ORDINAL where a Text term is 'mapped' to an integer value\. Philosophically Ordinal seem to have been conceived as being a list of values each of which is assigned a text term\. In practice, I think the reverse is true \- these are nearly always a list of terms to each of which is assigned a value, which is somewhat arbitrary\. GCS, Apgar and many other well\-recognised scores are really examples of term lists mapped to values, which in most cases happen to be unique AND integer\. I am clear that we need this more open idea of a term\-list, to which each member is assigned a real number\. The only issue is how this is implemented\. 1\. Create a completely new datatype\. There is so much crossover between this and DV\_ORDINAL \(which also needs 'real' values\) that the creation of a separate datatype is unnecessary\. 2\. Add a unique/non\-unique\_values attribute to the constraint, defaulting to unique\. This would allow the current uniqueness rule to be applied as default but which could be lifted for specific use\-cases like the Waterlow scale\. 3\. Simply remove the uniqueness requirement\. It seems unnecessary to me since all of the possible allowed values are always explicitly expressed in the constraint\. It is up to the archetype designer to decide whether uniqueness is required or not\. 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@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 --- ## Post #16 by @thomas.beale Ruminating on the discussion so far, it seems to me that we do need to do this properly\. What use are openEHR archetypes if they don't cope with common medical things? A new data type seems to make sense \- a kind of DV\_CODED\_TEXT containing also a score\_value attribute\. Maybe we can call this DV\_CODED\_VALUE \(other possibilities: DV\_CODED\_RATING, DV\_CODED\_SCORE\)? The properties would be different from DV\_ORDINAL: with DV\_CODED\_VALUE, each possible value in a series must have a distinct code and meaning, but may have any numeric value associated with it, allowing multiple such DVs to have the same value\. If we wanted to make it quite score oriented \- which seems like a good idea to me, we might use the name DV\_CODED\_SCORE\_VALUE, and include in it a reference to the score, in the form of a DV\_CODED\_TEXT\. Thus: class DV\_CODED\_SCORE\_VALUE inherit      DV\_CODED\_TEXT      score\_value: Real      score\_reference: DV\_CODED\_TEXT end This requires more thinking by those who know the problem better than I do, but it is easy to test any model like this by adding to an experimental variant of one of the BMM\-schemas used in the ADL Workbench\. Test archetypes can then be written to see what it is like\. \- thomas --- ## Post #17 by @system Hi Thomas Sounds OK \- just not sure that we need both?? The alternative is to loosen up DV\_ORDINAL\. That could be easier? Having different ways of doing the same thing is always problematic\. Cheers, Sam --- ## Post #18 by @ian.mcnicoll Hi Tom, I agree with Sam\. I think you are correct in principle but the difference, in practice, between a DV\_ORDINAL and a DV\_SCORED\_VALUE is non\-existent where the constrained values are unique, which will be the majority of cases\. e\.g\. What makes Apgar and GCS Ordinals? They are essentially DV\_SCORED\_VALUES which happen to have unique values\. The differences will be too subtle for most archetype designers \(including this one\) to model consistently\. 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@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 --- **Canonical:** https://discourse.openehr.org/t/multiple-values-in-c-dv-ordinal-constraints/15083 **Original content:** https://discourse.openehr.org/t/multiple-values-in-c-dv-ordinal-constraints/15083