We're updating the issue view to help you get more done.Learn more

Revert meaning to STRING and rename as archetype_node_id

Recent analysis on an archetype language has shown
that all meanings should be archetype-local terms, rather than
terms coded from external terminologies. This is because a) we
want archetypes to be valid independent of terminologies, and b)
there are often archetype node meanings for which no term is
available, not even in UMLS.

SH: only meaning codes are needed on instances, since archetypes
are always needed to process openEHR data.

DK: what if there was a translation error in the archetype and the
e.g. english text of at0017 (meaning= Haemogloblin) should have
been at0017 (meaning=Haematocrit) instead; the original text
recorded next to at0017 in the meaning attribute would be the
wrong value. Problem is that it might be the text that is correct
from the application's point of view, and the code is wrong.

So - the application developer &/or data mapper need the support of
a normalised name as well as the code, in order to trace what the
intention of data recording was at any time. In the above example,
a new version of the archetype would be produced with the
translation corrected, and all data previously produced with it
would be corrected by replacing at0017 with at0016 (and presumably
vice versa). Not recording the text value of the node term in the
meaning attribute would prevent this from working.

Input from Vince MacCauley, Dipak Kalra, and others supports the
change to a String, and also the change of name from 'meaning' to

In addition, support is required for including terms at the top of
EHR Extracts, to allow for Extracts to be completely
interpretable, now that only the codes will be available in the
'node_id' field of the archetyped data.






Change Description

Meanings are thus given codes local to the archetype and these are mapped to one or more terminologies at the bottom of the archetype. The meaning attribute in LOCATABLE and in ARCHETYPE_FRAGMENT should be changed to type STRING. A further point to consider. Even if the meanings are only archetype local terms, it might be argued that at least the term (e.g. 'at0002') and the text (e.g. "systolic blood pressure") should be included as the meaning. The problem with this argument is that the latter can only be in one language; how should this language be chosen from the available languages of the archetype? Presumably it would be the language of the locale in which the archetype was used, even if this language is not the primary language of the archetype. The final changes agreed after a net discussion: - rename LOCATABLE.meaning to archetype_node_id - change its type to String - change EHR Extract to include terminology extracted from the archetypes in the extract.

Approved By


Fix versions