We discussed about this item a lot: https://openehr.atlassian.net/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model
IMO we can simplify the model a lot by removing the ITEM_STRUCTURE hieranchy and translating the semantics to CLUSTER. My proposal is here: https://openehr.atlassian.net/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model#openEHR2.xRMproposals-lowerinformationmodel-CandidateB-RemoveITEM_STRUCTURE
The main point here is to correctly deal with existing data and software - this may be solved with a breaking change, so we need to be careful. I'll have a careful review myself of the options, but I very strongly recommend all reviewers from implementer organisations (vendors, universities, provider IT groups) look very carefully at the impact of the various options.
I think that the more 'breaking' change to current implementations is that potentially you can have an ELEMENT hanging directly from several places. Already developed archetypes can be automatically transformed to the new approach without breaking them (although it would be wise to simplify them to avoid unnecessary structures).
Probably some software needs to be upgraded, but as long as a guidance for the transformation is provided, the transition shouldn't be dramatic.
+1 Agree with removing ITEM_STRUCTURE as in candidate B of the mentioned page.
We might need to discuss If this is for 1.0.3 or if it is a change mandating a version increment to 1.1. It is likely to be a fairly easy algorithmically solvable conversion though.
Candidate C on that wikipage suggests also altering things a bit further up in the RM (children of CONTENT_ITEM and ABSTRACT_CARE_ENTRY) - perhaps that should be split into a separate PR and handled later (breaking change). Perhaps handle at a time whensuggestion doing CIMI-harmonization (when CIMI RM has settled more). Thoughts?
This is a duplicate of and SPECPR-74. Can we have a single issue with a summary of the options?
I would like to have it both ways leaving the existing mechanisms in place with an indication of depreciation while providing support for a new structure. This may mean CLUSTER or ITEM needs to inherit from a new class that ITEM_STRUCTURE also inherits. Perhaps this is one of the proposed options?