...
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 - simplification and class renaming for easier explanation and implementation
Proposal - Erik Sundvall
Status
under constructionNow updated to include the suggested "Candidate A.2" ITEM/CLUSTER/ELEMENT change.
Design Concept
Due to archetyping the model is actually allowed to be simpler than the 1.0.2 spec is without losing 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
...
(TODO: find links to more threads in mail-archive)
ChangesChanges
See comments in diagram.
Diagram
'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.
| 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}]^[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]
|
...