CIMI RM Patterns

Jump to: navigation, search

This page is for recording notes about CIMI RM patterns. The original 'Technical Architecture' page containing early discussions is here, including an original table of RM patterns.

A version of this table is shown below. The intention here is to describe candidate RM patterns described / provided by various CIMI participants. The table works as follows:

  • one row per distinct pattern, from whatever source. Common patterns whose concrete details are different should be one row, since the design intention is the same (e.g. 'hierarchy'), but if you think your pattern is distinct at an abstract level from another similar one, make a separate row;
  • The 'original description' column should include references to the original description material. If none is available online, it may make sense for the propopent of that pattern to put up a dedicated wiki page and point to that.
  • The 'CIMI description' column indicates the description that CIMI agrees on for this pattern. This implies that CIMI has agreed that the pattern is relevant, and what it means. NB: the current descriptions are placeholders from the original draft version of this page on CollabNet.

Data types openEHR: spec[1]; UML[2]
ISO 21090 Data Types
Generalised data types for key atomic data representation, including text, coded text, quantity, dates & times, etc
Key concept + qualifiers + modifiers Inter-mountain Healthcare CEMs[4] Method of referencing terminology concept and adding context-specific information
Tree structure openEHR: spec[5]; UML[6], [7]
ISO 13606: RM
Generalised free-form tree for containing clusters of data items, e.g. the 5+1 Apgar items, numerous microbiology result items, etc.
Participation HL7:
openEHR: spec[8]; UML[9]
ISO 13606
A pattern defining the connection between parties (people, organisations, devices) and other information.
Party + role + accountability HL7: RIM
openEHR demographics: spec[]; UML[10]
A pattern defining relationships between parties, including those that are roles played by some underlying actor.
Clinical process
History of events openEHR: spec[11]; UML[12] A structure containing 1..* Events, allowing data and patient state at each one, supporting intervals, point events, and math functions, e.g. ave/delta/max/min
Entry / clinical statement types openEHR: Beale Heard 2007 Medinfo paper Distinguish key Entry types based on clinical / scientific problem solving process, including Observation, Evaluation, Instruction (order), Action, Admin entry, Generic (any content) entry
Entry: data / state / protocol (/reasoning) openEHR: Entry classes spec[13]; FAQ[14]; UML [15] In observation data, separate out data (actual datum being recorded e.g. BP) from patient state (e.g. lying, standing) and protocol (cuff type, instrument type)
Order state machine + careflow mapping openEHR: spec[16]; UML[17]; state machine[18]
A way of recording current state in progression through a standard state machine applying to any ‘order’, and mapping any specific careflow step to a standard state machine transition, enabling standardised querying
Clinical process event links HL7: RIM Act Relationship
openEHR: LINK class spec[19]; UML[20]
A pattern for representing temporal links between related events in a clinical process
Composition / document openEHR: spec[21]; UML[22]
ISO 13606:
An aggregation concept acting as a ‘bucket’ for information recorded by a professional at a given time for a given subject of care, supporting audit & context meta-data.