EHR Modernization - Conceptual Architecture EHR Services Platform (ESP) - Software Development Kit (SDK)

Transcription

1 CALL FOR PARTICIPATION Please post your discussion comments at This DRAFT document should be treated as a Request for Information (RFI) Modernization - Conceptual Architecture Platform (ESP) - Software Development Kit (SDK) Open Source Custodial Agent (OSA) Architecture Committee Stephen Hufnagel PhD, Chair In collaboration with 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: October 20, 2011 DRAFT-O ESP SDK WORKING DRAFT RFI: not for official use. 1

2 Architecture Working Group (AWG) Weekly Teleconference DATE & TIME: Every Tuesday 4:00 pm EDT WebEx: PHONE: Access code: DOCUMENTS at: DISCUSSIONS at: HTML SYSTEM ARCHITECTURE at: Please become an OSA member and participate; individual membership is free. Please join and participate in the Architecture Work Group. The initial 2011-baseline "OSA System Architecture, Product Definition and Roadmap" working-document is posted under the Architecture-Group's Documents-tab. There is also an HTML browser viewable version. This is a living document. Please add your comments and suggestions to help us improve the architecture. Between now and December we plan to validate the System Architecture, define a future-state architecture Software Development Kit (SDK) and Implementation Guide (IG) and then begin to define an OSA Product Roadmap. ESP SDK WORKING DRAFT RFI: not for official use. 2

3 Future-State-Architecture GOAL: To Support Modular Plug-&-Play Innovation Incremental Innovation Little Impact on links between components (e.g., Interoperability) Modular Plug- &- Play Innovation OBJECTIVE A change-immune domain-specific componentarchitecture emphasizing interoperable standardsbased services, resulting-in simpler, loosely-coupled, and less-costly agile module-level innovation. Little impact on components Great impact on components PROBLEM Little innovation, long lead times and high costs resulting from complex highly-coupled components Architectural Innovation Start Great Impact on links between components (e.g., interoperability) Radical Innovation ESP SDK WORKING DRAFT RFI: not for official use. 3

4 Technical Vision: Service Platform (ESP) INTEGRATED SOLUTION SERVICES PLATFORM (ESP) Population Population Registries IS Locator Information Access & Longitudinal Record (LRS) Information ( IS) Point of Service Applications Personal Record Systems Viewers See notes page ESP SDK WORKING DRAFT RFI: not for official use. 9

5 ESP Key Concepts: Federated Architecture INTEGRATED SOLUTION IS Enabled Legacy System IS Enabled PHR System SERVICES PLATFORM (ESP) IS Tier 3 Plug-&-Play Data Stores Population Population Registries IS Locator ESP Based System Tier 2 Information Tier 1 Plug-&-Play Applications Information Access & Longitudinal Record (LRS) Point of Service Applications Information ( IS) Personal Record Systems Viewers Data Access Layer Application Layer IP is SOA Interoperability Profile aka Service Interface EAI is Enterprise Application Integration See notes page ESP SDK WORKING DRAFT RFI: not for official use. 11

6 ESP Legacy Transition Strategy INTEGRATED SOLUTION SERVICES PLATFORM (ESP) LEGACY SYSTEM -IS ENABLED LEGACY INFRASTRUCTURE Population Data Warehouse Registries Legacy Point of Service Application Data Warehouse Personal Record System Legacy Information Access & Longitudinal Record (LRS) Information Access & Longitudinal Record (LRS) Information ( IS) -IS Bi-Directional Information Exchange Information ( IS) -IS Point of Service Application Personal Record Systems Viewer EAI is Enterprise Application Integration IP is SOA Interoperability Profile aka Service Interface -IS enabled legacy systems allow users to transition at a convenient time and then legacy systems can be gracefully shut down. ESP SDK WORKING DRAFT RFI: not for official use. 13

7 Common Information Integration (CIIF) within Information ( IS) SERVICES PLATFORM (ESP) ORGANISATIONAL INFOSTRUCTURE Registries Data & Population Data & Data & Data Warehouse & Client Registry Outbreak Management PHS Reporting Shared Record Drug Information Diagnostic Imaging Laboratory Information Provider Registry Location Registry Business Rules Index Message Structures Normalization Rules Terminology Registry Information Access & Longitudinal Record (LRS) IP is SOA Interoperability Profile aka Service Interface EAI is Enterprise Application Integration Security Mgmt Rules/Data Privacy Mgmt Rules/Data Configuration Rules/Data IS Common Information Integration Framework (CIIF) and Common Secure Communications Bus Public Pharmacy System Radiology Center PACS/RIS Lab System (LIS) Hospital, LTC, CCC, EPR Physician Office EMR Viewer Public Provider POINT OF SERVICE APPLICATIONS Pharmacist Radiologist Lab Clinician Physician/ Provider Physician/ Provider See notes page Physician/ Provider ESP SDK WORKING DRAFT RFI: not for official use. 15

8 ERH Platform (ESP) enabled system (conceptual view) ESP SDK WORKING DRAFT RFI: not for official use. See notes page 17 17

9 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 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 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 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 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 ESP SDK WORKING DRAFT RFI: not for official use. 19

10 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 OS 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) Performance optimize ESP & integrated applications to meet KPPs NOTE: Refactoring can be MUMPS to MUMPS or MUMPS to another language; either approach MUST meet ESP SDK specifications in IG. 23 ESP SDK WORKING DRAFT RFI: not for official use. 23

11 Suggested OSA Role in MUMPS Code Refactoring 1. Thought Leadership 2. OS 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. OS 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 24 ESP SDK WORKING DRAFT RFI: not for official use. 24