Simplify RM by reducing or removing ITEM_STRUCTURE package

Raise

Analysis

Raise

Analysis

Description

Regarding ITEM_TABLE (and the other classes in the openEHR item_structure package) there was a change request from Sam that went pretty unnoticed by a while ago, see:
http://www.openehr.org/mailarchives/openehr-technical/msg04994.html

I'm not saying we should go exactly by the letter in Sam's CR, but somehow skipping the things currently in item_structure package in openEHR could simplify understanding and slightly reduce implementation complexity. (It might also shorten paths in object traversal (and thus storage depth) one step - a possible performance gain in some implementations.)

Probably letting the "data" attribute of openEHR ENTRY subtypes point straight to ITEM (or possibly CLUSTER) would be best.

If something should be suggested to be shown in a GUI as a table, list (or other non-tree formalism) it might be possible to define using any of the following...
a) ...a GUI directive/hint in archetype annotations similar to the directives shown by Koray Altag at Medinfo 2010, see slide 30 and onwards in http://www.openehr.org/wiki/download/attachments/5996988/3_GastrOS_Atalag.pdf
b) ...a new attribute in the CLUSTER or ITEM class (with accompanying controlled vocabulary).
c) ...some other way I have not thought of

Suggestion a) means the directive/hint might not be available in instance data, only in the archetype, that might be bad for safety reasons. If b) is chosen, then that new attribute could of course be archetyped if you want the information in the archetype as Andrew suggests.

I'd suggest that this change, after refinement and discussion with openEHR implementers followed by successful prototype implementation, be introduced as soon as possible before there is too much real patient data stored using the present item_structure package. Perhaps it can be introduced at the same time as ADL 1.5 and enhancements of the LINK class which anyway will require code changes.