EHR System Function and Information Model (EHR-S FIM) Release 2.1 HL7 Project ID# 688

(1)

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

, EHR WG Modeling Facilitator

, DoD‐MHS Proponent

February 9, 2012 – Original Working‐Draft

March 15, 2012+ – Last‐Update to Working‐Draft

3/15/2012 1

Call for Participation

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#

(2)

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-and-workflow agnostic EHR-S FIM into implementable

interoperability-specifications, which meet their system

acquisition, implementation or test needs.

(3)

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) Demonstrate Service Aware Interoperability Framework (SAIF) use

3) Support specific profiles (e.g., DAMs, DIMs, DCMs).

The DoD-VA Joint Immunization Capability (JIC), Pharm-Lab-Rad, and than ISO

13940 Continuity-of-Care System-of Concepts-and-Glossary harmonization are

proposed as a set of demonstration prototypes of increasing complexity.

(4)

Notional Set of Artifacts within an HL7 SAIF

Enterprise Compliance and Conformance Framework (ECCF)

4 Business • Mission, • Vision, • Scope , Inventory of • Applicable Laws • Contracts • Policies • Procedures • Enterprise Capabilities Enterprise Dimension “Why” - Policy Business Policies Governance Implementation Guides Design Constraints Organization Contracts Business Nodes Business Rules Business Procedures Business Workflows Technology Specific Standards Inventory of Reusable • Entities • Associations • Information Information Models • Dependencies • Associations Data Models • Data Dictionary • Mandatory or Optional Information Dimension “What” - Content Information Models • Domain IM • Detailed Clinical Terminology binding Value Set binding Content Specifications • CCD • RMIM Schemas for • Databases • Messages • Documents • Services • Transformations Inventory of Reusable • Scenario Events • Business Activities • System Functions Requirements • Accountability, Roles • Conformance Criteria • Profiles, Behaviors • Interactions and • Info. Exchanges Requirements Traceability Computational Dimension “Who/How” -Behavior Specifications

• Scenario & Use Cases • Components Interfaces Collaboration Actors • Collaboration Types • Collaboration Roles Function Types Interface Types Service Contracts Automation Units Technical Interfaces Technical Operations Orchestration Scripts Inventory of • SW Platforms, Layers • SW Environments • SW Components • SW Services • Technical Requirements • Enterprise Service Bus Key Performance Parameters Engineering Dimension “Where” - Implementation Models, Capabilities, Features and Versions for • SW Environments • SW Capabilities • SW Libraries • SW Services • SW Transports SW Specifications for • Applications • GUIs • Components SW Deployment Topologies Inventory of • HW Platforms • HW Environments • Network Devices • Communication Devices Technical Requirements Technical Dimension “Where” -Deployments Models, Capabilities, Features and Versions for • HW Platforms • HW Environments • Network Devices • Communication Devices HW Deployment Specifications HW Execution Context HW Application Bindings HW Deployment Topology HW Platform Bindings Conceptual Perspective

ECCF

Logical Perspective Implementable Perspective

Responsibility: Sponsoring Organization | EHR-S FIM| Work Groups / Projects | Vender / Development Organization See notes page for ECCF description

(5)

Information models define the intricate details of how clinical information comes together in a

cohesive fashion to allow clinical decision support, automation of routine care measures,

epidemiological and research use of clinical data; ultimately, Information models must specify a

level-of “working-interoperability” among system components, capabilities and services.

Information models are created for a specific purpose; such as, providing a specification from

which implementation artifacts can be derived and conformance can be assured. A particular

implementation type (e.g., messages, documents, services) may constrain the

content-and-style of information models and the choice of modeling environments.

• Conceptual Information models-of-use are closely related to functional requirements.

• Logical Information models-of-meaning require explicit semantic specifications to govern

persistence, processing, and information exchanges.

As an emergency care example, well-specified information models-of-meaning should

allow-the-potential for initial-care-site triage-information to help subsequent care givers understand

diagnostic-imaging done prior-to acute-injury-stabilization and ultimately to help other health

care professionals, potentially years later, help patients achieve maximum recovery.

Information Models

(6)

• 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).

• Conceptual Information Models identify the highest-level conceptual components in a

domain (e.g., EHR) and their relationships; however, data content is not specified.

• Conceptual Data Models (CDMs) specify conceptual components and their content, without

regard to how they will be physically implemented.

• Sub-domain and realm-specific CDMs (profiles) typically refine the following:

– Conceptual components and their relationships – conceptual components and their content

• date element optionality (e.g., MAY, SHOULD, SHALL) are constrained

– 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 CDMs, which can be transformed into deterministic

and testable physical schema for a specific implementation.

Information Model Types

(7)

NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

EHR‐FIM

Model Legend

3/15/2012 DRAFT WORKING DOCUMENT 7 class Legend C lin ic ia n A ct iv iti

es Business Activity Corresponding to EHR-S Function

Task 1 within Activity EHR-S Co m po ne nt EH R -S F un ct ion s a nd R equ ire m en ts EHR-S Component :: System Component 1 - Attribute 1 «SHALL» + attribute 2 - operation #xx() «SHALL» + operation #yy() FEATURE: EHR-S Function <<SHALL>> REQUIREMENT: Conformance Criteria (CC) #xx FEATURE 2: EHR-S Function

Start Activity End Activity

EHR-S Component :: System Component 2 EHR-S Component :: Syatem Component 3 EHR-S Component :: System Component 4 En co un te r

Dependency is a model-element relationship between a Dependent-Client ---> Independent-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.

<<SHOULD or MAY>> REQUIREMENT Conformance Criteria #yy

<<SHALL>> REQUIREMENT Conformance Criteria #05 Task 2 within Activity Task 3 within Activity Task 4 within Activity

Capitalized Attribute or Operation implies that it is implemented by an external entity. Attribute 1 Data Structure implements depends-on control

flow control_flow

association has-a (part) aggregation depends on requirement-for requirement-for requirement-for is-a (type) generalization

(8)

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

3/15/2012 DRAFT WORKING DOCUMENT 8

CIM is Conceptual Information Model CDM is Conceptual Data Model

(9)

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. Gather A core set of reusable components appropriate for the function 2. Create Model‐of‐use (Activity Model based on conformance criteria). • Map Activities to EHR‐S Components 3. Create CIM based on Information Patterns (e.g., encounters, events, lists, documents) • Show supporting EHR‐S Function associations and dependencies. • Map EHR‐S Components to supporting EHR‐S Functions (“See Also” Dependencies) 4. Add CDM component content, based on conformance criteria. • 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 – 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 “‐”

5. Add Specific Information Exchanges, based on conformance criteria.

This Executive Summary was created from the resultant model.

(10)

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.

(11)

Issues

1. How do we harmonize with ISO 13940 … synonyms (clinician vs. Health care professional)?

2. 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)

• Recommend normative

• Distinguish between elements derived from SHALLs vs. those from SHOULDs and MAYs • Remove data element conformance criteria from EHR-S Functional Model

3. How do we incorporate:

– Quality Measures/ Model – Meaningful-use measures – Patient outcome measures

4. 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

5. How will we represent the Information Models for Ballot.

– Tool generated report showing model views (e.g., similar to Immunization Prototype) • Benefit: maximum completeness and consistency

• Will ISO accept graphics?

– Textural listing of components and data elements similar to • HITSP/C83 CDA Content Modules and

• HITSP/C154 Data Dictionary

(12)

Recommendations

Based on Immunization Management Prototype

• Add the following functions and components to EHR-S FIM :

1. Business Rules

2. Clinical Decision Support (CDS)

3. Metadata for realm-specific Information-Exchange Standards 4. Manage Patient Consents

5. 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. an EHR-S manages Encounters; where,

2. each Encounter is a set of Events, Documents and Lists.

3. Events, Documents and Lists are decomposed into types (immunization, medication). 4. Benefits:

• Reduced Conformance Criteria duplication • Increased Conformance Criteria consistency

(13)

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

(14)

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

– We also need models plus components for [Kevin Coonan, HL7 Patient Care WG]: Care Record (what you actually do during an encounter), Health Concern List (contraindications to immunization usually fall in this category), and Care

Plan (i.e. immunization schedules).

• 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

3/15/2012 14

Call for Participation

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#

(15)

PART 2: Immunization Management Capability

Specified by EHR‐S FIM

CP.6.2 Manage Immunization Administration,

depends on

1. CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List

2. CP.1.3 Manage Medication List

3. CP.1.6 Manage Immunization List

4. CP.3.3 Manage Clinical Documents and Notes

5. CPS.1.7.2 Manage Patient Advance Directives

6. CPS.3.9 Clinical Decision Support System Guidelines Updates

7. CPS.9.4 Standard Report Generation

8. AS.4.1 Manage Registry Communication

9. Record Infrastructure

10. Trust Infrastructure

3/15/2012 DRAFT WORKING DOCUMENT 15 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 NOTE: EHR‐S FIM is NOT intended to imply a specific architecture or workflow!

(16)

EHR‐S FM Release 2.0

• 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

(17)

CP.6.2 Immunization Management

“See Also” Dependencies (3 Levels)

3/15/2012

DRAFT WORKING DOCUMENT

17

RED: delete, Blue: insert

class CP.6.2 DEP-2 Manage Immunization Administration

CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List

CP.1.3 Manage Medication List

CP.1.6 Manage Immunization List

CP.1.8 Manage Patient and Family Preferences CP.6.2 Manage Immunization Administration 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 CPS.4.2 Support for

Medication and Immunization Ordering

CPS.9.5 Ad Hoc Query and Rendering

CPS.9.3 Health Record Output

CP.3.3 Manage Clinical Documents and Notes

CPS.1.7.3 Manage Consents and Authorizations CPS.1.6.1 Related by Genealogy CPS.1.6.3 Related by Living Situation CPS.1.6.4 Related by Other Means

Record Infrastructure Trust Infrastructure

CP, CPS & AS

CP.3.2 Manage Patient Clinical Measurements POP.4 Support for

Monitoring Response Notifications Regarding a Specific Patient’s Health

CPS.7.1 Access Healthcare Guidance

CP.3.1 Conduct Assessments

POP.6 Measurement, Analysis, Research and Reports

POP.8 De-Identified Data Request Management depends on depends on depend on depends on depends on Start Here 

(18)

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.

CP.6.2 Manage Immunization Administration

(19)

Immunization Management Capability

Resultant Models

1. CP.6.2 EHR-S Components Dependent-on Clinician-Activities (Model-of-Context)

2. CP.6.2 Manage Immunization Administration Traceability

– Components Dependent-on EHR-S Functions; Dependent-0n Clinician-Activities

3. CIM for Immunization Management Capability

4. Information Exchanges Defined-by Conformance Criteria (CC)

5. CDM for Advanced Directive

6. CDM for Allergy, Intolerance and Adverse Reaction Event

7. CDM for Clinical Decision Support (CDS)

8. CDM for Clinical Document or Note

9. CDM for Event

10. CDM for List

11. CDM for Immunization Event

12. CDM for Report

CC is Conformance Criteria

CIM is Conceptual Information Model CDM is Conceptual Data Model

(20)

RED: Recommend deletion, Blue: Recommended Insertion

CP.6.2 Manage Immunization Administration Model-of-Context

EHR‐S Components Dependent‐on Clinician‐Activities

3/15/2012 20

NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! act CP.6.2 ACT Manage Immunization Administration

CP.6.2 Manage Immunization Administration Manage

Events

Manage Documents &

Notes

Manage Records Manage Trusts

Start _End

Manage Schedules

Manage Business Rules

Manage Terminology Event Immunization Schedule Allergy, Intolerance and Adverse Reaction Event Document or Note Terminology Report Immunization List Registry (Public Health Immunization) EHR-S Com pone nt s C lin ic ia n A ct iv iti es En coun te r Manage Lists List Registry Advanced Directive Clinical Document or Note Immunization

Event

Advanced Directive Event

Schedule Clinical Information Reminder or Alert is-a depends on depends on depends on is-a is-a is-a is-a ia-a is-a is-a

(21)

3/15/2012 21

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 Events Manage Documents & Notes Manage Records Manage Trusts Manage Schedules Manage Business Rules Manage Terminology Manage Lists Record Infrastructure Trust Infrastructure

CP.6.2 Manage Immunization Administration CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List

CP.1.6 Manage Immunization List

CPS.1.7.2 Manage Patient Advance Directives

CP.3.2 Manage Patient Clinical Measurements CPS.9.4 Standard Report Generation

AS.4.1 Manage Registry Communication

Event Immunization Schedule Allergy, Intolerance and Adverse Reaction Event Document or Note Terminology Report Immunization List Registry (Public Health Immunization) List Registry Advanced Directive Clinical Document or Note

Immunization Event Advanced Directive Event

Schedule Allergy, Intolerance and Adverse Reaction List Clinical Information

(22)

Immunization Management Capability

Conceptual Information Model (CIM)

3/15/2012 RED: Recommend deletion, Blue: Recommended Insertion 22

NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! class CIM Immunization Management Capability

Event Immunization Event Immunization History Immunization List Allergy, Intolerance and Adverse Reaction Event Immunization Schedule List Clinical Information

Allergy, Intolerance and Adverse Reaction List

Medication List Patients Requiring Followup List Encounter Medication Event Registry Report Clinical Document or Note Document or Note Advanced Directive Advanced

Directive Event CDS Reminder or Alert

Update Immunization

Witheld Event EHR-S

Registry (Public Health Immunization) Medical Device

Terminology

Template Problem List

CDS-Clinical Decision Support

Clinical and Clinical Support System Components

Record Infrastructure Trust Infrastructure

0..* is-a is-a is-a is-a other EHR or related systems is-a has-a 0..* 1..* has-a is-a has-a is-a is-a ia-a is-a _is-a is-a is-a

(23)

3/15/2012 23

Immunization Management Capability

Information Exchanges Defined-by Conformance Criteria (CC)

SHALL CCs have bolded borders. See individual EHR‐S Function’s slide deck

for CC detailsat:

http://wiki.hl7.org/index.php?title=EHR_Interop erability_WG

class IE-RT Immunization Management Capability

EHR-S

- reminders or alerts

- Information Exchange Metadata

+ manage()

+ Manage 'Do Not Recusitate"()

Medical Device Registry (Public Health Immunization) Registry - clinical information - demographic information - organization (source) - patient - provider (source) - type - manage() AS.4.1#01 AS.4.1#02 AS.4.1#03 AS.4.1#04 AS.4.1#05 Demographic Information (structured) CP.3.3#07 EHR-S Information-Exchange Metadata - sourceSystem - recipientSystem - releventStandard - standardOrganization - standardVersion - standardType - standardRealm - Usage - rational - effectiveDate - possibleRisk - harmonizationIssue - implementationGuide - implementationGuideVersion Usage Enumeration - SHALL - SHOULD - MAY EHR-S StandardType Enumeration - content - transport - information assurance - other CDS-Clinical Decision Support - maintain() CPS.3.9#01 is-a other EHR or related systems implemented by

(24)

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.

(25)

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.

(26)

CDM for Advanced Directive

Conformance Criteria (CC) Applicable to this CDM

SHALL CCs have bolded borders.

See individual EHR‐S Function’s slide deck for CC detailsat: http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG

ass RT Advanced Directive

Advanced Directive Event

+ advanced directive captured :boolean + person completing AD

+ relationship to patient + circumstances (of receipt) + circumstances (of review) + date (received) + date (recinded) + date (review) + date (signed/completed) + date (updated) + Review + type CPS.1.7.2#01 CPS.1.7.2#02 CPS.1.7.2#03 CPS.1.7.2#06 CPS.1.7.2#07 CPS.1.7.2#08

Advanced Directive Type Enumeration

- Do Not Recusitate (DNR) Order - Durable Power of Attorney - Living Will

- other

- Preferred Interventions for Known Conditions

Advanced Directive Review - circumstances - date - reviewer Advanced Directive Author - date signed - name - relationship - time signed 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() Document or Note + authenticator + author + date + facility + patient + type + status + render() + capture() + update() + tag() CP.3.3#02 CP.3.3#03 CP.3.3#08 CP.3.3#09 CP.3.3#10 CP.3.3#11 Clinical Document or Note - disposition - signature - structured :boolean - manage() + render() + tag() Advanced Directive CPS.1.7.2#04 CPS.1.7.2#05 CP.3.3#01 CP.3.3#04 CP.3.3#05 CP.3.3#07 CP.3.3#12 CP.3.3#14 CP.3.3#15 CP.3.3#16 CP.3.3#17 CP.6.2#02 CP.6.2#06 EHR-S - reminders or alerts

- Information Exchange Metadata

+ manage()

+ Manage 'Do Not Recusitate"()

CPS.2.4 Support Externally Sourced Clinical Images 0..* 0..* other EHR or related systems implemented-by is-a is-a

(27)

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#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).

(28)

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 patientspecific 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.

(29)

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.

(30)

NOTE: EHR-S FIM is NOT intended to imply an architecture or workflow!

class RT Allergy, I ntolerance and Adverse Reaction Event

Allergy, I ntolerance and Adverse Reaction Event - data of review - reaction type - severity - type + manage() 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() Clinical I nformation - type CP.1.2# 25 CP.1.2# 01 CP.1.2# 02 CP.1.2# 03 CP.1.2# 04 CP.1.2# 07 CP.1.2# 13 CP.1.2# 16 CP.1.2# 17 CP.1.2# 18 CP.1.2# 19 CP.1.2# 21 CP.1.2# 22 CP.1.2# 24 CP.1.2# 26 CP.6.2# 04 CP.6.2# 09 is-a

CDM for Allergy, Intolerance and Adverse Reaction Event

Conformance Criteria (CC) Applicable to this CDM

(31)

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".

(32)

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).

(33)

CDM for Clinical Decision Support

Conformance Criteria (CC) Applicable to this CDM

3/15/2012 33

class RT Clinical Decision S upport (CDS )

CDS -Clinical Decision S upport - maintain() CDS Rules CDS Content CDS Update - date (update) - version - manage() CPS.3.9# 01 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() CPS.3.9# 02 CPS.3.9# 03 CPS.3.9# 04 is-a

(34)

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.

(35)

CDM for Clinical Document or Note

Conformance Criteria (CC) Applicable to this CDM

class RT Clinical Document or Note

Clinical Document or Note - disposition - signature - structured :boolean - manage() + render() + tag() Document or Note + authenticator + author + date + facility + patient + type + status + render() + capture() + update() + tag() Unstructured Document Template - type Document or Note Status Enumeration - final - preliminary - signed

Document or Note Type Enumeration - addenda

- original

- updated by amendment in order to correct

Clinical Document or Note Disposition

Enumeration - future follow-up - recall patient - reviewed and files

CP.3.3# 03 CP.3.3# 07 CP.3.3# 10 CP.3.3# 11 CP.3.3# 12 CP.3.3# 16 CP.3.3# 17 CP.6.2# 02 CP.6.2# 06 CPS.1.7.2# 05 Clinical Document or Note Type Enumeration

«enum» + original + addenda + update Advanced Directive CP.3.3# 01 CP.3.3# 02 CP.3.3# 04 CP.3.3# 05 CP.3.3# 08 CP.3.3# 09 CP.3.3# 14 CP.3.3# 15 CPS.1.7.2# 04 CPS.1.7.2# 01 CPS.1.7.2# 03 is-a is-a

(36)

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#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).

standard choices for disposition (e.g., reviewed and filed, recall patient, or future follow-up). NOTE: EHR‐S FIM is NOT intended to imply a specific architecture or workflow!

(37)

• 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).