CIMI Modelling Taskforce Progress Report Dr Linda Bird, IHTSDO Implementation Specialist.
CIMI Reference Model Taskforce Report
description
Transcript of CIMI Reference Model Taskforce Report
CIMI Reference Model Taskforce Report
Dr Linda Bird10th May 2012
Agenda
• Mission & Charter• Members & Guests• Definition• Architectural Framework• May Deliverables• Requirements• Starting Point• Change List & Exclusions• Proposed CIMI Reference Model• Gap Analysis• Recommendations• Isosemantic Models• Clinical Modelling Layers
Mission & Charter
To define a candidate CIMI reference model
• Define a set of requirements for the CIMI reference model• Define or choose a candidate CIMI reference model• Work with the Clinical Modeling taskforce to test the
candidate reference model in the development of a set of initial clinical information models
• Compare the candidate CIMI reference model with the requirements to identify gaps
• Present the results at the face-to-face meeting in May
Members & Guests
Members• Linda Bird (Chair) – Ministry of Health Holdings, Singapore• Michael van der Zel – Results4Care & LifeLines• Gerard Freriks, EN13606 Association• Josh Mandel, SMArt• Thomas Beale – Ocean Informatics• Stan Huff, Intermountain Healthcare• Richard Kavanagh – NHS Connecting for Health• Galen Mulrooney, ONC, U.S.A.• Grahame Grieve – Health IntersectionsGuests• Cecil Lynch• Ian Townend• Dipak Kalra
Definition
The CIMI Reference Model is the underlying Reference Model on which CIMI’s clinical models will be defined.
This reference model defines a rigorous and stable set of modelling patterns, including a set of structural patterns, complex data types and demographic
classes.
All CIMI clinical models (i.e. archetypes) will be defined by constraining the CIMI reference model.
Each example instance of a CIMI Clinical Model will be an instance of the CIMI reference model, which conforms to the constraints defined by the associated
clinical model.
Architectural Framework
May Deliverables
• A set of requirements for the CIMI reference model;• One or more UML class diagrams, which together represent the
candidate CIMI reference model (and supporting material);• An implementation of the candidate CIMI reference model that
enables a set of initial Clinical Models to be created based on this reference model1 (preferably using ADL);
• A report identifying the gaps between the proposed CIMI reference model and the requirements; and
• A summary of the results and recommendations for the CIMI Reference Model pending CIMI approval.
1: Please note that this implementation may either be as simple as an appropriately formatted spreadsheet, or may involve a tool that is specifically designed for authoring clinical models against a given reference model – depending on the time and resources available.
11 meetings from 23rd February – 3rd May 2012
CIMI RM taskforce website
Requirements - Overview
• General (Technical / Governance)• Structural• Information Pattern• Terminology Binding• Data Type
Requirements – General
• General Technical‒ Support for architectural framework‒ Multiple purpose & outputs‒ Realm-specific specialisations & extensions (*)‒ Move clinically-relevant attributes to clinical patterns‒ Model mapping & query support (*)‒ Versioning & Approval status (*)‒ Stability
• General governance‒ Governance, cost and licensing‒ Clinician verification (*)‒ Inter-organisation semantic interoperability
Requirements – Structural & Information Patterns
• Structural‒ Data elements‒ Relationships / Links‒ Data groups‒ Tree structure‒ Entry / Clinical statement‒ Composition‒ Data absent
• Information Pattern‒ Concept model‒ Participation‒ Parties and roles
Requirements – Terminology Binding & Datatype
• Terminology Binding‒ Semantic / Value / Name binding (*)‒ Relationship semantics (*)‒ Concept model terminology definition (*)‒ Translations
• Datatype‒ Common datatypes‒ Datatype constraints & mappings‒ Inheritance from single type‒ Primitive & string-based datatypes‒ Complex datatypes
• Attachment, Ordinal, Codeable concept, Coding, Identifier, Interval, Quantity, Ratio
Starting Point - Options
Options• A profile, simplification or improvement of ISO13606-1• openEHR reference model• openEHR / ISO13606-1 model• DCM reference model (ISO13972-based)• EN13606 Association proposal
Other models, whose features were considered• Parts of Intermountain Healthcare’s Clinical Element Model• Federal Healthcare Information Model (US Gov FHIM• Logical Record Architecture (NHS LRA)
• Ability to meet requirements– including capturing required information patterns, and semantics
• Demonstrable computability, implementability and transformability (e.g. to ISO13606, openEHR, DCM, HL7 v2, v3, CDA)
• Existing tooling & infrastructure• Existing library of clinical models• Existing community (implementation and clinical)• IP considerations• Simplicity• Can support all use cases
Starting Point - Considerations
openEHR reference model selected as starting point by 6 of 9 members
Reasons• The range of existing archetypes, tooling, infrastructure, methodology and
documentation;• Established reference model tested by multiple authoring participants;• Can benefit from lessons learned by many implementations;• Able to start designing clinical models straight away;• Demonstrable use within a two-level modelling architecture;• Specification is freely available on the web to read and redistribute without
cost;• Willingness of the organisation to work with CIMI and make changes as
needed to meet CIMI’s needs
Concerns• Complexity of current model - a simplified model is preferred;• Need to bridge the gap between the model and the requirements;• Requires us to work together to simplify and improve• It is not a standard, and there are IP concerns relating to the specifications• Requires work to develop a UML-based profile and editing environment
Starting Point - Selection
Change List - openEHR RM v1.0.2
• Core CIMI reference model‒ Simpify item structure‒ Move ELEMENT.value and null_flavour to ITEM‒ Remove specialisations of ENTRY from model‒ Remove ENTRY.encoding and workflow_id‒ Remove EVENT_CONTEXT
• Datatypes‒ Remove “DV_” prefix from all datatypes‒ Make CODE_PHRASE concrete‒ Add CODE_PHRASE.terminology_version, term, term_id‒ Change datatype of QUANTITY.units to CODE_PHRASE‒ Remove MULTIMEDIA.compression_algorithm and
integrity_check_algorithm‒ Remove ENCAPSULATED.charset and language
• Demographics – no changes
Exclusions - openEHR RM v1.0.2 (1 of 2)
• Assumed types‒ Any, Hash, INTERVAL
• Common‒ FEEDER_AUDIT, FEEDER_AUDIT_DETAILS, CONTRIBUTION,
IMPORTED_VERSION, T, VERSION, VERSIONED_OBJECT, FOLDER, VERSIONED_FOLDER, ATTESTION, AUDIT_DETAILS, REVISION_HISTORY, REVISION_HISTORY_ITEM, AUTHORED_RESOURCE, RESOURCE_DESCRIPTION, RESOURCE_DESCRIPTION_ITEM, TRANSLATION_DETAILS
• Composition‒ EVENT_CONTEXT, ACTION, ACTIVITY, ADMIN_ENTRY, CARE_ENTRY,
EVALUATION, INSTRUCTION, INSTRUCTION_DETAILS, ISM_TRANSITION, OBSERVATION
• Data structures‒ EVENT, HISTORY, INTERVAL_EVENT and POINT_EVENT
Exclusions - openEHR RM v1.0.2 (2 of 2)
• Datatypes‒ DV_STATE, PROPORTION_KIND, REFERENCE_RANGE,
DV_PARAGRAPH, DV_GENERAL_TIME_SPECIFICATION, DV_PERIODIC_TIME_SPECIFICATION, DV_TIME_SPECIFICATION
• Demographics‒ VERSIONED_PARTY
• Ehr‒ EHR, EHR_ACCESS, EHR_STATUS, VERSIONED_COMPOSITION,
VERSIONED_EHR_ACCESS, VERSIONED_EHR_STATUS• Ehr_Extract
‒ EHR, EHR_ACCESS, EHR_STATUS, VERSIONED_COMPOSITION, VERSIONED_EHR_ACCESS, VERSIONED_EHR_STATUS
Proposed CIMI Reference Model - Core
• COMPOSITION (category, language, territory, composer, content)• CONTENT_ITEM
‒ SECTION (items)‒ ENTRY (subject, provider, other_participation, language, data)
• ITEM (null_flavour, value)‒ CLUSTER (structure_type, items)‒ ELEMENT
• DATA_VALUE
• PARTICIPATION (function, mode, time, performer)• LOCATABLE (name, uid, archetype_node_id, archetype_details, links)• LINK (meaning, target, type)• ARCHETYPED (archetype_id, template_id, rm_version
class CIMI Core Reference Model
COMPOSITION
+ category :CODED_TEXT+ language :CODE_PHRASE+ territory :CODE_PHRASE
CONTENT_ITEM
ENTRY
+ language :CODE_PHRASE
SECTION
ARCHETYPED
+ archetype_id :ARCHETYPE_ID+ template_id :TEMPLATE_ID [0..1]+ rm_version :String
LOCATABLE
+ name :TEXT+ uid :UID_BASED_ID [0..1]+ archetype_node_id :String
LINK
+ meaning :TEXT+ target :EHR_URI+ type :TEXT
ITEM
+ null_flavor :CODED_TEXT [0..1]
ELEMENTCLUSTER
+ structure_type :CODE_PHRASE [0..1]
DATA_VALUE
PARTICIPATION
+ function :TEXT+ mode :CODED_TEXT+ time :DATE_TIME [0..1]
PARTY_PROXY PARTY_SELF
PATHABLE
+items1..*
+participations *
+provider
0..1 +subject 1..1
+items
*..*+content
*..*
+data 1..*
1
+other_participation
0..*
+value
0..1
+performer
1..1
+archetype_details
0..1
+links
*..*
+composer
1..1
Proposed CIMI Reference Model - Core
Proposed CIMI Reference Model - Datatypes
• BOOLEAN• IDENTIFIER• URI• CODE_PHRASE• TEXT
‒ CODED_TEXT• ENCAPSULATED
‒ MULTIMEDIA, PARSABLE• INTERVAL• ORDINAL• AMOUNT
‒ COUNT, DURATION, PROPORTION, QUANTITY• TEMPORAL
‒ TIME, DATE, DATE_TIME
Proposed CIMI Reference Model - Datatypes class CIMI Datatypes
BOOLEAN
+ value :Boolean
DATA_VALUE
IDENTIFIER
+ id :String+ type :String+ assigner :String+ issuer :String
ENCAPSULATED
MULTIMEDIA
+ alternate_text :String [0..1]+ data :Byte [0..1]+ integri ty_check :Byte [0..1]+ media_type :CODE_PHRASE+ uri :URI [0..1]
PARSABLE
+ formalism :String+ value :String
COUNT
+ magnitude :Integer
QUANTITY
+ magnitude :Real+ units :CODE_PHRASE+ precision :Integer [0..1]
PROPORTION
+ numerator :Real+ denominator :Real+ precision :Integer [0..1]+ type :CODE_PHRASE
ORDINAL
+ symbol :CODED_TEXT+ value :Integer
ORDERED
+ normal_status :CODE_PHRASE [0..1]
QUANTIFIED
+ magnitude :DATA_VALUE+ magnitude_status :String [0..1]
AMOUNT
+ accuracy :Real [0..1]+ accuracy_is_percent :Boolean [0..1]
ABSOLUTE_QUANTITY
+ accuracy :AMOUNT [0..1]
DATE
+ value :String
TIME
+ value :String
DATE_TIME
+ value :String
DURATION TEMPORAL
TEXT
+ language :CODE_PHRASE [0..1]+ value :String
CODED_TEXT
URI
+ value :String
CODE_PHRASE
+ code_string :String+ terminology_id :TERMINOLOGY_ID+ terminology_version :String [0..1]+ term :String [0..1]+ term_id :String [0..1]
EHR_URI
ORDERED : Class
INTERVAL
TERM_MAPPING
+ match :Char+ purpose :CODED_TEXT [0..1]
+upper
0..1
#normal_range
0..1
+lower
0..1
+mappings0..*
+defining_code1..1
+target
1..1
+thumbnail 0..1
Proposed CIMI Reference Model – Supporting Class
• OBJECT_ID‒ TEMINOLOGY_ID‒ TEMPLATE_ID‒ ARCHETYPE_ID‒ UID_BASED_ID
o HIER_OBJECT_ID• LOCATABLE_REF• PART_REF
• PARTY_PROXY‒ PARTY_IDENTIFIED
o PARTY_RELATED‒ PARTY_SELF
Proposed CIMI Reference Model – Supporting Class
class CIMI Supporting Classes
OBJECT_ID
+ value :String
OBJECT_REF
+ id_namespace :String+ type :String
UID_BASED_ID
ARCHETYPE_IDTEMPLATE_ID
PARTY_REFLOCATABLE_REF
+ path :String [0..1]HIER_OBJECT_ID
TERMINOLOGY_ID
PARTY_PROXY
PARTY_SELF
PARTY_IDENTIFIED
+ identifiers :IDENTIFIER [0..1]+ name :String [0..1]
PARTY_RELATED
+ relationship :CODED_TEXT
+external_ref 0..1
+id
1..1
+id
1..1
Proposed CIMI Reference Model - Assumed
• Integer• Real• String• Boolean• Byte• Char
• UID‒ UUID‒ ISO_OID‒ INTERNET_ID
Proposed CIMI Reference Model - Assumed
class CIMI Assumed Types
UID
+ value :String
UUID ISO_OID INTERNET_ID
«dataType»String
«dataType»Boolean
«dataType»Integer
«dataType»Real
«dataType»Byte
«dataType»
Char
Gap Analyss
• Fully supports‒ Most requirements
• Requires further investigation‒ Realm-specific specialisations and extensions‒ Governance, cost and licensing‒ Inter-organisation Semantic Interoperability‒ Terminology Concept model‒ Relationship semantics‒ Data type mappings‒ Primitive data types (base64Binary)‒ String-based data types (code)
• Partially supports‒ No clinically-significant attributes or specialisations
Recommendations (1-4 of 11)
Recommendation 1: The proposed reference model is thoroughly tested using a representative set of clinical models that together demonstrate all aspects of the reference model;
Recommendation 2: A set of stable clinical patterns (e.g. OBSERVATION, EVALUATION, INSTRUCTION, ACTION, TIME_SERIES, SCHEDULE) are defined as archetypes, upon which more specific clinical models are based, within an agreed framework of ‘clinical model specialisation layers’.
Recommendation 3: The CIMI reference model is fully documented in a format that promotes effective understanding by both clinical modellers and implementers. This documentation should include both example models and example instance data;
Recommendation 4: A coherent modelling methodology is documented to ensure consistent models, including modelling style guides and best practice guidelines;
Recommendations (5-6 of 11)
Recommendation 5: The Archetype Object Model (and associated serialisations) is reviewed against requirements, and extended to fully express the semantic meaning of archetypes, (including the meaning of the relationship between nodes);
Recommendation 6: Further investigation is planned to consider issues, such as the following:
• The syntax and use of terminology bindings for both the meaning and valid values of nodes in the clinical models;
• The semantic meaning between all structural nodes;• The use of CLUSTER.value (including defining the meaning)• Whether null_flavour (or similar) should be allowed on ENTRY or
SECTION• Whether further simplifications can be made to the reference model (e.g.
demographics);• Modelling methodology to ensure consistency of models, including the
development of modelling style guides and best practices;
Recommendations (7-11 of 11)
Recommendation 7: The requirements of iso-semantic clinical models are explored further, in terms of both (a) the ability to transform CIMI models to/from iso-semantic representations in other languages/standards (e.g. CDA, openEHR, ISO13606, DCM, CEM), and (b) the ability to transform CIMI models between iso-semantic representations that use a different split between terminology pre-coordination and structure (Please refer to Appendix B).
Recommendation 8: Appropriate tooling is developed and/or adopted, which allows clinical models to be created and is capable of generating ADL 1.5.
Recommendation 9: Any relevant Intellectual Property issues relating to the CIMI reference model are addressed.
Recommendation 10: A UML Profile is developed, in collaboration with the OMG, which allows CIMI models to be created in UML.
Recommendation 11: The taskforces be reorganised to support the above activities
Recommendations (Summary)
1: Test Reference Model (using clinical models)
2: Define clinical patterns and modelling layers
3: Document (including examples)
4: Modelling style guide5: Review and extend AOM (e.g. node relationship meaning)
6: Further investigate outstanding issues (e.g. terminology binding)
7: Iso-semantic clinical models (transformation and terminology equivalence)
8: Tooling
9: Intellectual Property
10: UML Profile
11: Organise taskforces
Isosemantic Models
Linda Bird10th May 2012
IsoSemantic Models – Example of Problem
e.g. “Suspected Lung Cancer”
IsoSemantic Models – Example Instances
e.g. “Suspected Lung Cancer”
IsoSemantic Models – Hierarchy
ELEMENTName: Problem Diagnosis Name
Meaning: 404684003|Clinical finding|Parent-child-link: 246090004|Associated finding|
Value: ϵ ProbDiag_RefSet
CLUSTERName: Location Details
Meaning: 123037004|Body structure|Parent-child-link: 363698007|Finding site|
ELEMENTName: Body Site
Meaning: 123037004|Body structure|Parent-child-link: 363698007|Finding site|
Value: ϵ BodyStructure_RefSet
ELEMENTName: Laterality
Meaning: 182353008|Side|Parent-child-link: 272741003|Laterality|
Value: ϵ Side_RefSet
ELEMENTName: Severity
Meaning: 272141004|Severities|Parent-child-link: 246112005|Severity|
Value: ϵ Severity_RefSet
ELEMENTName: Finding Context
Meaning: 410514004|Finding context value|Parent-child-link: 408729009|Finding context|
Value: ϵ FindingContext_RefSet
CLUSTERName: Problem Diagnosis
Meaning: 243796009|Situation with explicit context|
CLUSTERName: Associated Problem Diagnosis
Meaning: 404684003|Clinical finding|Parent-child-link: 246090004|Associated finding|
IsoSemantic Models – Graph-based Model
246090004 |associated finding|
<<Cluster>>Problem Diagnosis
meaning: 243796009|Situation with explicit context|
<<Element>>Problem Diagnosis Name
meaning: 404684003|Clinical Finding| value: ϵ ProbDiag_RefSet
363698007 |finding site|
<<Cluster>>Location Details
meaning: 123037004|Body structure|
<<Element>>Body Site
meaning: 123037004|Body structure| value: ϵ BodyStructure_RefSet
363698007 |finding site|
<<Element>>Laterality
meaning: 182353008|Side| value: ϵ Side_RefSet
272741003|laterality|
<<Element>>Severity
meaning: 272141005|Severities| value: ϵ Severity_RefSet
246112005 |severity|
<<Element>>Finding Context
meaning: 410514004|Finding context value| value: ϵ FindingContext_RefSet
408729009 |finding context|
<<Navigational Cluster>>Associated Problem Diagnosis
meaning: 404684003|Clinical Finding|
246090004 |associated finding|
IsoSemantic Models – Compositional Grammar
Problem Diagnosis = 243796009 |situation with explicit context| :
246090004 |associated finding| =( $ProblemDiagnosisName : 363698007 | finding site | = ($BodySite:
272741003|laterality| = $Laterality), 246112005 | severity| = $Severity),
408729009 | finding context | = $FindingContextGP Problem Diagnosis = 243796009 |situation with explicit context| :
246090004 |associated finding| =(86049000|Cancer| : 363698007 | finding site | = 39607008|Lung |),
408729009 | finding context | = 415684004|Suspected|Polyclinic Problem Diagnosis = 243796009 |situation with explicit context| :
246090004 |associated finding| =(162572001 |Suspected cancer|:
363698007 | finding site | = 39607008|Lung|)RH Problem Diagnosis = 243796009 |situation with explicit context| :
246090004 |associated finding| = (86049000|Suspected lung cancer|)
Clinical Model Layers
Linda Bird10th May 2012
Clinical Modelling Layers - Ideas
Reference Model
Clinical Patterns e.g. Schedule e.g.
Observation e.g. List e.g. Event Summary
Clinical Models
e.g. Medication
Item
e.g. Blood Pressure
e.g. Medication
List
e.g. Discharge Summary
Context-Specific Clinical Models
e.g. Dispensed Medication
Item
e.g. Neonatal Blood
Pressure
e.g. Ceased Medication
List
e.g. Inpatient Discharge Summary
Use Case-Specific Clinical Models
e.g. Dispensed Medication
GUI
e.g. Neonatal Blood
Pressure GUI
e.g. Current Medication List in EHR
e.g. Inpatient Discharge Summary
Message/Doc
CLUSTER ENTRY SECTION COMPOSITN
ADL Workbench Editor Demonstration
Thomas Beale10th May 2012
Breakout Session 10:30 – 12:00
RM & CMTaskforces11th May 2012
10:30 – 12:00 pm• Core Reference Model• Datatypes Models• Demographics Model• Requirements Gap Analysis• Semantics/Terminology (e.g. Relationships b/w model elements)
1:00 – 3:00 pm• Isosemantic models and transformations to/from other specifications • Clinical Patterns, Modelling Layers and Modelling Style• Select an initial set of Clinical Models to test CIMI reference model• Modelling/Review process
1:00 – 3:00 pm• Continuation of agenda above• Collaboratively model and/or review specific clinical models• Next Steps
Breakout Agenda Summary
• Core Reference Model• Datatypes Models• Demographics Model• Requirements Gap Analysis• Semantics/Terminology
– including agreeing on method for defining semantics of relationships between model elements
Agenda (10:30 – 12:00 pm)
IsoSemantic Models – Example of Problem
e.g. “Suspected Lung Cancer”
IsoSemantic Models – Example Instances
e.g. “Suspected Lung Cancer”
IsoSemantic Models – Hierarchy
ELEMENTName: Problem Diagnosis Name
Meaning: 404684003|Clinical finding|Parent-child-link: 246090004|Associated finding|
Value: ϵ ProbDiag_RefSet
CLUSTERName: Location Details
Meaning: 123037004|Body structure|Parent-child-link: 363698007|Finding site|
ELEMENTName: Body Site
Meaning: 123037004|Body structure|Parent-child-link: 363698007|Finding site|
Value: ϵ BodyStructure_RefSet
ELEMENTName: Laterality
Meaning: 182353008|Side|Parent-child-link: 272741003|Laterality|
Value: ϵ Side_RefSet
ELEMENTName: Severity
Meaning: 272141004|Severities|Parent-child-link: 246112005|Severity|
Value: ϵ Severity_RefSet
ELEMENTName: Finding Context
Meaning: 410514004|Finding context value|Parent-child-link: 408729009|Finding context|
Value: ϵ FindingContext_RefSet
CLUSTERName: Problem Diagnosis
Meaning: 243796009|Situation with explicit context|
CLUSTERName: Associated Problem Diagnosis
Meaning: 404684003|Clinical finding|Parent-child-link: 246090004|Associated finding|
IsoSemantic Models – Graph-based Model
246090004 |associated finding|
<<Cluster>>Problem Diagnosis
meaning: 243796009|Situation with explicit context|
<<Element>>Problem Diagnosis Name
meaning: 404684003|Clinical Finding| value: ϵ ProbDiag_RefSet
363698007 |finding site|
<<Cluster>>Location Details
meaning: 123037004|Body structure|
<<Element>>Body Site
meaning: 123037004|Body structure| value: ϵ BodyStructure_RefSet
363698007 |finding site|
<<Element>>Laterality
meaning: 182353008|Side| value: ϵ Side_RefSet
272741003|laterality|
<<Element>>Severity
meaning: 272141005|Severities| value: ϵ Severity_RefSet
246112005 |severity|
<<Element>>Finding Context
meaning: 410514004|Finding context value| value: ϵ FindingContext_RefSet
408729009 |finding context|
<<Navigational Cluster>>Associated Problem Diagnosis
meaning: 404684003|Clinical Finding|
246090004 |associated finding|
IsoSemantic Models – Compositional Grammar
Problem Diagnosis = 243796009 |situation with explicit context| :
246090004 |associated finding| =( $ProblemDiagnosisName : 363698007 | finding site | = ($BodySite:
272741003|laterality| = $Laterality), 246112005 | severity| = $Severity),
408729009 | finding context | = $FindingContextGP Problem Diagnosis = 243796009 |situation with explicit context| :
246090004 |associated finding| =(86049000|Cancer| : 363698007 | finding site | = 39607008|Lung |),
408729009 | finding context | = 415684004|Suspected|Polyclinic Problem Diagnosis = 243796009 |situation with explicit context| :
246090004 |associated finding| =(162572001 |Suspected cancer|:
363698007 | finding site | = 39607008|Lung|)RH Problem Diagnosis = 243796009 |situation with explicit context| :
246090004 |associated finding| = (86049000|Suspected lung cancer|)
Breakout Session 1:00 – 3:00 pm
RM & CMTaskforces11th May 2012
• Isosemantic models and transformations to/from other specifications
• Clinical Patterns, Modelling Layers and Modelling Style• Select an initial set of Clinical Models to test CIMI
reference model• Modelling/Review process
Agenda (1:00 – 3:00 pm)
Clinical Modelling Layers - Ideas
Reference Model
Clinical Patterns e.g. Schedule e.g.
Observation e.g. List e.g. Event Summary
Clinical Models
e.g. Medication
Item
e.g. Blood Pressure
e.g. Medication
List
e.g. Discharge Summary
Context-Specific Clinical Models
e.g. Dispensed Medication
Item
e.g. Neonatal Blood
Pressure
e.g. Ceased Medication
List
e.g. Inpatient Discharge Summary
Use Case-Specific Clinical Models
e.g. Dispensed Medication
GUI
e.g. Neonatal Blood
Pressure GUI
e.g. Current Medication List in EHR
e.g. Inpatient Discharge Summary
Message/Doc
CLUSTER ENTRY SECTION COMPOSITN
Breakout Session 3:30 – 5:00 pm
RM & CMTaskforces11th May 2012
• Continuation of agenda above• Collaboratively model and/or review specific clinical
models• Next Steps
Agenda (3:30 – 5:00 pm)