# Looking ahead to openEHRv2

**URL:** https://discourse.openehr.org/t/looking-ahead-to-openehrv2/11448
**Category:** Specifications
**Tags:** openehrv2
**Created:** [29 September 2025 20:50 UTC](https://discourse.openehr.org/t/looking-ahead-to-openehrv2/11448 "2025-09-29T20:50:10Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### Author: ![pablo](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pablo/32/3505_2.png) [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [29 September 2025 22:02 UTC](https://discourse.openehr.org/t/looking-ahead-to-openehrv2/11448/2 "2025-09-29T22:02:18Z")

</div>

This is my kind of brain dump discussion 🙂 I even have my own list of stuff that I would like to change:

1. 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](https://openehr.atlassian.net/wiki/pages/viewpageattachments.action?pageId=4915242&preview=%2F4915242%2F5177365%2FopenEHR%20RM%20Simplifications%20ppazos.png)
2. 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.
3. 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.
4. Fix the INSTRUCTION\_DETAILS references to the instruction and activity (I raised an issue about that [Jira](https://openehr.atlassian.net/browse/SPECPR-221) )
5. 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](https://discourse.openehr.org/t/demographic-model-does-it-make-sense-to-have-contacts-and-identities-for-role/3043/7)

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](https://openehr.atlassian.net/wiki/spaces/spec/pages/4915242/openEHR+2.x+RM+proposals+-+lower+information+model)

> [@thomas.beale](#):
>
> flatter structures generally, resulting in shorter paths

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.

---

_[View the full topic](https://discourse.openehr.org/t/looking-ahead-to-openehrv2/11448)._