Open Source EHR Custodial Agent (OSEHRA) Architecture Committee Stephen Hufnagel PhD, Chair

1. 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 - Conceptual Architecture EHR Services Platform (ESP) - 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

2. 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 open-source 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

3. 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 3 WORKING DRAFT RFI: not for official use

4. TALKING POINTS: SDK PurposeESP 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

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

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

7. INTEGRATED EHR SOLUTION EHR SERVICES PLATFORM (ESP) EHR ISLocator Information Access & Longitudinal Record Services (LRS) Population HealthData &Services EHRData &Services RegistriesData &Services Population HealthData &Services EHR Information Services (EHR IS) Point of ServiceApplications Personal Health Record Systems EHR Viewers Technical Vision: EHR Service Platform (ESP) See notes page

8. 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 domain-specific “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

9. EHR IS Enabled PHR System EHR IS Enabled Legacy System EHR IS INTEGRATED EHR SOLUTION EHR SERVICES PLATFORM (ESP) EHR ISLocator Information Access & Longitudinal Record Services (LRS) ESP Based System Population HealthData &Services EHRData &Services RegistriesData &Services EHR Information Services (EHR IS) Point of ServiceApplications Personal Health Record Systems EHR Viewers Key Concepts: Federated EHR Services Architecture Population HealthData &Services Tier 3 Plug-&-Play Data Stores EAI IP Data Access Virtualization Layer Tier 2 EHR Information Services Application Virtualization Layer EHR IP EHR IP EHR IP Tier 1 Plug-&-Play Applications IP is SOA Interoperability Profile aka Service Interface EAI is Enterprise Application Integration See notes page

10. D R A F T Talking Points 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 10

11. INTEGRATED EHR SOLUTION LEGACY EHR SYSTEM EHR SERVICES PLATFORM (ESP) EHR-IS ENABLED LEGACY INFRASTRUCTURE Information Access & Longitudinal Record Services (LRS) Information Access & Longitudinal Record Services (LRS) DataWarehouse Data & Services DataWarehouse Data & Services Population HealthData &Services EHRData &Services RegistriesData &Services EHRData &Services EHR Information Services (EHR IS) EHR Information Services (EHR IS) Legacy Point of ServiceApplication Personal Health Record System Point of ServiceApplication EHR Viewer Personal Health Record Systems Legacy Transition Strategy Legacy EAI IP EHR-IS Bi-Directional Information Exchange EHR-IS EAI IP EAI IP EHR IP EHR IP EHR IP EAI is Enterprise Application Integration IP is SOA Interoperability Profile aka Service Interface EHR-IS enabled legacy systems allow users to transition at a convenient time and then legacy systems can be shut down. 11

12. TALKING POINTS: Transition Strategy based on ESP enabled systems • ESP kernel-services and data stores CAN be set-up at one-or-more data-centers (any cloud topology). • 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. • Agile SDK, ESP and application development and certification processes MUST have up-to-date VMs and ongoing regression testing to obtain/maintain “certified” status. • 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. • One-or-more user-configurable ESP enabled viewers SHOULD be made freely available. • 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 DoD-VA sharing; • Terminology mapping SHOULD be a part of legacy-data transition. • To be repurposed to ESP capability, legacy-applications MUST conform to ESP SDK-IG and associated certification criteria. • 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. • Clinically-meaningful legacy-data MUST be extracted to ESP before legacy systems are shut down. 12

13. Information Access & Longitudinal Record Services (LRS) Common Information Integration Framework (CIIF) and Common Services Secure Communications Bus EHR SERVICES PLATFORM (ESP) ORGANISATIONAL INFOSTRUCTURE Population Health Data& Services EHR Data& Services Data Warehouse & Services Registries Data& Services OutbreakManagement PHSReporting SharedHealth Record DrugInformation DiagnosticImaging Laboratory HealthInformation ClientRegistry ProviderRegistry BusinessRules EHRIndex MessageStructures NormalizationRules LocationRegistry TerminologyRegistry Security MgmtRules/Data Privacy Mgmt Rules/Data Configuration Rules/Data EHR IS Public HealthServices PharmacySystem RadiologyCenterPACS/RIS Lab System(LIS) Hospital, LTC,CCC, EPR PhysicianOffice EMR EHR Viewer Public Health Provider Pharmacist Radiologist Lab Clinician Physician/Provider Physician/Provider Physician/Provider POINT OF SERVICE APPLICATIONS EHR Information Services (EHR IS) within EHR Services Platform (ESP) IP is SOA Interoperability Profile aka Service Interface EAI is Enterprise Application Integration EAI IP EAI IP EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP EHR IP See notes page

14. 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 software-service 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. 14 14 See notes page

15. ERH Services Platform (ESP) enabled system (conceptual view) 15 15 See notes page

16. D R A F T Talking Points TALKING POINTS: EHR Services Platform (ESP)Addressing Legacy Problems • 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. • 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. • 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 open-source applications, scalable databases and infrastructure to coexist. • 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. • 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. Interchangeable-components 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. . • Patient Safetyissues resulting from software changes. • Component architecture localizes faults. BITE identifies faults early, improving system robustness, patient safety. • 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 16

17. HL7 Service Aware Interoperability Framework (SAIF)Enterprise Compliance and Conformance Framework (ECCF) ECCF Enterprise Dimension “Why” - Policy Information Dimension “What” - Content Computational Dimension “How” - Behavior Engineering Dimension “Where” - Implementation Technical Dimension “Where” - Deployments Conceptual Perspective • Inventory of • User Cases, Contracts • Capabilities • Business Mission, Vision, Scope • Inventory of • Domain Entities • Activities • Associations • Information Requirements • Information Models • Conceptual • 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 Logical Perspective • 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 • Implementable Perspective • Business Nodes • Business Rules • Business Procedures • Business Workflows • Technology Specific Standards • Schemas for • Databases • Messages • Documents • Services • Transformations • Automation Units • Technical Interfaces • Technical Operations • Orchestration Scripts • SW Specifications for • Applications • GUIs • Components • SW Deployment Topologies • HW Deployment Specifications • HW Execution Context • HW Application Bindings • HW Deployment Topology • HW Platform Bindings Five (5) Categories: Capability | Mission | Business Process | Infrastructure/Enterprise Architecture | Interoperability 17

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

19. ESP SDK Conceptual View 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 EHR Services Platform concepts SDK Scope Business Context Clinical/Work Process Architecture System Architecture Information Architecture Integration & Deployment Options Potential Applications Summary & Conclusion Next: ESP SDK Future-State SAIF Conceptual Perspective CALL FOR PARTICIPATION Please post your discussion comments at http://www.osehra.org/group/architecture ESP SDK 19 WORKING DRAFT RFI: not for official use

20. Abbreviations • AKA Also Known As • BITE Built in Test Environment • CM Configuration Management • DI Diagnostic Imaging • DoD Department of Defense • EAI Enterprise Application Integration • EHR IS EHR Information Services • ESP HER Services Platform • ESB Engineering Service Bus • HAIMS Health Artifact and Image Management Solution • ICIB Interagency Clinical Informatics Board • IG Implementation Guide • IHS Indian Health Services • IP Interoperability Profile / Specification • IV&V Independent Verification and Validation • LIS Laboratory Information Systems • LRS Longitudinal Record Service • OSEHR Open Source EHR • OSEHRA OSEHT Custodial Agent • RFI Request for Information • RIS Radiology Information System • SAIF HL7’s Service Aware Interoperability Framework • SDK Software Development Kit • SDO Standards Development Organization • SOA Service Oriented Architecture • TSA Telehealth Scheduling Application • VA Veterans Administration • VHA Veterans Health Administration • VM Virtual Machine 20