Presentation to OSEHRA Board and than Interagency Program Office (IPO) September 6, 2012-d Seong K Mun PhD, OSEHERA President Stephen P Hufnagel PhD, Architecture Work Group 1 Recommendations for iEHR-OSEHRA Win-Win Success

Proposed iEHR Technical Vision iEHR (integrated Electronic Health Record) is a component-based HSP (Healthcare Services Platform) for the standards-based integration of interoperable COTS (Commercial Off the Shelf), GOTS (Government Off the Shelf) and OSC (Open Source Component) applications and services; furthermore, OSEHRA is the marketplace for pre-tested and pre-certified “plug- and-play” iEHR capabilities, which can be configured to meet operational needs, in accordance with scope-of-practice, organizational policy, iEHR governance and jurisdictional law. 2

Discussion Open–Source Components (OSC) require clearly-defined standards-based component-boundaries, including web services: OSC can accommodate new, unexpected, or subtly differing requirements among health providers, possibly due to improved medical domain knowledge, insight and innovation. OSC allows users or small-businesses to focus on a limited domain OSC provides risk-mitigation alternatives in case COTS does not work or is inadequate, or OSC may allow a less expensive option, where licensing costs are prohibitive, such as for education and non-governmental organizations. 3

Objectives 1.iEHR publish its APIs (Application Program Interfaces) – Standards-based information exchanges – SOA Suite and Enterprise Service Bus – Virtual Data Repository (VDR) and User Experience (UX) Framework – Clinical/Business components/services 2.Open-source competes on “best-value” to the Government basis – Better Modularization, Reuse and Security, due to extensive use and review – Lower Total Lifecycle Cost, due to shared investment and no license fees 3. Open-Source Solutions are a COTS risk-mitigation strategy. – Repurposed VistA can transition as one-or-more iEHR components – Funding is needed to develop, integrate, test, certify open-source alternatives – Open-source is not free 4

Process Issues Hindering Success 1.Current capability RFI/RFP process is backwards – Specifying iEHR capabilities as “systems” will result in stovepipes 2.RFI / RFP pre-condition must include: – Published iEHR Healthcare Services Platform (HSP) Specifications Data and Terminology models Infrastructure Services and Business / Clinical Services User Experience (UX) Portal Framework and Virtual Data Repository (VDR) 3.Individual capabilities must build upon the HSP foundation – iEHR Service Governance must prevent duplicative services – Service catalogue / registry must be accessible to all 5

For Open-Source to Compete, we need iEHR to be a Healthcare Services Platform (HSP), with well-specified – Data and Terminology Models, Infrastructure, Business and Clinical Services – User Experience (UX) Portal Framework and Virtual Data Repository (VDR) All medical specialty-domains are an orchestration of (replaceable) HSP services; where, each medical-specialty domain has its own – data-and-terminology models, business-rules, workflows, reports and displays – in accordance with scope-of-practice, organizational policy, iEHR governance and jurisdictional law. An iEHR Integration Contractor to Operationalize Innovation – Specify HSP data and service interfaces, prior to RFI/RFP releases – Facilitate open-source alternatives within standards-based Service Oriented Architecture Small Business Innovation Research or similar VA-I2 funding to catalyze – Open-Source Community participation without onerous contract-vehicle requirements – Vista open-source component/capability repurposing to iEHR 6

Backup / Questions? 7 iEHR N-Tier Conceptual Architecture

Assumptions 1.iEHR is intended to be a Healthcare Services Platform (HSP) – emphasizing the reuse of high quality clinical/business and ESB infrastructure services and User Experience (UX) framework Virtual Data Repository (VDR) 2.The HSP is intended to be an interoperability-framework for – COTS (Commercial Off-The-Shelf), – GOTS (Government Off-The-Shelf) and – open-source components. 8

Assumptions 3.All medical specialty domains, should be an orchestration of – HSP services; – each medical-specialty domain having user-managed domain-specific Capabilities/Applications, data-and-terminology models, business-rules, workflows, user-interactions and reports in accordance with scope-of-practice, organizational policy, iEHR governance and jurisdictional law. 9

Clinical/Business Services 1. Virtual Patient Record (VPR) Service to collate data from legacy sources – RLUS (Retrieve, Locate Update Service) fronted databases and COOP / performance caches – CIIF (Common Information Interoperability Framework) 2. Care Coordination Services enabling “medical-home” type patient-care management – Problems, including Diagnosis and Allergies – Treatments, including Medication List and Procedures – Diagnostic Test Results, including Radiology, Pulmonary Function Tests, Electrocardiograms, Laboratory, Microbiology, Pathology – Demographics, Advance Directives and Patient / Family Preferences 3. Orders Management Service, ideally, provided within the Care Coordination Service 4. Note Writer Service, ideally, provided within the Care Coordination Service 5. Inventory and Funds Control Management Services 6. CDS (Clinical Decision Support), possibly built from the Business Rules Service 7. UX Portal Framework enabling SSO/CM/AM/ID and medical-domain-specific portlets SSO/CM/AM/ID=SSO (single sign on), CM (context management), AM (access management), ID (identification). 10

Design Principles The recommended solution separates and componentizes: – Data, Business Rules, Application Code – Presentation framework services – Common services SOA Suite, Enterprise Service Bus Security, UX User Experience) Framework and Reporting Tools Scheduling – Clinical/Business Services – Orchestrated Business Workflow – Business “Value Chain” Services 11

Medical Department Customization The recommended solution uses orchestrated core HSP services to support – local work-flow, – domain specific data-and-terminology – both enterprise and local business rules – UX in accordance with scope of practice, organizational policy, iEHR governance and jurisdictional law. for FOC, the 3M HDD will be used; and, for FOC the CIIF data and terminology services will be used. 12

KEY TO SUCCESS is iEHR Software Development Kit 1.Joint DOD & VA Information Exchange (IE) tool : legacy & iEHR IEs mapped-to 1.capabilities, activities, system functions, content & exchange standards, information and terminology model views 2.Joint DOD & VA SOA “ Enterprise Application Architecture (EAA) ” document, which discusses principles and guidelines for development or acquisition of components within a Service Oriented Architecture (SOA) 3.Joint DOD & VA “ SOA Technical Framework (SOA TF) ” document, which discusses SOA specification and implementation guidelines. 4.Joint DOD & VA “ SOA Governance Framework (SOA GF) ” document, which discusses the required governance to support a SOA. 5.Joint DOD & VA “ Technical Standards Profile (TSP) ” document, which lists the DOD-VA information sharing approved standards for interoperability. 6.iEHR “ Technical Reference Model (TRM) ” document, which list approved software components and tools for use within iEHR 13

KEY TO SUCCESS is Software Development Kit 7.iEHR Catalogue/Registry of Infrastructure Services, including ESB and CIIF services 8.iEHR “CIIF Requirements and Architectural Vision” Document, which provides a iEHR Conceptual View and lists non-functional requirements (NFRs). 9.iEHR Catalogue/Registry of Core Business Services 10.iEHR Catalogue/Registry of Capability Services 11.Sample code, ether for direct use or which defines an API. Since we can generate Java code directly from the HL7 v3 information models with MDHT (Model Driven Health Tool), this is an important tool for developers and integrators. This has been very useful, for example, in CDA r2 exchanges. 14

KEY TO SUCCESS is Software Development Kit 12.Similar to what NIEM does (we should create IEPD-like bundles for people to download), we should include the relevant XML Schema and XML based conformance tools (i.e. XPath expressions and/or Schematron). 13. A human readable (PDF) implementation guide that defines the interactions, the information models, value sets, standards used, and the conformance criteria. 14. A separate IG for iEHR web services that discusses how to use the CIIF, how services are orchestrated, how/when/why to use the enterprise rules engine/workflow system/complex planning/scheduling/event processing framework, logging/audit trails, monitoring, security, overall design paradigm, etc. 15.A MDHT (Model Driven Health Tool) based validation engine to support the BITE (Built In Test Environment). 15