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 4, 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., WG project 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 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 EHR-S FM Release 2.0 Sections • 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 4 Immunization Management Capability Scope, (Including Dependent EHR-S Functions) We started with CP6.2 and included its dependencies: 1. CP.6.2 Manage Immunization Administration 2. CP.1.6 Manage Immunization List 3. CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List 4. CP.1.3 Manage Medication List 5. CP.3.3 Manage Clinical Documents and Notes 6. CPS.1.7.2 Manage Patient Advance Directives 7. CPS.3.9 Clinical Decision Support System Guidelines Updates 8. CPS.9.4 Standard Report Generation 9. AS.4.1 Manage Registry Communication 10. Record 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 11. Trust Infrastructure 7/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 5 Immunization Management Capability Models 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. CP.6.2 Clinician-Activities Mapped-to System-Components CP.6.2 Conceptual Information Model (CIM) Mapped-to EHR-S Functions CIM for Immunization Management Capability Information Exchanges Mapped-to Conformance Criteria 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 Lists CDM for Immunization Event CC is Conformance Criteria 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 6 EHR-FIM Model Legend class Legend Clinician Perspective 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 The complete semantics of the depending elements is either semantically or structurally dependent upon the definition of the supplier element(s). Business Activity Corresponding to EHR-S Function control flow control flow Task within Activity Start Activity End Activity depends on EHR-S Component Encounter depends on Syatem Component 3 System Component + - attribute 2 [SHALL CC] attribute 1 [SHOULD or MAY CC] + - operation [SHALL CC]() operation 2 [SHOULD or MAY CC]() association system component 4 has-a (part) aggregation is-a (type) generalization System Component 2 EHR-S Function implemented-by «trace» FEATURE: EHR-S Function depends on FEATURE 2 realization "implements" REQUIREMENT: Conformance Criteria (CC) 7/21/2015 DRAFT WORKING DOCUMENT 7 EHR-FIM Description of Model Diagrams “Clinician-Activities Mapped-to System-Components” shows • Row 1: operational activities performed by the clinician, indicating dependencies on • Row 2: The EHR System components, which support the clinician’s activities. “CIM Mapped-to EHR-S Functions” shows • System Components Mapped-to the EHR-S Functions they support “Conceptual Data Model (CDM)” shows • Attributes & operations for System Components. “Information Exchanges mapped-to Conformance Criteria” shows • Conformance Criteria requiring specific information exchanges “CDM Requirements-Traceability” shows • Conformance Criteria requiring specific attributes and operations within a Component 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 recommended to be 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 As part of the interoperability specification process, the CDMs must be refined to support appropriate domain and realm specific message, document and service content, transport and security (ideally) standardsbased interoperability-specifications. 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 demographic information is harmonized with and reports are made to the appropriate public health immunization registries and organizations (e.g., PHRs, schools), according to scope of practice, organizational policy and/or jurisdictional law. 7/21/2015 RED: Recommend deletion, Blue: Recommended Insertion 10 CP.6.2 Manage Immunization Administration EHR-S Components Dependent-on Clinician-Activities NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! Clinician act CP.6.2 ACT Manage Immunization Administration Manage Records Manage Trusts Manage Business Rules depends on depends on depends on CP.6.2 Manage Immunization Administration Manage Events Manage Terminology Manage Lists Manage Documents & Notes Terminology List Document or Note Encounter Start Manage Schedules EHR-S Components Schedule is-a Immunization Schedule 7/21/2015 Event is-a is-a Allergy, Intolerance and Adverse Reaction Event Immunization Event Advanced Directive Event ia-a Immunization List End is-a Registry is-a Clinical Document or Note is-a Registry Immunization (Public Health) RED: Recommend deletion, Blue: Recommended Insertion Advanced Directive is-a Report 11 CP.6.2 Manage Immunization Administration EHR-S Components Dependent-on EHR-S Functions Dependent-0n Activities act CP.6.2 ACT-3 Manage Immunization Administration CP.6.2 Manage Immunization Administration Manage Business Rules Schedule Terminology Manage Records Record Infrastructure Immunization Schedule Manage Trusts Manage Terminology Manage Events Manage Schedules Manage Lists Trust Infrastructure Event CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List Allergy, Intolerance and Adverse Reaction Event List Allergy, Intolerance and Adverse Reaction List Document or Note Clinical Document or Note CP.1.6 Manage Immunization List CPS.9.4 Standard Report Generation CPS.1.7.2 Manage Patient Advance Directives Advanced Directive Event Advanced Directive Registry CP.3.2 Manage Patient Clinical Measurements Manage Regestries Registry Immunization (Public Health) AS.4.1 Manage Registry Communication Manage Documents & Notes 7/21/2015 CP.6.2 Manage Immunization Administration Immunization Event RED: Recommend deletion, Blue: Recommended Insertion Immunization List Report 12 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 System Medical Device Clinical Information Registry other EHR or related systems Registry - Immunization (Public Health) Encounter 1..* has-a has-a Event Immunization Event Medication Event is-a Advanced Directive Event Immunization Schedule Terminology is-a List is-a is-a Allergy, Intolerance and Adverse Reaction Event Immunization Witheld Event CDS Update Document or Note ia-a Immunization List Allergy, Intolerance and Adverse Reaction List Problem List is-a is-a Clinical Document or Note Medication List is-a Patients Requiring Followup List Immunization History Reminder or Alert Template is-a Advanced Directive is-a Report Trust Infrastructure Record Infrastructure 7/21/2015 0..* has-a 0..* is-a is-a is-a RED: Recommend deletion, Blue: Recommended Insertion 13 Immunization Management Capability Information Exchanges Mapped-to Conformance Criteria (CC) class IE-RT Immunization Management Capability NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! 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 CDS-Clinical Decision Support - maintain() standardUsage Enumeration - SHALL - SHOULD - MAY StandardType Enumeration - content transport information assurance other 7/21/2015 EHR-System Information-Exchange Metadata - sourceSystem recipientSystem releventStandard standardOrganization standardVersion standardType standardUsage standardRealm rational effectiveDate possibleRisk harmonizationIssue implementationGuide implementationGuideVersion Medical Device has-a AS.4.1#04 EHR System 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 Immunization (Public Health) 14 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 15 Advanced Directive Conformance Criteria (CC) Applicable to this CDM NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! class RT Advanced Directive CPS.1.7.2#03 Event + + - CP.3.3#09 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#02 CPS.1.7.2#08 CPS.1.7.2#07 CPS.1.7.2#06 7/21/2015 SHALL CCs have bolded borders. See individual EHR-S Function’s slide deck for CC details at: http://wiki.hl7.org/index.php?title=E HR_Interoperability_WG CP.3.3#11 Document or Note CPS.1.7.2#01 + + + + + + + authenticator author date facility patient type status + + + + render() capture() update() tag() CP.3.3#10 CP.3.3#02 Advanced Directive Event + + + + + + + + + + + + CP.3.3#08 CP.6.2#06 is-a 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) Advanced date (recinded) Directive Review 0..* date (review) - circumstances date (signed/completed) 0..* - date date (updated) - reviewer Review type CP.6.2#02 CP.3.3#05 Advanced Directive Type Enumeration - CP.3.3#03 CP.3.3#07 Clinical Document or Note - disposition - signature - structured :boolean - date signed name relationship time signed CP.3.3#17 other EHR or related systems CP.3.3#12 is-a Advanced Directive DRAFT WORKING DOCUMENT CP.3.3#15 CP.3.3#04 - manage() + render() + tag() Advanced Directive Author CP.3.3#14 CP.3.3#01 EHR System CP.3.3#16 - reminders or alerts - Information Exchange Metadata CPS.1.7.2#05 CPS.1.7.2#04 + manage() + Manage 'Do Not Recusitate"() 16 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 17 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 18 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 19 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! Clinical I nformation - type CP.6.2# 09 CP.1.2# 04 CP.1.2# 16 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() 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 20 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 21 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 unization. • 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 22 Clinical Decision Support Conformance Criteria (CC) Applicable to this CDM class RT Clinical Decision S upport (CDS ) 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 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! 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 23 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 24 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 25 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 26 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 27 7/21/2015 Event Conformance Criteria (CC) Applicable to this CDM class RT Event Trigger Enumeration - Terminology - drug environment food other Clinical Information code set + manage() - type 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.1.3#08 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! CP.1.3#13 Person-Role - Demographic Information - date & Time identifier location Clinical Document or Note - Demographic Information (structured) disposition signature structured :boolean - manage() + render() + tag() Event-Status Enumeration - 7/21/2015 person identifier role active completed deactive erroneously captured pending Event Type Enumeration Event 1..* 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() 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 - 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 CP.1.6#02 DRAFT WORKING DOCUMENT 28 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 29 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 30 Lists 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 31 Lists 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 32 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 33 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 34 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 jurisdictiona • 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 35 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 36 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 37 Issues 1. Should we / how do we harmonize with ISO 13940? 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 3. Criteria to determine the “See Also” Dependencies. – EHR-S Function dependency on other Functions’ conformance criteria – Shared activities & tasks within multiple EHR-S Functions 4. How will we represent the Information Model for Ballot. – – 7/21/2015 Tool generated report showing models (e.g., similar to Immunization Prototype) • Will ISO accept this? • • 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 38 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! 39 Recommendations • EHR-S FIM needs the following additional functions and components: 1. 2. 3. Manage Business Rules Clinical Decision Support (CDS) EHR-System Metadata for realm-specific Information-Exchange Standards • Make EHR-S Conceptual Data Model (CDM) Normative 1. Remove data elements from Conformance Criteria. • EHR-S FM CP-section should be hierarchically organized. 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! 40 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 be composed into higher level capabilities by functional analysts and system engineers – Encourage reuse of EHR-S FIM components – Avoid duplication and “stovepipe applications” • EHR-S FIM can populate portions of the HL7 SAIF for WGs – Information and Computational Dimensions – Conceptual Perspective • 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 41 Next Steps / To Do / Help Needed • SMEs verify and validate Conceptual Data Models (CDMs) • 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 7/21/2015 NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 42 Reference Information • • • • • 7/21/2015 Glossary of Key Terms EHR-S FIM Verb Hierarchy HL7 SAIF Enterprise Compliance and Conformance Framework (ECCF) Observations by reviewers Backup Slides NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT 43 Glossary of Key Terms • A Conceptual Information Model identifies the highest-level concepts in a domain and the relationships between each concept; however, no attributes are specified and no primary key is specified. 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). http://www.w3.org/TR/owl-features/ • A Conceptual Data Model describes the data, without regard to how the data will be physically implemented in the database. Features typically include the following: – All concepts and relationships between them are defined. – Key attributes for each concept are specified. – 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 key for each concept is specified. – Foreign keys (keys identifying the relationship between different entities) are specified. – Normalization, based on reusable components, can occur at this level. 7/21/2015 DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! 44 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 45 Notional Set of HL7 Artifacts within a SAIF Enterprise Compliance and Conformance Framework (ECCF) ECCF Conceptual Perspective Logical Perspective Implementable Perspective Enterprise Dimension “Why” - Policy 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 Data Models Inventory of Reusable • Scenarios • Business Activities • System Functions Requirements • Accountability, Roles • Conformance Criteria • Profiles, Behaviors • Interactions and • Info. Exchanges 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 Business Policies Governance Implementation Guides Design Constraints Organization Contracts Information Models • Domain IM • Detailed Clinical Terminologies Value Sets Content Specifications • CCD • RMIM Specifications • Scenario Events • Use Cases • Workflow 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 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 Business • Mission, • Vision, • Scope , Inventory of • Contracts - PSSs • Capabilities - RIM • Policies • Procedures Responsibility: HL7 Organization | EHR-S FIM | HL7 WG Projects | Development Organization See notes page for ECCF description 46 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 47 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 48 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 49 CP.6.2 Manage Immunization Administration EHR-S Components Dependent-on EHR-S Functions NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! class CP.6.2 CI M Manage I mmunization Administration CP, CPS & AS List Registry Clinical Document or Note Document or Note Registry I mmunization (Public Health) Advanced Directive AS.4.1 Manage Registry Communication Encounter Terminology Event I mmunization List Schedule Report I mmunization History CPS.9.4 Standard Report Generation I mmunization Event CPS.1.7.2 Manage Patient Advance Directives Allergy, I ntolerance and Adverse Reaction Event CP.3.2 Manage Patient Clinical Measurements CP.6.2 Manage Immunization Administration CP.1.6 Manage Immunization List CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List Trust I nfrastructure 7/21/2015 Record I nfrastructure RED: Recommend deletion, Blue: Recommended Insertion 50 CP.6.2 Manage Immunization Administration Components Mapped-to Requirements req CP.6.2 RT Manage Immunization Administration Encounter NOTE: SHALL conformance criteria have bolded borders - differential diagnosis disposition follow up activities follow up needed :boolean follow up results type + manage() 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. 0..* List 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. - define sort restrictions() define sort criteria() filter() link to problem-treatment() manage() manage reason for change () sort() + manage() depends on CP.6.2#11 The system SHOULD exchange immunization histories with public health immunization registries according to scope of practice, organizational policy and/or jurisdictional law. 7/21/2015 CP.1.2 Manage Allergy, Intolerance and Adverse Reaction List ia-a depends Immunization List on Registry Immunization (Public Health) + + depends on CP.6.2#14 The system SHALL conform to function CP.1.6 (Manage Immunization List). analyze() manage() is-a CP.6.2#13 The system SHOULD capture and render immunization histories from a public health immunization registry. CP.6.2#07 The system SHALL provide the ability to maintain the immunization schedule. Immunization Schedule Immunization History + - CP.6.2#15 The system SHOULD provide the ability to update immunization histories at the time of capturing an immunization administration. render() harmonize() capture() exchange() update() Allergy, Intolerance and Adv erse Reaction Ev ent depends on CP.1.6 Manage Immunization List 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. CP.6.2#17 The system SHALL provide the ability to determine due and overdue ordered immunizations and render a notification. DRAFT WORKING DOCUMENT - data of review reaction type severity type + manage() CP.6.2#04 The system SHOULD provide the ability to capture, in a discrete field, an allergy/adverse reaction to a specific unization. CP.6.2#09 The system SHALL conform to function CP.1.2 (Manage Allergy, Intolerance and Adverse Reaction List). 51 CP.6.2 Manage Immunization Administration Components Mapped-to Requirements req CP.6.2 RT Manage Immunization Administration CP.6.2#02 T he system MAY auto-popul ate the i mmuni zati on admi ni strati on record as a by-product of veri fi cati on of admi ni steri ng provi der, pati ent, medi cati on, dose, route and ti me accordi ng to scope of practi ce, organi zati onal pol i cy and/or j uri sdi cti ona Ev ent + + - date (occurence) ti me (occurence) change j usti fi cati on ci rcumstances cl i ni cal i nformati on date (entry) date (revi ew) descri pti on durati on i nformati on revi ewed i nformati on source i nformati on val i dator l ocati on mechani sm metadata person-rol e status tri gger type + + + deacti vate() j usti fy() manage() CP.6.2#21 T he system SHALL provi de the abi l i ty to capture the recei vi ng enti ty (e.g., pati ent, representati ve, organi zati on) when pati ent educati on i nformati on i s provi ded at the ti me of i mmuni zati on admi ni strati on. CP.6.2#06 T he system SHOULD provi de the abi l i ty to l i nk standard codes (e.g. NDC, LOINC, SNOMED or CPT ) wi th di screte data el ements associ ated wi th an i mmuni zati on. Medi cati on Admi ni strati on? Terminology - code set + manage() Immunization Ev ent i s-a CP.6.2#05 T he system SHALL conform to functi on CP.3.2 (Manage Pati ent Cl i ni cal Measurements) to capture other cl i ni cal data perti nent to the i mmuni zati on admi ni strati on (e.g., vi tal si gns). 7/21/2015 + + + date (recommended booster) dose educati onal i nformati on recei ved :bool ean encounter future booster heal thcare organi zati on i mmuni zati on order i mmuni zati on provi der i mmuni zati on type j usti fi cati on-i mmuni zati on refusal l ot manufacturer ordered i mmuni zati on due date recei pt of i mmuni zati on preference recei vi ng enti ty (educati onal i nformati on) refusal of vacci ne type route of admi ni strati on ti me (admi ni strati on) type seri es (i mmuni zati on) CP.3.2 Manage Pati ent Cl i ni cal Measurements NOTE: SHALL conformance criteria have bolded borders DRAFT WORKING DOCUMENT CP.6.2#18 T he system SHALL provi de the abi l i ty to render a pati ent educati onal i nformati on regardi ng the admi ni strati on (e.g., Vacci ne Informati on Statement (VIS)). CP.6.2#19 T he system SHALL provi de the abi l i ty to capture that pati ent educati onal i nformati on (e.g., VIS) was provi ded at the ti me of i mmuni zati on admi ni strati on. CP.6.2#01 T he system SHALL provi de the abi l i ty to capture, mai ntai n and render i mmuni zati on admi ni strati on detai l s as di screte data, i ncl udi ng:(1) the i mmuni zati on name/type, strength and dose;(2) date and ti me of admi ni strati on;(3) manufacturer, l ot numb CP.6.2#23 T he system SHOULD provi de the abi l i ty to capture pati ent preferences regardi ng recei pt of i mmuni zati on (e.g. refusal of certai n vacci ne types) at ti me of i mmuni zati on admi ni strati on. CP.6.2#22 T he system SHOULD provi de the abi l i ty to capture and mai ntai n i mmuni zati on refusal reasons as di screte data. CP.6.2#20 T he system SHALL provi de the abi l i ty to capture documentati on that pati ent educati onal i nformati on (e.g., VIS) was provi ded at the ti me of i mmuni zati on admi ni strati on. CP.6.2#16 T he system SHALL provi de the abi l i ty to render the i mmuni zati on order as wri tten (i .e., exact cl i ni ci an order l anguage) when renderi ng admi ni strati on i nformati on. CP.6.2#10 T he system SHOULD transmi t requi red i mmuni zati on admi ni strati on i nformati on to a publ i c heal th i mmuni zati on regi stry accordi ng to scope of practi ce, organi zati onal pol i cy and/or j uri sdi cti onal l aw. 52 Immunization Management Capability CP.6.2 Manage Immunization Administration Dependencies 7/21/2015 DRAFT WORKING DOCUMENT 53 CP.6.2 Immunization Management “See Also” Dependencies DRAFT WORKING DOCUMENT 7/21/2015 RED: delete, Blue: insert 54