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 .
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.
The current data structure models are shown below.
|
|
|
|
Problems / irritations with the above models appear to include the following:
Below, various simplified models are proposed, each with an impact analysis.
Proposal - Thomas Beale
under construction
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 |
|
The structure_type attribute of the CLUSTER class is slightly redundant with respect to the ITEM_STRUCTURE descendant types, but makes sense in terms of backward compatibility with existing data. A system that already has ITEM_STRUCTURE + subtypes, + existing instances of those types might be changed to only create CLUSTER-based data in the future, where only the structure_type attribute was used to mark the intended logical structure of a given CLUSTER subtree. Assuming this attribute is used for anything but 'tree', then the result is software that has to implement the same logic as the original ITEM_STRUCTURE descendants, but without having any explicit types to which to attach it.
The second obvious comment one can make on this above model is that ITEM_STRUCTURE is technically redundant (i.e. if building such a model from scratch, it would not be needed). We have left it in here, so that existing static declarations of type ITEM_STRUCTURE in the Release 1.0.2 openEHR RM will remain valid. Getting rid of it would require changing such static references to CLUSTER.
Proposal - Thomas Beale / Ian McNicoll
This 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.
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.
This model is not intended as a 'final solution', just to show what is needed (a CLUSTER-with-value idea), and one way to model it. The technical needs we are trying to meet here are:
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.
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 |
|
Questions/thoughts from Erik Sundvall:
Proposal - Thomas Beale / Ian McNicoll
Under development
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:
The value properties from ELEMENT are moved to ITEM.
The following shows the adjusted CLUSTER/ELEMENT part of the model.
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 |
|
xxx
Proposal - Thomas Beale
Under development
The design integrates Candidate A (ITEM_STRUCTURE becomes a child of CLUSTER) and A.2 (ELEMENT.value & null_flavour move to ITEM). The effects of this should be as follows:
The following shows the result.
Proposal - Thomas Beale
Under development
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.
In addition to Candidate A.3 changes:
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:
The following shows the result.
Proposal - Pablo Pazos
under construction
I have the source of this diagram if anyone wants it, it's a .dia file (http://live.gnome.org/Dia)
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 |
Proposal - Erik Sundvall
Now updated to include the suggested "Candidate A.2" ITEM/CLUSTER/ELEMENT change.
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
See comments in diagram.
'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|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]
|
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 |
|
xxx