CALL FOR PARTICIPATION Please post your discussion comments at http://www.osehra.org/group/architecture This DRAFT document is a Request for Information (RFI) EHR Modernization EHR Services Platform (ESP) Conceptual Architecture - Software.
Download ReportTranscript CALL FOR PARTICIPATION Please post your discussion comments at http://www.osehra.org/group/architecture This DRAFT document is a Request for Information (RFI) EHR Modernization EHR Services Platform (ESP) Conceptual Architecture - Software.
CALL FOR PARTICIPATION Please post your discussion comments at http://www.osehra.org/group/architecture This DRAFT document is a Request for Information (RFI) EHR Modernization EHR Services Platform (ESP) Conceptual Architecture - Software Development Kit (SDK) Open Source EHR Custodial Agent (OSEHRA) Architecture Committee Stephen Hufnagel PhD, Chair In collaboration with Health Architecture Interagency Group (HAIG) Nancy Orvis, MHA, CPHMS and Paul Tibbits, M.D., DoD and VA Co-Chairs Current 180+ slide set Conceptual Architecture SDK and companion Implementation Guide (IG) is available at: http://www.osehra.org/node/47/content/documents October 18, 2011 DRAFT-N ESP SDK WORKING DRAFT RFI: not for official use. 1 Preface In March 2011, VA Secretary Eric Shinseki and DOD Secretary Robert Gates agreed on a common Electronic Health Record (EHR) technical architecture, data and services and exchange standards for the joint integrated EHR system, where the joint EHR will include both proprietary and open source software. The secretaries of the Veterans Affairs and Defense Departments met on May 2 and June 30, 2011 to determine their next steps toward developing a common EHR.. “VA is developing an open source track to modernize VistA and will incorporate the approach in the joint EHR", Shinseki said. “One of my objectives is to have minimal disruption in the hospitals as we evolve from VistA to the joint EHR system What I think you will see us do is replace modules, do incremental upgrades.” … “In five or 10 years, there may not be one line of code left from VistA. And in my ideal world, the users will have no idea that I have made any changes,” VA Secretary Eric Shinseki said. “Our goals are to bring in as many private sector modules as possible and selecting the same thing to run between VA and DOD so that we end up with a single, common electronic health record system,” Roger Baker, VA CIO said. OSEHRA sees private modules including both open source or commercial; OSEHRA intends to foster innovation at the module level and encourages Darwinian selection among competing modules based on cost, performance and support preferences. "We planned, as part of this EHR framework, to release all the documents, architecture, all these things. It will no longer be, 'you figure it out, you tell us a solution,'" said Col. Hon Pak, the Army medical department's chief information officer. "The opensource custodial agent, largely a VA-led effort but we also participate, really gives you an opportunity in ways that we've never had before." … "Having that venue now equalizes the playing ground so that small, innovative organizations can come and help us figure things out." said Pak. Opening the door to nimble, innovative technologies is a core focus for Pak, who said “DoD is looking for more modular capabilities.” All the Services "have pretty much bet the farm" that patient-centered medical home will change healthcare, but he said they need the right tools to get there. "This idea around [health information exchange], telehealth, mobile health, patient-centered medical home are really going to be the necessary ingredients that have to be formulated to drive some of the transformation," Col. Pak said. This Software Development Kit (SDK) specifies the EHR Services Platform (ESP) to implement the vision expressed above . 2 ESP SDK WORKING DRAFT RFI: not for official use. 2 Executive Summary SAIF (Service Aware Interoperability Framework) Conceptual Perspective EHR Services Platform SDK Scope Business Context Clinical/Work Process Architecture System Architecture Information Architecture Integration & Deployment Options Potential Applications Summary & Conclusion Also See Companion SAIF Logical Perspective Implementation Guide (IG) ESP SDK WORKING DRAFT RFI: not for official use 3 TALKING POINTS: SDK Purpose ESP enabled systems are a part of a joint DoD-VA Open Source EHR (OSEHR) Initiative • The ESP Software Development Kit (SDK) presents the vision (this slide deck) and specifies the means (see the companion ESP Implementation Guide (IG)) for Open Source and vender applications to plug-&-play within future-state ESP enabled operating and data-access platforms; ESP enabled systems are composed of “information” services supporting efficient plug-&-play application-integration. • The SDK development, following agile processes, is intended to become a clear, complete, concise, correct and consistent HL7 SAIF (Service Aware Interoperability Framework) conformant standards-based ESP enabled system SDK IG for vender and open-source developers. • This comprehensive set of slides may be freely used or repurposed with appropriate attribution YOUR HELP IS REQUESTED IN VERIFYING, VALIDATING AND INCREASING THE USABILITY OF THE ESP SDK 4 ESP SDK WORKING DRAFT RFI: not for official use. 4 A five-color star “branding” indicates that a slide was adapted from Canada Health Infoway’s EHR Blueprint ACKNOWLEDGEMENT This ESP SDK started with the Canada Health Infoway “Electronic Health Record Blueprint” as a foundation; the SDK is being adapted to meet the Open Source EHR modernization situation and needs. https://www.infoway-inforoute.ca/working-with-ehr/knowledgeway/knowledge-center/657 ESP SDK WORKING DRAFT RFI: not for official use. 5 DISCLAIMER THIS DRAFT SDK IS NOT LEGALLY BINDING AND DOES NOT REPRESENT OFFICIAL DOD OR VA POSITION. • The DoD and VA wish to openly-and-transparently collaborate with the Open-Source EHR-Community; this is a new “agile acquisition” approach for the government and MUST evolve with lessons learned. • This SDK, its companion Implementation Guide (IG) and related artifacts are DRAFT Working Documents, being coordinated by the Open Source EHR Custodial Agent (OSEHRA) Architecture Committee with the guidance of the DoD-VA Health Architecture Interagency Group (HAIG). The purpose is to seek EHR-modernization architectural-input from DoD & VA staff, contractors, partners, stakeholders, venders and open-source-community in an open-and-transparent collaborative-forum; • The DRAFT Software Development Kit (SDK), its IG and any related documents MUST be considered a government Request for Information (RFI); without obligation to the government as we go through this new open-and-transparent agile-development-process; • Once feedback has been received, OSEHRA Architecture Committee’s updates have been made and the SDK has been reviewed and approved by appropriate government leadership, DRAFT can be removed from the SDK and its IG and they will be versioned, time-stamped and an official government letter of endorsement MUST be attached. Only an official government-endorsed-and-versioned SDK, its IG and related artifacts can be used in any government contract or acquisition process. 6 ESP SDK WORKING DRAFT RFI: not for official use. 6 Technical Vision: EHR Service Platform (ESP) INTEGRATED EHR SOLUTION EHR SERVICES PLATFORM (ESP) Population Health Data & Services Population Health Data & Services EHR Data & Services Registries Data & Services EHR IS Locator Information Access & Longitudinal Record Services (LRS) EHR Information Services (EHR IS) Point of Service Applications ESP SDK Personal Health Record Systems EHR Viewers WORKING DRAFT RFI: not for official use. See notes page 7 • • • • • • TALKING POINTS: Technical Vision is to modernize and transition legacy to an EHR Services Platform (ESP) for Application Integration An EHR Services Platform (ESP) facilitates application innovation; it is composed of separated operation, business-rule and information services to integrate plug-&-play applications; the ESP services MUST be used by ALL applications and ALL applications MUST be service-based. As the ESP is fully-specified in the SDK Implementation Guide (IG), as standardized and reference implementations become available; then, general-purpose and domainspecific “best-of-class” certified applications can be user-selectable and evolve on a Darwinian basis. This is analogous to a Smart-Phone Application-Markets Anyone can build and submit ESP services and/or applications for certification The Open Source EHR Custodial Agent (OSEHRA) will IV&V and CM certified ESP application services and reference-implementations (e.g., gold builds). DoD, VA, IHS and others may pick-&-choose, which certified applications they use. Legacy-systems and ESP enabled systems can co-exist during long legacy transition periods across large enterprises. This is analogous to the PC and telecommunications evolution-revolution from the 1980s to now. 8 ESP SDK WORKING DRAFT RFI: not for official use. 8 Key Concepts: Federated EHR Services Architecture EHR IS Enabled Legacy System INTEGRATED EHR SOLUTION EHR IS EHR SERVICES PLATFORM (ESP) Tier 3 Plug-&-Play Data Stores Population Health Data & Services Population Health Data & Services EHR Data & Services EHR IS Enabled PHR System Registries Data & Services EHR IS Locator ESP Based System EAI IP Tier 2 EHR Information Services Tier 1 Plug-&-Play Applications Data Access Services Layer Information Access & Longitudinal Record Services (LRS) EHR Information Services (EHR IS) EHR IP EHR IP EHR IP Point of Service Applications Personal Health Record Systems EHR Viewers Application Services Layer IP is SOA Interoperability Profile aka Service Interface EAI is Enterprise Application Integration ESP SDK WORKING DRAFT RFI: not for official use. See notes page 9 TALKING POINTS: Benefits The ESP can become the National and possible International EHR standard for “best-of-breed” Darwinian innovation, evolution or revolution where anyone can participate. The SDK’s Standards-Based Best-Practices ensure consistency across: – Interoperable Application Service APIs • Common/ Engineering Service Bus (C/ESB) • Interoperable Plug-and-Play Applications – Interoperable Virtual Database (DB) APIs scalable from • Legacy MUMPS-globals acting as a DB to MS Access, Open or MS SQL, Oracle to • Massively-parallel high-performance grids running on commodity-hardware-blade-platforms (i.e., amazon.com & google.com models). – – – – ESP enabled Trading Partners Acquisitions (ESP SDK-IG as GFI for RFIs and RFPs) VA, DoD and IHS offices, staff and contractors Open Source and vender community ESP SDK D R A F T Talking Points WORKING DRAFT RFI: not for official use. 10 Legacy Transition Strategy INTEGRATED EHR SOLUTION LEGACY EHR SYSTEM EHR SERVICES PLATFORM (ESP) EHR-IS ENABLED LEGACY INFRASTRUCTURE Population Health Data & Services Data Warehouse Data & Services EHR Data & Services Data Warehouse Data & Services Legacy Point of Service Application Registries Data & Services EHR Data & Services Personal Health Record System Legacy EAI IP EHR-IS EAI IP Information Access & Longitudinal Record Services (LRS) Information Access & Longitudinal Record Services (LRS) EAI IP Bi-Directional Information Exchange EHR Information Services (EHR IS) EHR IP Point of Service Application EHR IP Personal Health Record Systems EHR Information Services (EHR IS) EHR IP EHR Viewer EAI is Enterprise Application Integration IP is SOA Interoperability Profile aka Service Interface ESP SDK EHR-IS EHR-IS enabled legacy systems allow users to transition at a convenient time and then legacy systems can be gracefully shut down. WORKING DRAFT RFI: not for official use. 11 TALKING POINTS: Transition Strategy based on ESP enabled systems 1. ESP kernel-services and data stores CAN be set-up at one-or-more data-centers (any cloud topology). 2. For pre-certification self-testing and attestation, venders and developers MUST be provided: i) SDK-IG, ii) an open-source test virtual-machine (VM) with the ESP set-of operating-and-data services, iii) clinically-meaningful test-database, test-scripts, certification-criteria. A. Agile SDK, ESP and application development and certification processes MUST have up-to-date VMs and ongoing regression testing to obtain/maintain “certified” status. B. Certified applications, test and certification VMs, test fixtures/scripts, test-results MUST be made available to anyone (e.g., open source community) to verify and validate test results & attestations. 3. One-or-more user-configurable ESP enabled viewers SHOULD be made freely available. 4. Legacy systems MUST be updated i) to “journal” their clinically-relevant data-store transactions with the ESP data-store and to query via the ESP, analogous to legacy “BHIE” DoD-VA sharing; 5. Terminology mapping SHOULD be a part of legacy-data transition. 6. To be repurposed to ESP capability, legacy-applications MUST conform to ESP SDK-IG and associated certification criteria. 7. Once certified ESP enabled viewer(s) and ESP enabled applications are available to clinical users, they CAN transition to modernized ESP based systems, while others might continue on legacy systems. 8. Clinically-meaningful legacy-data MUST be extracted to ESP before legacy systems are shut down. 12 ESP SDK WORKING DRAFT RFI: not for official use. 12 EHR Information Services (EHR IS) within EHR Services Platform (ESP) EHR SERVICES PLATFORM (ESP) ORGANISATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services Client Registry Outbreak Management EHR Data & Services PHS Reporting Shared Health Record Drug Information Data Warehouse & Services Diagnostic Imaging Health Information Laboratory Provider Registry Location Registry Business Rules EHR Index Terminology Registry Message Structures Normalization Rules Information Access & Longitudinal Record Services (LRS) IP is SOA Interoperability Profile aka Service Interface EAI IP Security Mgmt Rules/Data EAI is Enterprise Application Integration Privacy Mgmt Rules/Data Configuration Rules/Data EAI IP Common Information Integration Framework (CIIF) and Common Services EHR IS Secure Communications Bus EHR IP Public Health Services Public Health Provider EHR IP Pharmacy System Pharmacist EHR IP Radiology Center PACS/RIS Radiologist EHR IP Lab System (LIS) EHR IP Hospital, LTC, CCC, EPR Lab Clinician Physician/ Provider EHR IP Physician Office EMR Physician/ Provider EHR IP EHR Viewer Physician/ Provider POINT OF SERVICE APPLICATIONS ESP SDK WORKING DRAFT RFI: not for official use. See notes page 13 TALKING POINTS: Common Information Integration Framework (CIIF) • The Common Information Integration Framework (CIIF) is a business-driven agile enterprise-information-management methodology and set of softwareservice technologies, which enable semantic interoperability of clinical data. • The CIIF Team specifies or imposes a standards-based set of information services that enables any authorized empowered provider to care for any beneficiary regardless of location, organization or device. ESP SDK 14 WORKING DRAFT RFI: not for official use. See notes page 14 ERH Services Platform (ESP) enabled system (conceptual view) 15 ESP SDK WORKING DRAFT RFI: not for official use. See notes page 15 TALKING POINTS: EHR Services Platform (ESP) Addressing Legacy Problems 1. Innovation to revitalize legacy systems • Services within a standards-based component-architecture encourage lower-cost component innovation without requiring enterprise-wide expertise and extensive testing. SDK empowers individuals and avoids stovepipes. 2. Interoperability among partners. • CIIF canonical information and terminology models can be used to map among heterogeneous system information exchanges. By adopting common EHR IS data, terminology, and communications standards; multiple organizations can share and ultimately harmonize Electronic Medical Records. 3. Transition from legacy systems and data to an integrated EHR architecture. • Virtualization-Layers of Federated Standards-Based Services allow new and legacy COTS, GOTS and opensource applications, scalable databases and infrastructure to coexist. 4. Agility to respond to rapid healthcare changes and related legislation. • Services within a standards-based component-architecture encourage faster and lower-cost changes to be made and tested within components without requiring enterprise-wide expertise and testing. 5. High Costs of change and sustainment. • Virtualization-Layers of Federated Standards-Based Services make plug-and-play applications, databases and infrastructure possible, which can be treated as commodities and can be tested efficiently. Interchangeablecomponents can compete based, on functionality, quality, performance vs. cost, usability and supportability. Built In Test Environment (BITE) identifies faults early, improving robustness and reducing test costs. . 6. Patient Safety issues resulting from software changes. • Component architecture localizes faults. BITE identifies faults early, improving system robustness, patient safety. 7. Open Source Community Enablement • Virtualization-Layers of Federated Standards-Based Services support alternate configurations of applications, databases and infrastructure, which may be combinations of MUMPS, COTS, GOTS and open source code to meet the specific-needs of various stakeholder-and-user communities. 16 ESP SDK WORKING DRAFTTalking RFI: not for official use. DR AFT Points HL7 Service Aware Interoperability Framework (SAIF) Enterprise Compliance and Conformance Framework (ECCF) ECCF Conceptual Perspective Logical Perspective Implementable Perspective Enterprise Dimension Information Dimension Computational Dimension “How” - Behavior “Where” - Implementation “Where” - Deployments Inventory of • Domain Entities • Activities • Associations • Information Requirements • Information Models o Conceptual o Domain Inventory of • Functions-services Requirements • Accountability, Roles • Functional Requirements, Profiles, Behaviors, Interactions • Interfaces, Contracts 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 Terminologies Value Sets Content Specifications Specifications • Use Cases, Interactions • Components, Interfaces Collaboration Participations Collaboration Types & 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 “Why” - Policy Inventory of • User Cases, Contracts • Capabilities Business Mission, Vision, Scope “What” - Content Engineering Dimension Technical Dimension Five (5) Categories: Capability | Mission | Business Process | Infrastructure/Enterprise Architecture | Interoperability 17 ESP SDK WORKING DRAFT RFI: not for official use. TALKING POINTS: HL7 Service Aware Interoperability Framework (SAIF) Conformant ESP Implementation Guide (IG) • To be OSEHRA software-quality certified, ESP enabled applications MUST be conformant to the companion ESP SDK Implementation Guide (IG) which follows HL7 SAIF guidance. – The SDK slide set is the SAIF Conceptual Perspective – The SDK Implementation Guide is the SAIF Logical Perspective – Developers & Venders MUST deliver the SAIF Physical Perspective • SAIF provides guidance; but, OSEHRA, DoD, VA, IHS and stakeholders MUST establish a consensus ESP IG, defining required architectural views (e.g., subset of DoDAF views) and appropriate specification language (e.g., BPMN, UML). • The ESP companion SDK IG is HL7 SAIF conformant and defines software-engineering best-practices for interoperability Standards and Conventions (iSAC). • Agile processes are being followed to define the SDK slides and IG; that is, there will be many incremental refinements. 18 ESP SDK WORKING DRAFT RFI: not for official use. 18 Generally, only the preceding Executive Summary is distributed via e-mail The most-current 180+ slide ESP SDK Conceptual Architecture and The most-current evolving ESP SDK Implementation Guide (IG) can be downloaded at: http://www.osehra.org/node/47/content/documents ESP SDK Conceptual View Next: ESP SDK Future-State SAIF Conceptual Perspective EHR Services Platform concepts SDK Scope Business Context Clinical/Work Process Architecture System Architecture Information Architecture Integration & Deployment Options Potential Applications Summary & Conclusion CALL FOR PARTICIPATION Please post your discussion comments at http://www.osehra.org/group/architecture ESP SDK WORKING DRAFT RFI: not for official use 19 Abbreviations AKA BITE CM DI DoD EAI EHR IS ESP ESB HAIMS ICIB IG IHS IP IV&V LIS LRS OSEHR OSEHRA RFI RIS SAIF SDK SDO SOA TSA VA VHA VM Also Known As Built in Test Environment Configuration Management Diagnostic Imaging Department of Defense Enterprise Application Integration EHR Information Services HER Services Platform Engineering Service Bus Health Artifact and Image Management Solution Interagency Clinical Informatics Board Implementation Guide Indian Health Services Interoperability Profile / Specification Independent Verification and Validation Laboratory Information Systems Longitudinal Record Service Open Source EHR OSEHT Custodial Agent Request for Information Radiology Information System HL7’s Service Aware Interoperability Framework Software Development Kit Standards Development Organization Service Oriented Architecture Telehealth Scheduling Application Veterans Administration Veterans Health Administration Virtual Machine 20 ESP SDK WORKING DRAFT RFI: not for official use. 20 Suggested Plan of Actions and Milestones (POA&M) to Refactor & Certify Legacy MUMPS within ESP Enabled System 1. CY2011: Verified System Architecture, Product Baseline and Roadmap 2. CY2012: Prepare • Complete ESP SDK through Open-Source-Community & DoD, VA, IHS collaboration • Specify future-state ESP Key Performance Parameters (KPPs) and implementation constraints • Get ESP SDK officially endorsed by DoD and VA leadership; work ESP SDK through HL7, OASIS & OMG SDOs • Specify OSEHR automated ESP enabled system certification-test-scripts & Built-in-Test-Environment (BITE) • Proof-of-concept refactoring-prototype (e.g., scheduling, clinical & nursing notes modules) • ESP enabled system & test environment prototype in a Virtual Machine (VM) 3. CY2013: Build Critical Components • Construct automated-certification test-scripts for ESP & key applications • Construct ESP Built-in-Test-Environment (BITE) • Construct ESP reference-implementation in a VM test environment • Refactor & certify VistA Kernel & FileMan into as ESP enabled system 4. CY2014: Build Necessary Components • Refactor & certify strategically important applications to be ESP conformant. • Refactor & certify other modules/routines in MUMPS to use ESP SDK specified services 5. CY2015: Integrate and Make Everything Work to Users Satisfaction • ESP Integrate & certify other-available critical-components ESP (e.g., VLER, pharmacy, lab, imaging) • ESP Performance optimize ESP & integratedWORKING applications DRAFTto RFI:meet not forKPPs official use. SDK 21 21 Suggested OSEHRA Role in MUMPS Code Refactoring 1. Thought Leadership 2. OSEHR System Architecture, Product Definition and Roadmap 3. Technical, Operational and Functional Certification 4. Open Source Tools, Test & Collaboration Environment Management 5. Configuration Management of: 1. OSEHR Services Platform (ESP) Software Development Kit (SDK) 2. Codebase 3. Certification test artifacts (fixtures, results, attestations) 6. Technical/ Standards Mentoring, Verification and Validation of: 1. Refactoring 2. ESP system enablement (Refactored VistA Kernel & Fileman Modules) 3. Automated Certification test scripts, fixtures & Built-in-Test-Environment (BITE) 4. Operational/technical/functional testing and certification 7. Open Source Community Engagement and Professional Organizations Evangelism 22 ESP SDK WORKING DRAFT RFI: not for official use. 22 Outline ESP SDK Future-State SAIF Conceptual Architecture EHR Services Platform Concepts ESP SDK Scope Business Context Clinical/Work Process Architecture System Architecture Information Architecture Integration & Deployment Options Potential Applications Summary & Conclusion CALL FOR PARTICIPATION Please post comments at http://www.osehra.org/group/architecture ESP SDK WORKING DRAFT RFI: not for official use 23 EHR IS Benefits • Increases availability & accessibility of information patient safety & quality of care • Eliminates/reduces costly data mapping • Clarifies & communicates improved requirements (for vendors) • Provides common reproducible software development processes (interoperability design patterns) • Encourages faster-and-lower-cost changes • Supports efficient legacy transition to modernized systems • Assures consistent information context and meaning 24 ESP SDK WORKING DRAFT RFI: not for official use. 24 ESP SDK Scope EHR IS CONCEPTUAL LAYER ADDRESSES BUSINESS CONTEXT (Mission, objectives, stakeholders, benefits) WORK PROCESS INFORMATION SYSTEM Conceptual framework V1 YES V2 framework framework YES V2 framework V1 YES V2 framework Logical framework YES V2 framework YES V2 framework YES V2 TECHNOLOGY Physical EHR IS Implementations ESP SDK WORKING DRAFT RFI: not for official use. 25 Architecture Perspectives Business Architecture Clinical Work Process Architecture Potential Applications CONTEXT Integration & Deployment Models System Architecture Information Architecture ESP SDK WORKING DRAFT RFI: not for official use 26 Architecture Perspectives Business Architecture Clinical Work Process Architecture Potential Applications CONTEXT Integration & Deployment Models System Architecture Information Architecture ESP SDK WORKING DRAFT RFI: not for official use 27 Business Context ESP SDK WORKING DRAFT RFI: not for official use 28 Healthcare Industry Elected Federal Government Federal Agencies and States Provides $ Planning & Resources Planning & Resources Tax $$$ VHA, MHS, IHS, SSA, State Agencies, etc. Homecare Community Care Center Emergency Services Patient Providers Clients/Patients Pharmacy Specialist Clinic Hospital Emergency Laboratory Diagnostic ESP SDK WORKING DRAFT RFI: not for official use 29 International Industry: IT Spending Comparisons IT spending as a % of total expenditures 12.1 Financial Services 5.7 Government 5.5 Telcos 4.2 Worldwide Health Providers 3.3 Transportation 2.7 Utilities 2.2 Textiles 1.9 Manufacturing Petroleum 1.7 Pulp & Paper 1.6 Canadian Healthcare Food & Bev HELP NEEDED This slide should be updated to current US figures 1.4 1.2 SOURCE: Gartner Group – as reported in the Health Services Restructuring Commission’s (www.hsrc.gov.on.ca) report: Ontario Health Information Management Action Plan, June 1999 ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 30 Mean Hospital: IT spending in Canada <2% IT budgets as a % of total hospital budget 25 less than 1% 1-1.4% 27 1.5-1.9% 27 12 2-2.4% 10 2.5% or more 0 5 10 15 20 HELP NEEDED This slide should be updated to current US figures 25 30 SOURCE: 2003 Report on I.T. in Canadian Hospitals: Top issues, applications and vendors. Canadian Healthcare Technology, 2003. CIHI NHex 2002 (Hospital Expenditures) ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 31 Why an ESP? The World of Healthcare is Changing… The Old World The New World Provider-focused Illness centric Site-of-care centric Episode Management Supply Management Solitary decision making Inefficiency De-centralized, generalized care Patient & family-focused Medical home and wellness care Continuum of care & case management Disease and demand management Collaborative, evidence-based decisions Meaningful-Use objectives, metrics & criteria Patient safety, quality and effectiveness Centralized, specialized care ESP SDK WORKING DRAFT RFI: not for official use See notes page 32 Why an EHR IS? The World of Healthcare is Changing… The changes in healthcare require significant capability from the health infostructure; this capability does not fully exist today ESP SDK WORKING DRAFT RFI: not for official use 33 The Timing Has Never Been Better! WILL • Public wants more accessibility • Health Authorities recognize benefits • Increased financial pressures • Healthcare professionals embracing technology • Willingness to collaborate ESP SDK CONVERGENCE CAPACITY • Better infrastructure • More mature application technologies CAPABILITY • Political will • Funding is now available • mandated to pursue investments HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 34 EHR IS: Key Concepts ESP SDK WORKING DRAFT RFI: not for official use 35 EHR An Electronic Health Record (EHR) provides each individual with a secure and private lifetime record of their key health history and care within the health system. The record is available electronically to authorized health providers and the individual anywhere, anytime in support of high quality care. This record is designed to facilitate the sharing of data – across the continuum of care, across healthcare delivery organizations and across geographies. ESP SDK WORKING DRAFT RFI: not for official use 36 Interoperable EHR Solution The Interoperable EHR Solution is a combination of people, organizational entities, business processes, systems, technology and standards that interact and exchange clinical data to provide high quality and effective healthcare. ESP SDK WORKING DRAFT RFI: not for official use See notes page 37 EHR Information Services (EHR IS) The EHR Information Services are a collection of common and reusable component-services in support of a diverse set of health information management applications. It consists of interoperable software-solutions for the EHR, semantically-interoperable data and terminology for the EHR and secure information-exchange standards for the EHR. ESP SDK WORKING DRAFT RFI: not for official use See notes page 38 EHR IS Outcomes Providers Researchers & Health Surveillance Professionals • Relevant data, granular, computable if needed • Real time • Rapid access from multiple locations, anywhere, anytime • Decision support • • • Clinical reference data Guidelines & protocols Common terms & codes Authoritative, reliable, secure, private • Case management & workflow • Safety • Improved quality of care • Regulation & accountability • Computable data • Appropriately summarized data • Anonymized in framework • Designed for analysis: • • • • • • Statistical sampling Trends Outbreak detection Outcome analysis Regional National Payer/Payee Patient/Public/Clients • Convenient, relevant access to accredited health information • Access to relevant personal health information • Safety • Improved quality of care • Relevant data to adjudicate claim • Workflow management Public Sector Health Managers • • • • Registry solutions & initiatives Objective analysis of results & benefits Management reports Funding & resource allocation • Policy ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. Key EHR IS Architecture Concepts INTEGRATED EHR SOLUTION EHR Services Platform (ESP) EHR IS Locator Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Information Access & Longitudinal Record Services (LRS) EHR Information Services (EHR IS) Point of Service Application ESP SDK Point of Service Application EHR Viewer WORKING DRAFT RFI: not for official use. See notes page 40 EHR Services Platform (ESP) Recommended Approach for Partner Collaboration EHR IS ENABLED SYSTEM SOLUTION EHR IS ENABLED SYSTEM SOLUTION EHR INFOSTRUCTURE (EHRi) EHR INFOSTRUCTURE (EHRi) Population Health Data & Services Health Information Data Warehouse EHR Data & Services Population Health Data & Services Registries Data & Services Information Access & Longitudinal Record Services (LRS) Point of Service Application ESP ESP SDK Registries Data & Services EHR Information Services (EHR IS) Point of Service Application EHR Viewer ESP EHR Data & Services Information Access & Longitudinal Record Services (LRS) EHR Information Services (EHR IS) Point of Service Application Health Information Data Warehouse ESP ESP ESP Point of Service Application ESP HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. EHR Viewer ESP See notes page 41 EHR IS Infostructure: Conceptual Architecture ORGANISATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services Client Registry Outbreak Management PHS Reporting EHR Data & Services Shared Health Record Drug Information Data Warehouse Diagnostic Imaging Health Information Laboratory Provider Registry Location Registry Business Rules EHR Index Terminology Registry Message Structures Normalization Rules Information Access & Longitudinal Record Services (LRS) Security Mgmt Data Privacy Data Configuration Information and Common Services EHR IS Secure Communications Bus Public Health Services POINT OF SERVICE ESP SDK Public Health Provider Radiology Center PACS/RIS Pharmacy System Pharmacist Radiologist Lab System (LIS) Lab Clinician Hospital, LTC, CCC, EPR Physician Office EMR Physician/ Provider HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. Physician/ Provider EHR Viewer Physician/ Provider See notes page 42 Guiding Principles for EHR Services Platform (ESP) • Patient-centric • Leverage legacy systems & solutions • Easially customized views of all clinical data • VA VistA • Value add for the provider • MHS AHLTA • Open Source Applications • Timely, accurate information • Enable sharing at local, regional, cross-organizational • Design for phased rollout with near term results • Scalable • Interoperable, integrated applications • Individual provider’s Point-of-Service (POS) • Specialty, Ancillary, Public Health POSs • Standards based • Interoperating with large -o-massive Enterprise • Computable where required • Extensible to support future growth • Replicable solution – patterns, components • Pragmatic and Cost-effective • Secure & private • Allow for innovation & competition • Open Source commodity applications • Best –of-class COTS applications • Comprehensive ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 43 HELP NEEDED This slide should be updated Generations of EHR Capabilities Gen 5 Full The Mentor Gen 4 The Colleague Gen 3 Functionality The Helper Gen 2 The Documentor Gen 1 The Collector Minimal 1993 1998 2005 2010 2015+ End of 2009 Source: Gartner (December 2005) ESP SDK Availability of Products WORKING DRAFT RFI: not for official use. See notes page 44 A Few Misconceptions About integrated EHR Solutions Misconception Reality • A person’s health data is in only one physical EHR • EHR: an integrated service covering all available integrated EHR Solutions; a client’s record is seen as coming from a single integrated EHR • All data for a person must be in the EHR to have value and generate adoption • An Organization is a provider practice • The EHR is a data warehouse to support research and surveillance • Quality, safety & effectiveness enhanced with only subsets of clinically relevant data available for sharing • An organization is any geo-political entity mandated or chartered to govern the operation of an integrated EHR Solution • The EHR IS: an information support service available to caregivers in the daily context of care provision work activities ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 45 Future-State-Architecture GOAL: To Support Modular Plug-&-Play Innovation Modular Little Impact on links Incremental between components Plug-&-Play Innovation (e.g., Interoperability) Innovation OBJECTIVE A change-immune domain-specific componentarchitecture emphasizing interoperable standardsbased services, resulting-in simpler, loosely-coupled, and less-costly agile module-level innovation. Great impact on components Little impact on components PROBLEM Little innovation, long lead times and high costs resulting from complex highly-coupled components Start Architectural Innovation Great Impact on links between components (e.g., interoperability) Radical Innovation 46 ESP SDK WORKING DRAFT RFI: not for official use. Coordination Across the Enterprise Common Services Bus (CSB) Rules Engine Technical Services EHR IS Terminology Model Services Model Information Model Rule Set Mapping to Legacy Data Standardization Translation Service MDR Services Communications Physical Data Model Caching Database Topologies Latency Outside • Clinical Measures • Capabilities • Applications • Adapters Infrastructure 47 ESP SDK WORKING DRAFT RFI: not for official use. See notes page The EHR IS drives the ESP enabled run-time environment EHR IS 48 ESP SDK WORKING DRAFT RFI: not for official use. 48 Pharmacy Delivery Use Case – The EHR IS Leads the Way Translation Services Mediation Services Rules Engine Common Information Interoperability Framework (EHR IS) Common Information Model, Common Terminology Model, Information Exchange Specifications, Translation Service Common Data Standards: 49 ESP SDK WORKING DRAFT RFI: not for official use. See notes page Business/Clinical Scope ESP SDK WORKING DRAFT RFI: not for official use 50 EHR IS Serving Healthcare Service Delivery EHR IS ENABLED SYSTEM SOLUTION EHR IS ENABLED SYSTEM SOLUTION EHR INFOSTRUCTURE (EHRi) EHR INFOSTRUCTURE (EHRi) Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Population Health Data & Services Information Access & Longitudinal Record Services (LRS) Registries Data & Services EHR Information Services (EHR IS) Poin of Service Application Point of Service Application EHR Viewer Homecare Point of Service Application EHR Viewer Homecare Community Care Center Emergency Services Community Care Center Clients/Patients Pharmacy Hospital Emergency Laboratory Diagnostic Emergency Services Clients/Patients Specialist Clinic ESP SDK EHR Data & Services Information Access & Longitudinal Record Services (LRS) EHR Information Services (EHR IS) Point of Service Application Health Information Data Warehouse Specialist Clinic Pharmacy Hospital Emergency Laboratory Diagnostic HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 51 Population/Public Health Business Requirements • Focuses on managing health status of populations • Managed and executed through complex network of public/private organizations acting at different levels of the health system (Federal, State, Regional, Local, Individual) • Involves: • Research & analysis to identify/define population health programs • Surveillance activities to detect and pro-actively react to potential population health problems • Application of health programs to prevent the appearance and/or dissemination of preventable diseases • Active management of communicable disease outbreaks • Active management of the delivery of health services to individuals in the context public health related programs • Current focus limited to: • Surveillance and detection (focused on human health-related diseases) • Outbreak Management • Public Health Alert Management • Disease Information Dissemination • Immunization Management • Communicable Disease Case Management ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 52 Integrating Population/Public Health in the Architecture Candidate services required to support: • Surveillance & Detection: There is a business need for a Health information data warehouse • Outbreak Management: requires the addition of a new category of service called Population Health Services where a specific service is introduced to address outbreak management; analogous services will evolve. • Common Information Integration Framework (EHR IS): addresses the need for a formal terminology registry system that maintains information and terminology models for clinical domains and other key terminologies required for many services of the ESP • Public Health Alert Management • Public health disease alert reporting requires use of specific applications also positioned as Population Health services • Public health alerts dissemination relies on terminology registry and EHR IS Alerts and Notification services • Immunization Management • Immunization programs and their management requires a specific application that would live under the Population Health services category • Delivery of immunisation would be tracked by the drug information domain as part of the EHR • Communicable Disease Case Management • Delivery of health services in relation with the treatment of a CD case would be tracked by the shared health record and other domains as part of the EHR • Management of a CD case from the perspective of the public health specialists involved in detection and tracking would require a specific application that would live under the Population Health services category ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 53 Integrating Public Health in the Architecture Some Public Health business requirements can be sustained by the existing services of the EHR Infostructure • Public Health Alert Management: EHR IS and LRS to provide for mechanism to help with detection & reporting on communicable diseases • Immunization Management: Drug Information Domain is the home of immunization information as part of the core clinical data in client’s health records. EHR IS and LRS to provide mechanisms to communicate the data and coordinate its location and access within the EHRi • Communicable Disease Case Management: CD Cases, from the perspective of the EHR are treated like any other health delivery encounter ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 54 EHR IS Serving Public Health Service Delivery ORGANIZATIONAL INFOSTRUCTURE Immunization “Registry“ Population Health Data & Services Registries Data & Services Client Registry Outbreak Management Provider Registry EHR Data & Services PHS Reporting Shared Health Record Drug Information Data Warehouse & Services Diagnostic Imaging Health Information Laboratory Case Management Reference Management Location Registry Business Rules EHR Index Message Structures Terminology Registry Normalization Rules PHS Data Warehouse Services Information Access & Longitudinal Record Services (LRS) Alert Notification Services Content & Knowledge Management Messaging Security & Privacy Services Security Mgmt Data Privacy Data Configuration Information and Common Services EHR IS Secure Communications Bus PHS Systems Operational data PHS A CM OM AM IM* Other PH System(s) Pharmacy System Radiology Center PACS/RIS Lab System (LIS) Hospital, Community, etc… EPR Physician Office EMR EHR Viewer Public Health Surveillance Portal Pharmacist POINT OF SERVICE ESP SDK Public Health Providers Radiologist Lab Clinician Physician/ Provider HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. Physician/ Provider See notes page Physician/ Provider 55 Telehealth Business Requirements • Telehealth: the use of information & communication technologies to deliver health services in contexts where the providers and clients are in separate locations • Telecommunication infrastructure is a pre-requisite • Telehealth solutions enable health service delivery channels: Tele-consultations Videoconferencing stations, communication enabled medical devices Tele-education Videoconferencing stations used for training/education Tele-homecare Active or passive monitoring of remote patients for pre-/ post-op procedures, chronic diseases management, etc Tele-triage Centralized call centers to offer first line delivery of service to clients as part of primary care and emergency response • Scheduling solutions – a key enabler required for the effective use of telehealth service delivery • EHR Infostructures support telehealth applications as per any other Point-of-Service Application ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 56 EHR IS Serving Telehealth Scheduling ORGANIZATIONAL INFOSTRUCTURE Registries Data & Services Client Registry Population Health Data & Services Outbreak Management PHS Reporting EHR Data & Services Shared Health Record Drug Information Data Warehouse Diagnostic Imaging Health Information Laboratory Provider Registry Location Registry Terminology Registry Business Rules EHR Index Message Structures Normalization Rules Information Access & Longitudinal Record Services (LRS) Security Mgmt Rules/Data EHR IS Privacy Rules/Data Configuration Rules/Data Information and Common Services Secure Communications Bus TSA Database Patient Info End-user Info Event History Clinical Profile Scheduling Video Session Referring Physician Site POINT OF SERVICE Physician/ Provider Attending Physician Site Physician/ Provider Telehealth Scheduling Application (TSA) ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. See notes page 57 EHR IS Framework: Tele-Consultation EHR INFOSTRUCTURE (EHRi) Population Health Data & Services Health Information Data Warehouse EHR Data & Services EHR INFOSTRUCTURE (EHRi) Registries Data & Services Information Access & Longitudinal Record Services (LRS) Population Health Data & Services ESP SDK Telehealth Application EHR Data & Services Registries Data & Services Information Access & Longitudinal Record Services (LRS) EHR Information Services (EHR IS) Local Electronic Medical Record Health Information Data Warehouse EHR Information Services (EHR IS) Live Video-Conferencing Session Tele-Consultation Devices Data Telehealth Application HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: [email protected] official use Local Electronic Patient Record 58 EHR IS Framework: Tele-Homecare EHR INFOSTRUCTURE (EHRi) Population Health Data & Services Health Information Data Warehouse EHR Data & Services EHR INFOSTRUCTURE (EHRi) Registries Data & Services Information Access & Longitudinal Record Services (LRS) EHR Information Services (EHR IS) Local Electronic Medical Record ESP SDK Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Information Access & Longitudinal Record Services (LRS) EHR Information Services (EHR IS) Homecare Application Server Tele-Homecare Data Feed Tele-Consultation Devices Homecare Client Application HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: [email protected] official use 59 EHR IS Framework: Tele-Triage EHR INFOSTRUCTURE (EHRi) Population Health Data & Services Health Information Data Warehouse EHR Data & Services EHR INFOSTRUCTURE (EHRi) Registries Data & Services Information Access & Longitudinal Record Services (LRS) End-user Info Event History Clinical Profile Scheduling Video Session Health Information Data Warehouse EHR Data & Services Registries Data & Services Information Access & Longitudinal Record Services (LRS) EHR Information Services (EHR IS) Patient Info Population Health Data & Services EHR Information Services (EHR IS) Tele-Triage Application Personal Health Record Application EHR Viewer ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: [email protected] official use 60 Clinical, Business & Socio-economic Drivers for integrated EHR solutions ESP SDK WORKING DRAFT RFI: not for official use 61 Why is Value Created by an integrated EHR solution? • Healthcare professionals make clinical decisions based on knowledge • Encounter and Case Management, • Care Plan, • Health Concern Tracking • Analytics • Better knowledge translates to better care • Knowledge starts with accurate, relevant clinical information • The EHR creates the capability to share relevant clinical information • The 5 Rs of the EHR: • The right information • About the right client • Available to the right person • In the right place • At the right time ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 62 How Is Value Delivered By An ESP Enabled System? The value of the ESP Enabled System for clients, families and their providers increases with the completeness of the information contained as well as the level of standardization of the data Point of greatest value Extent of the Care Continuum Involved (PCP office, Hospital, Long Term Care Homecare, etc.) # of Data Domains Included (Encounter Summaries, Lab, DI, Drugs, etc.) ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. See notes page 63 Why Pursue The EHR IS: Circle of Care Homecare Clinic Emergency Services Community Care Center Pharmacy Specialist Clinic Laboratory Hospital Emergency ESP SDK WORKING DRAFT RFI: not for official use. Diagnostic See notes page 64 DoD priorities: 1. Experience of care 2. Readiness 3. PopHealth 4. Per capita costs Why Pursue The EHR: Benefits Homecare Clinic Emergency Services Community Care Center Pharmacy QUALITY SAFETY ACCESSIBILITY Specialist Clinic Laboratory Hospital Emergency ESP SDK Diagnostic HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. See notes page 65 The EHR IS is a Key to a Renewed Health System! integrated EHR Solutions provide an opportunity to • Improve the quality, safety, accessibility and timeliness of care • Support more informed healthcare decision making, research and management • Improve the efficiency of the healthcare system and reduce costly duplication • Maximize return on IT investments • Achieve standards based solution allowing interoperability ESP SDK WORKING DRAFT RFI: not for official use 66 EHR IS Key Clinical & Business Requirements • Life-long longitudinal record of clinical data • Allowing private and secured access to data made available in EHR • Focused on clinically relevant data shared beyond organizational boundaries • Support for accurate, complete, timely delivery of information • Shared across multiple organizations, Organizations • Adaptive to the future of healthcare delivery in the 21st Century • Requiring ongoing governance and operations management with 24/7 high availability service • Affordable in relation to complexity and size of integration challenges (connecting large numbers health points of service) • Scalable to allow continuous, extensive growth of clinical and financial ROI • More POS applications sourcing data to EHR • More users accessing and using data from EHR • Allowing natural growth of capabilities towards Generation 3 and beyond ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. See notes page 67 Different Approaches To Achieving EHR IS ESP SDK WORKING DRAFT RFI: not for official use 68 EHR IS: How Do We Do This? Sharing Information From Multiple Systems Homecare Clinic Emergency Services Community Care Center Pharmacy INTEGRATED VIEW Clients/Patients Specialist Clinic Laboratory Hospital Emergency ESP SDK WORKING DRAFT RFI: not for official use. Diagnostic 69 Methods of Sharing EHR Information The “Big Database in the Sky” Broadcast to all or a logical subset of Systems (caching) The “Big Index in the Sky” • All Point-of-Service (POS) systems share same data store • Replication of data from one system to all other relevant/ participating POS systems • EHR Index or locator service that holds links to all POS systems where information resides • Every POS system holds same information • Each POS system interfaces to other systems ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. Use of a shared reference information source • POS systems populate it • POS systems or viewers reference it • External to the “operational” store 70 Key Factors Affecting How to Share • Sharing creates some very profound issues & requirements • Unique identification of clients, providers, service delivery locations, etc. • Protecting privacy and confidentiality of patients and providers while simultaneously not limiting the ability to deliver appropriate services • Ensuring information is stored, shared securely • Ensuring compatibility of how data is interpreted/understood --- EHR IS DEERS EDIPN Service is the DoDVA unique person identification solution • Issues the same no matter which model is chosen to share patient identified information • Governance model for healthcare means these issues are organizational responsibilities – requirements vary • People increasingly mobile, especially when considering long periods of time • Provider’s confidence in the mechanisms to enable sharing is crucial The DoD & VA use the Electronic Data Interchange Personal Number, or EDIPN, is a unique number assigned to a record in the United States Department of Defense's Defense Enrollment and Eligibility Reporting System (DEERS) database. A record in the DEERS database is a person plus personnel category (e.g. contractor, reservist, civilian, active duty, etc.). ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 71 The Integration Challenge of integrated EHR Solutions ESP SDK WORKING DRAFT RFI: not for official use 72 Integrating Heterogeneous Systems Homecare Clinic Emergency Services Community Care Center Pharmacy Clients/Patients Specialist Clinic Laboratory Hospital Emergency ESP SDK WORKING DRAFT RFI: not for official use. Diagnostic 73 Integrating Heterogeneous Systems: Hospital Hospital Emergency Homecare Clinic Emergency Services Finance, inventory, payroll ADT Order/ Results Electronic Patient Record Specialized Care Community Care Center Pharmacy Human Resources Scheduling Laboratory Clients/Patients Clinical Data Repository Specialist Clinic Radiology PACS Emergency Laboratory Hospital Emergency ESP SDK Pharmacy WORKING DRAFT RFI: not for official use. Diagnostic 74 Integrating Heterogeneous Systems: Hospital Homecare Clinic Clinic Emergency Services Scheduling Accountiing/ Billing Electronic Medical Record Community Care Center Pharmacy Clients/Patients Specialist Clinic Laboratory Hospital Emergency ESP SDK WORKING DRAFT RFI: not for official use. Diagnostic 75 Locations of Electronic Clinical Data Today: Number of Systems to Integrate Homecare Clinic Emergency Services DoD/VA each have • 100+ regional systems/hospitals • 1000+Clients/Patients clinics • 100,000+ clinical staff • 1,000,000+ patients Community Care Center Specialist Clinic Laboratory Hospital Emergency ESP SDK Pharmacy Diagnostic HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 76 Integrating Health Information Systems: Key Challenges • Protecting Privacy • • • • • Governance, accountability & data custodianship Controlling access Managing & applying consent directives Controlling feeds and queries to the data Trust relationships & contracts • Existence & availability of data thru EHR IS • Discovery capability • Availability in electronic format • Timeliness • Harmonization through EHR IS • Data structures (format) • Vocabularies (encoding, normalization) • Semantics • Heterogeneous technology environments • Number of organizations, connection points & systems • Costs inherent to integration ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 77 Recommended Approach: The Cost of Integration As A Key Driver ESP SDK WORKING DRAFT RFI: not for official use 78 Integrating Health Information Systems: Point-to-Point Connectivity SYSTEMS TO CONNECT ApplApp 1 1 Costs basis AppAppl 1 2 • Cost of one integration • Simple = $32K; Medium = $95K; Complex = $190K Contracts App 1 App 1 2 Futile approach SYSTEMS TO CONNECT • 38,783 systems (Canadian example) ApplApp 1 App 1 1 AppAppl 1 2 ApplApp 3 App 1 1 • Simple = $4,527; Medium = $20,081; Complex = $14,175 • 1.5 B integration points 6 • $183.928 B SYSTEMS TO CONNECT App 1 ApplApp 1 App 1 1 AppAppl 1 2 App 1 We need a different approach App 1 ApplApp 3 App 1 1 AppAppl 1 4 App 1 12 Interfaces = N (N-1) ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 79 Integrating Health Information Systems: Hospital Networks Approach SYSTEMS TO CONNECT ApplApp 1 1 Costs basis AppAppl 1 2 • Cost of one integration • Simple = $32K; Medium = $95K; Complex = $190K Contracts App 1 App 1 2 Hypothesis SYSTEMS TO CONNECT ApplApp 1 App 1 1 • 1,126 Hospital networks, each includes 71 systems to integrate and group (EAI) in 44 points of integration AppAppl 1 2 ApplApp 3 App 1 1 • 1,892 (44 x 43) integrations per network totalling 2.1 M (1,126 x 1,892) (Canadian example) 6 SYSTEMS TO CONNECT App 1 ApplApp 1 App 1 1 AppAppl 1 2 App 1 • Assuming existence of standardized protocol for interfaces • $68.172 M App 1 ApplApp 3 App 1 1 AppAppl 1 4 12 App 1 (if Simple – $32K) • $202.316 M (if Medium – $95K) We need a different approach Interfaces = N (N-1) ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 80 Rational for Recommended Approach • Only cost effective scenario to handle degree of application integration required • Maximized ability to deliver proper response time and consistent access to data across thousands of source systems • Maximized ability to apply privacy and security policies in a harmonized and consistent fashion • Enables evolutionary path to semantic harmonization of health information across service delivery points • Enables high degree of scalability from local health services integration, to regional, state and cross-organizational • Enables high degree of flexibility in reconfiguration of health services delivery networks ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 81 Architecture Perspectives Business Architecture Clinical Work Process Architecture Potential Applications CONTEXT Integration & Deployment Models System Architecture Information Architecture ESP SDK WORKING DRAFT RFI: not for official use 82 EHR IS Work Process Architecture • The EHR Clinical Reference Framework: Life of the Lamberts • Depiction of the use of an integrated EHR Solution in different contexts of health service delivery • 14 different storyboards created • Extensible by adding new use cases • System or security administration use cases not represented • Life of the Lamberts • Patient centric framework • Focused on different members of a family and their health status evolution • Focused on health related events • Represented with UML use case notation • Published as artefacts under the Artefact Repository • Available in HTML and PDF format • Available in Magic Draw format and XMI for upload to other case tools Functional/Clinical Help needed downloading, verifying, validating the 14 storyboards and integrating them into the SDK https://www.infoway-inforoute.ca/working-with-ehr/knowledgeway/knowledge-center/657 ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 83 EHR IS Reference Architecture Comm Step Put New Patient EHR IS POS APPLICATION SIGNIFICANT REUSE HERE Encounter Life Of The Lamberts COPD Storyboard Encounter Clinical Activity Clinical Events Storyboard New Family Physician Activity New Family Physician Activity Clinic Visit Admission EHR IP Clinical Activity Clinical Events EHR IP Clinical Events EHR IP Storyboard EHR IP Public Health Services POINT OF SERVICE ESP SDK Public Health Provider EHR IP Pharmacy System EHR IP Radiology Center PACS/RIS Pharmacist Radiologist EHR IP Lab System (LIS) Lab Clinician EHR IP Hospital, LTC, CCC, EPR EHR IP Physician Office EMR Physician/ Provider HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: not to for [email protected] official use EHR IP Add New Patient EHR IP EHR Viewer Physician/ Provider EHR IS Reference Architecture Physician/ Provider 84 Documenting EHRi Services Requirements ORGANIZATIONAL INFOSTRUCTURE EAI IP Provider Registry EAI IP Location Registry Population Health Data & Services EHR Data & Services Data Warehouse Outbreak Management PHS Reporting Shared Health Record Drug Information Diagnostic Imaging Laboratory EAI IP EAI IP EAI IP EAI IP EAI IP EAI IP Business Rules EHR Index EAI IP Client Registry EAI IP Registries Data & Services Terminology Registry Message Structures Health Information Normalization Rules Information Access & Longitudinal Record Services (LRS) EAI IP EHR IS EHR IS IP is Interoperability Profile EAI is Enterprise Application Integration ESP SDK Privacy Rules/Data Configuration Rules/Data Information and Common Services IP “Put” EHR IP Data EHR IP IP “List” Secure Communications IP “Get”Bus EHR IP Data EHR IP Hospital, LTC, CCC, EPR POINT OF SERVICE Security Mgmt Rules/Data EAI IP Radiologist Physician Office EMR Lab Clinician EHR IP Data IP “List” EHR IP Data IP “Get” EHR IP Data EHR IP EHR IP EHR IP Physician Office EMR EHR Viewer EHR Viewer Physician/ Provider Physician/ Provider HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. Physician/ Provider EHR IS Reference Architecture 85 People Use Cases: Caregiver Perspective ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse • First class of SDK informative deliverables are contextual & informational • They describe the end-user functional requirements and assumptions for use of an integrated EHR Solution (DoDAF OV-3: Operational Resource Flow Matrix) • Establish when POS applications expected to interact with an EHRi in the context of daily work activities for caregivers (DODAF OV-6c: Event-Trace Description aka BPMN use case diagrams) • ESP SDK is only documenting Interoperability Specifications (ISs); not internal EHR features. • Scope is broad enough to cover large spectrum of healthcare and public health service delivery to achieve representative set Security Mgmt Rules/Data Privacy Rules/Data Configuration Rules/Data Information and Common Services EHR IS Secure Communications Bus EHR INTERFACE REQUIREMENTS DOCUMENTATION Public Health Services Radiology Center PACS/RIS Pharmacy System Storyboards, Use Cases Stakeholder Entities POINT OF SERVICE ESP SDK Public Health Provider Pharmacist Radiologist Lab System (LIS) Hospital, LTC, CCC, EPR Physician Office EMR Events, Encounters, Episodes of Care Lab Clinician Physician/ Provider HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. EHR Viewer Clinical Activities, Information Exchanges Physician/ Provider Physician/ Provider 86 EHR Interoperability Profile (EHR IP) ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services EHR Data & Services Data Warehouse • Second class of SDK normative deliverables; specify the interfaces between POS applications and ESP Enabled System (DODAF SV-6: Systems Resource Flow Matrix & SvcV-6: Services Resource Flow Matrix) • Establishes a language to describe types of service requests made to an EHRi (DODAF SV-1: Systems Interface Description & SvcV-1: Services Context Description) • Positions which data to be exchanged by referring to data views of the data model (DODAF DIV-1: Conceptual Data Model & DIV-2: Logical Data Model) • Assumes SOAP-based web services calls where XML encoded HL7 V3 message requests … V3? and responses are carried between POS applications and the EHRi EHR IS EHR Interoperability Profile (IP) Public Health Services Pharmacy System Radiology Center Information Exchange PACS/RIS Content Standards POINT OF SERVICE ESP SDK Public Health Provider Pharmacist Radiologist Lab System Hospital, LTC, (LIS) Information Exchange CCC, EPR Physician Office EMR EHR Viewer Transport Standards Lab Clinician Physician/ Provider HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. Physician/ Provider Physician/ Provider 87 EHR Infostructure IP (EHR I-IP) ORGANIZATIONAL INFOSTRUCTURE Registries Data & Services Client Registry Population Health Data & Services Outbreak Management PHS Reporting EHR Data & Services Shared Health Record Drug Information Data Warehouse Diagnostic Imaging Laboratory Health Information Provider Registry • Third class of SDK normative deliverables; specify inner workings within ESP Enabled System Infostructure to orchestrate and process transactions (DODAF SV-10c: Systems Event-Trace Description & SvcV-10c: Business EHR Message Normalization Services Event-Trace Rules Description) Index Structures Rules Location Registry Terminology • Express Registry sequencing of activities to process transactions (DODAF SV-5a: Information Access & Longitudinal Record Services (LRS)Operational Activity to Systems Function Traceability Matrix & SvcV-5: Operational Activity to Services Traceability Matrix) • Express expected capabilities of services within an EHRi to process transactions (DODAF CV-3: Capability Security Mgmt Privacy Configuration Phasing) Rules/Data Rules/Data Rules/Data Information and Common Services EHR IS Secure Communications Bus INFOSTRUCTURE INTEROPERABILITY PROFILE Infostructure IP Infostructure Services Catalogue Generic Interface Specification POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: not to [email protected] official use. 88 Enterprise Application Integration (EAI IP) ORGANIZATIONAL INFOSTRUCTURE Registries Data & Services Client Registry Population Health Data & Services Outbreak Management PHS Reporting EHR Data & Services Shared Health Record Drug Information Diagnostic Imaging Data Warehouse Laboratory Health Information Provider Registry • Fourth class of SDK normative deliverables; specify inner workings within ESP Enabled System Applications to orchestrate and process transactions (DODAF SV-10c: Systems Event-Trace Description & SvcV-10c: Business EHR Message Normalization Services Event-Trace Rules Description) Index Structures Rules Location Registry Terminology • Express Registry sequencing of activities to Information processAccess transactions (DODAF SV-5a: & Longitudinal Record Services (LRS)Operational Activity to Systems Function Traceability Matrix & SvcV-5: Operational Activity to Services Traceability Matrix) • Express expected capabilities of services within an EHRi to process transactions (DODAF CV-3: Capability Security Mgmt Privacy Configuration Phasing) Rules/Data Rules/Data Rules/Data Information and Common Services EHR IS Secure Communications Bus Enterprise Application Integration Interoperability Profile / Specification Application IP Application Services Catalogue Generic Interface Specification POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 89 Architecture Perspectives Business Architecture Clinical Work Process Architecture Potential Applications CONTEXT Integration & Deployment Models System Architecture Information Architecture ESP SDK WORKING DRAFT RFI: not for official use 90 EHR Infostructure: Services Drill-Down ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services Client Registry Outbreak Management PHS Reporting EHR Data & Services Shared Health Record Drug Information Data Warehouse Diagnostic Imaging Health Information Laboratory Provider Registry Location Registry Business Rules EHR Index Terminology Registry Message Structures Normalization Rules Information Access & Longitudinal Record Services (LRS) Security Mgmt Rules/Data Privacy Rules/Data Configuration Rules/Data Information and Common Services EHR IS Secure Communications Bus Public Health Services POINT OF SERVICE ESP SDK Public Health Provider Radiology Center PACS/RIS Pharmacy System Pharmacist Radiologist Lab System (LIS) Lab Clinician Hospital, LTC, CCC, EPR Physician Office EMR Physician/ Provider HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. Physician/ Provider EHR Viewer Physician/ Provider 91 EHR Infostructure: Standards Based Connectivity ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services EAI IP Provider Registry EAI IP Location Registry EHR Data & Services Data Warehouse Outbreak Management PHS Reporting Shared Health Record Drug Information Diagnostic Imaging Laboratory EAI IP EAI IP EAI IP EAI IP EAI IP EAI IP Business Rules EHR Index EAI IP Client Registry EAI IP Registries Data & Services Terminology Registry Message Structures Health Information Normalization Rules Information Access & Longitudinal Record Services (LRS) EAI IP IP is Interoperability Profile EAI is Enterprise Application Integration EAI IP Security Mgmt Rules/Data EAI IP Privacy Rules/Data Configuration Rules/Data Information and Common Services EHR IS Secure Communications Bus EHR SCP Standards EHR IP EHR IP Standards EHR IP EHR IP Standards EHR IP Standards EHR IP EHR IP EHR IP Standards EHR IP EHR IP Standards EHR IP Standards EHR IP EHR IP Standards EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP Public Health Services Pharmacy System Radiology Center PACS/RIS Lab System (LIS) Hospital, LTC, CCC, EPR Physician Office EMR EHR Viewer POINT OF SERVICE ESP SDK EHR IP Public Health Provider Pharmacist Radiologist Lab Clinician Physician/ Provider HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. Physician/ Provider Physician/ Provider 92 EHR Infostructure: Secure Communications Bus ORGANIZATIONAL INFOSTRUCTURE Registries Data & Services Population Health Data & Services EHR Data & Services Data Warehouse Secure Communications Bus MESSAGING Transformation Services Routing Services Encrypt/Decrypt Services En/Decoding Services Parser Services Serialization Services EHR IS PROTOCOL App Protocol Services Secure Communications Bus Network Protocol Services POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 93 EHR Infostructure: Common Services ORGANIZATIONAL INFOSTRUCTURE Registries Data & Services Population Health Data COMMON SERVICES & Services EHR Data & Services PRIVACY & SECURITY INTEROP Interoperability Services Identity Protection Services Anonymization Services Consent Directives Mgmt Services Search/Resolution Services Identity Mgmt Services User Authentication Services Encryption Services INTEGRATION Access Control Services Secure Auditing Services Digital Signature Services Service Catalogue Services General Security Services Broker Services Mapping Services SUBSCRIPTION Queuing Services Alert/Notification Services CONTEXT Pub/Sub Services EHR IS Caching Services Data Warehouse MANAGEMENT GENERAL Security Mgmt Rules/Data Privacy Rules/Data Configuration Rules/Data Management Information and Common Auditing Services Services Services Configuration Services Log Mgmt Services Policy Mgmt Services Exception/Error Handling Services Session Mgmt Services POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 94 EHR Infostructure: Longitudinal Record Services (LRS) ORGANIZATIONAL INFOSTRUCTURE Registries Data & Services Population Health Data & Services EHR Data & Services Data Warehouse Longitudinal Record Services (LRS) DATA Business Rules EHR Index Message Structures Normalization Rules Key Mgmt Services Data Services ETL Information Access & Longitudinal Record Services (LRS)Services Replication Services BUSINESS Data Quality Services Normalization Services EHR IS Domain Business Components (Registries, EHR, Domains, User, Context) EHR Index Services Business Rules Services Orchestration Services Assembly Services POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 95 EHR Infostructure: Longitudinal Record Services (LRS) ORGANIZATIONAL INFOSTRUCTURE Registries Data & Services Population Health Data & Services The EHR Index maintains a sequential list of all events that affect the clinical picture of a client. It also provides the location where the data relevant to each event is kept in the EHRi. It can be used to retrieve the history of events for a client or to trace the information about a specific event. EHR Data & Services Data Warehouse Longitudinal Record Services (LRS) DATA EHR INDEX Event ID (Instance ID of an Business Rules event) Parent Folder ID Focal Class Type EHR Index Message Structures Normalization Rules Key Mgmt Services Data Services ETL Information Access & Longitudinal Record Services (LRS)Services Replication Services Focal Act Subject (Client ECID) Focal Act Author (Provider) BUSINESS Focal Act Service Delivery Location Data Quality Services Focal Act Timestamp Normalization Services EHR IS Focal Act Status Domain Business Components (Registries, EHR, Domains, User, Context) Focal Act Language Focal Act Type: • Act Mood (e.g. Order Request) • Act Class Code (type of class, e.g. Lab order) • Act Code (Class value, e.g. CBC) Focal Act Source ID (ID provided by POS) EHR Index Services Business Rules Services Orchestration Services Assembly Services Focal Act Template ID Focal Act Data Location ID (URI) POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 96 EHR Infostructure: EHR IS Locator Data CROSS-ORGANIZATIONAL INFOSTRUCTURE • • • • • EHR IS Locator EHRi Client ID (resolved ECID) CR instance ID (OID root) EHRi instance ID (which instance of an EHRi) EHRi URI (the URI to access the EHR IS) Optimized for performance • Information type (drug, lab, DI) (derived from HL7 act classes) • First created date • Last updated date ORGANIZATIONAL INFOSTRUCTURE EHR IS ENABLED SYSTEM SOLUTION EHR IS ENABLED SYSTEM SOLUTION EHR INFOSTRUCTURE (EHRi) EHR INFOSTRUCTURE (EHRi) Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services Information Access & Longitudinal Record Services (LRS) Point of Service Application Health Information Data Warehouse EHR Data & Services Registries Data & Services Information Access & Longitudinal Record Services (LRS) EHR Information Services (EHR IS) Point of Service Application Population Health Data & Services EHR Information Services (EHR IS) EHR Viewer Point of Service Application Point of Service Application EHR Viewer POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 97 Centralized Service Approach CROSS-ORGANIZATIONAL INFOSTRUCTURE EHR IS Locator ORGANIZATIONAL INFOSTRUCTURE EHR IS ENABLED SYSTEM SOLUTION EHR IS ENABLED SYSTEM SOLUTION EHR IS ENABLED SYSTEM SOLUTION EHR INFOSTRUCTURE (EHRi) EHR INFOSTRUCTURE (EHRi) EHR INFOSTRUCTURE (EHRi) Health Information Data Warehouse Population Health Data & Services EHR Data & Services Registries Data & Services Information Access & Longitudinal Record Services (LRS) Point of Service Application EHR Data & Services Registries Data & Services Information Access & Longitudinal Record Services (LRS) EHR Information Services (EHR IS) Point of Service Application Health Information Data Warehouse Population Health Data & Services Point of Service Application Point of Service Application EHR Data & Services Registries Data & Services Information Access & Longitudinal Record Services (LRS) EHR Information Services (EHR IS) EHR Viewer Health Information Data Warehouse Population Health Data & Services EHR Information Services (EHR IS) EHR Viewer Point of Service Application Point of Service Application EHR Viewer POINT OF SERVICE ESP SDK Organization Organization Organization A B C HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 98 Distributed Service Approach CROSS-ORGANIZATIONAL INFOSTRUCTURE EHR IS Locator Synchronization EHR IS Locator EHR IS Locator ORGANIZATIONAL INFOSTRUCTURE EHR IS ENABLED SYSTEM SOLUTION EHR IS ENABLED SYSTEM SOLUTION EHR IS ENABLED SYSTEM SOLUTION EHR INFOSTRUCTURE (EHRi) EHR INFOSTRUCTURE (EHRi) EHR INFOSTRUCTURE (EHRi) Health Information Data Warehouse Population Health Data & Services EHR Data & Services Registries Data & Services Information Access & Longitudinal Record Services (LRS) Point of Service Application EHR Data & Services Registries Data & Services Information Access & Longitudinal Record Services (LRS) EHR Information Services (EHR IS) Point of Service Application Health Information Data Warehouse Population Health Data & Services Point of Service Application Point of Service Application EHR Data & Services Registries Data & Services Information Access & Longitudinal Record Services (LRS) EHR Information Services (EHR IS) EHR Viewer Health Information Data Warehouse Population Health Data & Services EHR Information Services (EHR IS) EHR Viewer Point of Service Application Point of Service Application EHR Viewer POINT OF SERVICE ESP SDK Organization Organization Organization A B C HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 99 EHR IS Locator: LRS Integrated Approach CROSS-ORGANIZATIONAL INFOSTRUCTURE EHR IS Locator ORGANIZATIONAL INFOSTRUCTURE Registries Data & Services Population Health Data & Services EHR Data & Services Data Warehouse Client Registry Provider Registry Location Registry Terminology Registry Business Rules EHR Index Message Structures Normalization Rules Information Access & Longitudinal Record Services (LRS) EHR IS POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 100 LRS Integrated Services Approach CROSS-ORGANIZATIONAL INFOSTRUCTURE Client Registry Synchronization ORGANIZATIONAL INFOSTRUCTURE EHR IS ENABLED SYSTEM SOLUTION EHR IS ENABLED SYSTEM SOLUTION EHR IS ENABLED SYSTEM SOLUTION EHR INFOSTRUCTURE (EHRi) EHR INFOSTRUCTURE (EHRi) EHR INFOSTRUCTURE (EHRi) Health Information Data Warehouse Population Health Data & Services EHR Data & Services Registries Data & Services Information Access & Longitudinal Record Services (LRS) Point of Service Application EHR Data & Services Registries Data & Services Information Access & Longitudinal Record Services (LRS) EHR Information Services (EHR IS) Point of Service Application Health Information Data Warehouse Population Health Data & Services Point of Service Application Point of Service Application EHR Data & Services Registries Data & Services Information Access & Longitudinal Record Services (LRS) EHR Information Services (EHR IS) EHR Viewer Health Information Data Warehouse Population Health Data & Services EHR Information Services (EHR IS) EHR Viewer Point of Service Application Point of Service Application EHR Viewer POINT OF SERVICE ESP SDK Organization Organization Organization A B C HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 101 EHR Infostructure: EHR Data Domain Services ORGANIZATIONAL INFOSTRUCTURE Registries Data & Services Population Health Data & Services EHR Data & Services Shared Health Record Drug Information Diagnostic Imaging Data Warehouse Laboratory SHARED HEALTH RECORD DATA Key Mgmt Services EHR IS Data Services BUSINESS Domain Business Components (Registries, EHR, Domains, User, Context) Normalization Services Business Rules Services EHRi Interoperability Services Assembly Services POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 102 EHR Infostructure: EHR Viewer ORGANIZATIONAL INFOSTRUCTURE Registries Data & Services Population Health Data & Services EHR Data & Services Data Warehouse EHR VIEWER EHRi Interoperability Services Data Services EHR Viewer Business Objects Components Normalization Services Business Rules Services End-user Navigation Services End-user Display Services EHR IS EHR Viewer Physician/ Provider POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 103 EHR Infostructure: Client Registry ORGANIZATIONAL INFOSTRUCTURE Registries Data & Services Population Health Data & Services EHR Data & Services Data Warehouse Client Registry Provider Registry Location Registry Terminology Registry EHR IS POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 104 EHR Infostructure: Why A Client Registry? ORGANIZATIONAL INFOSTRUCTURE Registries Data & Services Population Health Data & Services EHR Data & Services Data Warehouse Client Registry Provider Registry Location Registry Terminology Registry Has Mr. Lambert had any ER visits since I’ve last seen him one year ago? EHR IS Patient Info End-user Info Visit History Drug Profile Laboratory Diagnostic Imaging POINT OF SERVICE EHR Viewer Physician/ Provider EHR VIEWER ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 105 EHRi Client Registry: The Challenge EMPI 1: A 123 Robert Lambert 1 Main St 1: B 456 Bob Lambert 1 Main St 1: C 789 Robert Lambert 1 Main St 1: C 987 Robert Lambert 1 Main St 2: B 444 Robert Lambert 2 Elm St Pharmacy Lab ??? A B C 123 Robert Lambert 1 Main St 456 Bob Lambert 1 Main St 444 Robert Lambert 2 Elm St 789 Robert Lambert 1 Main St 987 Robert Lambert 1 Main St ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 106 EHRi Client Registry: What Data? Name Birthdate Gender The generation (or sourcing) of the EHRI Client Identifier (ECID) is a service offered by the Client Registry. Address Phone SSN ULI ECID The ECID is the foundation for interoperability both locally and across EHR Infostructures. MDR – Medical Device Regulations SSN – Social Security Number ULI – Unique Lifetime Identifier Static, natural person identity information Dynamic, natural person identity information Static, artificial person-identifying information MDR ID Lab ID Dynamic, artificial person-identifying information Eligibility status Coverage details Core system data about the person The DoD & VA ULI is called Electronic Data Interchange Personal Number, or EDIPN, is a unique number assigned to a record in the United States Department of Defense's Defense Enrollment and Eligibility Reporting System (DEERS) database. A record in the DEERS database is a person plus personnel category (e.g. contractor, reservist, civilian, active duty, etc.). ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 107 EHRi Client Registry: Interoperability Pattern ORGANIZATIONAL ECID: J1 Root ID. Client ID ECID: J2 Root ID. Client ID Client Registry J1 Client Registry J2 Client Registry J1/2 Client Registry J1.1 Applications ESP SDK Active synchronization of travelling clients only Applications HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 108 EHR Infostructure: Provider Registry ORGANIZATIONAL INFOSTRUCTURE Registries Data & Services Population Health Data & Services EHR Data & Services Data Warehouse Client Registry Provider Registry Location Registry Terminology Registry EHR IS POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 109 EHR Infostructure: Why A Provider Registry? ORGANIZATIONAL INFOSTRUCTURE Registries Data & Services Population Health Data & Services EHR Data & Services Data Warehouse Client Registry Provider Registry Location Registry Terminology Registry Have any new test results been published for me? EHR IS Patient Info End-user Info Visit History Drug Profile Laboratory Diagnostic Imaging POINT OF SERVICE EHR Viewer Physician/ Provider EHR VIEWER ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 110 Provider Registry: Data Sources ORGANIZATIONAL Doctors Unlicensed Providers Dentists EHR SCP Standards Provider Registry Provider Registry EHR SCP Standards Provider Registry Applications Applications Applications REGIONAL ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 111 Standards-based Solutions: What Does It Mean? ESP SDK WORKING DRAFT RFI: not for official use 112 integrated EHR Solutions: Key Architectural Requirements Standardized Architecture Standardized Interfaces Standardized Data Structures Standardized Data Vocabularies (encoding rules) Standards-based Solutions Standardized Functional Behaviour ESP SDK WORKING DRAFT RFI: not for official use 113 Standards-based Solutions Why Standards? • They facilitate information exchange; are a critical foundation for EHR • They create opportunity for future cost reduction as vendors and systems converge on national and international standards • They ease effort required for replication Mandatory Investment Eligibility Requirements • Compliance to standards (infostructure, architecture) • Initiatives must comply with existing guidelines or standards adopted by US Health and Human Services (HHS) An OSEHRA role is to encourage standards and requirements for robust, interoperable EHR products for improved clinical outcomes • Where standards or guidelines do not exist, projects must support longer-term interoperability and congruence of solutions ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 114 Principles for Establishing ESP Enabled System Standards • The HL7 has created Principles for Establishing EHR interoperability • Standards to provide guidance in the adoption of standards-based solutions • As the ESP SDK evolves, there are many assumptions made that, once implemented in the architecture, can no longer be considered assumptions anymore: they are now principles about the function of EHR IS Infostructures and EHR IS Solutions that need to guide detailed design and development of solutions and Business-driven Adoption of existing standards where ever possible ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 115 Principles for Establishing EHR IS Standards • Standards initiatives to be driven by the business of healthcare with a clearly defined business need • Existing standards work must be leveraged wherever possible and practical with an approach that includes adoption, or adaptation of existing standards, before development • Health Level 7 V3 messaging standard required for all new message development related to EHR • Investments predicated on a commitment to implement national EHR Services standards • Standards to be established, tested, refined and evaluated within the context of early adopter implementations • We should support early adopter investment projects that have the establishment of National standards as their goal HELP NEEDED to confirm Official DoD-VA Principles ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. See notes page 116 Principles for Establishing EHR IS Standards • Establishing standards is an evolutionary process and will not be perfect the first time; implementation of standards that are not fully balloted may be needed • OSEHRA program is committed to supporting influencing EHR national and international standards • OSEHRA program and its stakeholders will work with other organizations undertaking similar EHR initiatives to leverage their work and bring synergies to the projects as they move toward balloted standards • OSEHRA program and its stakeholders will partner with HL7, IHE, OASIS, IHTSDO and other standards organizations in the establishment of EHR IS standards • Establishment of EHR IS related standards is coordinated via an open, transparent and inclusive Stakeholder Collaboration Process HELP NEEDED to confirm Appropriate Principles ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. See notes page 117 Standards Collaboration Process (SCP) • National EHR Standards Advisory Committee REGIONAL DEVELOPMENT Telehealth Lab Interoperable EHR Diagnostic Imaging Drugs Registries Infostructure/EHR The EHR Standards Collaboration Process will establish standards for investments through collaboration and consensus EHR Standards Steering Committee Expert Working Groups • The EHR Standards Collaboration Process includes those Organizations, standardsrelated organizations, healthcare professionals and vendors that will build, operate and use an integrated EHR Services Platform (ESP) GOVERNANCE STRATEGIC COLLABORATION/COORDINATION • An integral element of and key requirement for the establishment of an interoperable Electronic Health Record (EHR) Infostructure National Standards working groups ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 118 EHR IS Standards: Status Needed Standards Groups • • • • • • • Drugs Client Registry Provider Registry DI/Tele-radiology Laboratory Clinical Terminology EHR Technical Standards (coming soon) • EHR Clinical Standards (coming soon) • Public Health (coming soon) Suggested Projects Health Surveillance Telehealth Lab Diagnostic Imaging Drugs Registries integrated EHR • • • • • • • • • • • • • ESP SDK EHR Data Definition & Standards Standards Collaboration Process Standards Tactical Plan Artefacts Repository Telehealth ISO Interoperability Telehealth CCHSA Accreditation Client Registry Provider Registry Laboratory Nomenclature & Messaging NeCST: electronic claims messaging EHR Clinical Terminology Integration EHR Profiles for Interoperability between DI, Registries & Consumers • EHR-EHR IS Evolution Project • Privacy & Security Architecture Project HELP NEEDED to confirm Current Status ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 119 EHR IS Infostructure: Standards-based Connectivity ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services EHR Data & Services Data Warehouse EAI IP Registries Data & Services EAI IP Architecture Standards EAI IP Data Messaging Standards EAI IP EAI IP • Client Registry EAI IP • ESP Blueprint EAI IP EAI IP EAI IP • HL7 Provider Registry • FHIM/EHR Data Model • HL7 Pharmacy • EHR IS Services Model • Laboratory • EHR Interoperability Profiles • Public Health Services Standards EAI IP • Terminology Standards EAI IP Health Surveillance Standards • Public EAI IP • EHR Use Cases EAI IP EHR • IS Terminology implemented in data messaging standards EHR SCP Standards EHR IP EHR IP Standards EHR IP POINT OF SERVICE ESP SDK Public Health Provider EHR IP • Diagnostic Imaging/Teleradiology (in planning) EHR IP EHR IP Standards EHR IP EHR IP Standards IP Standards EHR IP Standards • Technical Standards EHR (DODAF StdV-1: EHR IP IP EHR IP Standards ProfileEHR aka DoD-VA shared Standards Profile) EHR IP Standards EHR IP Pharmacist • Clinical EHR IP Messaging EHR(in IP planning) EHR IP Radiologist Lab Clinician Physician/ Provider HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. Physician/ Provider EHR IP EHR IP Standards EHR IP Physician/ Provider 120 Service-oriented Architecture (SOA): What Does It Mean? ESP SDK WORKING DRAFT RFI: not for official use 121 Level of Encapsulation Can Vary: Five Normal Forms of Encapsulated Software 1 2 3 4 5 External access Other data Own data Encapsulated software Programmatic interface Overloaded, incomplete; any data One complete function; any data Own data only Exclusive data Opaque data Source: Gartner ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. See notes page 122 SOA as an Enabler Applications of SOA in EHRi Solutions • Repurposed legacy applications to offer services as part of SOA-based EHR Infostructure • New breed of services to enable coordinated transactions in an EHR Infostructure (e.g. Information Access & Longitudinal Record Services (LRS)) • Use of commercially available solutions to enable components of EHR Infostructure Two Degrees of Separation • Services exposed outside of an EHRi in the form of supported EHR Interoperability Profiles for an entire Infostructure perceived as a single system with transactional services • Services within an EHR Infostructure to optimize scalability, maintainability and functional flexibility ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 123 First Degree: The EHR Service ORGANIZATIONAL INFOSTRUCTURE ClientGet Client ID RegistryResolution Get Outbreak Case Data PHS Reporting Outbreak Management Provider Registry Location Registry EHR SERVICE Population Health Data & Services Registries Data & Services List CD Report Events Shared Health Record Business Rules EHR Index List Service Terminology Registry Delivery Locations Data Warehouse Get DI Report List DI Results Diagnostic Imaging Drug Information Message Structures Health Information Laboratory List Laboratory Results List Encounter Events Get Provider Information EHR Data & Services Stream DI Image Normalization Rules List Laboratory Orders Get Laboratory Result Information Access & Longitudinal Record Services (LRS) List Medications Get Encounter Summary Security Get Clinical Dashboard Privacy Data Configuration Get Client Get Prescription DemographicInformation and Common Services EHR IS Secure Communications Bus Public Health Services POINT OF SERVICE ESP SDK Public Health Provider Radiology Center PACS/RIS Pharmacy System Pharmacist Radiologist Lab System (LIS) Lab Clinician Hospital, LTC, CCC, EPR Physician Office EMR Physician/ Provider HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. Physician/ Provider EHR Viewer Physician/ Provider 124 Second Degree: Inside The EHR Infostructure ORGANIZATIONAL INFOSTRUCTURE Registries Data & Services CR Services Client Registry PR Provider Services Registry LR Location Services Registry Terminology Terminology Registry Services Population Health Data & Services Detection Outbreak & Reporting Services Services Outbreak PHS Management Business Rules Rules Services A&A Services EHR IS Reporting EHRi SERVICES Shared Health Record Services Shared Health Record EHR Data & Services Drug Services Drug Information DI Services Diagnostic Imaging EHR Message Normalization EHR Index Index Structures Rules Orchestration Services Services Information Access & Longitudinal Record Services (LRS) Normalization Services Brokering Services Consent Services Session Services Data Warehouse Lab Services Health Information Laboratory Assembly Services Security Mgmt Privacy Data Logging Data Services Configuration Information and Common Services Secure Communications Bus EHR IP Any Point-of-Service Application POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. See notes page 125 Functioning Principles ESP SDK WORKING DRAFT RFI: not for official use 126 Functioning Principles/Rules • Home/no-home EHR • Level of parameterization • EHRi Identifier Management • Primary Purpose for EHRi repositories • EHR Index • Other uses of the EHR IS (POS to POS) • ESP Locator • Multilingual capabilities • POS to EHRi interface • Runtime environment • Level of transparency of EHR to POS applications • Performance principles – targets • Transaction scope • Error Handling • Trust Models valid for an EHRi • Consent • EHR IS normalization of information/terminology • Authentication & Authorization • Auditing, logging, use of logs • HL7 V3 (Messaging and templates) ESP SDK • POS Integration environment • OIDS as a principle • Prospective Events HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 127 Architecture Perspectives Business Architecture Clinical Work Process Architecture Potential Applications CONTEXT Integration & Deployment Models System Architecture Information Architecture ESP SDK WORKING DRAFT RFI: not for official use 128 EHRi Conceptual Data Model Governance • High-level model representing generalized concepts • Encounter Management, • Care Plan Service, Role Event Linkage • Health Concern Tracking • Analytics • Event driven model to represent instances of clinical service impacting a patient record • Broad range of event typing – governance, people playing roles, delivery, environment, resource Event People Place • Derived from the Federal Health Information Model (FHIM) • Detailed Clinical Models (DCLs) Capability • Aligned and mapped to HL7 V3 RIM • Mapped against several local and international EHR data models • More detailed views available – transactional views, domain views ESP SDK Resource HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. Environment 129 Components of Computable Data Terminology Model • An Terminology is a formal representation of healthcare knowledge as a set of concepts , called terms, and the relationships between those terms. • An information model is a representation of concepts, relationships, constraints, rules, and operations to specify data semantics for healthcare. Concepts Concept relationships Concept definitions Terms Hierarchies Clinical propositions Standard terminologies Mappings Not patient specific Information Model Structural layout Clinical definition Hierarchical in nature Contains fields for discrete values Fields tied to dictionary Defines “valid data” Not patient specific Instances of data using model and dictionary Event based Constrained by model Patient specific Repository 130 ESP SDK WORKING DRAFT RFI: not for official use. See notes page Key Terms and Concepts … Terminology The approach to common terminology is for both agencies to use SNOMED + Extensions = Lingua Franca for semantically interoperable Terminology. The EHR Services Platform will incorporate the EHR IS Information and terminology models as the logical data models for our shared (virtual) repositories; thereby, improving semantic interoperability and performance. 131 ESP SDK WORKING DRAFT RFI: not for official use. See notes page 131 Use Case Example: Patient is Admitted with “Cold” Symptoms As-Is = Different Points of Entry Can Have Different Interpretations of “Cold” As-Is… MHS Private Health Sector VA To Be… & Other Cold GUI GUI GUI SERVICES SERVICES SERVICES cold C.O.L.D. Cold = cold = C.O.L.D. = EHR IS = Patient is diagnosed with the Common Cold Patient is diagnosed as psychologically unfeeling and distant Patient is diagnosed with Chronic Obstructive Lung Disease The right diagnosis based on the right data applied in the right context The EHR IS reduces redundancies, leverages agency resources, provides contextual information, and ensures data integrity across DoD and VA applications, directly improving continuity of care 132 ESP SDK WORKING DRAFT RFI: not for official use. 132 132 HDD and SNOMED-CT mapping work - Mapping Example (not actual codes) HDD NCID SNOMED-CT 443 <Substance> <acetylsalicylic acid (ASA) ID: 123455> 812 123 RxNORM MEDCIN CPT CHCS 1 VistA 1 <Orderable drug Brand Name ID> <Aspirin: 82464> 2214 N/A ASP A112 <Condition: diagnosis><Cold> N/A 9923 123 Cld CD8 <Procedure Test Result Name:> < Red Blood Count> N/A 1324 98231 RBC RBC DoD specific term VA term 923 133 ESP SDK WORKING DRAFT RFI: not for official use. See notes page 133 EHR IS Services • Services Provided by EHR IS Translation – syntactic and semantic data harmonization using standard information models and SNOMED CT and extensions as the EHR IS conical terminology and ESP data stores’ native terminology. • Syntactic field mapping and conformance • Semantic terminology mediation and value normalization • Mediation - a mediation service can handle the transformation from one information-exchange payloadformat and transport to another. • Built-In-Test-Environment (BITE) - for run-time information-exchange integrity-checking. • Common Terminology Services 2 (CTS2) - CTS 2 terminology services • Metadata Service – provides information schemas and terminology bindings Services Used by EHR IS • Identification – Who are you looking for? • Authentication – Who are you? • Authorization –What are you allowed to know or do? • Secure Data Transport - Standards-based information exchanges. • RLUS - Retrieve, Locate, Update Service • Rules Engine – – A business rule service enables policies and other operational decisions to be defined, tested, executed and maintained separately from application code. 134 ESP SDK WORKING DRAFT RFI: not for official use. 134 Architecture Perspectives Business Architecture Clinical Work Process Architecture Potential Applications CONTEXT Integration & Deployment Models System Architecture Information Architecture ESP SDK WORKING DRAFT RFI: not for official use 135 EHR IS Integration Layer: Evolutionary Path ESP SDK WORKING DRAFT RFI: not for official use 136 Interim State: No EHR Services (Undesirable) ORGANIZATIONAL INFOSTRUCTURE Registries Data & Services Drug Information System Repository CR API Client Registry EHR Data & Services CR API HL7 (CR) Search/Resolve DR API HL7 v3 (Rx) Client Registration 1) Search client 2) Create new client 3) Update existing client PATIENT ENCOUNTER Client Registration 1) Search client 2) Create new client 3) Update existing client Pharmacy Profile 4) Request drug profile 5) Request DUR 6) Enter new prescription CR API Each Organization Infostructure level system uses patient and other required strong identifiers (e.g. provider, encounter) based on point-of-service generated IDs (e.g. MRNs). The CR-EMPI source systems make the CR-EMPI aware of client identifiers. The Point-ofService applications and Infostructure systems query the CR EMPI for these identifiers in order to access data within any Infostructure System. The level of queries and maintenance of MRNs in the EMPI is not scalable to hundreds or thousands of Point-ofService systems. There are performance issues accessing CR/EMPI for every Drug system interaction. Pharmacy Profile 4) Request drug profile 5) Request DUR 6) Enter new prescription HL7 v3 (Rx) DR API CR API Pharmacy System EHR Viewer DR API HL7 (CR) Pharmacist Physician POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. See notes page 137 Interim State: EHR IS Without LRS The Client Registry system “determines” a global unique ID (EHR ID) for patients. The Drug Informaton System (DIS) will use the EHR patient ID to store prescribing and dispensing data. Point-of-Service applications query the Client Registry and obtain the EHR patient ID and will use this ID as a token throughout the entire business transaction. This model eliminates the need for communication between the DIS and CR and reduces the transactions to the CR to one per business transaction. ORGANIZATIONAL INFOSTRUCTURE EAI IP Client Registry Client Registration 1) Search client 2) Create new client 3) Update existing client Get EHR ID HL7 (CR) HL7 v3 (Rx) Drug Information System Repository Pharmacy Profile 4) Request drug profile 5) Request DUR 6) Enter new Prescription EAI IP Determine EHR Client ID EHR Data & Services Search/ Resolve EAI IP Registries Data & Services Security Mgmt Rules/Data Privacy Rules/Data Configuration Rules/Data Information and Common Services EHR IS HL7 Pharmacy System HL7 EHR IP PATIENT ENCOUNTER Client Registration 1) Search client 2) Create new client 3) Update existing client EHR IP Secure Communications Bus EHR Viewer Pharmacy Profile 4) Request drug profile 5) Request DUR 6) Enter new prescription Pharmacist Physician POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 138 Interim State: EHR IS Without LRS ORGANIZATIONAL INFOSTRUCTURE Client Registration 1) Search client 2) Create new client 3) Update existing client Search/Resolve Get EHR ID HL7 (CR) Data Access Information Access & LRS Business Components Determine EHR Client ID CR API The Client Registry determines a global unique ID (EHR ID) for patients. The DIS will use the EHR patient ID to store prescribing and dispensing data. EHR services will use the CR to map any local MRN found within transactions to the corresponding EHR client ID. The POS applications do not necessarily have to be aware of the EHR client ID or they can continue to provide this ID themselves after querying the CR (compatible with prior model). EHR Data & Services DR API EHR Index HL7 v3 (Rx) EAI IP Client Registry EAI IP Registries Data & Services Drug Information System Repository Pharmacy Profile 4) Request drug profile 5) Request DUR 6) Enter new Prescription Security Mgmt Rules/Data Privacy Rules/Data Configuration\ Rules/Data Information and Common Services EHR IS HL7 Pharmacy System HL7 EHR IP PATIENT ENCOUNTER Client Registration 1) Search client 2) Create new client 3) Update existing client EHR IP Secure Communications Bus EHR Viewer Pharmacy Profile 4) Request drug profile 5) Request DUR 6) Enter new prescription Pharmacist Physician POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 139 Target State: Full Featured EHR IS Infostructure ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services Client Registry Outbreak Management PHS Reporting The client, provider, location registries and EHR Services Data determine (respond with) Warehouse global unique ids for patient, providers, encounters and other required strong identifiers. Health All Laboratory Infostructure systems use these Information unique IDs to store clinical data about a person. The EHR Services will map any local ID to the corresponding EHR ID. The Domain services (DIS, DI, Lab) systems rely on the EHR Services to ensure that the necessary EHR IDs are provided with every transaction. EHR Data & Services Shared Health Record Drug Information Diagnostic Imaging Provider Registry Location Registry Business Rules EHR Index Terminology Registry Message Structures Normalization Rules Information Access & Longitudinal Record Services (LRS) Security Mgmt Rules/Data Privacy Rules/Data Configuration Rules/Data Information and Common Services EHR IS Secure Communications Bus Public Health Services POINT OF SERVICE ESP SDK Public Health Provider Radiology Center PACS/RIS Pharmacy System Pharmacist Radiologist Lab System (LIS) Lab Clinician Hospital, LTC, CCC, EPR Physician Office EMR Physician/ Provider HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. Physician/ Provider EHR Viewer Physician/ Provider 140 ESP Infostructure: Deployment Models ESP SDK WORKING DRAFT RFI: not for official use 141 Client Registry Provider Registry Laboratory Repository REGION 1 DI Repository Drug Repository Larger size Organizations • Organizational or regional Client and Provider and Location Registries REGION 2 Shared Health Record DI Repository Information Access & Longitudinal Record Services (LRS) • Organizational or regional Lab, Drug Repositories and EHR IS Shared Health Record • Supra-regional LRS, Shared Health Record and DI Repositories and EHR Viewer Information Access & Longitudinal Record Services (LRS) Information and Common Services EHR IS • ESP Locator across organizations or regions Secure Communications Bus EHR Viewer EMR Medium size Organizations • Organizational or regional Client and Provider and Location Registries • Organizational or regional Lab, Drug, Diagnostic Imaging (DI), Shared Health Record, LRS, EHR IS and EHR Viewer CIS REGIONAL/ ORGANIZATIONAL CIS • ESP Locator across Organizational or regional • Local EMR, CIS and other applications ESP SDK EHR Viewer Client Registry EMR • Local EMR, CIS and other applications Provider Registry Laboratory Repository Shared Health Record Drug Repository DI Repository Information Access & Longitudinal Record Services (LRS) Information and Common Services EHR IS Secure Communications Bus LOCAL LOCAL/REGIONAL REGIONAL/ ORGANIZATIONAL Large & Medium Deployment Models CIS EHR Viewer HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. EMR 142 Small Organizations REGIONAL Client Registry Provider Registry Diagnostic Imaging (DI) Repository Shared Health Record Drug/Lab Information Access & Longitudinal Record Services (LRS) Information and Common Services EHR IS Secure Communications Bus LOCAL CIS EHR Viewer EMR • Regional Client, Provider & Location Registry • integrated hospital CIS solution fulfilling the roles of the Regional EHR Services, Laboratory and Drug services • Regional Diagnostic Imaging (DI) Service • Regional EHR IS & EHR Viewer • Local physician office systems & other CIS connect as POS Systems ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 143 Model 1: Single EHR Infostructure REGIONAL Registry & Data Services Client registry Provider Registry EHR Data & Services Location registry Terminology Registry Drug Information EHR Data & Services Shared Health Record Business Rules EHR Index Message Structures Diagnostic Imaging (DI) Laboratory Normalization Rules Information Access & Longitudinal Record Services (LRS) Security Mgmt Rules/Data Privacy Rules/Data Configuration Rules/Data Information and Common Services EHR IS Secure Communications Bus Public Health Services POINT OF SERVICE ESP SDK Public Health Provider Radiology Center PACS/RIS Pharmacy System Pharmacist Radiologist Lab System (LIS) Lab Clinician Hospital, LTC, CCC, EPR Physician Office EMR Physician/ Provider HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. Physician/ Provider EHR Viewer Physician/ Provider 144 Model 2: Shared EHR Infostructure REGIONAL Registry & Data Services Client registry Provider Registry Location registry REGIONAL EHR Data & Services Terminology Registry Drug Information REGION 1 Shared Health Record Business Rules Diagnostic Imaging (DI) EHR Index … REGION 2 Shared Health Record Laboratory Message Structures Normalization Rules Business Rules Information Access & Longitudinal Record Services (LRS) Diagnostic Imaging (DI) EHR Index Shared Health Record Laboratory Message Structures Normalization Rules Information Access & Longitudinal Record Services (LRS) Security Mgmt Rules/Data Privacy Rules/Data Configuration Rules/Data Information and Common Services EHR IS Secure Communications Bus Public Health Services POINT OF SERVICE ESP SDK Public Health Provider Radiology Center PACS/RIS Pharmacy System Pharmacist Radiologist Lab System (LIS) Lab Clinician Hospital, LTC, CCC, EPR Physician Office EMR Physician/ Provider HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. Physician/ Provider EHR Viewer Physician/ Provider 145 Model 3: Distributed EHR Infostructures REGIONAL Registry & Data Services Client registry Provider Registry REGIONAL Location registry EHR Data & Services Terminology Registry Drug Information REGIONAL EHR Data & Services POINT OF SERVICE REGIONAL EHR Data & Services POINT OF SERVICE Region 1 EHR Data & Services POINT OF SERVICE Region 2 Region X Least leverage No solution Most leverage Different specification Different standards Specification & standards Data model Business process Business rules User Interface Same solution Use shared service Reuse drives down cost, accelerates timelines, reduces risk and enables interoperability ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 146 Regional/Organizational Deployment Decisions Business choices? • Who, where, when, what EHR Data & Services • Clinical value • Adoption Drug REGIONAL Registry & Data Services Client registry Provider Registry Location registry Terminology Registry Information Solution development choices? • Services/functions • Data persistence EHR Data & Services Shared Health Record Business Rules EHR Index Message Structures Diagnostic • Imaging Laboratory standards Communication • Data standards • Integration tooling Normalization Rules/Data Evolution plan? • What Information Access & Longitudinal Record Services (LRS) functionality when • EHR Service evolution path Privacy Configuration choices? Deployment configuration Security Mgmt Data Information and Common Services EHR IS Secure Communications Bus Public Health Services POINT OF SERVICE ESP SDK Public Health Provider Radiology Center PACS/RIS Pharmacy System Pharmacist Radiologist Lab System (LIS) Lab Clinician Rules/Data Rules/Data • State vs regional • Single Solution/many deployments • Multiple solutions Hospital, LTC, CCC, EPR Physician Office EMR Physician/ Provider HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. Physician/ Provider EHR Viewer Physician/ Provider 147 Architecture Perspectives Business Architecture Clinical Work Process Architecture Potential Applications CONTEXT Integration & Deployment Models System Architecture Information Architecture ESP SDK WORKING DRAFT RFI: not for official use 148 EHR Infostructure Deployment ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services Registries Data & Services Client Registry Outbreak Management EHR Data & Services PHS Reporting Shared Health Record Drug Information Data Warehouse Diagnostic Imaging Health Information Laboratory Provider Registry Location Registry Business Rules Terminology Registry EHR Index Message Structures Normalization Rules Information Access & Longitudinal Record Services (LRS) Security Mgmt Data Privacy Data Configuration Information and Common Services EHR IS Secure Communications Bus • Strategic planning • Testing (compliance) • Change management • System implementation • System development/integration • Education & training • EHR SCP message development • Operation & maintenance ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 149 ESP Data: Value Enabler For Existing Applications EHR Infostructure (EHRi) EHR IS ENABLED SYSTEM SOLUTION EHR INFOSTRUCTURE (EHRi) Population Health Data & Services Health Information Data Warehouse EHR Data & Services Registries Data & Services EHR IS EHR SCP Standards EHR SCP Standards ADT CDR EHR SCP Standards PMS Rx Lab Client data Provider data Location data Privacy data Security data Encounter data Blood/allergy/ immunization data • Encounter summaries • Clinical notes • Observations/ problems/conditions • Orders/Results data • Referrals data • Lab data • Pharmacy data • Diagnostic Imaging data EHR SCP Standards EHR SCP Standards Chronic Disease Health Education Health Prevention Custom projects Data Mining DI Data loading Data feeds Enhanced presentation Enhanced presentation Initial data load/ data feeds/integration of systems Hospitals/private clinics/ emergency/homecare/specialty centers/LT care Laboratories/pharmacy / diagnostics ESP SDK • • • • • • • WORKING DRAFT RFI: not for official use. Self-care Research/surveillance See notes page 150 End-User Perspective: EHR Viewer ORGANIZATIONAL INFOSTRUCTURE Registries Data & Services Client Registry Population Health Data & Services Outbreak Management PHS Reporting EHR Data & Services Shared Health Record Drug Information Data Warehouse Diagnostic Imaging Health Information Laboratory Provider Registry Location Registry Terminology Registry Business Rules EHR Index Message Structures Normalization Rules Information Access & Longitudinal Record Services (LRS) Security Mgmt Data EHR IS Privacy Data Configuration Information and Common Services Secure Communications Bus Patient Info End-user Info Visit History Drug Profile Laboratory Diagnostic Imaging POINT OF SERVICE EHR Viewer Physician/ Provider EHR VIEWER ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 151 End-User Perspective: EMR Application ORGANIZATIONAL INFOSTRUCTURE Registries Data & Services Client Registry Population Health Data & Services Outbreak Management PHS Reporting EHR Data & Services Shared Health Record Drug Information Data Warehouse Diagnostic Imaging Health Information Laboratory Provider Registry Location Registry Terminology Registry Business Rules EHR Index Message Structures Normalization Rules Information Access & Longitudinal Record Services (LRS) Security Mgmt Data EHR IS Privacy Data Configuration Information and Common Services Secure Communications Bus EMR Database Patient Info End-user Info Patient History Drug Profile Laboratory Diagnostic Imaging POINT OF SERVICE Physician Office EMR Physician/ Provider EMR APPLICATION ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 152 ESP Data: Enables New Classes of Applications EHR Infostructure (EHRi) • • • • • • • Client data Provider data Location data Privacy data Security data Encounter data Blood/allergy/ immunization data • Encounter summaries EHR IS ENABLED SYSTEM SOLUTION EHR INFOSTRUCTURE (EHRi) Population Health Data & Services EHR Information Services (EHR IS) Health Information Data Warehouse EHR SCP Standards ? ? Decision support The Helper The Mentor EHR Data & Services Registries Data & Services EHR SCP Standards ? ? ? Automated workflow Drug interactions Abnormal results EHR SCP Standards ? ? ? New applications Patient monitoring • Clinical notes • Observations/ problems/conditions • Orders/Results data • Referrals data • Lab data • Pharmacy data • Diagnostic Imaging data EHR SCP Standards ? Custom projects Data mining Patients ESP SDK WORKING DRAFT RFI: not for official use. 153 Deployment Configurations: Hybrid Open Source and COTS-based Solutions ESP SDK WORKING DRAFT RFI: not for official use 154 COTS: CIS with Integrated Viewer ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services EAI IP Provider Registry EAI IP Location Registry EHR Data & Services PHS Reporting Services Outbreak Services Drug Information System Diagnostic Imaging EAI IP EAI IP CLINICAL INFORMATION SYSTEM EAI IP Client Registry EAI IP Registries Data & Services Shared Health Record EAI Terminology Registry Consent Management Authentication/Acess Control Auditing/Logging IP is Interoperability Profile EAI is Enterprise Application Integration Interoperability General Integration Subscription Context Management Laboratory Laboratory Shared Health Record Longitudinal Record Services (LTS) Secure Communications Bus EHR Viewer Server EHR IP Transactions: Get, Put, List; National and International EHR Standards EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP Public Health Services Pharmacy System Radiology Center PACS/RIS Lab System (LIS) Hospital, LTC, CCC, EPR Physician Office EMR EHR Viewer Client POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 155 COTS: Clinical Information System (CIS) with External Viewer ORGANIZATIONAL INFOSTRUCTURE Population Health Data & Services EAI IP Provider Registry EAI IP Location Registry EHR Data & Services PHS Reporting Services Outbreak Services Drug Information System Diagnostic Imaging EAI IP EAI IP CLINICAL INFORMATION SYSTEM EAI IP Client Registry EAI IP Registries Data & Services EAI Terminology Registry Consent Management Authentication/Acess Control Auditing/Logging IP is Interoperability Profile EAI is Enterprise Application Integration Interoperability General Integration Subscription Context Management Shared Health Record Laboratory Laboratory Shared Health Record Longitudinal Record Services (LTS) Secure Communications Bus EHR IP Transactions: Get, Put, List; National and International EHR Standards EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP Public Health Services Pharmacy System Radiology Center PACS/RIS Lab System (LIS) Hospital, LTC, CCC, EPR Physician Office EMR EHR Viewer Client POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 156 COTS Based: Enterprise Application Centric (EAI) Centric ORGANIZATIONAL INFOSTRUCTURE EAI IP Provider Registry EAI IP EAI IP Location Registry Outbreak Services PHS Reporting Services CIS: Shared Health Record & Laboratory Drug Information System Diagnostic Imaging EAI IP EAI IP EAI IP EAI IP Client Registry EHR Data & Services Population Health Data & Services Registries Data & Services EAI Terminology Registry Consent Management Authentication/Acess Control Auditing/Logging IP is Interoperability Profile EAI is Enterprise Application Integration Interoperability General Integration Subscription Context Management Secure Communications Bus Enterprise Application Integration (EAI) is the unrestricted sharing of data and business processes throughout the networked applications or data sources in an organization. EHR IP Transactions: Get, Put, List; National and International EHR Standards EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP Public Health Services Pharmacy System Radiology Center PACS/RIS Lab System (LIS) Hospital, LTC, CCC, EPR Physician Office EMR EHR Viewer Client POINT OF SERVICE ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 157 157 157 ESP SDK: In Summary ESP SDK WORKING DRAFT RFI: not for official use 158 EHR IS As Design Pattern & Standard Provides specifications for provider organizations & the vendor community to design and develop: • EHR infostructure • Interfaces to allow existing systems to interoperate using EHR infostructure • New applications that take advantage of the EHR infostructure to provide added value to service providers, patients; to promote wellness • Provides design pattern & set of standardized specifications that: • Provide flexibility to meet the variety found in existing service delivery settings while providing an ability for Organizations to evolve their solution set, leveraging their current investments in systems • Allowing the managed addition of contributors to and users of Electronic Health Records ESP SDK WORKING DRAFT RFI: not for official use 159 From Concept to Implementation interoperable ESP SDK provides the Blueprint for transition to working interoperability through: • partnering with Organizations ready to build interoperability between existing systems • Organizations ready to incorporate their registries and domain repositories The second vehicle for testing and refining the Blueprint specifications is adoption by the vendor community and acquisitions of “interoperable ready” applications • Major vendors have incorporated the EHR IS architectural approach into their product strategies This process will be the test-bed for the EHR IS specifications • Elements of the EHR IS Blueprint specifications will be updated by these project teams as the concepts are tested and refined • Implementation guidelines will be produced to assist others in implementing these capabilities • The EHR IS can provide the framework for Organizations to evaluate vendor provided solutions and ensure they will work with their evolving EHR IS infostructures CONCEPT ESP SDK IMPLEMENTATION HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 160 Maintaining the EHR IS as a National / International Standard • It is critically important to have a stable, managed specification for interoperability • Organizations and provider organizations need to be confident that their commitment to implementing EHR infostructure is based on a sound specification that will be maintained and managed • Implementations of the infostructure will reveal where the specification needs to be adjusted to optimize performance and ensure reliability • For this reason, the EHR IS specifications will be subject to the Standards Collaboration Process ESP SDK • Ensuring broad participation in requirements definition • Providing foreknowledge of the financial and change management requirements to all affected groups and organizations • Providing a scope and change-management model for the EHR IS specifications themselves HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: [email protected] official use 161 The EHR IS Architecture In Summary: EHR Repository Concepts Benefits • Patient’s data is stored and accessed from one logical EHR • Interoperability, performance, scalability • Patient’s longitudinal clinically relevant information, authoritative & reliable • Provider adoption, supports use cases across continuum of care, timely and accurate for provider • EHR IS co-exists with legacy domain repositories • Preserves investments, does not unnecessarily duplicate data • EHR IS may be implemented at any organizational level • Flexibility, configurable to local & regional needs • EHR IS has a common definition • Cost effective, standards-based, Interoperability ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 162 The Architecture In Summary: EHR IS Concepts Benefits • EHR IS (EHR Information Services (EHR IS)) provides common way to interoperate with EHRs, registries, domain repositories • Common and standards based is most cost effective, secure & private; applications focus on clinical logic vs. integration logic • Provider applications interoperate through EHR IS to access HER, providing semantic interoperability • Cost effective environment for broad set of provider applications, standards based integration • EHR IS provides peer-to-peer trusted communication and value-added Information and Common Services to enable interoperability across the continuum of care and across Organizations • Secure & private, efficient, scalable, cost effective and standard runtime environment, responsive ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 163 The Architecture In Summary: ESP Concepts Benefits • Common standards will enable integration & interoperability • Reduces design, development, test & operational costs • Standard message data protocol for external communications is HL7 V3 • True interoperability, international standard will incent vendors • Registries have common definition nationally and internationally • Interoperability, cost, security & privacy ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 164 The Architecture In Summary: Applications Concepts Benefits • Messages initiated by point-of-care applications populate EHR with clinical data • Low cost and common model of integration, secure and private, scalable, extensible, preserves current investments • Provider applications read data out of the EHR via the EHR IS in addition to their operational data stores • Mass customized views of data tailored to provider needs, secure and private, scalable, authoritative, reliable, responsive • Use cases, business rules and visualization of data is a function of the point-of-care application • Vendors compete and innovate, extensible, value added services for providers ESP SDK HELP NEEDED validating that this Canada Health Infoway basedslide applies to the US ESP/EHR IS situation & needs. Please send your feedback WORKING DRAFT RFI: notto [email protected] official use. 165 CALL FOR PARTICIPATION Please post your comments at http://www.osehra.org/group/architecture You may get the most current version of this document and submit suggestions for improvement at: http://www.osehra.org/node/47/content/documents CALL FOR PARTICIPATION See companion ESP SDK Implementation Guide (IG), which is also under development. Your help is solicited. Thank you! ESP SDK WORKING DRAFT RFI: not for official use. 166 Backup The following slides are more technical in nature and will be discussed in the EHR Services Platform SDK Implementation Guide ESP SDK WORKING DRAFT RFI: not for official use. 167 HL7 EHR System Functional Model (EHR-S) (> 230 System Functions in 4 level categorization, (see attached spreadsheet for full enumeration) Business Choreography System Functions Business Entity (Information) Business Infrastructure Entity (Information) Service Types Choreography Infrastructure Infrastructure Infrastructure Business Choreography Other O-1 Electronic Resource Planning (ERP) O-2 Finances O-3 Other NOTE: “Other” Category - The EHR-S model does NOT include Electronic Resource Planning (ERP) / Logistics and Financial components, which are needed for completeness of a military EHR. 168 ESP SDK WORKING DRAFT RFI: not for official use. Approach to Architectural Traceability Core Projects Interoperability Projects Plan for New, Improved, Sustained or Sunset Capabilities Conceptual Independent Model Platform Independent Model Platform Specific Model CUIs Architectural Business Viewpoints Conceptual Independent Model Platform Independent Model Platform Specific Model CUIs Inventory of Systems and their Capabilities and Functions CUIs Architectural Information Viewpoints System Architecture CUIs CUIs CUIs CUIs CUIs Architectural Engineering/Technical Viewpoints Innovation/ Prototype Projects Conceptual Independent Model Platform Independent Model Platform Specific Model Conceptual Independent Model Platform Independent Model Platform Specific Model Product Line Inventory Conceptual Independent Model Platform Independent Model Platform Specific Model Architectural Behavioral Viewpoints Conceptual Independent Model Platform Independent Model Platform Specific Model Key to Traceability Traceability is achieved by using Concept Unique (numeric) Identifiers (CUIs) from the HL7 EHR System Functional Model (EHR-S FM) as attributes to all artifacts. This is analogous to a library system, which uses Dewey decimal numbers as book identifiers. 169 ESP SDK WORKING DRAFT RFI: not for official use. Healthcare SOA Framework Based on HL7 EHR System Functional Model & Thomas Erl’s SOA Layers HL7 System Functions Direct Care Supportive Information Infrastructure Other Business Process Value Chains Composite Services Federated Composition (e.g., Choreograph or Orchestration) Within and Across Business Areas Core Business Services Functional Areas + Focal Classes Functional Areas + Focal Classes Functional Areas + Focal Classes Functional Areas + Focal Classes Entity Services Information Management Information Management Information Management Information Reporting and Management C r o s s T e c h n I c a l “Common S e r v I c e s” (e.g., Security, Privacy, Auditing, Logging…) Agnostic Services Application Services Ambulatory Care Systems, In Patient Care Systems Logistics Systems Financial Systems Decision Support Systems Data Marts Repositories Business Objects Implementation Profiles Integrated Healthcare Enterprise (IHE) Profiles Analysis Profiles Communications Profiles/Stacks Implementation Profiles 170 ESP SDK WORKING DRAFT RFI: not for official use. 170 EHR DATA REUSE THROUGH H-SOA-RA ACROSS EPISODES OF CARE Previous Episode Of Care EHR Current Episode Of Care EHR Reusable Services IDENTITY ESP SDK 11/7/2015 • Patient Demographics • Provider Demographics • Insurer Demographic Data Must Be Verified And Updated Terminology • Chronic Diagnoses • Procedure History Document • Patient History • Summary Lists - Medication List - Allergy/Adverse Reaction List - Immunization WORKING DRAFT RFI: not for official use. 171 ANATOMY OF AN ANCILLARY SYSTEM LABORATORY RADIOLOGY PHARMACY CARDIOLOGY OT/PT/SPEECH s CORE BUSINESS SERVICES IDENTITY TERMINOLOGY AUTHORIZATION SCHEDULING SUPPLY CHAIN (ORDER/CHARGE) DOCUMENT RECORDS MANAGEMENT DECISION SUPPORT PERFORMANCE DATA MANAGEMENT ESP SDK 11/7/2015 WORKING DRAFT RFI: not for official use. 172 RECORDS MANAGEMENT DECISION SUPPORT PERFORMANCE Agnostic Services DATA MANAGEMENT ESP SDK ANALYTIC SUPPORT IT PLATFORM WORKING DRAFT RFI: not for official use. INTEGRATED REQUIREMENTS DESIGNS: Putting the H-SOA-RA Pieces Together Federated Business Services Inter-Service Inter-Agency Across Providers DOCUMENT OUTPATIENT OTHER SUPPLY CHAIN: (ORDERS/CHARGES) ER SCHEDULING ASU AUTHORIZATION CLINIC Core Business Services TERMINOLOGY INPATIENT IDENTITY TEST ONLY Ancillary Systems Federated Services, may be categorized by: -- Encounter Types -- CMS billing category -- Record type -- Care setting type -- etc. Data sets are defined for each system functionalcapability-service module 173 Case Management Coordination Across SOAs and the Continuum c CARE, PROVIDERS and LOCATIONS COORDINATION ` ACROSS LEVELS OF Wartime Theater ER Acute Inpatient Acute Rehab. Chronic Rehab. Skilled Long Term Care Custodial Long Term Care Home Health Outpatient Prevention/ Wellness Care Continuum Coordination ACROSS SOAS ASSESSMENT CARE PLANNING ORDERS & SCHEDULING BENEFIT MANAGEMENT AUTHORIZATION & UTILIZATION MGT. COMMUNICATION (FACILITATION ADVOCACY) DISCHARGE/ TRANSFER PLANNING REFERRAL RECORD EDUCATION. TRANSPORT ROLE OF CASE MANAGER 174 ESP SDK WORKING DRAFT RFI: not for official use. 174 ADDRESSING REAL BUSINESS ISSUES THROUGH H-SO • • • • • • • Incomplete/Inaccurate Demographic Data Incomplete/Inaccurate Insurance Information Unauthorized Service Diagnosis/Procedure Coding Errors Service Delays Incomplete and Inefficient Charge Capture Non-indicated or Contra-indicated Services (Identity Service) (Authorization Service) (Authorization Service) (Terminology Service) (Scheduling Service) (Supply Chain Service) (Decision Support/ Authorization Services) • Delays in EHR Document Production and Provision • Billing Delays and Errors • Not fully coordinated Scheduling • Lack of fully integrated Patient Assessment and Treatment Plan • Delayed or Lack of Medical Record Access (Document Service) (Supply Chain/ Billing/ Collection Services) (Scheduling Service) (Document Service/ Decision Support Service) (Record Service) 175 ESP SDK WORKING DRAFT RFI: not for official use. 175 175 DoDAF 2.x Views AV-1: Overview and Summary Information. AV-2: Integrated Dictionary CV-1: Vision CV-2: Capability Taxonomy CV-3: Capability Phasing CV-4: Capability Dependencies CV-5: Capability to Organizational Development Mapping CV-6: Capability to Operational Activities Mapping CV-7: Capability to Services Mapping DIV-1: Conceptual Data Model DIV-2: Logical Data Model DIV-3: Physical Data Model OV-1: High-Level Operational Concept Graphic OV-2: Operational Resource Flow Description OV-3: Operational Resource Flow Matrix OV-4: Organizational Relationships Chart OV-5a: Operational Activity Decomposition Tree OV-5b: Operational Activity Model OV-6a: Operational Rules Model OV-6b: State Transition Description OV-6c: Event-Trace Description PV-1: Project Portfolio Relationships PV-2: Project Timelines PV-3: Project to Capability Mapping StdV-1: Standards Profile StdV-2: Standards Forecast ESP SDK SV-1: Systems Interface Description SV-2: Systems Resource Flow Description SV-3: Systems-Systems Matrix SV-4: Systems Functionality Description SV-5a: Operational Activity to Systems Function Traceability Matrix SV-5b: Operational Activity to Systems Traceability Matrix SV-6: Systems Resource Flow Matrix SV-7: Systems Measures Matrix SV-8: Systems Evolution Description SV-9: Systems Technology & Skills Forecast SV-10a: Systems Rules Model SV-10b: Systems State Transition Description SV-10c: Systems Event-Trace Description SvcV-1: Services Context Description SvcV-2: Services Resource Flow Description SvcV-3a: Systems-Services Matrix SvcV-3b: Services-Services Matrix SvcV-4: Services Functionality Description SvcV-5: Operational Activity to Services Traceability Matrix SvcV-6: Services Resource Flow Matrix SvcV-7: Services Measures Matrix SvcV-8: Services Evolution Description SvcV-9: Services Technology & Skills Forecast SvcV-10a: Services Rules Model SvcV-10b: Services State Transition Description SvcV-10c: WORKING DRAFT RFI: not forServices official use. Event-Trace Description Future-State Architecture Software Development Kit (SDK) Draft Specifications needed by Fall 2011 * 1. Built-In-Test-Environment (BITE) Service Specification to support automated fault-detection resulting from distributed ad-hoc partners & plug-and-play applications. • Model-Driven Health-Tool defines run-time schematron test fixtures. • Performance-Monitoring-Component Service-Specification to trace run-time execution pathways and measure latency to support, system tuning, automated testing and certification. • Code-Coverage Regression-Test and Stress-Test Tool-Specification, to support automated testing and certification of “happy path” and fault recovery pathways. • Cross-Reference Tool-Specification to automatically map module-module and moduledata dependencies and certify no unexpected changes. • Pretty-Printer Tool-Specification to certify software-module Standards and Conventions (SAC) & to do syntax verification and readability reformatting. * Must be done in collaboration with DoD-VA joint ESP initiative and open source community. 177 ESP SDK WORKING DRAFT RFI: not for official use. Future-State Architecture Software Development Kit (SDK) Draft Specifications needed by Fall 2011 * 2. SAIF ECCF Implementation Guide (IG) for documenting component Interoperability Specifications, which will support new development, repurposing, reimplementation, automated testing and certification. 3. SAIF ECCF Tool Specification to manage module Interoperability Specifications, which will support new development, repurposing, reimplementation, automated testing and certification. 4. ESB Services Specification of ESP Tier 1-2 Application Virtualization-Layer of federated standards-based services. 5. Database Services Specification of ESP Tier 2-3 Database Virtualization-Layer of federated standards-based services. 6. Standards and Conventions (SAC), updated to modern SOA software engineering practices, as defined by Thomas Erl. * Must be done in collaboration with DoD-VA joint ESP initiative and open source community. 178 ESP SDK WORKING DRAFT RFI: not for official use. NIST 7497 Security Architecture * Design Principles 1. Perform Information Assurance Risk assessments of shared information; 2. Create “master” trust agreements describing requirements for a trust domain; 3. Separate authentication/credential management and authorization/privilege management; 4. Develop data protection capabilities as plug-and-play services; 5. Maintain a standards-based, technology-neutral, and vendor-neutral architecture. * NIST IR 7497, Security Architecture Design Process for Health Information Exchanges (HIEs), Sept. 2010, available at http://csrc.nist.gov/publications/PubsNISTIRs.html 179 ESP SDK WORKING DRAFT RFI: not for official use. NIST 7497 Security Architecture Enabling Services 1. Risk Assessment is a Security and Privacy Principles, which means to identify security and privacy risks to HIE operations based on threats, assets, vulnerabilities, and likelihood of threat success. 2. Entity Identity Assertion (Authentication) is HITSP Construct * SC110 & C19, which ensures that an entity is the person or application that claims the identity provided. 3. Credential Management is a Security Principles, which means to manage the life cycle of entity credentials used for authentication and authorization. 4. Access Control (Authorization) is HITSP Construct * SC108 & TP20, which ensures that an entity can access protected resources if they are permitted to do so. 5. Privilege Management is a Security Principles, which means to manage the life cycle of an entity’s authorization attributes (e.g., roles, permissions, rules) for making access control decisions. 6. Collect and Communicate Audit Trail is HITSP Construct * SC109 & T15, which defines and identifies security-relevant events and the data to be collected and communicated as determined by policy, regulation, or risk analysis. ESP SDK * HITSP constructs areRFI: available at www.HITSP.org WORKING DRAFT not for official use. 180 NIST 7497 Security Architecture Enabling Services 7. Document Integrity is HITSP Construct * T31, which validates that the contents of a document have not been changed in an unauthorized or inappropriate manner. 8. Secured Communication Channel is HITSP Construct * SC109 & SC112, which ensures that the mechanism through which information is shared or transmitted appropriately protects the authenticity, integrity, and confidentiality of transactions to preserve mutual trust between communicating parties. 9. Document Confidentiality is a Security Principles, which means to prevent the unauthorized disclosure of a document that is exchanged or shared. 10. De-identification is a Privacy Principles, which means to remove individual identifiers from a health record, or replace them with other information such as pseudonyms, so that it cannot be used to identify an individual. 11. Non-Repudiation of Origin is HITSP Construct * C26, which provides the proof of the integrity and origin of data in an unforgettable relationship which can be verified by any party. 12. Manage Consent Directives is HITSP Construct * TP30, which ensures that individually identifiable health information is accessed only with an individual’s consent. ESP SDK R AFT Talking Points * HITSPD constructs are available www.HITSP.org WORKING DRAFT RFI: not for at official use. 181 NIST 7407 Security Architecture Web-Service Security-Standards 182 ESP SDK WORKING DRAFT RFI: not for official use. NIST 7497 Security Architecture Notional Development Process 183 ESP SDK WORKING DRAFT RFI: not for official use.