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 10, 2012 – Last Update to Working-Draft Call for Participation This work is being done by the HL7 EHR Interoperability Work-group, meeting every Tuesday at 4PM 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 7/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 2 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), HL7 EHR Diabetes project, ISO 13940 Continuity-of-Care System-of Concepts-and-Glossary harmonization are proposed as a set of demonstration prototypes of increasing complexity. 7/21/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) Enterprise Dimension ECCF “Why” - Policy Business • Mission, • Vision, • Scope , Inventory of • Applicable Laws • Contracts • Policies • Procedures • Enterprise Capabilities Conceptual Perspective Business Policies Governance Implementation Guides Design Constraints Organization Contracts Logical Perspective Implementable Perspective 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 | WG Projects | Development Organization See notes page for ECCF description 4 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 5 Immunization Management Capability Scope, (Including Dependent EHR-S Functions) We started with CP6.2 and included its “See Also” dependencies: • 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 6 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/21/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 7 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 8 How should CIMs and CDMs be interpreted? EHR-S Conceptual Information Models (CIMs) are considered informative or exemplary, because they might be interpreted-as or imply a specific architecture; while, Conceptual Data Models (CDMs) are considered normative because they specify the minimum set of required and optional data elements needed for semantic interoperability among functions, components and systems. Neither model type is intended to imply: – An implementation architecture – Internal data structures – Specific information-exchange data-content, transport or security CDMs should be refined into appropriate domain-and-realm specific logicaland-implementable standards-based content, transport and security Interoperability-Specifications for messages, documents and services. 7/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! 9 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) 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/21/2015 RED: Recommended deletion, Blue: Recommended Insertion 10 Immunization Management Capability 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 11 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/21/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 12 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/21/2015 RED: Recommend deletion, Blue: Recommended Insertion Immunization List Report 13 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/21/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 14 CIM 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/21/2015 DRAFT WORKING DOCUMENT 15 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/21/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) 16 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 17 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/21/2015 DRAFT WORKING DOCUMENT 18 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/21/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"() 19 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 20 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 21 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 22 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/21/2015 DRAFT WORKING DOCUMENT CP.1.2# 13 23 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 24 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 25 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/21/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 26 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 27 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/21/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 28 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 29 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. NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 30 7/21/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/21/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 31 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 32 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 33 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/21/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 34 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 35 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/21/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 36 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 37 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 38 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 39 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/21/2015 DRAFT WORKING DOCUMENT CPS.9.4#09 40 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/21/2015 DRAFT WORKING DOCUMENT 41 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/21/2015 DRAFT WORKING DOCUMENT 42 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. • 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. 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 Functions 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 43 Issues 1. 2. How do we harmonize with ISO 13940; aliases (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 How do we incorporate: Quality Measures/ Model Meaningful-use measures Patient outcome measures – – – Criteria to determine the “See Also” Dependencies. – 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/21/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 44 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/21/2015 Reduced Conformance Criteria duplication Increased Conformance Criteria consistency NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! 45 Next Steps / To Do / Help Needed • SMEs verify and validate Conceptual Data Models (CDMs) • Harmonize with – – – – 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) • Create Data Dictionary of CDM attributes – ISO 13940 Continuity-of-Care System-of-Concepts and Glossary • Add Metadata for Terminology Binding • Model the remaining EHR-S Functions – – – – – – – 7/21/2015 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 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 46 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/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 47 Backup Reference Information • • • • 7/21/2015 Glossary of Key Terms EHR-S FIM Verb Hierarchy Observations by reviewers Backup Slides NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 48 Glossary of Key Terms • 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.) – The primary and foreign key for concepts may be specified. – Foreign keys (keys identifying the relationship between different entities) 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/21/2015 DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! 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/21/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/21/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/21/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/21/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/21/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/21/2015 DRAFT WORKING DOCUMENT 55 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 CPS.9.5 Ad Hoc Query and Rendering 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 depends on 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 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/21/2015 RED: delete, Blue: insert 56