Multiple values in C_DV_ORDINAL constraints

Clinical (archive)
1

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

2

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
(attachments)

OceanInformaticsl.JPG

3

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

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

(attachments)

OceanInformaticsl.JPG

4

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

(attachments)

OceanInformaticsl.JPG

5

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:

(attachments)

OceanInformaticsl.JPG

6

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
7

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

8

can someone please put an issue on the SPECPR tracker? It should quote this and Daniel’s posts.

  • thomas
9

VCOV rule is in the openEHR archetype profile, page 17.
/Daniel

10

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

11

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

12

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

13

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

14

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'.

15

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

16

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

17

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

18

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