Introduction
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 .
ITEM_STRUCTURE & ITEM / CLUSTER / ELEMENT
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
The current data structure models are shown below.
|
|
|
|
Problems
Problems / irritations with the above models appear to include the following:
- 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)
- archetype paths are made more complex ... MORE INFO REQUIRED - WHAT'S THE PROBLEM?
Below, various simplified models are proposed, each with an impact analysis.
Candidate A - make ITEM_STRUCTURE inherit from CLUSTER
Proposal - Thomas Beale
Status
under construction
Design concept
- Keep ITEM_STRUCTURE and children, but just make them a variety of CLUSTER. Impact remaining model as little as possible.
Changes
- ITEM_STRUCTURE now inherits from CLUSTER.
- all static declarations in the remainder of the RM for ITEM_STRUCTURE changed to CLUSTER. In theory they should stay ITEM_STRUCTURE, but the problem is that with no static declarations anywhere for CLUSTER or ITEM, CLUSTER archetypes have no place to go, and the CLUSTER type is not detected by my current 'type closure' detecting algorithm. This should probably be changed.
- the types ITEM_TREE, ITEM_SINGLE, ITEM_TABLE, ITEM_LIST could be kept as programming types for manipulating the specific kinds of data structure.
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 |
|
Candidate A.1 - Add VALUE_CLUSTER, Remove ITEM_STRUCTURE types
Proposal - Thomas Beale / Ian McNicoll
Status
Under development
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.
Changes
A new VALUE_CLUSTER, inheriting from ELEMENT and CLUSTER provides the semantics of both: a node which can itself have a value (like an ELEMENT), but may still hvae substructure. By inheriting from both CLUSTER and ELEMENT, it means that where either of these two are currently specified in the RM or archetypes, VALUE_CLUSTER could be substituted at runtime.The downside of this model is that there is no way to force a node to be just an ELEMENT or CLUSTER, since the new type is always substitutable.
Diagram
Impact Analysis
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
Component |
Impact |
---|---|
On RM |
RM change |
On existing archetypes |
RM change |
On archetype tooling |
RM change |
On existing RM-1.0.2 based software |
RM change |
On existing RM 1.0.2 data |
transformation needed |
Candidate C - xxx
Proposal - xx
Status
under construction
Design concept
- 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)
Below is an initial suggestion based on some previous mail threads
(TODO: find links to more threads in mail-archive)
'UML' image above produced by pasting the "diagram sourcecode" below to http://yuml.me/diagram/scruffy/class/draw2 (initially by Erik Sundvall)
The yellow stuff is what I guess could be in a 13606-1(a?) "healthcare a-specific" update and the rest in a new 13606-6 or 13606-1b healthcare-specific part.
I have likely missed some details (and did not have time to add datatypes to all attributes, but they are in the openEHR specs).
[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]