VSA Integration with Apache VistA SOA Update Edward Ost 11/14/2018

Purpose Identify differences between VA and Community use of VSA Understand lifecycle impacts of VSA on OSEHRA Platform Align and leverage with VSA

Agenda Quick Overview of Apache Camel Applying Apache Camel for VSA Architecture Camel-RPC connector for VistA Using Spring Dynamic Proxies with Camel Next Steps

Principles Apply separation of concerns to technology stack Open Standards – interoperability Open Architecture – pluggable solution stack Open Business Model – robust supply chain Promote rapid evolution by minimizing client impact Managed variation across VA and Community

What Stays the Same Same emphasis on VistA as provider of Services Same emphasis on coarse grained Managed Services Same emphasis on VSA as tooling to facilitate Managed Services compliant with Governance Same external interoperable transport VSA provides a Vista Platform Service Development Kit (SDK) to embed Governance into Development

Enterprise Service Bus (ESB) Registry and Repository VA SOA Runtime View E$B not in Community Enterprise Service Bus (ESB) VistA Site 1 M Code and Data M Routines for Progress Notes VMRCS VMRCA M Routines for Outpatient Meds M Routines for Allergies Registry and Repository (Websphere Registry and Repository) VistA SOA Federating Services Platform - Regional (Java) Progress Notes Service Registry Entry Outpatient Meds Service Registry Entry Progress Notes Service Allergies Service Registry Entry Consumers Consuming Applications Outpatient Meds Service Site N M Code and Data M Routines for Progress Notes VMRCS VMRCA M Routines for Outpatient Meds M Routines for Allergies Core ESB (Websphere Message Broker) Allergies Service Each service is deployed separately to the VistA SOA Federating Services Platform hosted in each regional data center. As a Java application server platform it is scalable using standard application server clustering strategies. Use of commodity servers may be used to reduce cost. Providers of a new VistA SOA Service do not have to install new servers, but add their service to the VistA SOA Federating Service Platform. This platform is managed at the Regional level. VMRCS is deployed to each site instance in a Cache database separate from the standard VistA Cache database Progress Notes Service Proxy Outpatient Meds Service Proxy No RPC Support for Existing Clients Cache WS-* in M Allergies Service Proxy VistA SOA Services VistA Service Assembler (VSA) Conceptual and Technical Overview VSA Development Team April 2014 VistA Service Assembler

VistA Service Backplane OSEHRA VistA Platform VistA Platform Site 1 M Code and Data M Routines for Progress Notes VMRCS VMRCA M Routines for Outpatient Meds M Routines for Allergies Optional VistA SOA Federating Services Platform - Regional (Java) Enterprise Infrastructure VistA Service Backplane Managed Application Progress Notes Service Hybrid Environment Outpatient Meds Service Site N M Code and Data M Routines for Progress Notes VMRCS VMRCA M Routines for Outpatient Meds M Routines for Allergies Legacy App (managed) Each service is deployed separately to the VistA SOA Federating Services Platform hosted in each regional data center. As a Java application server platform it is scalable using standard application server clustering strategies. Use of commodity servers may be used to reduce cost. Providers of a new VistA SOA Service do not have to install new servers, but add their service to the VistA SOA Federating Service Platform. This platform is managed at the Regional level. VMRCS is deployed to each site instance in a Cache database separate from the standard VistA Cache database Allergies Service RPC Support and Migration of Existing Clients RPC (logical VMRCS layer) VistA Service Assembler

Client Requirements Many existing RPC Clients Impacts on Clients slows rollout Low risk migration path Manage a hybrid client environment

Service Backplane Integration No ESB in OSEHRA Community deployments Responsibilities of ESB can be delegated / integrated VistA Federated Service Platform Service backplane should integrate with existing community infrastructure Lightweight, open source solution

Differences – Operations Legacy Client Support Manage Legacy Clients Zero-touch Deployment Site N M Code and Data M Routines for Progress Notes M Routines for Outpatient Meds M Routines for Allergies VistA Service Backplane Legacy App (managed)

Differences – Technical VSA Compose low level RPC into high level Managed Services VMRCS Implemented in process in M Logical layer to compose internal services Manage connection and session state Enforce RBAC Less IPC and marshalling overhead RPC rather than SOAP for intra-Platform communication

Differences – Supply Chain No WS-* implementation in M Multiple OSS vendors for integration No required custom built integration Leverage existing RPC bindings

What Stays the Same VistA trusts the identity communicated by the Service Backplane via secure transport Service Backplane has pluggable Identity consistent with Enterprise Infrastructure (e.g. VA ESB) Responsibility for coarse grained enforcement of Access Control is in the Service Backplane Privacy and other concerns may require propagation of identity and access control policies to VistA

OSS Supply Chain Don’t forget the maintenance tail! Good software is software you don’t need to maintain Leverage the Apache OSS community for technology KPI : [lines of business code] / [lines of tech code] Don’t build applications, build components

Technical Challenges RPC currently has 32k payload limit Need to build an appropriate Connection model for the Service Backplane to VRCS Need to capture the Identity and Access Control mechanisms and points of enforcement

Common Legacy SOA Interpretations VistA Encapsulation / Encasement HealtheVet VistA Notes Service Rx Service Ordering Service CP&E Service Consumers Perpetuates shortcomings and dependencies on legacy systems Inhibits individual application replacement Granular logic, “chatty” communications exacerbated by the middleware layer Atomization / Re-Hosting Major retooling and investment Subjective interpretation Inability to anticipate future consumers Tendency to build too much, to build too little MDWS/VIA Consumers VistA Notes Rx Ordering CP&E VistA SOA Services VistA Service Assembler (VSA) Conceptual and Technical Overview VSA Development Team April 2014 VistA SOA Services

Architecture Risk Management Mitigation Strategy Perpetuates shortcomings and dependencies on legacy systems VSA extends governance to design phase, OSS allows client refactoring Inhibits individual application replacement Composition layer in VistA enables incremental refactoring Granular logic, “chatty” communications exacerbated by the middleware layer Coarse grained services composed directly in VistA Major retooling and investment Non-invasive, zero-touch deloyment Subjective interpretation Common policies expressed declaratively in VSA at design time, and enforced at runtime by VistA Service Backplane Inability to anticipate future consumers Layered composition of fine grained VistA services provides flexibility, EIP in Service Backplane allow choreography Tendency to build too much, to build too little Build a little, test a little, deploy incrementally, rapid feedback; service maturity cycle

Summary VistA Federated Service Platform Accelerate Adoption Minimize impact on existing clients Supporting existing RPC clients Manage existing clients within new framework Support Community operations without ESB No dependency on Cache No need to build and maintain WS-* in M Option for EWD Separation of Concerns focuses VistA M stack on data and domain logic rather than tech stack.

Next Steps Demo VistA integration with Medical Devices using VistA Service Backplane Pluggable Camel transport for VSA Apache Camel Proxy to WS Apache Camel Proxy to RPC