Transcript Document

EHR System Function and Information Model
(EHR-S FIM) Release 2.1
HL7 Project ID# 688
Executive Summary for
EHR-S FIM Immunization Capability Prototype
[email protected] , EHR WG Modeling Facilitator
[email protected] , DoD-MHS Proponent
February 9, 2012 – Original Working-Draft
March 15, 2012 – Last-Update to Working-Draft
Call for Participation
7/16/2015
This work is being done by the HL7 EHR Interoperability Work-group,
meeting every Tuesday at 2 PM ET, dial-in: 1-770-657-9270, Passcode: 510269#
The most current artifacts are at: http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
1
EHR System Function and Information Model
EHR-S FIM Vision
The EHR-S FIM vision is that analysts, engineers or testers
can efficiently compose and refine the architecture-andworkflow agnostic EHR-S FIM into logical-or-implementable
interoperability-specifications
for
system
acquisitions,
implementations or tests;
• for domain-and-realm specific EHR system capabilities,
components and their messages, documents and services;
• which are tailored to specific environments and needs.
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
2
PART 1: Executive Summary
For EHR-S FIM Release 2.1, this prototype has the purpose to
1) add conceptual information and data models for each EHR-S function
•
make the EHR-S FM easier to use for analysts and engineers
•
verify and validate EHR-S FM Release 2.0
2) Service Aware Interoperability Framework (SAIF) DSTU demonstration
3) Support specific profiles (e.g., DAMs, DIMs, DCMs).
The Sparx Enterprise Architect modeling tool is being used to represent the
EHR-S FIM and then generate appropriate views, reports, XML and HTML
renderings of each EHR-S function’s scenarios, requirements, actors,
actions/activities, dependencies, business rules, information & data models.
The DoD-VA Joint Immunization Capability (JIC), Pharm.-Lab.-Rad, than ISO
13940 Continuity-of-Care System-of Concepts-and-Glossary harmonization are
proposed as a set of demonstration prototypes of increasing complexity.
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
3
Notional Set of Artifacts within an HL7 SAIF
Enterprise Compliance and Conformance Framework (ECCF)
ECCF
Conceptual
Perspective
Logical
Perspective
Implementable
Perspective
Enterprise
Dimension
“Why” - Policy
 Business
• Mission,
• Vision,
• Scope ,
 Inventory of
• Applicable Laws
• Contracts
• Policies
• Procedures
• Enterprise
Capabilities
 Business Policies
 Governance
 Implementation Guides
 Design Constraints
 Organization Contracts
 Business Nodes
 Business Rules
 Business Procedures
 Business Workflows
 Technology Specific
Standards
Information
Dimension
Computational
Dimension
Engineering
Dimension
Technical
Dimension
“What” - Content
“Who/How” - Behavior
“Where” - Implementation
“Where” - Deployments
 Inventory of Reusable
• Entities
• Associations
• Information
 Information Models
• Dependencies
• Associations
 Data Models
• Data Dictionary
• Mandatory or Optional
 Inventory of Reusable
• Scenario Events
• Business Activities
• System Functions
 Requirements
• Accountability, Roles
• Conformance Criteria
• Profiles, Behaviors
• Interactions and
• Info. Exchanges
 Requirements Traceability
 Inventory of
• SW Platforms, Layers
• SW Environments
• SW Components
• SW Services
• Technical
Requirements
• Enterprise Service Bus
 Key Performance
Parameters
 Inventory of
• HW Platforms
• HW Environments
• Network Devices
• Communication
Devices
 Technical Requirements
 Specifications
• Scenario & Use Cases
• Components
Interfaces
 Collaboration Actors
• Collaboration Types
• Collaboration Roles
 Function Types
 Interface Types
 Service Contracts
 Models, Capabilities,
Features and Versions for
• SW Environments
• SW Capabilities
• SW Libraries
• SW Services
• SW Transports
 Models, Capabilities,
Features and Versions for
• HW Platforms
• HW Environments
• Network Devices
• Communication
Devices
 Automation Units
 Technical Interfaces
 Technical Operations
 Orchestration Scripts
 SW Specifications for
• Applications
• GUIs
• Components
 SW Deployment
Topologies
 HW Deployment
Specifications
 HW Execution Context
 HW Application Bindings
 HW Deployment Topology
 HW Platform Bindings
 Information Models
• Domain IM
• Detailed Clinical
 Terminology binding
 Value Set binding
 Content Specifications
• CCD
• RMIM
 Schemas for
• Databases
• Messages
• Documents
• Services
• Transformations
Responsibility: Sponsoring Organization | EHR-S FIM | Work Groups / Projects | Vender / Development Organization
7/16/2015
See notes page for ECCF description
4
EHR-FIM
Model Legend
NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!
class Legend
Clinician Activities
Dependency is a model-element relationship between a Dependent-Client ---> I ndependent-Supplier (e.g. sales cart --> product producer, client sends a message to
a supplier). A Dependency is NOT a run-time relationship ... the arrow representing a dependency specifies the direction of the relationship, NOT the direction of a process.
Business Activity Corresponding to EHR-S Function
control
flow
Task 1 within
Activity
Start Activity
EHR-S Component
Encounter
Capitalized Attribute or Operation
implies that it is implemented by
an external entity.
Attribute 1
Data Structure
Task 2 within
Activity
EHR-S Component ::
Syatem Component 3
EHR-S Component ::
System Component 1
-
control
flow
End Activity
-
EHR-S Component ::
System Component 4
Attribute 1
has-a (part)
aggregation
«SHALL»
+ attribute 2
implements
EHR-S Functions and Requirements
Task 4 within
Activity
depends on
operation # xx()
association
«SHALL»
+ operation # yy()
7/16/2015
Task 3 within
Activity
is-a (type)
generalization
EHR-S Component ::
System Component 2
EHR-S Function depends-on a Business Activity (e.g., Without a business requirement, the function would not exist.).
FEATURE:
EHR-S Function
depends-on
FEATURE 2:
EHR-S Function
requirement-for
<<SHALL>> REQUIREMENT
Conformance Criteria # 05
requirement-for
requirement-for
<<SHALL>> REQUIREMENT:
Conformance Criteria (CC) # xx
<<SHOULD or MAY>> REQUIREMENT
Conformance Criteria # yy
DRAFT WORKING DOCUMENT
5
Information Model Types
• Conceptual Models are typically human readable though there are ways to build conceptual
models that systems can process, such as, the Web Ontology Language (OWL).
• A Conceptual Information Model identifies the highest-level concepts in a domain (e.g.,
EHR) and their relationships; however, no attributes are specified.
• A Conceptual Data Model (CDMs) specifies data entities and their data elements, without
regard to how they will be physically implemented.
• Sub-domain and realm-specific CDMs (profiles) typically include the following:
– All concepts and their relationships are defined.
– All attributes for each concept are specified
• date element optionality (e.g., MAY or SHOULD) is removed.
– Business terms for concepts and attributes are agreed upon and used. (These terms should be part of the
agreed upon common terminology, which may vary by domain-and-realm.)
– Primary keys (keys identifying specific entities within a class) for concepts may be specified.
– Foreign keys (keys identifying the relationship between different entities) among concepts may be specified.
– Normalization, based on reusable components, may occur.
– Terminology (code and value sets) binding may occur.
• Logical Data Models are fully-qualified to be transformed into deterministic and testable
physical schema for a specific implementation.
7/16/2015
NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!
6
EHR-FIM
Description of Model Diagrams
“System-Components Dependent-on Clinician-Activities” shows
• Row 1: operational activities performed by the clinician, indicating dependencies on
• Row 2: The EHR System components, which support the clinician’s activities.
“Immunization Management Traceability” shows
•
Components Dependent-on EHR-S Functions Dependent-0n Clinician-Activities
“Conceptual Data Model (CDM)” shows
• Attributes & operations for System Components.
• Conformance Criteria requiring specific attributes and operations within a Component
“Information Exchanges Defined-by Conformance Criteria (CC)” shows
• Conformance Criteria requiring specific information exchanges
CIM is Conceptual Information Model
CDM is Conceptual Data Model
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
7
Methodology
Sparx Enterprise Architect views were used to create a separate slide set for an
Immunization Management Capability based on CP.6.2 Manage Immunization
Administration and its “See Also” Dependencies :
1.
Create Activity Model for the function, based on conformance criteria.
•
2.
Map Activities to EHR-S Components
Create Conceptual Data Model (CDM) view from step 1.
•
•
•
Start with applicable reusable components and their data elements
Based on Conformance Criteria, add additional function-specific components
Based on Conformance Criteria, add additional attributes or operations
–
–
–
3.
Create Conceptual Information Model (CIM) view from step 2.
•
•
4.
Bold SHALL conformance criteria to expedite test traceability
Indicate SHALL attributes or operations as “public” with a proceeding “+”
Indicate SHOULD or MAY attributes or operations as “private” with a proceeding “-”
Show supporting EHR-S Function associations and dependencies.
Map EHR-S Components to supporting EHR-S Functions (“See Also” Dependencies)
Show Conformance Criteria (CC) Requiring Specific Information Exchanges
This Executive Summary was created from the resultant model.
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
8
Observation
Where is the Patient?
• Healthcare is patient-centric; but, EHR-S FIM is
system-centric; consequently, EHR-S FIM does not
reflect patients and their healthcare interactions.
• EHR system is modeled as a repository for
encounters; (patient) encounters are composed
of events and associated (clinical) information;
events can be composed into lists; lists can be
composed into documents. Each of the above
concepts can be specified as types (e.g., problem
vs. medication list) and linked.
7/16/2015
DRAFT WORKING DOCUMENT
9
Issues
1.
2.
How do we harmonize with ISO 13940 … synonyms (clinician vs. Health care professional)?
What is normative within the EHR-S Information Model.
– Activity Diagrams map operational-activities to system components-and-functions.
• Recommend informative
– Conceptual Information Models
• set of applicable components and their relationships …
• Recommend informative
– Conceptual Data Models ( attributes and operations within components)
3.
4.
5.
• Recommend normative
• Distinguish between elements derived from SHALLs vs. those from SHOULDs and MAYs
• Remove data element conformance criteria from EHR-S Functional Model
How do we incorporate:
Quality Measures/ Model
Meaningful-use measures
Patient outcome measures
–
–
–
Criteria to automatically determine the “See Also” Dependencies from models.
– EHR-S Function dependency on other Functions’ conformance criteria
– Shared activities & tasks within multiple EHR-S Functions
How will we represent the Information Models for Ballot.
–
–
7/16/2015
Tool generated report showing model views (e.g., similar to Immunization Prototype)
•
•
Benefit: maximum completeness and consistency
Will ISO accept graphics?
•
•
HITSP/C83 CDA Content Modules and
HITSP/C154 Data Dictionary
Textural listing of components and data elements similar to
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
10
Recommendations
Based on Immunization Management Prototype
• Add the following functions and components to EHR-S FIM :
1.
2.
3.
4.
5.
Business Rules
Clinical Decision Support (CDS)
Metadata for realm-specific Information-Exchange Standards
Manage Patient Consents
Add Dependency link to CP.8 Manage Patient Education & Communication
• Make EHR-S Conceptual Data Model (CDM) Normative
1.
Remove data elements from Functions’ Conformance Criteria.
• Organize EHR-S FM CP-section hierarchically.
1.
2.
3.
4.
an EHR-S manages Encounters; where,
each Encounter is a set of Events, Documents and Lists.
Events, Documents and Lists are decomposed into types (immunization, medication).
Benefits:
•
•
7/16/2015
Reduced Conformance Criteria duplication
Increased Conformance Criteria consistency
NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!
11
Conclusions
• EHR-S FIM can be the conceptual foundation for Interoperability
Specifications, refined into:
– HL7 Domain analysis Models (DAMs) and Detailed Clinical Models (DCL)
– Logical Perspectives
– Implementable Perspectives (Physical or Serialiazable Models)
• Messages, Documents, Services
• EHR-S FIM can populate portions of the HL7 SAIF for WGs
– Information and Computational Dimensions
– Conceptual Perspective
• EHR-S FIM can be composed into higher level capabilities by functional
analysts and system engineers
– Encourage reuse of EHR-S FIM components
– Avoid duplication and “stovepipe applications”
• An Enterprise Architecture tool is essential to maintain consistency
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
12
To Do … Help Needed
• SMEs verify and validate Conceptual Data Models (CDMs)
– Conformance criteria vs. component operations-and-attributes
– Create Data Dictionary of CDM Components and attributes
• EHR-S FIM Data Dictionary for components & attributes (similar to HITSP C83, C154).
• Start with ISO 13940 Continuity-of-Care System-of-Concepts and Glossary
• Add Metadata for Terminology Binding
• Harmonize Conceptual Data Models (CDMs) with
–
–
–
–
–
HL7 Reference Information Model (RIM)
US Federal Health Information Model (FHIM)
ISO 13940 Continuity-of-Care System-of Concepts-and-Glossary.
HL7 PHER Immunization Domain Analysis Model (DAM)
HL7 Patient Care & IHTSDO-CIMI Immunization Detailed Clinical Models (DCMs)
• Allergies Intolerance project.
• Care Plan project
• Model the remaining EHR-S Functions
–
–
–
–
–
–
–
Overarching (O) – 2 major subsections
Care Provision (CP) – 9 major subsections
Care Provision Support (CPS) – 9 major subsections
Population Health Support (POP) – 10 major subsections
Administrative Support (AS) – 9 major subsections
Record Infrastructure (RI) – 3 major subsections
Trust Infrastructure (TI) – 9 major subsections
Call for Participation
7/16/2015
This work is being done by the HL7 EHR Interoperability Work-group,
meeting every Tuesday at 2 PM ET, dial-in: 1-770-657-9270, Passcode: 510269#
The most current artifacts are at: http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
13
PART 2: Immunization Management Capability
Specified by EHR-S FIM
CP.6.2 Manage Immunization Administration, depends on
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List
CP.1.3 Manage Medication List
CP.1.6 Manage Immunization List
CP.3.3 Manage Clinical Documents and Notes
CPS.1.7.2 Manage Patient Advance Directives
CPS.3.9 Clinical Decision Support System Guidelines Updates
CPS.9.4 Standard Report Generation
AS.4.1 Manage Registry Communication
Record Infrastructure
Trust Infrastructure
For details, see separate slide deck for each EHR-S Function.
All referenced EHR-S Functions are available at:
http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
14
EHR-S FM Release 2.0
Contents
•
•
•
•
•
•
•
Overarching (O) – 2 major subsections
Care Provision (CP) - 9 major subsections
Care Provision Support (CPS) – 9 major subsections
Population Health Support (POP) – 10 major subsections
Administrative Support (AS) – 9 major subsections
Record Infrastructure (RI) – 3 major subsections
Trust Infrastructure (TI) – 9 major subsections
EHR-S FM R2 ballot package can be downloaded at:
http://wiki.hl7.org/index.php?title=December_2011_Ballot_Package
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
15
CP.6.2 Immunization Management
“See Also” Dependencies (3 Levels)
class CP.6.2 DEP-2 Manage Immunization Administration
CP, CPS & AS
POP.8 De-Identified Data
Request Management
POP.4 Support for
Monitoring Response
Notifications Regarding a
Specific Patient’s Health
depends on
CPS.4.2 Support for
Medication and Immunization
Ordering
POP.6 Measurement,
Analysis, Research and
Reports
CPS.3.9 Clinical Decision
Support System Guidelines
Updates
CPS.9.5 Ad Hoc Query and
Rendering
CPS.1.7.3 Manage
Consents and Authorizations
CP.3.1 Conduct
Assessments
CPS.7.1 Access Healthcare
Guidance
CPS.9.4 Standard Report
Generation
CP.3.3 Manage Clinical
Documents and Notes
CPS.1.6.1 Related by
Genealogy
CPS.1.6.3 Related by Living
Situation
CP.1.8 Manage Patient and
Family Preferences
CPS.9.3 Health Record
Output
depends on
CP.1.3 Manage
Medication List
CP.1.2 Manage Allergy,
Intolerance and Adverse
Reaction List
Start Here 
CPS.1.7.2 Manage Patient
Advance Directives
CP.1.6 Manage
Immunization List
CPS.1.6.4 Related by Other
Means
depends on
CP.3.2 Manage Patient
Clinical Measurements
CP.6.2 Manage
Immunization Administration
depends on
AS.4.1 Manage Registry
Communication
depend on
Trust Infrastructure
Record Infrastructure
DRAFT WORKING DOCUMENT
7/16/2015
RED: delete, Blue: insert
16
CP.6.2 Manage Immunization Administration
Statement: Capture and maintain discrete data concerning immunizations given to a patient including date
administered, type, manufacturer, lot number, and any allergic or adverse reactions. Facilitate the
interaction with an immunization registry to allow maintenance of a patient’s immunization history.
Description: During an encounter, recommendations based on accepted immunization schedules are
presented to the provider. Allergen and adverse reaction histories are checked prior to giving the
immunization. If an immunization is administered, discrete data elements associated with the immunization
including date, type, manufacturer and lot number are recorded. Any new adverse or allergic reactions are
noted. If required, a report is made to the public health immunization registry or other organization (e.g.
military unit commander, refugee program leadership).
Example: (notional scenario based on conformance criteria) During an encounter, recommendations
based on accepted immunization schedules and previous adverse or allergic reactions are presented to
the clinician. If an immunization is administered, discrete data elements associated with the immunization
are recorded and any new adverse or allergic reactions are noted. Patient Immunization and demographic
information is harmonized-with and reported-to the appropriate public health immunization registries,
patients and organizations (e.g., PHRs, schools, other providers), according to scope of practice,
organizational policy and/or jurisdictional law.
7/16/2015
RED: Recommended deletion, Blue: Recommended Insertion
17
Immunization Management Capability
Resultant Models
1.
2.
CP.6.2 EHR-S Components Dependent-on Clinician-Activities
CP.6.2 Manage Immunization Administration Traceability
–
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Components Dependent-on EHR-S Functions; Dependent-0n Clinician-Activities
CIM for Immunization Management Capability
Information Exchanges Defined-by Conformance Criteria (CC)
CDM for Advanced Directive
CDM for Allergy, Intolerance and Adverse Reaction Event
CDM for Clinical Decision Support (CDS)
CDM for Clinical Document or Note
CDM for Event
CDM for List
CDM for Immunization Event
CC is Conformance Criteria
CDM for Report
CIM is Conceptual Information Model
CDM is Conceptual Data Model
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
18
CP.6.2 Manage Immunization Administration
EHR-S Components Dependent-on Clinician-Activities
act CP.6.2 ACT Manage Immunization Administration
NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!
Clinician Activities
Manage Records
depends on
Manage Business Rules
depends on
depends on
CP.6.2 Manage Immunization Administration
Manage
Schedules
Encounter
Start
Schedule
EHR-S Components
Manage Trusts
is-a
Event
is-a
Manage
Lists
Manage
Documents &
Notes
Clinical
Information
Terminology
List
Document or
Note
is-a
Immunization
Allergy,
Schedule
Intolerance and
Adverse
Reaction Event
7/16/2015
Manage
Terminology
Manage
Events
Immunization
Event
Advanced Directive Event
ia-a
Immunization
List
End
is-a
Registry
is-a
Registry (Public
Health
Immunization)
RED: Recommend deletion, Blue: Recommended Insertion
Clinical Document or Note
is-a
is-a
Advanced Directive
Report
Reminder or Alert
19
CP.6.2 Manage Immunization Administration Traceability
EHR-S Components Dependent-on Functions; Dependent-0n Clinician-Activities
act CP.6.2 ACT-3 Manage Immunization Administration
CP.6.2
Manage
Immunization
Administration
Manage
Business Rules
Terminology
Schedule
Clinical Information
Manage Records
Immunization Schedule
Record Infrastructure
Event
Manage Trusts
Trust Infrastructure
Manage
Terminology
CP.1.2 Manage Allergy, Intolerance and
Adverse Reaction List
Manage Events
Manage
Schedules
List
Document or Note
Clinical Document or Note
Allergy,
Intolerance and
Adverse
Reaction Event
Allergy,
Intolerance and
Adverse
Reaction List
CP.1.6 Manage Immunization List
Registry
CPS.9.4 Standard Report Generation
CPS.1.7.2 Manage Patient Advance Directives
Advanced
Directive
Advanced Directive Event
Manage Lists
CP.3.2 Manage Patient Clinical Measurements
Manage
Documents &
Notes
Registry (Public
Health
Immunization)
AS.4.1 Manage Registry Communication
CP.6.2 Manage Immunization Administration
Immunization Event
7/16/2015
RED: Recommend deletion, Blue: Recommended Insertion
Immunization List
Report
20
Immunization Management Capability
Conceptual Information Model (CIM)
class CIM Immunization Management Capability
NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!
Clinical and Clinical Support System Components
CDS-Clinical Decision Support
EHR-S
Registry
other EHR or
related systems
Medical Device
is-a
Registry (Public Health Immunization)
Terminology
Clinical Information
Encounter
has-a
1..*
has-a
Event
Immunization
Event
Medication
Event
List
0..*
is-a
is-a
is-a
is-a
is-a
Allergy,
Intolerance and
Adverse Reaction
Event
Immunization
Schedule
Immunization
Witheld Event
CDS
Update
Document or Note
ia-a
Allergy, Intolerance and
Adverse Reaction List
Problem List
Clinical
Document or
Note
Medication
List
is-a
Patients Requiring
Followup List
Immunization
History
Record Infrastructure
7/16/2015
is-a
is-a
Immunization
List
is-a
Advanced
Directive Event
0..*
has-a
Reminder or Alert
Template
is-a
Advanced
Directive
is-a
Report
Trust Infrastructure
RED: Recommend deletion, Blue: Recommended Insertion
21
Immunization Management Capability
Information Exchanges Defined-by Conformance Criteria (CC)
class IE-RT Immunization Management Capability
NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!
CDS-Clinical
Decision
Support
CPS.3.9#01
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck
for CC details at:
http://wiki.hl7.org/index.php?title=EHR_Interop
erability_WG
- maintain()
implemented by
Usage Enumeration
- SHALL
- SHOULD
- MAY
EHR-S StandardType
Enumeration
-
content
transport
information assurance
other
7/16/2015
AS.4.1#04
EHR-S Information-Exchange
Metadata
-
sourceSystem
recipientSystem
releventStandard
standardOrganization
standardVersion
standardType
standardRealm
Usage
rational
effectiveDate
possibleRisk
harmonizationIssue
implementationGuide
implementationGuideVersion
Medical Device
EHR-S
Demographic
Information
(structured)
- reminders or alerts
- Information Exchange Metadata
CP.3.3#07
+ manage()
+ Manage 'Do Not Recusitate"()
other EHR
or related
systems
Registry
-
clinical information
demographic information
organization (source)
patient
provider (source)
type
- manage()
is-a
AS.4.1#02
AS.4.1#05
AS.4.1#03
RED: Recommend deletion, Blue: Recommended Insertion
AS.4.1#01
Registry (Public
Health
Immunization)
22
Immunization Management Information Exchange
Conformance Criteria (CC) Applicable to Information Exchanges
• CP.3.3#07 The system SHOULD provide the ability to link encounters, orders, medical equipment,
prosthetic/orthotic devices, medications, and notes to one or more problems (Ref: CP.1.4 [Manage
Problem List] cc#9).
• CPS.3.9#01 The system SHALL provide the ability to maintain the clinical content or rules utilized to
generate clinical decision support reminders and alerts.
• AS.4.1#01 The system SHOULD provide the ability to exchange structured demographic and clinical
information with registries (e.g., local, disease-specific, notifiable, patient, provider, organization, or
health services registries).
• AS.4.1#02 The system MAY provide the ability to render and tag registry information as reviewed and
the information's related assessment of validity or applicability for clinical, financial or administrative
activities.
• AS.4.1#03 The system SHOULD provide the ability to maintain information received from registries
(e.g., local, disease-specific, notifiable, patient, provider, organization, or health services registries).
• AS.4.1#04 The system MAY provide the ability to receive structured demographic and clinical
information from registries.
• AS.4.1#05 The system SHOULD provide the ability to harmonize system information with registry
information.
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
23
Immunization Standards-based Interoperability
US Realm
Currently, several HL7 and other SDO standards apply to the
immunization use case, including messages (HL7 V2.31, V2.51
and V3) documents (V3 CDA), and services (IXS, RLUS, DSS, etc.).
Some, such as HL7 V2 and V3 messaging, and CDA/CCD models
including the IHE Immunization Content profile, are fairly
mature. There is a CDC Implementation Guide for Immunization
Data Transactions using HL7 Version 2.3.1 and Version 2.5.1.
However, the issue of achieving interoperability in an
environment of diverse standards remains. A key lesson of
Meaningful Use Stage I in the U.S. has been that mismatched
sender and receiver capabilities in some localities have inhibited
public health reporting objectives.
7/16/2015
DRAFT WORKING DOCUMENT
24
CDM for Advanced Directive
Conformance Criteria (CC) Applicable to this CDM
NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!
ass RT Advanced Directive
CPS.1.7.2#03
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
CP.3.3#09
CP.3.3#11
Document or
Note
CPS.1.7.2#02
Event
+
+
-
date (occurence)
time (occurence)
change justification
circumstances
clinical information
date (entry)
date (review)
description
duration
information reviewed
information source
information validator
location
mechanism
metadata
person-role
status
trigger
type
+ deactivate()
+ justify()
+ manage()
7/16/2015
CPS.1.7.2#08
CPS.1.7.2#07
CPS.1.7.2#01
CPS.1.7.2#06
implemented-by
authenticator
author
date
facility
patient
type
status
+
+
+
+
render()
capture()
update()
tag()
CP.6.2#06
CP.3.3#02
-
CP.3.3#14
CP.3.3#15
is-a
CP.3.3#17
Clinical Document or
Note
- disposition
- signature
- structured :boolean
date signed
name
relationship
time signed
DRAFT WORKING DOCUMENT
CP.3.3#04
CP.3.3#12
CP.3.3#01
CP.3.3#16
- manage()
+ render()
+ tag()
Advanced
Directive Author
-
CP.3.3#07
CP.3.3#08
Do Not Recusitate (DNR) Order
Durable Power of Attorney
Living Will
other
Preferred Interventions for Known Conditions
advanced directive captured :boolean
person completing AD
relationship to patient
circumstances (of receipt)
circumstances (of review)
date (received)
date (recinded)
Advanced
date (review)
Directive Review
date (signed/completed)
0..*
date (updated)
- circumstances
Review
0..* - date
type
- reviewer
CP.3.3#05
CP.3.3#03
Advanced Directive Type Enumeration
Advanced Directive Event
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
CP.6.2#02
CP.3.3#10
other EHR or
related systems
CPS.1.7.2#05
EHR-S
is-a
Advanced
Directive
CPS.2.4 Support Externally
Sourced Clinical Images
- reminders or alerts
- Information Exchange Metadata
CPS.1.7.2#04
+ manage()
+ Manage 'Do Not Recusitate"()
25
Advanced Directive
Conformance Criteria (CC) Applicable to this CDM
• CP.3.3#01 The system SHALL provide the ability to capture and render clinical documentation
(henceforth "documentation") including original, update by amendment in order to correct, and addenda.
• CPS.1.7.2#08 The system SHALL provide the ability to manage the date and/or time an advance
directives paper document was signed/completed.
• CP.3.3#02 The system SHALL provide the ability to capture free text documentation.
• CP.3.3#03 The system MAY present documentation templates (structured or free text) to facilitate
creating documentation.
• CP.3.3#04 The system SHALL provide the ability to present other existing documentation within the
patient's EHR while new creating documentation.
• CP.3.3#05 The system SHOULD provide the ability to link documentation for a specific patient with a
given event (e.g., office visit, phone communication, e-mail consult, lab result).
• CP.3.3#07 The system SHOULD provide the ability to link encounters, orders, medical equipment,
prosthetic/orthotic devices, medications, and notes to one or more problems (Ref: CP.1.4 [Manage
Problem List] cc#9).
• CP.3.3#08 The system SHALL provide the ability to update documentation prior to finalizing it.
• CP.3.3#09 The system SHALL provide the ability to tag a document or note as final.
• CP.3.3#10 The system SHALL provide the ability to render the author(s) and authenticator(s) of
documentation when the documentation is rendered.
• CP.3.3#11 The system SHALL provide the ability to render documents based on document metadata
(e.g., note type, date range, facility, author, authenticator and patient).
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
26
Advanced Directive
Conformance Criteria (CC) Applicable to this CDM
• CP.3.3#12 The system MAY provide the ability for providers to capture clinical documentation using
standard choices for disposition (e.g., reviewed and filed, recall patient, or future follow-up).
• CP.3.3#14 The system SHOULD provide the ability to render clinical documentation using an integrated
charting or documentation tool (e.g., notes, flow-sheets, radiology views, or laboratory views).
• CP.3.3#15 The system MAY provide the ability to capture clinical documentation using specialized
charting tools for patient-specific requirements (e.g., age - neonates, pediatrics, geriatrics; condition impaired renal function; medication).
• CP.3.3#16 The system SHOULD provide the ability to capture, maintain and render transition-of-care
related information.
• CP.3.3#17 The system SHOULD provide the ability to tag the status of clinical documentation (e.g.,
preliminary, final, signed).
• CP.6.2#02 The system MAY auto-populate the immunization administration record as a by-product of
verification of administering provider, patient, medication, dose, route and time according to scope of
practice, organizational policy and/or jurisdictiona
• CP.6.2#06 The system SHOULD provide the ability to link standard codes (e.g. NDC, LOINC, SNOMED
or CPT) with discrete data elements associated with an immunization.
7/16/2015
RED: Recommend
deletion,
Blue:DOCUMENT
Recommended Insertion
DRAFT
WORKING
27
Advanced Directive
Conformance Criteria (CC) Applicable to this CDM
• CPS.1.7.2#01 The system SHALL provide the ability to manage advance directive information including
the type of directive, relevant dates (e.g., received, reviewed, rescinded, updated), circumstances under
which the directives were received, and the ...
• CPS.1.7.2#02 The system SHALL render an indication that advance directive(s) have been captured.
• CPS.1.7.2#03 The system SHALL provide the ability to render the type of advance directives captured
for the patient (e.g., living will, durable power of attorney, preferred interventions for known conditions, or
the existence of a "Do Not Resuscitate" ...
• CPS.1.7.2#04 The system SHALL provide the ability to manage “Do Not Resuscitate” orders.
• CPS.1.7.2#05 The system SHOULD conform to function CPS.2.4 (Support Externally Sourced Clinical
Images) in order to capture scanned patient advance directive documents and/or “Do Not Resuscitate”
orders.
• CPS.1.7.2#06 The system SHALL provide the ability to manage the date and circumstances of the most
recent review of the advanced directives.
• CPS.1.7.2#07 The system SHALL provide the ability to manage the name and relationship of the
principal completing the advance directive for the patient.
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
28
CDM for Allergy, Intolerance and Adverse Reaction Event
Conformance Criteria (CC) Applicable to this CDM
class RT Allergy, I ntolerance and Adverse Reaction Event
NOTE: EHR-S FIM is NOT intended to imply an architecture or workflow!
Event
Clinical
I nformation
-
type
CP.6.2# 09
CP.1.2# 04
CP.1.2# 16
+
+
-
date (occurence)
time (occurence)
change justification
circumstances
clinical information
date (entry)
date (review)
description
duration
information reviewed
information source
information validator
location
mechanism
metadata
person-role
status
trigger
type
+
+
+
deactivate()
justify()
manage()
CP.1.2# 17
CP.1.2# 19
CP.1.2# 22
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
is-a
Allergy,
I ntolerance and
Adverse Reaction
Event
CP.1.2# 25
CP.1.2# 07
CP.1.2# 02
CP.1.2# 01
CP.1.2# 03
data of review
reaction type
severity
type
CP.1.2# 18
CP.1.2# 26
-
CP.6.2# 04
+
manage()
CP.1.2# 21
CP.1.2# 24
7/16/2015
DRAFT WORKING DOCUMENT
CP.1.2# 13
29
Allergy, Intolerance and Adverse Reaction Event
Conformance Criteria (CC) Applicable to this CDM
• CP.1.2#01 The system SHALL provide the ability to manage true allergy, intolerance, and adverse
reaction to drug, food or environmental triggers as unique, discrete entries.
• CP.1.2#02 The system SHOULD provide the ability to manage the reason for entry or maintenance
(including update or remove) of the allergy, intolerance or adverse reaction.
• CP.1.2#03 The system SHALL provide the ability to manage the reaction type as discrete data.
• CP.1.2#04 The system SHALL provide the ability to manage the severity of an allergic or adverse
reaction as discrete data.
• CP.1.2#07 The system SHOULD provide the ability to manage the source of allergy, intolerance, and
adverse reaction information.
• CP.1.2#13 The system SHALL provide the ability to tag that the list of medications and other agents has
been reviewed.
• CP.1.2#16 The system SHOULD provide the ability to manage allergy information as coded data.
• CP.1.2#17 The system SHOULD provide the ability to capture and maintain the required documentation
of allergies prior to completion of the medication order.
• CP.1.2#18 The system SHOULD provide the ability to capture and render that the allergies are
“Unknown” or “Unable to Assess Allergies".
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
30
Allergy, Intolerance and Adverse Reaction Event
Conformance Criteria (CC) Applicable to this CDM
• CP.1.2#19 The system SHOULD provide the ability to capture the reason for “Unknown” or “Unable to
Assess Allergies” documentation.
• CP.1.2#21 The system SHOULD provide the ability to capture free text allergies and render them in a
manner that distinguishes them from coded allergy entries.
• CP.1.2#22 The system SHOULD tag and render an indicator that interaction checking will not occur
against free text allergies.
• CP.1.2#24 The system SHOULD provide the ability to link allergic reactions to specific treatment or
diagnostic protocols.
• CP.1.2#25 The system SHOULD conform to function CPS.4.2.1 (Support for Medication Interaction and
Allergy Checking) to render any potential interactions when capturing or maintaining allergies,
intolerances or adverse reactions.
• CP.1.2#26 The system SHOULD capture information that a provider was presented with and
acknowledged a drug interaction notification.
• CP.6.2#04 The system SHOULD provide the ability to capture, in a discrete field, an allergy/adverse
reaction to a specific immunization.
• CP.6.2#09 The system SHALL conform to function CP.1.2 (Manage Allergy, Intolerance and Adverse
Reaction List).
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
31
CDM for Clinical Decision Support
Conformance Criteria (CC) Applicable to this CDM
class RT Clinical Decision S upport (CDS )
NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!
Event
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
CPS.3.9# 04
CDS -Clinical
Decision S upport
CPS.3.9# 01
-
maintain()
is-a
CDS Update
-
date (update)
v ersion
-
manage()
CDS Content
7/16/2015
+
+
-
date (occurence)
time (occurence)
change justification
circumstances
clinical information
date (entry )
date (rev iew)
description
duration
information rev iewed
information source
information v alidator
location
mechanism
metadata
person-role
status
trigger
ty pe
+
+
+
deactiv ate()
justify ()
manage()
CPS.3.9# 03
CPS.3.9# 02
CDS Rules
RED: Recommend deletion, Blue: Recommended Insertion
32
Clinical Decision Support
Conformance Criteria (CC) Applicable to this CDM
• CPS.3.9#01 The system SHALL provide the ability to maintain the clinical content or rules utilized to
generate clinical decision support reminders and alerts.
• CPS.3.9#02 The system SHOULD provide the ability to render information that will allow validation that
the most applicable version (of the decision support rules) is utilized for the update.
• CPS.3.9#03 The system SHOULD capture the date of update of the decision support rules.
• CPS.3.9#04 The system MAY tag {track} and store {retain} the version used when guidelines are provided
in a patient encounter.
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
33
CDM for Clinical Document or Note
Conformance Criteria (CC) Applicable to this CDM
class RT Clinical Document or Note
Document or Note Type Enumeration
-
addenda
original
updated by amendment in order to correct
Document or Note
S tatus Enumeration
-
final
preliminary
signed
Clinical Document or
Note Disposition
Enumeration
-
future follow-up
recall patient
reviewed and files
Clinical Document or
Note Type Enumeration
«enum»
+ original
+ addenda
+ update
+
+
+
+
+
+
+
authenticator
author
date
facility
patient
type
status
+
+
+
+
render()
capture()
update()
tag()
CPS.1.7.2# 01
CP.3.3# 11
CP.3.3# 10
CP.3.3# 02
CP.3.3# 08
CP.3.3# 09
is-a
-
Template
CP.3.3# 03
type
CP.3.3# 04
CP.3.3# 16
Clinical Document or
Note
-
disposition
signature
structured :boolean
+
+
manage()
render()
tag()
CP.3.3# 14
CP.3.3# 15
CP.6.2# 06
CP.6.2# 02
CP.3.3# 07
is-a
CP.3.3# 12
Unstructured
Document
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
7/16/2015
CPS.1.7.2# 03
Document or
Note
Advanced
Directive
CP.3.3# 05
CP.3.3# 17
CPS.1.7.2# 04
DRAFT WORKING DOCUMENT
CPS.1.7.2# 05
CP.3.3# 01
34
Clinical Document or Note
Conformance Criteria (CC) Applicable to this CDM
• CP.3.3#01 The system SHALL provide the ability to capture and render clinical documentation
(henceforth "documentation") including original, update by amendment in order to correct, and addenda.
• CP.3.3#02 The system SHALL provide the ability to capture free text documentation.
• CP.3.3#03 The system MAY present documentation templates (structured or free text) to facilitate
creating documentation.
• CP.3.3#04 The system SHALL provide the ability to present other existing documentation within the
patient's EHR while new creating documentation.
• CP.3.3#05 The system SHOULD provide the ability to link documentation for a specific patient with a
given event (e.g., office visit, phone communication, e-mail consult, lab result).
• CP.3.3#07 The system SHOULD provide the ability to link encounters, orders, medical equipment,
prosthetic/orthotic devices, medications, and notes to one or more problems (Ref: CP.1.4 [Manage
Problem List] cc#9).
• CP.3.3#08 The system SHALL provide the ability to update documentation prior to finalizing it.
• CP.3.3#09 The system SHALL provide the ability to tag a document or note as final.
• CP.3.3#10 The system SHALL provide the ability to render the author(s) and authenticator(s) of
documentation when the documentation is rendered.
• CP.3.3#11 The system SHALL provide the ability to render documents based on document metadata
(e.g., note type, date range, facility, author, authenticator and patient).
• CP.3.3#12 The system MAY provide the ability for providers to capture clinical documentation using
standard choices for disposition (e.g., reviewed and filed, recall patient, or future follow-up).
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
35
Clinical Document or Note
Conformance Criteria (CC) Applicable to this CDM
• CP.3.3#14 The system SHOULD provide the ability to render clinical documentation using an integrated
charting or documentation tool (e.g., notes, flow-sheets, radiology views, or laboratory views).
• CP.3.3#15 The system MAY provide the ability to capture clinical documentation using specialized
charting tools for patient-specific requirements (e.g., age - neonates, pediatrics, geriatrics; condition impaired renal function; medication).
• CP.3.3#16 The system SHOULD provide the ability to capture, maintain and render transition-of-care
related information.
• CP.6.2#02 The system MAY auto-populate the immunization administration record as a by-product of
verification of administering provider, patient, medication, dose, route and time according to scope of
practice, organizational policy and/or jurisdictiona
• CP.6.2#06 The system SHOULD provide the ability to link standard codes (e.g. NDC, LOINC, SNOMED
or CPT) with discrete data elements associated with an immunization.
• CPS.1.7.2#01 The system SHALL provide the ability to manage advance directive information including
the type of directive, relevant dates (e.g., received, reviewed, rescinded, updated), circumstances under
which the directives were received, and the ...
• CPS.1.7.2#03 The system SHALL provide the ability to render the type of advance directives captured
for the patient (e.g., living will, durable power of attorney, preferred interventions for known conditions, or
the existence of a "Do Not Resuscitate" ...
• CPS.1.7.2#04 The system SHALL provide the ability to manage “Do Not Resuscitate” orders.
• CPS.1.7.2#05 The system SHOULD conform to function CPS.2.4 (Support Externally Sourced Clinical
Images) in order to capture scanned patient advance directive documents and/or “Do Not Resuscitate”
orders.
RED: Recommend
deletion,
Blue:DOCUMENT
Recommended Insertion
DRAFT
WORKING
36
7/16/2015
CDM for Event
Conformance Criteria (CC) Applicable to this CDM
class RT Event
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
Terminology
EHR-S
standardUsage
Enumeration
Trigger
Enumeration
-
drug
environment
food
other
Demographic
Information
-
date & Time
identifier
location
Demographic
Information
(structured)
7/16/2015
-
SHALL
SHOULD
MAY
+
+
+
+
+
+
+
+
attribute
code or value set
organization
version
type
realm
rational
Usage
Clinical
Information
-
NOTE: EHR-S FIM is NOT
intended to imply a specific
architecture or workflow!
type
Terminology
+ manage()
CP.1.3#08
Event
Person-Role
+
1..*
+
- person identifier
- role
1..* Clinical Document or
Note
- disposition
- signature
- structured :boolean
- manage()
+ render()
+ tag()
Event-Status Enumeration
- active
- completed
- deactive
+
- erroneously captured
+
- pending
+
date (occurence)
time (occurence)
change justification
circumstances
Clinical Information
date (entry)
date (review)
description
duration
information reviewed
information source
information validator
location
mechanism
metadata
person-role
status
trigger
type
deactivate()
justify()
manage()
CP.1.3#13
CP.1.2#15
CP.1.2#25
CPS.3.9#04
CP.1.2#14
CP.1.3#10
CP.1.3#05
AS.4.1#02
CP.1.6#02
DRAFT WORKING DOCUMENT
Event Type Enumeration
-
advanced directive
adverse reaction
allergy
CDS Alerts
CDS reminders
CDS update
clinical document or note
discharge
encounter
intolerance
medication (pharmacist change)
medication (prescription dispensing)
medication (prescription filling)
medication history received (external source)
order
other
procedure
registry
reminders & alerts
report
surgical
transfer
37
Event
Conformance Criteria (CC) Applicable to this CDM
• CP.1.6#02 The system SHALL provide the ability to manage, as discrete data elements, data
associated with any immunization given including date and time of administration, immunization type
and series, lot number and manufacturer, dose and administration
• CP.1.3#05 The system SHALL provide the ability to capture medications not reported on existing
medication lists or medication histories.
• CP.1.3#08 The system SHALL provide the ability to tag a medication as erroneously captured and
excluded from the presentation of current medications.
• CP.1.3#10 The system SHOULD provide the ability to capture and render information regarding the
filling of prescriptions.
• CP.1.3#13 The system SHALL provide the ability to capture that a medication history is unavailable or
incomplete.
• CP.1.2#14 They system SHALL provide the ability to capture and render the date on which allergy
information was entered.
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
38
Event
Conformance Criteria (CC) Applicable to this CDM
• CP.1.2#15 The system SHOULD provide the ability to capture and render the approximate date of the
allergy occurrence.
• CP.1.2#25 The system SHOULD conform to function CPS.4.2.1 (Support for Medication Interaction and
Allergy Checking) to render any potential interactions when capturing or maintaining allergies,
intolerances or adverse reactions.
• CPS.3.9#04 The system MAY tag {track} and store {retain} the version used when guidelines are
provided in a patient encounter.
• AS.4.1#02 The system MAY provide the ability to render and tag registry information as reviewed and
the information's related assessment of validity or applicability for clinical, financial or administrative
activities.
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
39
CDM for List
Conformance Criteria (CC) Applicable to this CDM
NOTE: EHR-S FIM is NOT
intended to imply a specific
architecture or workflow!
class RT List
CP.1.4#08
-
CP.3.3#06
is-a
define sort restrictions()
define sort criteria()
filter()
link to problem-treatment()
manage()
manage reason for change ()
sort()
ia-a
Allergy,
Intolerance and
Adverse Reaction
List
7/16/2015
CP.1.2#12
List
Immunization
List
+ analyze()
+ manage()
is-a
Medication
List
CP.1.2#11
SHALL CCs have
bolded borders.
See individual EHR-S
Function’s slide deck
for CC details at:
http://wiki.hl7.org/index.
php?title=EHR_Interop
erability_WG
Patients Requiring
Followup List
DRAFT WORKING DOCUMENT
CP.3.3#18
40
List
Conformance Criteria (CC) Applicable to this CDM
• CP.1.2#11 The system MAY provide the ability to render the list of allergies, intolerances and adverse
reactions in a user defined sort order.
• CP.1.2#12 The system MAY restrict the ability to render the list in a user defined sort order.
• CP.1.4#08 The system SHOULD provide the ability to render the list in a user defined sort order.
• CP.3.3#18 The system SHOULD provide the ability to tag and render lists of patients requiring follow up
contact (e.g., laboratory callbacks, radiology callbacks, left without being seen).
• CP.3.3#06 The system SHOULD provide the ability to render the list in a user defined sort order (Ref:
CP.1.4 [Manage Problem List] cc#8).
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
41
CDM for Immunization Event
Conceptual Conformance Criteria (CC) Applicable to this CDM
class RT Immunization Event
CP.1.2#13
CP.3.3#12
CP.6.2#03
CP.3.3#19
Encounter
-
Event
differential diagnosis
disposition
follow up activities
follow up needed :boolean
follow up results
type
has-a
+ manage()
CPS.3.9#04
CP.3.3#18
CP.3.3#13
CP.1.2#20
NOTE: EHR-S FIM is NOT
intended to imply a specific
architecture or workflow!
Immunization Future
Booster
- immunization type
- recommended date
health care
organisation
Immunization Witheld
Event
+ exception reason
+ withholding provider
7/16/2015
+
+
1..* -
date (occurence)
time (occurence)
change justification
circumstances
clinical information
date (entry)
date (review)
description
duration
information reviewed
information source
information validator
location
mechanism
metadata
person-role
status
trigger
type
+ deactivate()
+ justify()
+ manage()
0..*
is-a
CP.1.6#03
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
CP.6.2#21
CP.6.2#22
CP.6.2#06
CP.1.6#02
CP.6.2#17
CP.6.2#16
CP.6.2#02
Immunization Event
+
+
+
is-a 0..* -
date (recommended booster)
immunization type
series (immunization)
dose
educational information received :boolean
encounter
future booster
healthcare organization
immunization order
immunization provider
justification-immunization refusal
lot
manufacturer
ordered immunization due date
receipt of immunization preference
receiving entity (educational information)
refusal of vaccine type
route of administration
time (administration)
type
DRAFT WORKING DOCUMENT
CP.6.2#23
CP.6.2#18
CP.6.2#10
CP.6.2#20
CP.6.2#05
CP.6.2#19
CP.6.2#01
CP.1.6#05
42
Immunization Event
Conformance Criteria (CC) Applicable to this CDM
• CP.1.2#13 The system SHALL provide the ability to tag that the list of medications and other agents has
been reviewed.
• CP.1.2#20 The system SHOULD provide the ability to tag records and render to providers that the
allergies are “Unknown” or “Unable to Assess Allergies” and need to be updated.
• CP.1.6#02 The system SHALL provide the ability to manage, as discrete data elements, data associated
with any immunization given including date and time of administration, immunization type and series, lot
number and manufacturer, dose and administration
• CP.1.6#03 The system SHALL provide the ability to manage, as discrete elements, data associated with
any immunization withheld (including date and time, immunization type, series, exception reason and
immunization-withholding provider).
• CP.1.6#05 The system SHALL provide the ability to capture the currently recommended date for an
immunization booster dose with each immunization, if needed.
• CP.3.3#12 The system MAY provide the ability for providers to capture clinical documentation using
standard choices for disposition (e.g., reviewed and filed, recall patient, or future follow-up).
• CP.3.3#13 The system MAY provide the ability to capture, maintain and render the clinician’s differential
diagnosis and the list of diagnoses that the clinician has considered in the evaluation of the patient.
• CP.3.3#18 The system SHOULD provide the ability to tag and render lists of patients requiring follow up
contact (e.g., laboratory callbacks, radiology callbacks, left without being seen).
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
43
Immunization Event
Conformance Criteria (CC) Applicable to this CDM
• CP.3.3#19 The system SHOULD provide the ability to capture patient follow-up contact activities (e.g.,
laboratory callbacks, radiology callbacks, left without being seen).
• CP.6.2#01 The system SHALL provide the ability to capture, maintain and render immunization
administration details as discrete data, including:(1) the immunization name/type, strength and dose;(2)
date and time of administration;(3) manufacturer, lot numb
• CP.6.2#02 The system MAY auto-populate the immunization administration record as a by-product of
verification of administering provider, patient, medication, dose, route and time according to scope of
practice, organizational policy and/or jurisdictionsa
• CP.6.2#03 The system SHALL provide the ability to determine and render required immunizations, and
when they are due, based on widely accepted immunization schedules, when rendering encounter
information.
• CP.6.2#05 The system SHALL conform to function CP.3.2 (Manage Patient Clinical Measurements) to
capture other clinical data pertinent to the immunization administration (e.g., vital signs).
• CP.6.2#06 The system SHOULD provide the ability to link standard codes (e.g. NDC, LOINC, SNOMED
or CPT) with discrete data elements associated with an immunization.
• CP.6.2#10 The system SHOULD transmit required immunization administration information to a public
health immunization registry according to scope of practice, organizational policy and/or jurisdictional law.
• CP.6.2#16 The system SHALL provide the ability to render the immunization order as written (i.e., exact
clinician order language) when rendering administration information.
7/16/2015
RED: Recommend
deletion,
Blue:DOCUMENT
Recommended Insertion
DRAFT
WORKING
44
Immunization Event
Conformance Criteria (CC) Applicable to this CDM
• CP.6.2#17 The system SHALL provide the ability to determine due and overdue ordered immunizations
and render a notification.
• CP.6.2#18 The system SHALL provide the ability to render a patient educational information regarding
the administration (e.g., Vaccine Information Statement (VIS)).
• CP.6.2#19 The system SHALL provide the ability to capture that patient educational information (e.g.,
VIS) was provided at the time of immunization administration.
• CP.6.2#20 The system SHALL provide the ability to capture documentation that patient educational
information (e.g., VIS) was provided at the time of immunization administration.
• CP.6.2#21 The system SHALL provide the ability to capture the receiving entity (e.g., patient,
representative, organization) when patient education information is provided at the time of immunization
administration.
• CP.6.2#22 The system SHOULD provide the ability to capture and maintain immunization refusal reasons
as discrete data.
• CP.6.2#23 The system SHOULD provide the ability to capture patient preferences regarding receipt of
immunization (e.g. refusal of certain vaccine types) at time of immunization administration.
• CPS.3.9#04 The system MAY tag {track} and store {retain} the version used when guidelines are provided
in a patient encounter.
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
45
CDM for Report
Conceptual Conformance Criteria (CC) Applicable to this CDM
class RT Report
NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!
CP.6.2#10
Document or
Note
CP.6.2#12
CPS.9.4#06
CPS.9.4#01
is-a
Immunization
History
Registry (Public
Health
Immunization)
+
-
render()
harmonize()
capture()
exchange()
update()
Immunization Order
Clinical Document or
Note
CP.6.2#08
is-a
Report
CPS.9.4#05
CPS.9.4#04
CPS.9.4#03
CPS.9.4#02
CP.6.2#13
- type
- Parameters
CPS.9.4#08
CP.6.2#16
- manage()
+ render()
EHR-S
CPS.9.4#07
SHALL CCs have bolded borders.
See individual EHR-S Function’s slide deck for CC details at:
http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG
7/16/2015
DRAFT WORKING DOCUMENT
CPS.9.4#09
46
CDM for Report
Conceptual Conformance Criteria (CC) Applicable to this CDM
1. CP.6.2#08 The system SHALL provide the ability to render a patient‘s immunization history upon
request for appropriate authorities such as schools or day-care centers.
2. CP.6.2#10 The system SHOULD transmit required immunization administration information to a public
health immunization registry according to scope of practice, organizational policy and/or jurisdictional
law.
3. CP.6.2#12 The system SHOULD harmonize Immunization histories with a public health immunization
registry according to scope of practice, organizational policy and/or jurisdictional law.
4. CP.6.2#13 The system SHOULD capture and render immunization histories from a public health
immunization registry.
5. CP.6.2#16 The system SHALL provide the ability to render the immunization order as written (i.e., exact
clinician order language) when rendering administration information.
6. CPS.9.4#01 The system SHOULD provide the ability to render reports of structured clinical and
administrative data using either internal or external reporting tools.
7. CPS.9.4#02 The system MAY provide the ability to extract unstructured clinical and administrative data
for inclusion in the report generation process, using internal or external tools.
8. CPS.9.4#03 The system SHOULD provide the ability to extract and transmit reports generated.
9. CPS.9.4#04 The system SHOULD provide the ability to capture and maintain report parameters, based
on patient demographic and/or clinical data, which would allow sorting and/or filtering of the data.
7/16/2015
DRAFT WORKING DOCUMENT
47
CDM for Report
Conceptual Conformance Criteria (CC) Applicable to this CDM
10. CPS.9.4#05 The system MAY provide the ability to save report parameters for generating subsequent
reports either as integrated component of the system, or an external application, using data from the
system.
11. CPS.9.4#06 The system MAY provide the ability to edit one or more parameters of a saved report
specification when generating a report using that specification either as integrated component of the
system, or an external application, using data from the sy
12. CPS.9.4#07 The system SHOULD provide the ability to render automated reports as required by
industry and regulatory bodies.
13. CPS.9.4#08 The system SHOULD provide the ability to extract facility level data at an organizational
level in support of organizational initiatives.
14. CPS.9.4#09 The system MAY provide the ability to render a cumulative directory of all personnel who
use or access the data.
7/16/2015
DRAFT WORKING DOCUMENT
48
Backup
Reference Information
• EHR-S FIM Verb Hierarchy
• Observations by reviewers
• Backup Slides
7/16/2015
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
49
EHR-S FIM
Action Verb Hierarches
Manage (Data)
Capture
Maintain
AutoStore
Populate
Enter
Archive
Import
Backup
Receive
Decrypt
Encrypt
Recover
Restore
Save
Update
Remove
Annotate
Attest
Edit
Harmonize
Integrate
Link
Tag
Delete
Purge
7/16/2015
Render
Extract
Present
Exchange
Transmit
Export
Import
Receive
Transmit
Determine
Analyze
NOTE: EHR-S FIM is NOT
intended
to imply
a specific architecture or workflow!
DRAFT
WORKING
DOCUMENT
Decide
ManageDataVisibility
De-Identify
Hide
Mask
Re-Identify
Unhide
Unmask
50
Observation [David Baas]
•
•
From where I’m sitting, deriving conceptual information models based on the conformance criteria
could be useful for consuming a functional profile. I would assume it could be used as reference
for developing a domain analysis model for a project, to fill in blanks of conceptual information not
expressed by clinical SMEs, and to shorten the learning curve for projects required to adopt the
conformance criteria. Regardless of how modeling evolved on the project, the CDM would still be
a bridge to validate addressing information needs at a high level. I would not foresee using the
CDM or other artifacts verbatim in modeling for a specific project because some the
relationships/associations expressed appear to be more subjective than explicit representation of
the conformance criteria. I suggest annotating whether the relationships in the CDM represent
explicit conformance criteria or not. For those that are not explicit (SHALL), it should be clear
implementers have no obligation to portray those relationships the way they are expressed
in the model.
In reviewing the other artifacts (activity diagrams, and conceptual information model) I was a little
concerned that the content suggested a more prescriptive view of EHR functionality, which I’m not
sure is a good thing. In the case of the activity diagrams being prototyped, I can see they are not
attempting to sequence how tasks within an activity are executed, but using activity diagrams
suggests that is the intended direction. I think that path would be too restrictive for implementers. I
think the CIM raises more questions than it answers. This is another one where I think it best left
to specific implementation projects. Perhaps other folks will provide a different perspective, but I
think the CDM content is the most useful for understanding the conformance criteria for greater
adoption.
7/16/2015
DRAFT WORKING DOCUMENT
51
Observation [Kevin Coonan, HL7 Patient Care WG Co-chair]
•
•
•
•
•
•
We have been having a lot of discussions in patient care, clinical statement, CIMI and MnM regarding representation of clinical
content. One of the most important is the recognition and separation of dynamic uses / extracts of information one would see in an
EHR-S GUI or CDA v. an information model suited for information exchange, persistence, transformation, analytics, decision
support. A good example of this is the common notions of a “problem list”, “allergy list” or “list of immunizations”. These are artifacts
we are used to seeing in paper charts, since there was no other effective means to address longitudinal data which otherwise would
be scattered in the linear ordering progress notes. In fact, HL7 defines these working lists as ‘..collects a dynamic list of individual
instances of Act via ActRelationship which reflects the need of an individual worker, team of workers, or an organization to manage
lists of acts for many different clinical and administrative reasons. Examples of working lists include problem lists, goal lists, allergy
lists, and to-do lists.’
There are also design patterns well suited for static semantics from the (being revised for May ballot) Patient Care domain, all of
which are different entry points into a common model. These include a pattern for a Care Record, which corresponds best to the
conventional notion of the documentation of an encounter. The Care Record, however, has entries which follow the Health Concern
pattern and the Care Plan pattern.
Health Concerns are anything which affects one’s health which need to be managed/tracked over time. These includes risks,
diseases, problems, allergies/intolerances to medications, social circumstances, and complications.
The Care Plan documents interventions, treatments and orders. Care Plans can have embedded logic, e.g. stating a specific action
should (not) be taken if a specific criterion is met. So things like immunization schedules, insulin sliding scales/sick day rules, or
complex oncology protocols have a common design basis. While we are used to thinking of Concerns and Plans as future looking,
the same pattern is used to document things which have happened (e.g. procedure which has been completed), so the Care Plan
includes not just what is currently being done, what is planned, but also what has been done in the past.
An instance of an encounter’s documentation therefore would have elements from the Care Record (e.g. the signs/symptoms
discovered at the time of the encounter), Health Concerns (in a linear narrative like a CDA these typically are organized into the
familiar ‘lists’, e.g. allergy list, problem list, PMH), and Care Plan (again in ‘lists’—e.g. medication list). An encounter would also
expect to generate new Care Plans and new Health Concerns as part of the clinical decision making. (The A&P in Weed’s POMR).
By separating the model of use (various lists) from model of meaning (the Patient Care Domain Model plus the derived detailed
clinical models which bind terminology, etc.) we can most effectively devise those specifications needed for given use cases.
7/16/2015
DRAFT WORKING DOCUMENT
52
Observation [Kevin Coonan, HL7 Patient Care WG Co-chair]
•
•
•
•
I am coordinating with Richard Savage (now working for CDC) on immunizations with Patient Care. I
don’t know who the modeling facilitator is for the new immunization project, but if it is a void I might fill
in. I am going to start tacking the immunization (JIC) (analysis/conceptual) models and see if I can get
them into something which is a better approximation of a real information model of the clinical content
static semantics.
Do you think this is a good point to start to put together the background and socialization needed to
come to some decision regarding the representation of static semantics for iEHR? I see two related
decisions: #1 what modeling language is going to be used for design, and #2 what is the modeling
language used for the wire format. Obviously, with HL7 v3 there is close traceability between the
graphic format in the Visio based RMIM Designer and the resultant MIF2 representation. I believe that
the UML based SMD also does this. MIF2 è XSD, so there is a close tie between MIF and something
which can be implemented.
Of course, we could also use HL7 templates (whatever those are) on top of a base model, rather than
having all the explicit details in the MIF2. We could even use ADL for this, if we were so inclined. That
still leaves us the question about ‘wire format’. I.e. what one server says to another.
Eventually, I would expect a ‘cleaner’ modeling language to be used for design, with transformation to
arbitrary implementable paradigms. Hopefully CIMI will fill this niche. Not in time to do the modeling for
JIC, Pharmacy, etc. but hopefully just in time to model the core content of an ambulatory documentation
system.
7/16/2015
DRAFT WORKING DOCUMENT
53
Should the CDMs be Normative or Informative?
[Ann Wrightson (NWIS - Technical), 3-Mar-12]
•
•
ISO 13940 has a very similar intent, so it's at least overlapping, if not competing directly, as a
conceptual data model to underpin an EHR system. Have you mapped the extent and nature of the
overlap? Maybe the answer is not an additional elaborated CDM standard but rather an (informative)
crosswalk from the EHR-S FM to ISO 13940?
It would be useful to have informative and exemplary CDMs linked to the EHR-S FM, however, I don't
think there is enough uniformity and consensus across the world to support a normative approach. For
health system, technology, legal and other reasons there are likely to be different component
breakdowns required in different situations, & when the flow-down of features to system components is
different, the interfaces and information flows within the system are different. (For example, having a
specific and separable immunization registry system component is health system dependent and not a
necessary part of a public health programme for immunization. Immunization records may instead
be managed by a citizen's registered primary care practitioner and various data reported out to others
who need to know as part of broader management reporting and information sharing agreements.)
Moreover, to be normative and International you would need to take on the task of harmonizing this
EHR-S FM CIM/CDM approach with the (fair bit of) existing work in Europe. IMO this is not culturally or
practically feasible at this time, & the answer is not to set up a competing "International" normative
standard, but to accept the situation and develop informative/illustrative work from a different
perspective, that may lead to more harmonized work in the longer term.
(I was about to elaborate further, & noticed David Baas' comments - switch his implementation
perspective to an international harmonization perspective across health systems, and they fit there too.)
7/16/2015
NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!
54
Immunization Management Capability
CP.6.2 Manage Immunization Administration Dependencies
7/16/2015
DRAFT WORKING DOCUMENT
55