...
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
- solve the pizza problem - multi-value items
- ITEM_SINGLE, ITEM_LIST etc are not used much in archetyping, and are also not flexible enough because they cannot occur anywhere in a CLUSTER structure
- 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.----
...
Candidate A - make ITEM_STRUCTURE inherit from CLUSTER
Proposal - Thomas Beale
Status
...
Component | Impact |
|---|---|
On RM |
|
On existing archetypes |
|
On archetype tooling |
|
On existing RM-1.0.2 based software |
|
On existing RM 1.0.2 data |
|
Discussion
...
Candidate A.1 - Add VALUE_CLUSTER, Remove ITEM_STRUCTURE types
Proposal - Thomas Beale / Ian McNicoll
...
- 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.
...
Candidate B - Remove ITEM_STRUCTURE
Proposal - Pablo Pazos
Status
...
----Candidate C - xxx
Proposal - xxErik Sundvall
Status
under construction
Design
...
- xx.
Changes
- xxx
Impact Analysis
Component | Impact |
|---|---|
On RM |
|
On existing archetypes |
|
On archetype tooling |
|
On existing RM-1.0.2 based software |
|
On existing RM 1.0.2 data |
|
Middle and Lower IM (ENTRY and ITEM_STRUCTURE & ITEM / CLUSTER / ELEMENT)
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)
...
| Code Block |
|---|
[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
Component | Impact |
|---|---|
On RM |
|
On existing archetypes |
|
On archetype tooling |
|
On existing RM-1.0.2 based software |
|
On existing RM 1.0.2 data |
|