Page Comparison

...

• 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

...

Discussion

Questions/thoughts from Erik Sundvall:

• The above VALUE_CLUSTER sugestion is an interesting change, and if flexibility is what is sought for, then perhaps the simplification can be taken even further...
• Now the current ITEM+ELEMENT+CLUSTER follows the composite design pattern (see c2 wiki and wikipedia http://en.wikipedia.org/wiki/Composite_pattern). But since there are not many common operations/methods shared by ELEMENTs and CLUSTERs (except the ones already in PATHABLE/LOCATABLE) then perhaps the composite design pattern is not needed/helpful in this part of the openEHR structure. (Also see discussions at CompositeConsideredHarmful and maybe this.)
• If the contents of both ELEMENT and CLUSTER are pushed up to ITEM then we get the same functionality as proposed in VALUE_CLUSTER, but with fewer classes. (ITEM_STRUCTURE will not be needed, see the "Middle and Lower IM"-suggestion further down on this page, but perhaps ITEM_STRUCTURE would be a better name than ITEM for this new super-ITEM with VALUE_CLUSTER capabilities). And one (debatable) way of looking at the ITEM/ITEM_STRUCTURE family of classes is to consider them as being just for structuring and naming nodes internally in a hierarchy and considering the the DATA_VALUE classes to be the real leafs. (Yes, debatable...)
• Perhaps what is mentioned as a "downside" above (not being able to force ELEMENT or CLUSTER) is achievable (if wanted) by archetyping a new super-ITEM to have 0 items (forcing ELEMENT-functionallity) or 1..* items (forcing CLUSTER-functionality)? Also, perhaps "value" can be archetyped as disallowed if you rally want to force value-less CLUSTER behaviour.

...

Discussion

xxx

...

Candidate

...

A.3 - Integrated model 1 - preserve current archetypes

Proposal - Pablo PazosThomas Beale

Status

under constructionUnder development

Design

...

Concept

The design integrates Candidate A (ITEM_STRUCTURE

...

Changes

• Removed ITEM_STRUCTURE and children.
• Added attribute structure_type:CODE_PRHASE to CLUSTER (as in 13606 model)
• Added method is_root() to ITEM
• ITEM inherits from DATA_STRUCTURE
• Added backguards relationship "parent" from ITEM to CLUSTER

Diagram

Image Removed

I have the source of this diagram if anyone wants it, it's a .dia file (http://live.gnome.org/Dia)

Impact Analysis

Candidate C - class renaming for easier explanation

Proposal - Erik Sundvall

Status

under construction

Design Concept

Below is an initial suggestion based on some previous mail threadsbecomes a child of CLUSTER) and A.2 (ELEMENT.value & null_flavour move to ITEM). The effects of this should be as follows:

• with respect to CLUSTER/ELEMENT, same as for A.2, i.e. CLUSTERs now get optoinal values & null_flavour as well
• ITEM_STRUCTURE is retained because it is used ubiquitously in the openEHR RM and archetypes; therefore the current archetypes will not break.

Changes

• The value properties from ELEMENT are moved to ITEM.
• ITEM_STRUCTURE becomes child of CLUSTER
• DATA_STRUCTURE class removed

Diagram

The following shows the result.

Image Added

...

Candidate A.4 - Make ITEM the focal 'data structure' class

Proposal - Thomas Beale

Status

Under development

Design Concept

This version assumes that where ITEM_STRUCTURE is referenced in the model, we will now just use ITEM.

Note that the ITEM_STRUCTURE + subclasses could in theory be moved to another part of the spec, to do with implementation (I would have made the classes another colour here if the tool had allowed it). I do think they will help implementers when non-tree data structures are encoded as CLUSTER / ELEMENT hierarchies, because with no guidance they will all invent their own structures, and the data will be a mess. Standardised rules for encoding tables and lists as CLUSTER / ELEMENT trees will directly influence how archetyping tools represent structures like table (of various kinds) and list that may be presented in the UI of a modelling tool.

Changes

In addition to Candidate A.3 changes:

• Convert references in RM to ITEM_STRUCTURE to ITEM
• Optionally removed ITEM_STRUCTURE (it is shown as retained here)
• keep ITEM_STRUCTURE descendants, providing a standardised programming interface to tree, list, table etc arrangements of CLUSTER/ELEMENTs

Impact

This will break all RM-based software, most openEHR archetypes today, and is not directly compatible with existing openEHR data. However the costs may be reasonable:

• although  the RM will break, the semantics of ITEM and ITEM_STRUCTURE are not that different, and the changes should generally be simplications / removal;
• archetypes could be automatically processed to make the change. Almost all real archetypes use ITEM_TREE, which has the 'items' attribute which is the same as for CLUSTER.
• existing data would either have to be migrated to the new form (assessment required) or converted on the fly to the new form during querying.

Diagram

The following shows the result.

Image Added

...

Candidate B - Remove ITEM_STRUCTURE

Proposal - Pablo Pazos

Status

under construction

Design concept

• Remove ITEM_STRUCTURE and use ITEM for structures without losing meaning/semantics/modeling capabilities.

Changes

• Removed ITEM_STRUCTURE and children.
• Added attribute structure_type:CODE_PRHASE to CLUSTER (as in 13606 model)
• Added method is_root() to ITEM
• ITEM inherits from DATA_STRUCTURE
• Added backguards relationship "parent" from ITEM to CLUSTER

Diagram

Image Added

I have the source of this diagram if anyone wants it, it's a .dia file (http://live.gnome.org/Dia)

Impact Analysis

...

Candidate C - simplification and class renaming for easier explanation and implementation

Proposal - Erik Sundvall

Status

Now updated to include the suggested "Candidate A.2" ITEM/CLUSTER/ELEMENT change.

Design Concept

Due to archetyping the model could actually be allowed to be simpler than the 1.0.2 spec is without losing any significant expressiveness. The intention is primarily to make learning and usage simpler for archetype authors, but hopefully also for implementers. Below is an initial suggestion based on some previous mail threads

• http://www.openehr.org/mailarchives/openehr-clinical/msg01353.html, Mar 2009, Confusing naming of OBSERVATION and EVALUATION?
• http://www.openehr.org/mailarchives/openehr-clinicaltechnical/msg01353msg05299.html
• ...

(TODO: find links to more threads in mail-archive)

Changes

Diagram

...

• , Nov 2010, openEHR-13606 harmonization CR regarding CLUSTER/TABLE etc and ENTRY/OBSERVATION

Changes

See comments in diagram.

Diagram

Image Added

'UML' image above produced by pasting the "diagram sourcecode" below to http://yuml.me/diagram/scruffy/class/draw2 (initially by Erik Sundvall)

...

I have likely missed some details (and did not have time to add datatypes to all attributes, but they are in the openEHR specs).

Update: The attribute "structure" in the class "CLUSTER" could of course be named "structure_type" instead as in candidate A and B if that is preferred.

[note: No change suggestions in ACTION and INSTRUCTION except that ITEM_STRUCTURE type is replaced by ITEM]
[CONTENT_ITEM{bg:yellow}]]^[SECTION|0..* items: List CONTENT_ITEM{bg:yellow}]
[CONTENT_ITEM]^[ENTRY|data: ITEM{bg:yellow}]]
[CONTENT_ITEM]^[ABSTRACT_CARE_ENTRY|0..1 protocol: ITEM;0..1 guideline_id: OBJECT_REF;0..1 workflow_id: OBJECT_REF;language: CODE_PHRASE;encoding: CODE_PHRASE;subject: PARTY_PROXY;0..1 provider: PARTY_PROXY;0..1 other_participations: List PARTICIPATION; ]
[ABSTRACT_CARE_ENTRY]^[CARE_ENTRY|data: ITEM]
[CARE_ENTRY]-[note:CARE_ENTRY Replaces both ADMIN_ENTRY and EVALUATION.]
[ABSTRACT_CARE_ENTRY]^[OBSERVATION|data: EVENTS;0..1 state: EVENTS]
[ABSTRACT_CARE_ENTRY]^[INSTRUCTION]
[ABSTRACT_CARE_ENTRY]^[ACTION]
[ENTRY]-[note:ENTRY replaces GENERIC_ENTRY and is intended also for 'healthcare a-specific' stuff as indicated useful by 13606 experiences]
[EVENTS|origin;0..1 period;0..1 duration]++-events>[EVENT|time;0..1 state: ITEM; data: ITEM]]
[EVENTS]-[note: HISTORY renamed to EVENTS]
[EVENT]^[INTERVAL_EVENT|width;0..1 sample_count;math_function]
[ITEM{bg:yellow}]^[ELEMENT|0..1 null_flavor;0..1 value DATA_VALUE{bg:yellow}]^[ELEMENT|{bg:yellow}]
[ITEM]^[CLUSTER|1..* items: ITEM;0..1 structure_type: CODE_PHRASE{bg:yellow}]
[CLUSTER]-[note: 'structure_type' indicates if the cluster is to be validated and interpereted as e.g. a table or list - defaulting to tree if not provided]

...