VSA Integration with ApacheVistA SOA Update

Edward Ost

04/19/2023

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

VA SOA Runtime View

VistA Service Assembler 6

Enterprise Service Bus (ESB)

Registry and Repository(Websphere Registry and

Repository)

Core ESB(Websphere Message Broker)

Progress Notes ServiceRegistry Entry

Progress Notes Service Proxy

ConsumersConsuming

Applications

Outpatient Meds ServiceRegistry Entry

Allergies ServiceRegistry Entry

Outpatient Meds Service Proxy

Allergies ServiceProxy

VistA

VistA SOA Federating Services Platform -

Regional(Java)

Progress Notes Service

Outpatient Meds Service

Allergies Service

Site 1

M Code and DataM Routines for Progress Notes

VMRCS

VMRCA

M Routines for Outpatient Meds

M Routines for Allergies

Site N

M Code and DataM Routines for Progress Notes

VMRCS

VMRCA

M Routines for Outpatient Meds

M Routines for Allergies

CacheWS-* in M

E$B not in Community

No RPC Support for Existing

Clients

VistA SOA ServicesVistA Service Assembler (VSA)Conceptual and Technical OverviewVSA Development Team April 2014

OSEHRA VistA Platform

VistA Service Assembler 7

Legacy App(managed)

Managed Application

VistA

VistA SOA Federating Services Platform -

Regional(Java)

Progress Notes Service

Outpatient Meds Service

Allergies Service

Site 1

M Code and DataM Routines for Progress Notes

VMRCS

VMRCA

M Routines for Outpatient Meds

M Routines for Allergies

Site N

M Code and DataM Routines for Progress Notes

VMRCS

VMRCA

M Routines for Outpatient Meds

M Routines for Allergies

RPC(logical VMRCS layer)

Optional

Platform

Support and Migration of

Existing Clients

Hybrid Environment

RPC

VistA Service Backplane

Ente

rpris

e In

fras

truc

ture

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

Legacy App(managed)

Site N

M Code and Data

M Routines for Progress Notes

M Routines for Outpatient Meds

M Routines for Allergies

VistA Service Backplane

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

– Major retooling and investment– Subjective interpretation– Inability to anticipate future

consumers– Tendency to build too much, to

build too little

– Perpetuates shortcomings and dependencies on legacy systems

– Inhibits individual application replacement

– Granular logic, “chatty” communications exacerbated by the middleware layer

VistA SOA Services 16

VistA

HealtheVet VistANotes

ServiceRx

Service

Ordering Service CP&E

ServiceConsumers

Atomization / Re-Hosting

Encapsulation / Encasement

MDWS/VIA

Consumers

VistANotes

RxOrdering

CP&EVistA SOA ServicesVistA Service Assembler (VSA)Conceptual and Technical OverviewVSA Development Team April 2014

Architecture Risk Management

Risk 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