Page Comparison

...

Proposal - Thomas Beale / Ian McNicoll

Status

Under developmentThis particular model uses 'diamond' multiple inheritance, and is not intended for a real proposal, since most languages don't support this, and it isn't really necessary anyway. Here it is used just to illustrate the concept.

Design Concept

In this model, a new class is added that combines CLUSTER and ELEMENT. This reflects the fractal nature of reality. Initially you think you have just an ELEMENT, but later on, people want to start recording more fine detail. In the other direction, information users often want a 'summary' data point for a collection of details. No ITEM_STRUCTURE classes are included at all.

...

• retain CLUSTER and ELEMENT classes, since they remain useful, are already defined, and map cleanly to 13606-1
• support efficient, shortest possible path to a summary data item (e.g. 'smoking status' = Smoker)
• ensure that if the summary item is added at runtime, e.g. by converting a CLUSTER to the new CLUSTER+value type, the paths of the underlying detailed items don't change
• ensure that if an ELEMENT is converted to a CLUSTER+value at runtime, the path of the ELEMENT.value does not change
• make it so that a specialised archetype can convert a CLUSTER or ELEMENT to a CLUSTER+value type

...

• 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.
•  

  ---

  Candidate A.2 - Modify CLUSTER to have local value

Proposal - Thomas Beale / Ian McNicoll

Status

Under development

Design Concept

The design intent of this solution is the same as for Candidate A.1 above. However, in this version, we want to add a value attribute to the CLUSTER class. Since ELEMENT already has this, we can move it to ITEM, the common parent. The technical needs we are trying to meet here are:

• retain CLUSTER and ELEMENT classes, since they remain useful, are already defined, and map cleanly to 13606-1
• support efficient, shortest possible path to a summary data item (e.g. 'smoking status' = Smoker)
• ensure that if the summary item is added at runtime, e.g. by populating the new CLUSTER.value attribute, the paths of the underlying detailed items don't change
• ensure that if an ELEMENT is changed to a CLUSTER at runtime, the path of the value attribute does not change

Changes

The value properties from ELEMENT are moved to ITEM.

Diagram

Impact Analysis

Discussion

xxx

...

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

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 threads

...

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

Changes

Diagram

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

...

[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}]
[ITEM]^[CLUSTER|1..* items: ITEM;0..1 structure: CODE_PHRASE{bg:yellow}]
[CLUSTER]-[note: 'structure' indicates if the cluster is to be validated and interpereted as e.g. a table or list - defaulting to tree if not provided]

Impact Analysis

Discussion

xxx