Recommendations for iEHR -OSEHRA Win-Win Success Stephen Hufnagel PhD, Co-chair Architecture Work Group (AWG) Septembe

1. Recommendations foriEHR-OSEHRA Win-Win SuccessStephen Hufnagel PhD, Co-chairArchitecture Work Group (AWG)September 25, 2012 SeongK Mun PhD, OSEHERA President Peter Li, C0-Chair Architecture Work Group

2. Abstract iEHR is intended to be a Healthcare Services Platform (HSP), emphasizing the reuse of high quality clinical/business and ESB infrastructure services, User Experience (UX) framework, Virtual Data Repository (VDR). The HSP is intended to be an interoperability-framework for COTS (Commercial Off-The-Shelf), GOTS (Government Off-The-Shelf) and open-source components. All medical specialty domains, should be an orchestration of HSP services; where 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. 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. Considering the tight iEHR timeframes, open-source community participation requires VA leadership, commitment and Small Business Innovation Research or similar VA-I2 funding without onerous contract-vehicle requirements to catalyze VistAopen-source component/capability repurposing to iEHR.

3. 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.

4. 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.

5. Objectives • 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 • 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 • Open-Source Solutions are a COTS risk-mitigation strategy. • Repurposed VistA can transition as one-or-more iEHRcomponents • Funding is needed to develop, integrate, test, certify open-source alternatives • Open-source is not free

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

7. For Open-Source to Compete, we need • iEHR to be a Healthcare Services Platform (HSP), with well-specified • Common 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 adds unique • data-and-terminology models, business-rules, workflows, reports and displays • There are unique services to each medical domain (e.g., ophthalmology, dental services) • 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 • Funding is Required • Small Business Innovation Research or similar VA-I2 funding to catalyze • Open-Source Community participation without onerous contract-vehicle requirements • VistAopen-source component/capability repurposing to iEHR

8. Backup / Questions? iEHR N-Tier Conceptual Architecture

9. Assumptions • 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) • The HSP is intended to be an interoperability-framework for • COTS (Commercial Off-The-Shelf), • GOTS (Government Off-The-Shelf) and • open-source components.

10. Assumptions • 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.

11. Clinical/Business Services • Virtual Patient Record (VPR) Serviceto collate data from legacy sources • RLUS (Retrieve, Locate Update Service) fronted databases and COOP / performance caches • CIIF (Common Information Interoperability Framework) • 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 • Orders Management Service, ideally, provided within the Care Coordination Service • Note Writer Service, ideally, provided within the Care Coordination Service • Inventory and Funds Control Management Services • CDS (Clinical Decision Support), possibly built from the Business Rules Service • 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).

12. 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

13. 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.

14. KEY TO SUCCESS is iEHRSoftware Development Kit • Joint DOD & VA Information Exchange (IE) tool: legacy & iEHR IEs mapped-to • capabilities, activities, system functions, content & exchange standards, information and terminology model views • 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) • Joint DOD & VA “SOA Technical Framework (SOA TF)” document, which discusses SOA specification and implementation guidelines. • Joint DOD & VA “SOA Governance Framework (SOA GF)” document, which discusses the required governance to support a SOA. • Joint DOD & VA “Technical Standards Profile (TSP)” document, which lists the DOD-VA information sharing approved standards for interoperability. • iEHR “Technical Reference Model (TRM)” document, which list approved software components and tools for use within iEHR

15. KEY TO SUCCESS is Software Development Kit • iEHR Catalogue/Registry of Infrastructure Services, including ESB and CIIF services • iEHR “CIIF Requirements and Architectural Vision” Document, which provides a iEHR Conceptual View and lists non-functional requirements (NFRs). • iEHR Catalogue/Registry of Core Business Services • iEHR Catalogue/Registry of Capability Services • 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.

16. KEY TO SUCCESS is Software Development Kit • 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). • A human readable (PDF) implementation guide that defines the interactions, the information models, value sets, standards used, and the conformance criteria. • 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. • A MDHT (Model Driven Health Tool) based validation engine to support the BITE (Built In Test Environment).

17. Recommendations foriEHR-OSEHRA Win-Win Success Presentation toOSEHRA Boardby OSEHRA Architecture Work Group (AWG)September 18, 2012 version E SeongK Mun PhD, OSEHERA President Stephen P Hufnagel PhD, C0-Chair Architecture Work Group