This is my kind of brain dump discussion 
I even have my own list of stuff that I would like to change:
- Simplified ITEM_STRUCTURE (I think we all agree on that one) with just the ITEM, CLUSTER, ELEMENT to represent the same semantics (I don’t want to discuss if one class is enough, just point to the removal of ITEM_XXX). Attachments - openEHR 2.x RM proposals - lower information model - Specifications - Confluence
- DV_IDENTIFIER is underdeveloped and we need, for instance, to allow codes in the type and issuer as ADL constraints, even with external code systems.
- Allow to use some base types as data types (inherit from DATA_VALUE), for instance we needed PARTY_REF inside COMPO instances at the ELEMENT.value but used DV_IDENTIFIERS because we can’t use PARTY_REF. In fact most classes in the base.base_types.identification could be just data types.
- Fix the INSTRUCTION_DETAILS references to the instruction and activity (I raised an issue about that Jira )
- Not making the identities 1..* in the demographic model DEMOGRAPHIC model: does it make sense to have contacts and identities for ROLE? - #7 by thomas.beale
We discussed some of these some time ago https://openehr.atlassian.net/wiki/spaces/spec/pages/4915242/openEHR+2.x+RM+proposals+-+lower+information+model
I do like the idea of flatter structures! The ITEM_XXX can remove a level of the hierarchy, another level could be the SECTION, which I don’t know if today is of much use. I see its role in displaying data but not much in storage, querying and data processing.
That’s on the top of my mind, I’ll need to check the JIRA tickets for other stuff that I might have forgot.