1 / 55

Stephen.Hufnagel.ctr@tma.osd.mil , EHR WG Modeling Facilitator Nancy.Orvis@tma.osd.mil , DoD -MHS Proponent February

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. Stephen.Hufnagel.ctr@tma.osd.mil , EHR WG Modeling Facilitator Nancy.Orvis@tma.osd.mil , DoD -MHS Proponent

gazit
Download Presentation

Stephen.Hufnagel.ctr@tma.osd.mil , EHR WG Modeling Facilitator Nancy.Orvis@tma.osd.mil , DoD -MHS Proponent February

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EHR System Function and Information Model (EHR-S FIM) Release 2.1 HL7 Project ID# 688 Executive Summary forEHR-S FIM Immunization Capability Prototype Stephen.Hufnagel.ctr@tma.osd.mil , EHR WG Modeling Facilitator Nancy.Orvis@tma.osd.mil , DoD-MHS Proponent February 9, 2012 – Original Working-Draft March 15, 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 2 PM ET, dial-in: 1-770-657-9270, Passcode: 510269#  The most current artifacts are at: http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG

  2. EHR System Function and Information Model EHR-S FIM Vision The EHR-S FIM vision is that analysts, engineers or testers can efficiently compose and refine the architecture-and-workflow agnostic EHR-S FIM into 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. DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

  3. PART 1: Executive Summary For EHR-S FIM Release 2.1, this prototype has the purpose to • 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 • Service Aware Interoperability Framework (SAIF) DSTU demonstration • Support specific profiles (e.g., DAMs, DIMs, DCMs). The Sparx Enterprise Architect modeling tool is being used to represent the EHR-S FIM and then generate appropriate views, reports, XML and HTML renderings of each EHR-S function’s scenarios, requirements, actors, actions/activities, dependencies, business rules, information & data models. The DoD-VA Joint Immunization Capability (JIC), Pharm.-Lab.-Rad, than ISO 13940 Continuity-of-Care System-of Concepts-and-Glossary harmonization are proposed as a set of demonstration prototypes of increasing complexity. DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

  4. Notional Set of Artifacts within an HL7 SAIF Enterprise Compliance and Conformance Framework (ECCF) ECCF Enterprise Dimension “Why” - Policy Information Dimension “What” - Content Computational Dimension “Who/How” - Behavior Engineering Dimension “Where” - Implementation Technical Dimension “Where” - Deployments Conceptual Perspective • Business • Mission, • Vision, • Scope , • Inventory of • Applicable Laws • Contracts • Policies • Procedures • Enterprise Capabilities • Inventory of Reusable • Entities • Associations • Information • Information Models • Dependencies • Associations • Data Models • Data Dictionary • Mandatory or Optional • Inventory of Reusable • Scenario Events • Business Activities • System Functions • Requirements • Accountability, Roles • Conformance Criteria • Profiles, Behaviors • Interactions and • Info. Exchanges • Requirements Traceability • Inventory of • SW Platforms, Layers • SW Environments • SW Components • SW Services • Technical Requirements • Enterprise Service Bus • Key Performance Parameters • Inventory of • HW Platforms • HW Environments • Network Devices • Communication Devices • Technical Requirements Logical Perspective • Business Policies • Governance • Implementation Guides • Design Constraints • Organization Contracts • Information Models • Domain IM • Detailed Clinical • Terminology binding • Value Set binding • Content Specifications • CCD • RMIM • Specifications • Scenario & Use Cases • Components Interfaces • Collaboration Actors • Collaboration Types • Collaboration Roles • Function Types • Interface Types • Service Contracts • Models, Capabilities, Features and Versions for • SW Environments • SW Capabilities • SW Libraries • SW Services • SW Transports • Models, Capabilities, Features and Versions for • HW Platforms • HW Environments • Network Devices • Communication Devices • Implementable Perspective • Business Nodes • Business Rules • Business Procedures • Business Workflows • Technology Specific Standards • Schemas for • Databases • Messages • Documents • Services • Transformations • Automation Units • Technical Interfaces • Technical Operations • Orchestration Scripts • SW Specifications for • Applications • GUIs • Components • SW Deployment Topologies • HW Deployment Specifications • HW Execution Context • HW Application Bindings • HW Deployment Topology • HW Platform Bindings Responsibility: Sponsoring Organization | EHR-S FIM| Work Groups / Projects | Vender / Development Organization 3/15/2012 See notes page for ECCF description

  5. EHR-FIMModel Legend NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT

  6. Information Model Types • Conceptual Modelsare typically human readable though there are ways to build conceptual models that systems can process, such as, the Web Ontology Language (OWL). • A Conceptual Information Model identifies the highest-level concepts in a domain (e.g., EHR) and their relationships; however, no attributes are specified. • A Conceptual Data Model (CDMs) specifies data entities and their data elements, without regard to how they will be physically implemented. • Sub-domain and realm-specific CDMs (profiles) typically include the following: • All concepts and their relationships are defined. • All attributes for each concept are specified • date element optionality (e.g., MAY or SHOULD) is removed. • Business terms for concepts and attributes are agreed upon and used. (These terms should be part of the agreed upon common terminology, which may vary by domain-and-realm.) • Primary keys (keys identifying specific entities within a class) for concepts may be specified. • Foreign keys (keys identifying the relationship between different entities) among concepts may be specified. • Normalization, based on reusable components, may occur. • Terminology (code and value sets) binding may occur. • Logical Data Models are fully-qualified to be transformed into deterministic and testable physical schema for a specific implementation. NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

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

  8. 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 : • Create Activity Model for the function, based on conformance criteria. • 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 • Bold SHALL conformance criteria to expedite test traceability • Indicate SHALL attributes or operations as “public” with a proceeding “+” • Indicate SHOULD or MAY attributes or operations as “private” with a proceeding “-” • Create Conceptual Information Model (CIM) view from step 2. • Show supporting EHR-S Function associations and dependencies. • Map EHR-S Components to supporting EHR-S Functions (“See Also” Dependencies) • Show Conformance Criteria (CC) Requiring Specific Information Exchanges This Executive Summary was created from the resultant model. DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

  9. ObservationWhere 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. DRAFT WORKING DOCUMENT

  10. Issues • How do we harmonize with ISO 13940 … synonyms (clinician vs. Health care professional)? • What is normative within the EHR-S Information Model. • Activity Diagrams map operational-activities to system components-and-functions. • Recommend informative • Conceptual Information Models • set of applicable components and their relationships … • Recommend informative • Conceptual Data Models ( attributes and operations within components) • Recommend normative • Distinguish between elements derived from SHALLs vs. those from SHOULDs and MAYs • Remove data element conformance criteria from EHR-S Functional Model • How do we incorporate: • Quality Measures/ Model • Meaningful-use measures • Patient outcome measures • Criteria to automatically determine the “See Also” Dependencies from models. • EHR-S Function dependency on other Functions’ conformance criteria • Shared activities & tasks within multiple EHR-S Functions • How will we represent the Information Models for Ballot. • Tool generated report showing model views (e.g., similar to Immunization Prototype) • Benefit: maximum completeness and consistency • Will ISO accept graphics? • Textural listing of components and data elements similar to • HITSP/C83 CDA Content Modules and • HITSP/C154 Data Dictionary DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

  11. RecommendationsBased on Immunization Management Prototype • Add the following functions and components to EHR-S FIM : • 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 • Remove data elements from Functions’ Conformance Criteria. • Organize EHR-S FM CP-section hierarchically. • 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: • Reduced Conformance Criteria duplication • Increased Conformance Criteria consistency NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

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

  13. To Do … Help Needed • SMEs verify and validate Conceptual Data Models (CDMs) • Conformance criteria vs. component operations-and-attributes • Create Data Dictionary of CDM Components and attributes • EHR-S FIM Data Dictionary for components & attributes (similar to HITSP C83, C154). • Start with ISO 13940 Continuity-of-Care System-of-Concepts and Glossary • Add Metadata for Terminology Binding • Harmonize Conceptual Data Models (CDMs) with • HL7 Reference Information Model (RIM) • US Federal Health Information Model (FHIM) • ISO 13940 Continuity-of-Care System-of Concepts-and-Glossary. • HL7 PHER Immunization Domain Analysis Model (DAM) • HL7 Patient Care & IHTSDO-CIMI Immunization Detailed Clinical Models (DCMs) • Allergies Intolerance project. • Care Plan project • Model the remaining EHR-S Functions • Overarching (O) – 2 major subsections • Care Provision (CP) – 9 major subsections • Care Provision Support (CPS) – 9 major subsections • Population Health Support (POP) – 10 major subsections • Administrative Support (AS) – 9 major subsections • Record Infrastructure (RI) – 3 major subsections • Trust Infrastructure (TI) – 9 major subsections Call for Participation This work is being done by the HL7 EHR Interoperability Work-group, meeting every Tuesday at 2 PM ET, dial-in: 1-770-657-9270, Passcode: 510269#  The most current artifacts are at: http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG

  14. PART 2: Immunization Management CapabilitySpecified by EHR-S FIM CP.6.2 Manage Immunization Administration, depends on • 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 DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

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

  16. CP.6.2 Immunization Management“See Also” Dependencies (3 Levels) Start Here  DRAFT WORKING DOCUMENT RED: delete, Blue: insert

  17. CP.6.2 Manage Immunization Administration Statement: Capture and maintain discrete data concerning immunizations given to a patient including date administered, type, manufacturer, lot number, and any allergic or adverse reactions. Facilitate the interaction with an immunization registry to allow maintenance of a patient’s immunization history. Description: During an encounter, recommendations based on accepted immunization schedules are presented to the provider. Allergen and adverse reaction histories are checked prior to giving the immunization. If an immunization is administered, discrete data elements associated with the immunization including date, type, manufacturer and lot number are recorded. Any new adverse or allergic reactions are noted. If required, a report is made to the public health immunization registry or other organization (e.g. military unit commander, refugee program leadership). Example: (notional scenario based on conformance criteria) During an encounter, recommendations based on accepted immunization schedules and previous adverse or allergic reactions are presented to the clinician. If an immunization is administered, discrete data elements associated with the immunization are recorded and any new adverse or allergic reactions are noted. Patient Immunization and demographic information is harmonized-with and reported-to the appropriate public health immunization registries, patients and organizations (e.g., PHRs, schools, other providers), according to scope of practice, organizational policy and/or jurisdictional law. RED: Recommended deletion, Blue: Recommended Insertion

  18. Immunization Management Capability Resultant Models • CP.6.2 EHR-S Components Dependent-on Clinician-Activities • CP.6.2 Manage Immunization Administration Traceability • 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 • CDM for Report CC is Conformance Criteria CIM is Conceptual Information Model CDM is Conceptual Data Model DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

  19. CP.6.2 Manage Immunization AdministrationEHR-S Components Dependent-on Clinician-Activities NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! RED: Recommend deletion, Blue: Recommended Insertion

  20. CP.6.2 Manage Immunization Administration TraceabilityEHR-S Components Dependent-on Functions; Dependent-0n Clinician-Activities RED: Recommend deletion, Blue: Recommended Insertion

  21. Immunization Management CapabilityConceptual Information Model (CIM) NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! RED: Recommend deletion, Blue: Recommended Insertion

  22. Immunization Management Capability Information Exchanges Defined-by Conformance Criteria (CC) NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! SHALL CCs have bolded borders. See individual EHR-S Function’s slide deck for CC detailsat: http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG RED: Recommend deletion, Blue: Recommended Insertion

  23. Immunization Management Information ExchangeConformance 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. DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

  24. Immunization Standards-based InteroperabilityUS 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 ImmunizationData 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. DRAFT WORKING DOCUMENT

  25. CDM for Advanced DirectiveConformance Criteria (CC) Applicable to this CDM NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! SHALL CCs have bolded borders. See individual EHR-S Function’s slide deck for CC detailsat: http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG DRAFT WORKING DOCUMENT

  26. Advanced DirectiveConformance 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). DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

  27. Advanced DirectiveConformance Criteria (CC) Applicable to this CDM • CP.3.3#12The 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. DRAFT WORKING DOCUMENT RED: Recommend deletion, Blue: Recommended Insertion

  28. Advanced DirectiveConformance Criteria (CC) Applicable to this CDM • CPS.1.7.2#01The 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. DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

  29. CDM for Allergy, Intolerance and Adverse Reaction EventConformance Criteria (CC) Applicable to this CDM NOTE: EHR-S FIM is NOT intended to imply an architecture or workflow! SHALL CCs have bolded borders. See individual EHR-S Function’s slide deck for CC detailsat: http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG DRAFT WORKING DOCUMENT

  30. Allergy, Intolerance and Adverse Reaction EventConformance 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". DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

  31. Allergy, Intolerance and Adverse Reaction EventConformance Criteria (CC) Applicable to this CDM • CP.1.2#19The 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). DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

  32. CDM for Clinical Decision SupportConformance Criteria (CC) Applicable to this CDM NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! SHALL CCs have bolded borders. See individual EHR-S Function’s slide deck for CC detailsat: http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG RED: Recommend deletion, Blue: Recommended Insertion

  33. Clinical Decision SupportConformance 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. DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

  34. CDM for Clinical Document or NoteConformance Criteria (CC) Applicable to this CDM SHALL CCs have bolded borders. See individual EHR-S Function’s slide deck for CC detailsat: http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG DRAFT WORKING DOCUMENT

  35. Clinical Document or NoteConformance 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). DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

  36. Clinical Document or NoteConformance 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#15The 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. DRAFT WORKING DOCUMENT RED: Recommend deletion, Blue: Recommended Insertion

  37. CDM for EventConformance Criteria (CC) Applicable to this CDM SHALL CCs have bolded borders. See individual EHR-S Function’s slide deck for CC detailsat: http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT

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

  39. EventConformance Criteria (CC) Applicable to this CDM • CP.1.2#15The 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#02The 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. DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

  40. CDM for ListConformance Criteria (CC) Applicable to this CDM NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! SHALL CCs have bolded borders. See individual EHR-S Function’s slide deck for CC detailsat: http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG DRAFT WORKING DOCUMENT

  41. ListConformance 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). DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

  42. CDM for Immunization EventConceptual Conformance Criteria (CC) Applicable to this CDM SHALL CCs have bolded borders. See individual EHR-S Function’s slide deck for CC detailsat: http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! DRAFT WORKING DOCUMENT

  43. Immunization EventConformance 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). DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

  44. Immunization EventConformance Criteria (CC) Applicable to this CDM • CP.3.3#19The 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. DRAFT WORKING DOCUMENT RED: Recommend deletion, Blue: Recommended Insertion

  45. Immunization EventConformance Criteria (CC) Applicable to this CDM • CP.6.2#17The 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. DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

  46. CDM for ReportConceptual Conformance Criteria (CC) Applicable to this CDM NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow! SHALL CCs have bolded borders. See individual EHR-S Function’s slide deck for CC detailsat: http://wiki.hl7.org/index.php?title=EHR_Interoperability_WG DRAFT WORKING DOCUMENT

  47. CDM for ReportConceptual Conformance Criteria (CC) Applicable to this CDM 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#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#12 The system SHOULD harmonize Immunization histories with a public health immunization registry according to scope of practice, organizational policy and/or jurisdictional law. CP.6.2#13 The system SHOULD capture and render immunization histories from a public health immunization registry. 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. 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. 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. CPS.9.4#03 The system SHOULD provide the ability to extract and transmit reports generated. 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. DRAFT WORKING DOCUMENT

  48. CDM for ReportConceptual Conformance Criteria (CC) Applicable to this CDM 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. 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 CPS.9.4#07 The system SHOULD provide the ability to render automated reports as required by industry and regulatory bodies. CPS.9.4#08 The system SHOULD provide the ability to extract facility level data at an organizational level in support of organizational initiatives. CPS.9.4#09 The system MAY provide the ability to render a cumulative directory of all personnel who use or access the data. DRAFT WORKING DOCUMENT

  49. BackupReference Information • EHR-S FIM Verb Hierarchy • Observations by reviewers • Backup Slides DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

  50. EHR-S FIMAction Verb Hierarches DRAFT WORKING DOCUMENT NOTE: EHR-S FIM is NOT intended to imply a specific architecture or workflow!

More Related