Difference between revisions of "CIMI RM Patterns"

From CIMI
Jump to: navigation, search
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
This page is for recording notes about CIMI RM patterns. The original 'Technical Architecture' page containing early discussions is [[TechnicalArchitecture|here]], including an original table of RM patterns.
 
This page is for recording notes about CIMI RM patterns. The original 'Technical Architecture' page containing early discussions is [[TechnicalArchitecture|here]], including an original table of RM patterns.
  
A version of this table is shown below.
+
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.
  
  
Line 9: Line 12:
 
| Primitives ||  ||  ||   
 
| Primitives ||  ||  ||   
 
|-  
 
|-  
|  ||  Data types ||  openEHR DTs[http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/data_types_im.pdf]; <br/>ISO 21090 Data Types; <br/>HL7 FHIR[http://www.hl7.org/implement/standards/fhir/datatypes.htm] ||  Generalised data types for key atomic data representation, including text, coded text, quantity, dates & times, etc
+
|  ||  Data types ||  '''openEHR''': spec[http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/data_types_im.pdf]; UML[http://www.openehr.org/wiki/download/attachments/31981596/openEHR_102_DT_class_diag.png?version=1&modificationDate=1332320097000]<br/>'''ISO 21090 Data Types''' <br/>'''HL7 FHIR'''[http://www.hl7.org/implement/standards/fhir/datatypes.htm] ||  Generalised data types for key atomic data representation, including text, coded text, quantity, dates & times, etc
 
|-
 
|-
|  ||  Key concept + qualifiers + modifiers ||  Intermountain Healthcare CEMs[http://informatics.mayo.edu/sharp/index.php?title=File:CEReference20081114.pdf&limit=20] ||  Method of referencing terminology concept and adding context-specific information
+
|  ||  Key concept + qualifiers + modifiers ||  Inter-mountain Healthcare CEMs[http://informatics.mayo.edu/sharp/index.php?title=File:CEReference20081114.pdf&limit=20] ||  Method of referencing terminology concept and adding context-specific information
|-
+
|  ||  data / state / qualifier || openEHR Entry pattern: spec[http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/ehr_im.pdf]; FAQ[http://www.openehr.org/wiki/display/resources/openEHR+ENTRY+Types+FAQs]; UML [http://www.openehr.org/wiki/download/attachments/196630/openehr_entry_uml.jpg?version=1&modificationDate=1193397393000] <br/>DCM2010 ISO13972 ||  In observation data, separate out data, patient state and qualifiers
+
 
|-
 
|-
 
| Structure ||  ||  ||  
 
| Structure ||  ||  ||  
 
|-
 
|-
|  ||  Tree structure ||  Generalised free-form tree for containing clusters of data items, e.g. the 5+1 Apgar items, numerous microbiology result items, etc. ||  openEHR RM, 13606 RM, HL7 (all)
+
|  ||  Tree structure || '''openEHR''': spec[http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/data_structures_im.pdf]; UML[http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109581075362_259917_1445Report.html], [http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109346709572_859750_3810Report.html] <br/>'''ISO 13606''': RM<br/> '''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 ||  ||  ||  
 
| Actors ||  ||  ||  
 
|-
 
|-
|  || Participation ||  A pattern defining the connection between parties (people, organisations, devices) and other information. ||  HL7 (all), openEHR, 13606
+
|  || Participation ||  '''HL7''': <br/>'''openEHR''': spec[http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/common_im.pdf]; UML[http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140169202660_257304_813Report.html] <br/> ISO 13606  || A pattern defining the connection between parties (people, organisations, devices) and other information.
 
|-
 
|-
|  ||  Party + role + accountability ||   A pattern defining relationships between parties, including those that are roles played by some underlying actor. ||  HL7 RIM, openEHR
+
|  ||  Party + role + accountability || '''HL7''': RIM<br/>'''openEHR''' demographics: spec[]; UML[http://www.openehr.org/wiki/download/attachments/31981596/openEHR_102_demographic.png?version=1&modificationDate=1333208220000] ||  A pattern defining relationships between parties, including those that are roles played by some underlying actor.
 
|-
 
|-
 
| Clinical process ||  ||  ||   
 
| Clinical process ||  ||  ||   
 
|-
 
|-
|  ||  History of events ||  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; used in Observation type ||  openEHR RM
+
|  ||  History of events || '''openEHR''': spec[http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/data_structures_im.pdf]; UML[http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109157527311_729550_7234Report.html]  ||  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 ||  Distinguish key Entry types based on clinical / scientific problem solving process, including Observation, Evaluation, Instruction (order), Action, Admin entry, Generic (any content) entry ||  CIR
+
|  ||  Entry / clinical statement types || '''openEHR''': [[media:MedInfo2007-BealeHeard.pdf‎|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
 
|-
 
|-
|  ||  Observation: (Classifiers?) data / state / protocol (/reasoning) ||  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) ||  openEHR RM
+
|  ||  Entry: data / state / protocol (/reasoning) ||  '''openEHR''': Entry classes spec[http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/ehr_im.pdf]; FAQ[http://www.openehr.org/wiki/display/resources/openEHR+ENTRY+Types+FAQs]; UML [http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html] || 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 ||  ||  ||  
 
| Workflow ||  ||  ||  
 
|-
 
|-
|  ||  Order state machine + careflow mapping ||  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 ||  openEHR RM, HL7 RIM
+
|  ||  Order state machine + careflow mapping || '''openEHR''': spec[http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/ehr_im.pdf]; UML[http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109249648736_872559_12384Report.html]; state machine[http://www.openehr.org/325-OE/version/default/part/ImageData/data/openehr_state_machine.png]<br/>'''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 ||  A pattern for representing temporal links between related events in a clinical process ||  HL7 RIM Act Rel, openEHR / 13606 LINKs
+
|  ||  Clinical process event links || '''HL7''': RIM Act Relationship<br/>'''openEHR''': LINK class spec[http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/common_im.pdf]; UML[http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109318114715_211173_0Report.html]<br/> ||  A pattern for representing temporal links between related events in a clinical process  
 
|-
 
|-
 
| EHR ||  ||  ||   
 
| EHR ||  ||  ||   
 
|-
 
|-
|  ||  Composition / document ||   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. ||  openEHR, 13606, CDA
+
|  ||  Composition / document || '''openEHR''': spec[http://www.openehr.org/svn/specification/TRUNK/publishing/architecture/rm/ehr_im.pdf]; UML[http://www.openehr.org/uml/release-1.0.1/Browsable/_9_0_76d0249_1109090397344_693008_8499Report.html] <br/>'''ISO 13606''': <br/> '''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.
 
|}
 
|}

Latest revision as of 10:41, 30 July 2012

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.