How to override ordering in specialised archetypes
Description
Activity
(Ian McNicoll) inactive August 19, 2009 at 9:23 AM
It would be interesting to know why the author of Diagnosis wanted Criteria to be unordered. It makes no sense to me clinically or technically but is does perhaps to a lack of clarity of the effect of specifying ordered/unordered on clinical information. My understanding is that that ordered simply specifies that any items in a container must be listed (and therefore) persisted in a particular order. It does not and cannot say anything about how the information is displayed in a UI, although it might be seen as a recommendation.
'Unordered' does make more sense as a default, but only if we can assume that the designed order acts as the default order for storage and retrieval of a list, unless otherwise specified. This would leave us free to apply 'ordered' to those situations where order is critically important, 'ordered' acting both as am attribute which enforces ordered storage but also as a sort of UI / clinical knowledge directive, to implementers that any UI should enforce the same order.
Ian
Details
Details
Reporter
Components
Affects versions
Priority
Minor
In the following example from the problem-diagnosis archetype, the AWB warns:
Warning (WCACA): attribute items in object node at /data/items[at0.35]/items cardinality 1..* same as in reference model.
CLUSTER[at0.35] occurrences matches {0..1} matches { – Diagnostic criteria
items cardinality matches {1..*; unordered} matches {
....
}
}
However, how can this be fixed?
The reference model states "ordered" as default in this case, and the creator of the archetype wanted it unordered for some reason.
Possible syntax could be (not currently legal):
items cardinality matches {unordered} or
items cardinality matches {; unordered}
Making a list unordered is relaxing a constraint in Thomas' and also my opinion, and should be illegal; and in any case, if the intention is for the list to be 'unordered', then any order that exists is by definition ok. The problem might be in GUI processing if some layer of software wanted to read the archetype and determine whether to impose ordering or not.
Now, if there were places in the RM where 'unordered' was the default, it should be legal to narrow this to 'ordered', and the parser would need a way to deal with this.
So the questions are:
should the RM have ordered as a default?
what should the ADL look like for doing unordered -> ordered?
what should the AOM look like for the above constraint?
Ian also thinks that the concept of 'ordered' needs a bit of a rethink. He is aware of only a few instances of clinical concepts that MUST be ordered at archetype level, although there are more situations of ordered being applied at template level. Having said that, most archetypes and lists do have a 'natural order' which should not be disturbed if at all possible, as it helps the review and sign-off process and is a sensible start point for UI ordering of elements, terms etc. Therefore, in his opinion, 'ordered ' should not be an RM default but any design-time ordering should be honoured by tools and at run-time unless specifically overriden at run-time or in a template/specialisation and 'ordered' applied.
Heather also argues that a default of unordered makes sense, constraining to ordered when neccessary and that at the moment it is not possible to legally have unordered at all.