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

Transcription

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, Last Update to Working Draft Call for Participation This work is being done by the HL7 EHR Interoperability Work-group, meeting every Tuesday at 2 PM ET, dial-in: , Passcode: # 3/15/2012 The most current artifacts are at: Interoperability WG 1

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-andworkflow agnostic EHR-S FIM into implementable interoperability-specifications, which meet their system acquisition, implementation or test needs. 3/15/2012 NOTE: EHR S FIM is NOT DRAFT intended WORKING to imply DOCUMENT a specific architecture or workflow! 2

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 Continuity-of-Care System-of Concepts-and-Glossary harmonization are proposed as a set of demonstration prototypes of increasing complexity. 3/15/2012 NOTE: EHR S FIM is NOT DRAFT intended WORKING to imply DOCUMENT a specific architecture or workflow! 3

4 Notional Set of Artifacts within an HL7 SAIF Enterprise Compliance and Conformance Framework (ECCF) ECCF Enterprise Dimension Why - Policy Information Dimension What - Content Computational Dimension Who/How - Behavior Engineering Dimension Where - Implementation Technical Dimension Where - Deployments Conceptual Perspective Business Mission, Vision, Scope, Inventory of Applicable Laws Contracts Policies Procedures Enterprise Capabilities 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 Logical Perspective Business Policies Governance Implementation Guides Design Constraints Organization Contracts Information Models Domain IM Detailed Clinical Terminology binding Value Set binding Content Specifications CCD RMIM 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 Implementable Perspective Business Nodes Business Rules Business Procedures Business Workflows Technology Specific Standards Schemas for Databases Messages Documents Services Transformations 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 3/15/2012 Responsibility: Sponsoring Organization EHR-S FIM Work Groups / Projects Vender / Development Organization See notes page for ECCF description 4

5 Information Models 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-andstyle 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 allowthe-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. 3/15/2012 NOTE: EHR S FIM is NOT intended to imply a specific architecture or workflow! 5

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 Information Model Types 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. 3/15/2012 NOTE: EHR S FIM is NOT intended to imply a specific architecture or workflow! 6

7 class Legend EHR FIM Model Legend NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! 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. Clinician Activities Start Activity control flow Business Activity Corresponding to EHR-S Function Task 1 within Activity Task 2 within Activity Task 3 within Activity Task 4 within Activity control flow End Activity Encounter EHR-S Component Capitalized Attribute or Operation implies that it is implemented by an external entity. Attribute 1 Data Structure depends on EHR-S Component :: System Component 1 - Attribute 1 «SHALL» + attribute 2 - operation #xx() «SHALL» + operation #yy() EHR-S Component :: Syatem Component 3 has-a (part) aggregation association EHR-S Component :: System Component 2 EHR-S Component :: System Component 4 (type) generalization EHR-S Functions and Requirements implements EHR-S Function depends-on a Business Activity (e.g., Without a business requirement, the function would not exist.). FEATURE: EHR-S Function requirement-for <<SHALL>> REQUIREMENT Conformance Criteria #05 <<SHALL>> REQUIREMENT: Conformance Criteria (CC) #xx depends-on requirement-for FEATURE 2: EHR-S Function requirement-for <<SHOULD or MAY>> REQUIREMENT Conformance Criteria #yy 3/15/2012 DRAFT WORKING DOCUMENT 7

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 CIM is Conceptual Information Model CDM is Conceptual Data Model 3/15/2012 NOTE: EHR S FIM is NOT DRAFT intended WORKING to imply DOCUMENT a specific architecture or workflow! 8

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

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. 3/15/2012 DRAFT WORKING DOCUMENT 10

11 Issues 1. How do we harmonize with ISO 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 3/15/2012 NOTE: EHR S FIM is NOT DRAFT intended WORKING to imply DOCUMENT a specific architecture or workflow! 11

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

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

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 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 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 This work is being done by the HL7 EHR Interoperability Work-group, meeting every Tuesday at 2 PM ET, dial-in: , Passcode: # 3/15/2012 The most current artifacts are at: 14

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 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 For details, see separate slide deck for each EHR S Function. All referenced EHR S Functions are available at: 3/15/2012 NOTE: EHR S FIM is NOT DRAFT intended WORKING to imply DOCUMENT a specific architecture or workflow! 15

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

17 c lass CP.6.2 DEP-2 Manage Immunization Administration CP.6.2 Immunization Management See Also Dependencies (3 Levels) POP.8 De-Identified Data Request Management CP, CPS & AS CP.1.3 Manage Medication List POP.4 Support for Monitoring Response Notifications Regarding a Specific Patient s Health CPS.9.5 Ad Hoc Query and Rendering depends on CPS.4.2 Support for Medication and Immunization Ordering CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List CPS.3.9 Clinical Decision Support System Guidelines Updates CPS.9.3 Health Record Output depends on CPS.7.1 Access Healthcare Guidance CPS.9.4 Standard Report Generation CP.1.6 Manage Immunization List depends on CP.3.1 Conduct Assessments POP.6 Measurement, Analysis, Research and Reports CP.3.3 Manage Clinical Documents and Notes CPS Manage Consents and Authorizations CPS Related by Genealogy CPS Related by Living Situation CP.1.8 Manage Patient and Family Preferences CPS Manage Patient Advance Directives CPS Related by Other Means CP.3.2 Manage Patient Clinical Measurements Start Here CP.6.2 Manage Immunization Administration depends on AS.4.1 Manage Registry Communication depend on Record Infrastructure 3/15/2012 DRAFT WORKING DOCUMENT RED: delete, Blue: insert Trust Infrastructure 17

18 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. 3/15/ RED: Recommended deletion, Blue: Recommended Insertion

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

20 CP.6.2 Manage Immunization Administration Model-of-Context EHR S Components Dependent on Clinician Activities a ct CP.6.2 ACT Manage Immunization Administration NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! Manage Records Manage Trusts Manage Business Rules Encounter EHR-S Components Clinician Activities Start Immunization Schedule Schedule Manage Schedules Event Allergy, Intolerance and Adverse Reaction Event Manage Events Immunization Event depends on CP.6.2 Manage Immunization Administration Clinical Information Advanced Directive Event Manage Terminology Terminology depends on ia-a Immunization List Manage Lists List Registry Registry (Public Health Immunization) depends on Manage Documents & Notes Document or Note Clinical Document or Note Advanced Directive Reminder or Alert End Report 3/15/2012 RED: Recommend deletion, Blue: Recommended Insertion 20

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 Business Rules Manage Records Record Infrastructure Terminology Clinical Information Schedule Immunization Schedule Event List Document or Note Manage Trusts Trust Infrastructure Clinical Document or Note Manage Terminology CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List Allergy, Intolerance and Adverse Reaction Event Allergy, Intolerance and Adverse Reaction List Manage Events CP.1.6 Manage Immunization List Manage Schedules CPS.9.4 Standard Report Generation Registry Manage Lists CPS Manage Patient Advance Directives Advanced Directive Event Advanced Directive CP.3.2 Manage Patient Clinical Measurements Manage Documents & Notes AS.4.1 Manage Registry Communication Registry (Public Health Immunization) CP.6.2 Manage Immunization Administration Immunization Event Immunization List Report 3/15/2012 RED: Recommend deletion, Blue: Recommended Insertion 21

22 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 Terminology Medication Event Advanced Directive Event Medical Device Clinical Information Event Immunization Event Immunization Schedule Encounter has-a 1..* Allergy, Intolerance and Adverse Reaction Event Immunization Witheld Event CDS Update other EHR or related systems has-a 0..* Problem List Registry (Public Health Immunization) List Immunization List Allergy, Intolerance and Adverse Reaction List ia-a Immunization History Medication List Patients Requiring Followup List has-a Document or Note Reminder or Alert Template 0..* Clinical Document or Note Advanced Directive Report Record Infrastructure Trust Infrastructure 3/15/2012 RED: Recommend deletion, Blue: Recommended Insertion 22

23 Immunization Management Capability Information Exchanges Defined-by Conformance Criteria (CC) c lass IE-RT Immunization Management Capability Usage Enumeration - SHALL - SHOULD - MAY EHR-S StandardType Enumeration - content - transport - information assurance - other EHR-S Information-Exchange Metadata - sourcesystem - recipientsystem - releventstandard - standardorganization - standardversion - standardtype - standardrealm - Usage - rational - effectivedate - possiblerisk - harmonizationissue - implementationguide - implementationguideversion Medical Device CP.3.3#07 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! CPS.3.9#01 AS.4.1#02 implemented by CDS-Clinical Decision Support - maintain() SHALL CCs have bolded borders. See individual EHR S Function s slide deck for CC details at: erability_wg 3/15/2012 RED: Recommend deletion, Blue: Recommended Insertion 23 EHR-S - reminders or alerts - Information Exchange Metadata + manage() + Manage 'Do Not Recusitate"() AS.4.1#05 AS.4.1#03 AS.4.1#04 Demographic Information (structured) other EHR or related systems AS.4.1#01 Registry - clinical information - demographic information - organization (source) - patient - provider (source) - type - manage() Registry (Public Health Immunization)

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

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 and Version 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. 3/15/2012 DRAFT WORKING DOCUMENT 25

26 ass RT Advanced Directive 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! SHALL CCs have bolded borders. See individual EHR S Function s slide deck for CC details at: 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.1.7.2#07 CPS.1.7.2#06 CPS.1.7.2#02 CPS.1.7.2#08 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 implemented-by CPS.1.7.2#03 Advanced Directive Type Enumeration - Do Not Recusitate (DNR) Order - Durable Power of Attorney - Living Will - other - Preferred Interventions for Known Conditions Advanced Directive Review 0..* - circumstances 0..* - date - reviewer Document or Note + authenticator + author + date + facility + patient + type + status + render() + capture() + update() + tag() Advanced Directive Author - date signed - name - relationship - time signed 3/15/2012 DRAFT WORKING DOCUMENT 26 CP.3.3#09 CP.3.3#11 CP.3.3#10 CP.3.3#02 CP.3.3#03 CP.3.3#08 Clinical Document or Note - disposition - signature - structured :boolean - manage() + render() + tag() Advanced Directive CP.6.2#02 CP.6.2#06 CP.3.3#05 CP.3.3#07 CP.3.3#14 CP.3.3#15 CP.3.3#17 CP.3.3#04 CP.3.3#12 CP.3.3#01 CP.3.3#16 CPS.1.7.2#05 CPS.2.4 Support Externally Sourced Clinical Images CPS.1.7.2#04 EHR-S other EHR or related systems - reminders or alerts - Information Exchange Metadata + manage() + Manage 'Do Not Recusitate"()

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