This wiki has undergone a migration to Confluence found Here
CIMI RM Patterns
Jump to navigation
Jump to search
From Mayo CIMI Wiki
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.
CATEGORY | PATTERN | ORIGINAL DESCRIPTION(S) | CIMI DESCRIPTION |
---|---|---|---|
Primitives | |||
Data types | openEHR: spec[1]; UML[2] ISO 21090 Data Types HL7 FHIR[3] |
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 | |
Structure | |||
Tree structure | openEHR: spec[5]; UML[6], [7] ISO 13606: RM HL7: RIM |
Generalised free-form tree for containing clusters of data items, e.g. the 5+1 Apgar items, numerous microbiology result items, etc. | |
Actors | |||
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) | |
Workflow | |||
Order state machine + careflow mapping | openEHR: spec[16]; UML[17]; state machine[18] HL7: RIM |
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 | |
EHR | |||
Composition / document | openEHR: spec[21]; UML[22] ISO 13606: HL7 CDA: |
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. |