VCOV rule prevents non-unique values in C_DV_ORDINAL list
Description
is duplicated by
Activity
Thomas Beale April 27, 2018 at 3:36 PM
I can't find any mention of VCOV in the old Archetype Profile doc (https://www.openehr.org/releases/1.0.2/architecture/am/openehr_archetype_profile.pdf)
It was a rule for a while I think in AOM2, but we got rid of it. I think this problem is just a tooling implementation problem with the AE, and the best thing is to check that the ADL-designer does not have the same problem.
If I am wrong, I'll need refs to the relevant specification, because at the moment I cannot see what can be changed at the spec level.
Ian McNicoll April 26, 2018 at 5:42 PM
Can we close this off? Even though there may be a case for a new datatype, the rule seems unnecessary, removing it woud resolve at least some existing issues (including NEWS , I would argue( and as /I understand it, is being ignored e.g by CKM.
Thomas Beale November 13, 2017 at 10:01 PM
The other thing is that hacking DV_ORDINAL doesn't solve Silje's use case (i.e. NEWS) anyway, because it's a tuple of pairs of {Integer, Range<Real>}, and I guess it is very likely that similar tuples can occur like:
{Integer, Range<Quantity>}
{symbol, Range<Integer>}
etc.
So it looks like a complex map to me - not even a data type, but a data structure. It can already be achieved in ADL2, using tuples.
Thomas Beale November 13, 2017 at 6:22 PM
I partly agree. The inherent meaning of ordinals is that they are not just an association but ordered. I.e. the value 1 is less than 2 (it may be considered 'greater than' in some clinical sense, but that's a domain-level interpretation).
So for things that are really not ordered, and are more general maps of scalar values to ranges / ... other primitives, I think we need a new type. It may well be the more commonly used type in the future.
I don't think relaxing the uniqueness feature is correct - this data type will have been programmed as it is specified, which is as an ordered type for which the '<' operator is implemented. The current ordinal data type just isn't a map concept, it's an ordinal concept.
Ian McNicoll November 13, 2017 at 5:44 PM
While a new datatype is completely logical, I can pretty well guarantee that it will be used in future almost completely instead of DV_ORDINAL: Why? Because the value of the current ORDINAL is in allowing us to associate a numeric with a term, not in the ordinality per-se.
The number of 'true' ordinals is tiny in comparison to the much wider uses of numeric-linked-to-term, some of which are true ordinals but with no future guarantee that someone will augment an existing ordinal with a non-unique numeric.
I would still push for relaxing the uniqueness rule. Creating a whole new datatype creates a whole new layer of complication, training requirements and confusion that can be avoided. If you want to mae uniqueness a default state, that's fine but allow us to turn it off where it gets in the way.
Notes from list discussion...
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 see that two terms have identical values.
The Archetype Editor and VCOV rule in the TRUNK openEHR Archetype profile prevent non-unique values.
Daniel Karlsson:
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!
Ian McNicoll
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.