...
This page is describes changes proposed to the openEHR release 1.0.2 Reference Model (RM) in response to the many lessons learned over the years since its publication. The issues driving the changes are recorded on the Jira SPECPR issue tracker .
DATA_STRUCTURE classes
Needs
...
There are two possible flavours of proposals here. The first is for changes that have acceptable impact on the growing number of openEHR-based production systems and data. The second is for 'ideal' next generation models that don't necessarily take account of impact on existing data and systems. However, even 'blue-sky' suggestions need to be aware of the 'community memory' that exists, including people's current understanding of names and design ideas within the openEHR models. Is creating a completely new Reference Model still 'openEHR'? We need to be clear on what we understand as being an 'openEHR RM' versus something else, such as the 13606 RM, also based on the openEHR archetype design concept.
For the purpose of clarity, we suggest that this page and its children address only the 'openEHR Reference Model', not other reference models that simply use the archetype-based methodology.
...
Current state - Release 1.0.2
Models
The current data structure models are shown below.
...
- few archetypes use anything but ITEM_TREE because it appears that one 'can never know' if some more detail will be needed later
- TB: but what about things like Apgar, Barthel etc - surely they are linear lists?
- also, it appears that some form of 'table' structure is still needed
- ITEM_TREE, ITEM_LIST etc cannot be nested inside each other arbitrarily.
- the structures complicate the software unnecessarily, without adding much value (this would clearly be true if no/limited use is being made of ITEM_LIST, ITEM_SINGLE) - [question: by "use is being made", do you mean use of the class methods in software or use of the structuring possibilities? The structuring possibilities will remain if a structure_type variable is used.]
- Depending on how you write and divide/distribute software functionality, having ITEM_STRUCTURE subclasses may just complicate class structure and not add any value at all in server/backend/query code and storage. Storing the same structure/presentation info in a structure_type variable will still give GUI code what it needs for validation and presentation but a handful of classes less to implement and maintain e.g. on the server side. Some implementations (or parts of implementations) handle openEHR structures mainly as documents, not objects, thus only stored attributes, not object methods, are used - in those cases the methods of ITEM_STRUCTURE subclasses bring absolutely no value and a structure_type variable would be easier to handle than having to store or infer object type info.
- When learning and presenting openEHR, there will be fewer classes and one level of nesting less to consider, making the design less cluttered.
- "Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." - Antoine de Saint-Exupery
- archetype paths are made longer and more complex ... MORE INFO REQUIRED - WHAT'S THE PROBLEM?** Paths are used e.g. in AQL queries - shortening or simplification of paths make queries easier to read, write and understand.
- Having fewer nesting levels to traverse in hierarchical database backends (e.g. network-DBs and XML-DBs) or ORM mapping frameworks when fetching data from queries would likely improve performance.
- Shorter paths also means less to parse and translate for the query processing software, but without measuring the impact of this it is not possible to say if it matters very much for performance in practice.
- a clear solution to the pizza problem (multi-value items & UI) is needed
- add a type that is a mixture of CLUSTER and ELEMENT, i.e. has a value and also children, to allow for the fractal nature of data, with a 'summary' value, plus underlying detail
Below, various simplified models are proposed, each with an impact analysis.
...