Revert meaning to STRING and rename as archetype_node_id
Raise CR
Analysis
Resolution
Raise CR
Analysis
Resolution
Description
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 'node_id'.
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.
Major
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
'node_id'.
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.