In a number of situations it has been found that leaf level values, carried in the Element.value attribute in the openEHR model, need to allow for multiple items rather than just a single one. One example is for questions in a questionnaire, illustrated by the following (non-medical) example from Alessandro Torrisi, Medical Centre Alkmaar (MCA), Netherlands:
In real life :
In openEhr:
I did not asked the question twice, so it is not correct this way. Beside that, there is another problem :
In openEhr:
The need here is to be able to instead support the following:
It turns out that there are a number of circumstances where the same problem turns up. Currently, although this kind of data can be represented, the openEHR RM does not directly model multiple-values on a single data node, nor is there a clear guideline for archetyping it. Below, we describe these requirements in detail and consider possible solutions, including how to do it in the current model and archetyping infrastructure.
A clinical version of the 'pizza' problem above is questions like the following in questionnaires, such as given to a new patient at a GP clinic:
The typical answer to such questions are things like:
In these and many other cases, the answers are often a) multiple and b) unique, i.e. items are not repeated. In the above cases, the response values might or might not be coded.
In professional questionnaires, such as http://www.cap.org/apps/docs/committees/cancer/cancer_protocols/2005/breast05_ckw.pdf#page=5 there are questions that could easily have multiple answers, and the answers may be coded from Snomed-CT or elsewhere.
A similar thing can occur with dates, e.g. Date of prescription 12/12/2008, 1/4/2009, 23/5/2009. The same thing is true here - multiplicity and uniqueness apply.
The openEHR Release 1.0.2 RM does not directly provide a way to represent the above kind of data. In this release, data items are always atomic DATA_VALUE descendant objects, attached to the ELEMENT.value attribute in a data hierarchy. Representing multiple items is normally done with a CLUSTER or ITEM_LIST, e.g.
This structure is a reasonable representation of the requirement. The problem is how to control it properly within an archetype. Consider the following archetype fragment:
CLUSTER[at0004] matches { -- allergies question
items cardinality matches {;unique} matches {
ELEMENT[at0005] matches { -- question
value matches {"what allergies do you have"} -- would normally be coded
}
CLUSTER[at0006] matches { -- response
items cardinality matches {;unique} matches {
DV_TEXT matches \{*\}
DV_CODED_TEXT occurrences matches \{*\} matches {
defining_code matches {
[local::at0010, -- grass
at0011, -- pollen
at0012] -- penicillin
}
}
}
}
}
}
|
The above archetype does what is needed. However, there are some anomalies to consider:
The default approach is to make no changes to the RM or archetype model, and to require the above archetype pattern to always be used in this circumstance. This solution does not address the GUI mapping problem described in the section above.
A data type such as DV_MULTI_TEXT could be added to the Data_value package in openEHR, whose value was a List<DV_TEXT>. To deal with DATE, we would need DV_MULTI_DATE, and so on.
Pros:
Cons:
A more generic approach is to change the Data_structure.Representation package to add a new MULTI_ELEMENT class, whose value is a List<DATA_VALUE>. To make things work properly, a new parent of ELEMENT and MULTI_ELEMENT would have to be inserted as well, say ELEMENT_ITEM, so that the types ITEM_LIST.items and ITEM_SINGLE.item could be respecified to be this new type (thus allowing both kinds of ELEMENT).
Pros:
Cons:
An alternative generic approach is to add a new generic data value class DV_LIST<T: DATA_VALUE> which would allow the creation of types like DV_LIST<DV_TEXT>, DV_LIST<DV_DATE> and so on.
Pros:
Cons:
From the above, it would appear that Solution #3 above is the best. This seems to best represent the design intention corresponding to the requirement, and while it would have some impact on software, it will have no impact on existing data. It would require changes to the reference model, the XML schema, and existing query engines, but none of these changes appears to be difficult or to create problems with existing data.
Note that in solutions 2, 3, and 4 above, the semantics of paths change slightly: now a leaf-level path can no longer be assumed to point to an atom, it might point to a list. Existing queries would need to be reviewed, and new ones written in a slightly different way, such that matching a value of X must be done by testing for either equality e.g. x/y/z/value = 'pizza', and set membership e.g. x/y/z/value.has('pizza'). Solving this might be best done with a new operator say ~= which tests for both, e.g. x/y/z/value ~= 'pizza'.
The semantics of 'select' are essentially a flexible choice concept, in the general case, M from N, where M <= N. It initially seemed that 'select' would be a '1 from N' concept, in which case there was an idea that it might be used to make the choice semantics of single attributes with multiple children clearer, but this is not the case due to the more general 'N from M' meaning.{*}