A Framework to Organize-and-Assess VistA Open-Source SOA-Stack Components

Transcription

1 A Framework to Organize-and-Assess VistA Open-Source SOA-Stack Components An Open-Source VistA SOA Platform objective is to provide an openstandards eco-system within which VA employees, large prime contractors, healthcare professionals, innovative small companies, healthcare software vendors, and entrepreneurs can all contribute to improving the best care anywhere' being provided by VA today. OSEHRA Community Seong K. Mun PhD Mike Henderson Peter Li, co-chair Chris Edwards 15-Oct-2013 AWG Presentation 15-Oct-2013 DRAFT-G Update President and CEO Director, Open Source Product Management Architecture Work Group (AWG) Implementation & Test 10/15/2013-G OSEHRA-AWG Draft-Working-Document; Not for Official Distribution. 1

2 Introduction SITUATION: OSEHRA represents the open-source VistA EHR community; where, VA s VistA Evolution initiative proposes to transform legacy VistA into a Healthcare SOA Platform that can leverage modern technologies and cloud offerings. OSEHRA advocates for an open-source SOA stack assessment framework, as described in this presentation; but, OSEHRA does not advocate for a particular SOA stack.. PRESENTATION OBJECTIVE: Provide OSEHRA community s recommendations to the VA s VistA-Evolution initiative, regarding an approach to assessing and using open-source SOA stack components to create an Open-Source VistA SOA Platform that can leverage modern technologies and cloud offerings. 10/15/2013-G OSEHRA-AWG Draft-Working-Document; Not for Official Distribution. 2

3 Assumptions & Benefits Summary Open Source Components (OSC) in an open-architecture require clearlydefined standards-based component-boundaries, including web services: AGILITY: OSC can accommodate new, unexpected, or subtly differing requirements among health providers, possibly due to improved medical domain knowledge, insight and innovation. OPENNESS: OSC allows users or small-businesses to focus on supporting a limited domain (e.g., orthopedics) FLEXIBILITY: OSC provides risk-mitigation alternatives in case COTS does not work or is inadequate SECURITY & PRIVACY: OSC can be vetted-and-tested by a broad audience of stakeholders QUALITY: OSC is a form of reuse; where, components are appropriately modularized and are comprehensively documented, tested and peer reviewed. AFFORDABILITY: OSC may allow a less expensive option, where licensing costs are prohibitive. 3

4 LAYER Business User Notional (Federated) VistA-Business SOA-Stack adapted from: WSBFoverviewpart1/index.html Clinicians Patients Partners Business Processes Business Services Business Components Business Integration ESB DMS Business Resources VistA VistA VistA MUMPS Federated MUMPS MUMPS VistA Ancillary Serv ices First Databank 4

5 Notional VistA SOA Platform Future-State VistA N-Tier Conceptual-Architecture 5

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

7 Sample Data Management Services (DMS) 1. Retrieve, Locate, Update Service (RLUS) façade is used to access and harmonize heterogeneous data stores. Extraction, Transformation and Load (ETL) is an RLUS backend component. 2. Common Terminology Service (CTS) is used to harmonize terminology 3. Built in Test Environment (BITE) is used to verify information exchange syntax and semantics. 4. Clinical Template Repository (CTR) is used to standardize information exchanges. 5. Security and Privacy SSO/CM/AM/ID=SSO (single sign on), CM (context management), AM (access management), ID (identification). 7

8 ESB is intended to support Advanced SOA Maturity [Microsoft SOA Roadmap] ESB Objectives 8

9 Notional SOA-Stack View of Clinical Decision Support (CDS) Services Gartner has described Clinical Decision Support (CDS) as the CPR Systems Crown Jewel, because, CDS has the potential to be the most valuable component of a CPR; as, CDS is evolving to be a clinician s trusted mentor. RPCs ESB DMS RLUS CDW RLUS - RPCs VistA Legacy Apps. Business Resources 9

10 Notional SOA-Stack for VistA Exchange-Architecture 10/15/2013-G OSEHRA-AWG Draft-Working-Document; Not for Official Distribution. 10

11 A VistA Open-Architecture Must Be Standards-Based Clinical/Business Standards DICOM for radiology, LOINC for laboratory, anatomical pathology, LOINC document types for inpatient notes, HL7 CCD (HITSP C32), and CCDA-CCD for VLER Health data, RxNORM for pharmacy, ICD-10 and SNOMED CT for outpatient visits, ICD-10 and LOINC for admissions encounter, SNOMED CT for smoking status, CPT4 and HCPCS for procedures, PDA-F for scanned paper reports, CDC Race Codes for demographics, UCUM for units of lab measures, NUCC Health provider taxonomy for provider types, CVX and MVX for immunology, ICD9, CPT4/HCPCS, ICD9PCS for billing data. Technical Standards CTS or Common Terminology Service RLUS or Retrieve Locate Update Service for heterogeneous database facades CDS or Clinical Decision Support API VPR or Virtual Patient Record FHIR or Fast Healthcare Interoperability Resource with RESTful API. RDF or Resource Description Framework for semantic web applications JSON or JavaScript Object Notation WS* or Web Service Standards 10/15/2013-G OSEHRA-AWG Draft-Working-Document; Not for Official Distribution. 11

12 Notional Open-Source Assessment Criteria Applicability to need Options and customizability Software License Maturity of Software Documentation and Use Cases Testable requirements-specifications Test procedures, fixtures and results Community size and scope Supportability Community and Commercial venders Standards and Interoperability Other users Scalability & Performance 10/15/2013-G OSEHRA-AWG Draft-Working-Document; Not for Official Distribution. 12

13 Example Open-Source Components OSEHRA will not recommend a particular SOA solution stack Apache ServiceMix is a flexible, open-source integration container that unifies the features and functionality of Apache ActiveMQ, Camel, CXF, ODE, Karaf into an enterprise ready ESB exclusively powered by OSGi; where, The OSGi framework is a module system and service platform for the Java programming language that implements a dynamic component model. It is released under Apache License v2. The main features are: reliable messaging with Apache ActiveMQ messaging, routing and Enterprise Integration Patterns with Apache Camel WS-\* and RESTful web services with Apache CXF loosely coupled integration between all the other components with Apache ServiceMix NMR including rich Event, Messaging and Audit API complete WS-BPEL engine with Apache ODE OSGi-based server runtime powered by Apache Karaf JBossESB offers Business Process Monitoring, Integrated Development Environment, Human Workflow User Interface, Business Process Management, Connectors, Transaction Manager, Security, Application Container, Messaging Service, Metadata Repository, Naming and Directory Service, Distributed Computing Architecture. JBossESB is part of an SOI (Service Oriented Infrastructure). (Parts of Jboss accepted on VA TRM) Drools 5 includes a Business Logic integration Platform which provides a unified and integrated platform for Rules, Workflow and Event Processing 10/15/2013-G OSEHRA-AWG Draft-Working-Document; Not for Official Distribution. 13

14 Example Open-Source Components OSEHRA will not recommend a particular SOA solution stack Mirth Connect is the Swiss Army knife of healthcare integration engines, specifically designed for HL7 message integration. It provides tools for developing, testing, deploying, and monitoring interfaces. 3M Opens Access Healthcare Data Dictionary (HDD) Apelon Open-Source Common Terminology Service (CTS) version 2 OpenID is about authentication (ie. proving who you are) OAuth could be used in external partner sites to allow access to protected data without them having to re-authenticate a user. Paraview is a multi-platform data analysis and visualization application. 3D Slicer is an extensible medical-image visualization-and-analysis application. 10/15/2013-G OSEHRA-AWG Draft-Working-Document; Not for Official Distribution. 14

15 Questions? How can OSEHRA help? Seong K. Mun Administration Mike Henderson Products Peter Li Architecture Christopher Edwards Implementation & Test Thank You 10/15/2013-G OSEHRA-AWG Draft-Working-Document; Not for Official Distribution. 15

16 Plan-of-Actions and Milestones Participation Welcome SITUATION: OSEHRA represents the open-source VistA EHR community; where, VA s VistA Evolution initiative proposes to transform legacy VistA into a Healthcare SOA Platform that can leverage modern technologies and Cloud offerings. OSEHRA advocates an open-source SOA stack assessment framework, as described in this presentation. 8 Oct (Tuesday) 4 PM AWG AWG Discussion on 1 st draft of this presentation OSEHRA team create a Plan-of-Action for next week s AWG. 15 Oct (Tuesday) 4 PM AWG AWG Discussion on 2nd draft of this presentation OSEHRA team creates a Plan-of-Action for next week s AWG. 22 Oct (Tuesday) 4 PM AWG OSEHRA provide finalized presentation to open-source community and VA. Talend present their recommendations for VistA Service Backplane 10/15/2013-G OSEHRA-AWG Draft-Working-Document; Not for Official Distribution. 16

17 Backup Acronyms API Application Program Interface AWG Architecture Work Group CDS Clinical Decision Support CDR Clinical Data Repository (DOD) CDW Clinical Data Warehouse (VA) COTS Commercial off-the-shelf CPR Clinical Patient Record CTS Common Terminology Service DMS Data Management Services ESB Enterprise Service Bus HDD Health Data Dictionary JASON Javascript Object Notation RLUS Retrieve, Locate, Update Service RPC Remote Procedure Call SOA Service Oriented Architecture 17

18 Tom Munnecke s VistA Onion 18

19 TALKING POINTS: Notional VistA s-business SOA-Stack Based on 1. User Facing Layer provide support for users (both inside and outside the enterprise) to view and control the execution of the enterprise business processes and/or services. These users can be either humans using Web or rich clients or B2B connections (e.g., VLER) supporting intra-enterprise business processes. 2. Business Processes Layer, such as Orders Management, allow for creation of complex business protocols through orchestration of business services. 3. Business Services Layer, such as Ancillary Services, provide high-level business functionality throughout the enterprise. This layer effectively bridges between the "ideal" business model and the existing enterprise IT assets - applications and business components. 4. Business Components Layer, such as Laboratory, uses Service Orchestration to produce deployable units of software that provide the functionality required by business services. These components can be either newly developed or "wrappers" using integration layer to access the functionality of existing enterprise resources (e.g., Virtual Patient Record (VPR)). 5. Integration Layer uses various technologies (e.g., JASON, RLUS API) to expose existing enterprise resources (e.g., data stores, laboratory test machines) and operational systems (e.g., VistA) so resources could be used by business components. 6. Enterprise Resources Layer represents the portfolio of Operational Systems and existing applications (i.e., legacy, COTS and custom built systems). 19

20 TALKING POINTS: Enterprise Service Bus (ESB) The enterprise data bus provides access to the VistA enterprise data and other DOD and VA databases. ESB based business components implement business logic based on the existing functionality; but, data access is implemented through the ESB; where, the ESB advantage is explicit separation of concerns between implementation of the service functionality (business logic) and enterprise data support logic; because, the ESB creates an abstraction layer shielding business functionality from enterprise data access and transformations among enterprise semantic data model and data models of enterprise applications. Because all service implementations have access to all enterprise data, implementations significantly reduce coupling among services; because, actual data accesses are implemented by the service itself using enterprise data bus. The potential disadvantage of this approach is performance, due to the amount of concurrent synchronous accesses, which should be mitigated by Virtual Patient Record (VPR) local data caches. 10/15/2013-G OSEHRA-AWG Draft-Working-Document; Not for Official Distribution. 20

21 Enterprise Data Access Issues Mitigated by ESB Based On VISION: Federated SOA-Enabled VistA + ESB + Data Management Services (DMS) = Healthcare SOA Platform that can leverage modern technologies and Cloud offerings. ISSUE: VistA s M-implementation tightly couples functionality, data and business rules 1. Consolidation of data between multiple applications. DOD and VA data is scattered between multiple silo applications; where there is potential data redundancy among applications creating inconsistent enterprise data representations of "master" data stored for particular functionality/unit. As an SOA implementation is attempting to represent enterprise-wide functionality it needs to operate based on a well-defined enterprise data model. This means that enterprise data access from service implementations is required to correctly align and consolidate data from multiple existing applications and ensure propagation of data changes to all applications, using this data. 10/15/2013-G OSEHRA-AWG Draft-Working-Document; Not for Official Distribution. 21

22 Enterprise Data Access Issues Mitigated by ESB 2. Ownership of enterprise data by services is the foundation of the modern service definition technique; where, functional decomposition is not easily mapped to the enterprise data. For example, the notion of the patient (and corresponding data) is usually shared between multiple functional services; where, 1. The problem is that functional and data decompositions are driven by completely different rules. 1. Functional decomposition is defined based on the enterprise business processes - enterprise functionality; whereas, 2. Data decomposition is defined based on the enterprise data taxonomy - underlying enterprise data model. As a result, aligning of the enterprise data with enterprise services becomes a daunting task. 3. Interface definitions. Because service invocations are often remote, service design strives towards large granularity interfaces, aiming at minimizing service traffic (chattiness) between service consumers and providers; where, 1. Data access can require fine granularity of interfaces to meet functional requirements and 2. Data access typically implements pure CRUD (Create, Read, Update, Delete) a where as enterprise services implement business meaningful interface, like orders management, etc. 22

23 Open Source is not Free Open source is often called a "community" and there is a good reason why: most open source projects depend on volunteers, some of whom may be paid by their employer. People who are skilled and motivated get involved in open-source projects to help bring useful-ideas to life. User skin-in-the game generally provides better results; where, It is important to realize that successful organizational use of open-source software implies resource investment for the betterment of the Open-Source community as well as a particular organization s betterment; and where, Open-Source communities are meritocracies; where, leadership in a meritocracy is based on intellectual talent, demonstrated achievement and resource contribution. Although not free, open-source development can be: FASTER: Community participation encourages faster results. BETTER: Community peer-review of products & tests encourages quality. CHEAPER: Community software reuse encourage agility, economy and quality. 10/15/2013-G OSEHRA-AWG Draft-Working-Document; Not for Official Distribution. 23