CIMI RM Patterns

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.