Veterans Health Administration - OMG · dotNet, etc. CAIP Java service sharing methodology Shared Services Architecture. ... Common Services Development Perspectives. October 27,

Veterans Health AdministrationCommon Services

October 27,2005

Keith CoxActing Associate Deputy Director

Health Systems Design & Development

October 27, 2005 Common Services 2

“A technical overview in non-technical terms…”


The Motivation

• Legislative and Departmental Mandates– The Clinger-Cohen Act– E-Government– One VA

• Improve level of interaction with private sector information systems.

• Enhance ability to utilize commercially produced software and IT products.

• Inadequacy of current technology and architecture– Incompatible technology– “Silo” application design– Difficult to maintain


Enterprise Architecture Implementation

• N-tier software design• Modern technology• Service oriented architecture

– Decomposition of application capabilities– Creation of service components– Methodology for sharing services

• Centralized/distributed deployment– Virtual single record view– Synchronization across systems of interest– Support for continuity of operations

• Standards / Information Model based


client

DatabaseBrowser

Application

Web Server OC4J

Applets Servlets,

JSP, CGI

(Client Presentation) (Business Logic)

EJBs, Beans

1 2 3 4

N-tier ArchitectureApplication Services Business Services Data Services


client

DatabaseBrowser

Application

Shared Business Service

1 2 3 4

Application Services Business Services Data Services

Consuming application, service or external system

Java, C++, dotNet, etc.

CAIP

Javaservice sharing

methodology

Shared Services Architecture


What is CAIP?

• “Cross Application Interface Protocol” (CAIP)• CAIP defines a framework for establishing a consistent

foundation for integration across applications• A layer of abstraction between shared business services and

the applications that subscribe to them• CAIP can serve as a technology adapter between business

services created in Java and applications or systems based in other technologies


Application / Presentation Tier

Data TierADR

E/E Data

Identity MgmtData

Demo-graphics

Data

E/E Service

RegistrationApplication

Data QualityApplication

Human ResourcesApplication

Person Service

Person ServiceIdentity Mgmt

Person ServiceLookup

Person ServiceDemographics

Scheduling Application

Scheduling Service

Services Tier

N-tier Shared Services Example


System / Service Deployment Assumptions

Service “A”

Central System

Service “B”

Central System

Service “E”

Central System

Service “C”

Service “D”

Service “B”

Local System

Service “C”

Service “D”

Service “D”

Local System

Service “E”

Service “E”

Service “B”

Local System

Service “C”

WebInterfaceWeb

Interface

Medical Center

Medical Center

Medical Center

Legacy VistA

Legacy VistA

Legacy VistA


Publish & SubscribeShared ServiceProcess / Publish

Localsubscribers

Shared ServiceProcess / Publish

Localsubscribers

Delivery Service

OutShared ServicePublish / Process

Localsubscribers

Delivery InService Out

In / OutDelivery Service

Local System

Site “A”

Local SystemSite “B”

Central System

Scenario: Site “A” publishes an event in Hub-and-spoke configuration

App.


Interface Engine (test/backup)






Interface Engine (production)






DbServer

DbServer

App.Server

App.Server

(test/backup)

DbServer

DbServer

App.Server

App.Server

(test/backup)

DbServer

DbServer

App.Server

App.Server

(test/backup)

DbServer

DbServer

App.Server

App.Server

(prod-uction)

DbServer

DbServer

App.Server

App.Server

(prod-uction)

DbServer

DbServer

App.Server

App.Server

(prod-uction)

Central HeVSystems

Local HeVSite “A”

Local HeVSite “B”

Redundancy forTest / Failover?


Distrib.System

TargetSystem

Business Service Interaction

SynchronizationProcess

SynchronizationProcess

SourceSystem

ExtractLogic Import

LogicTransport

Method StagingSystem

Data Migration

Sync.Sync.

Data &MetadataCleanup

Data Migration Concepts


Common Services Focus

• Provision/coordination of core functionality– Business support functionality including Person Service and Standard

Data Service– Middleware services that support the sharing of services and data

between applications and systems– Infrastructure services such as security, auditing, archiving, etc.– Hardware deployment necessary to support application modernization.

• Maturation of organizational support structures• Proof of concept for SOA implementation


Scope: Common Services vs. common services

HealtheVetVistA

Application Services

Shared Business Services

Data Services

Deploy Hardware

Misc.

HDRSDS… PATS VPFS ADR LocalADR …Scheduling

AuditService

StandardData

Service…Lab

Service Appt.Service

DeliveryService Person

Service …Eligibility/Enrollment

Service

TrainStaff

EvaluateProcess…

PublicRelationsEducate

Sites

CoordinateSequence

ProvideOrganizationInformation

…Coordinate

ExternalSystems

SitePrep.

MonitorTimelines…

SiteTrainingDetermine

Capacity

CoordinateSoftware

Deployment

CoordinateCS

interests…Procurement

SDSMaint.

ProviderEnter/edit…

Enterorder Make

Appt.

PatientLookup Data

Quality …Registration


Use Case View – Business case, functionality scenarios

Logical View – Object models, classes, relationships

Process View – Control flows, intercommunication

Implementation View – modular structure (Service Oriented Arch.)

Deployment View – Allocation of software/hardware (Centralized/ Distributed deployment)

Common Services Development Perspectives


Common Services Efforts

• Person Service– Lookup– Demographics– Identity Management

• Standard Data Service– Table factory– Replication– Authoring– Maintenance

• Service Oriented Implementation– CAIP– Delivery Service– Subscription Management Service– Messaging Service– Dynamic Routing Service– Naming / Directory Service– HL7 Segment Service


Common Services Efforts (cont.)

• Application Preference Service

• Audit Service• Archive Service• Enterprise Exception Log• Administrative Data

Repository (ADR)• ADR Data Migration

• Institution file re-design• Data Standardization• National Provider Identifier• Metadata Service• Cross Service and

Extended Transaction Manager

• Non-Person Service


Ward

Equipment

Institution

NPI Org. Provider

Clinic

Room

Non-PersonIdentity

Management

RelationshipConstruct

PersonIdentity

ManagementPatient

Provider

IT User

Employee

System of Interest

LongitudinalView

Data Consumer

Relationship/Longitudinal Concepts

Note: This is a representation of concepts, not technical structure of files, etc.



Issues – A share of the wealth…

• Data– Standardization– Cleanup – Metadata uniformity– Synchronization– Migration– Ill formed data– History– Checksums


More Issues…

• Software Performance Engineering (SPE)– Invalid assumptions– Baseline– Usability vs. performance– Tolerance/threshold– Modeling/prediction– Benchmarking– Expectation management– Test environment


Yes, more issues…

• Versioning– Software– Metadata– Table content

• Overarching Requirements• N-tier Requirements Management• System interdependency


Questions?


Backup slides


Software Versioning Characteristics

• Co-existence of multiple component versions• Abstraction of versioning consumption specifics• Discoverable at development time and run time• Centrally and locally manageable configuration• Controlled consumption

– Arbitrary – maintain FDA device relationships– Dynamic – upgrade per compatibility– Selected – honor consumer’s preference– Forced – upgrade by mandate


Software Versioning Motivations

• Limited exposure in production environments• Reduced complexity in implementing software

upgrades• Maximize functional flexibility• Coordinated software rollout and activation• Effective software configuration management• Shift impacts from hard coded application logic to

application runtime configuration.


Factors Limiting Versioning Effectiveness

• Backwards and forwards compatibility• Shared computing environment• Software update types• Deployment architecture• N-tier development characteristics


Factors: Compatibility Considerations

• Backward compatible – new versions must be compatible with impact of older versions on the shared environment

• Forward compatible – old versions must be compatible with impact of newer versions on the shared environment

• Compatibility types– Syntactic – the structure of API signatures, message

formats, etc.– Semantic – the meaning of data, business rules, GUI

navigation logic, etc.


Factors: Shared Computing Environment• Shared transactions – both semantic and syntactic

concerns (e.g. message flow across systems)• Shared data – both semantic and syntactic concerns

– Shared data types• Primary data (patient records, etc.)• Reference data

– Shared data semantic and syntactic elements• Conceptual content• Domain (e.g. elements in a pick list)• Metadata (field length, etc.)


Factors: Software Update Types

• Defect repair – largely transparent from a syntactic/semantic standpoint

• Enhancement – potentially syntactic or semantic (or both)

• Business Process Re-engineering – likely to have significant semantic changes and potentially syntactic changes as well


Factors: Deployment Architecture

• Central/Web based – Voluntary• Central/Web/Integrated – PATS, VPFS, Blind Rehab• Central Database/Distributed processing –

Scheduling Replacement• Centralized/Distributed Database & processing –

Common Services• Decentralized/Integrated – Imaging


Co-existent Version Deployment

Enhancements, Business Process Re-engineeringDefect repairs

Centralized/distributed data or processing

Decentralized data and processing

Database, Business Service updatesApplication Service updates

Forward/backward incompatibleForward/backward compatible

Cross-system transactionsLocal transactions

Shared, distributed dataNo data, local data

LimitationOpportunity


Conclusions: Versioned vs. Incremental release• Governed by factors of environment and software

update characteristics• Constrained by limiting factors that exist• Forward/backward compatibility is not consistently

achievable• Changes to shared data and cross-system

transactions cannot be effectively partitioned• Versioning rigor is needed to support both co-existent

versioned and incremental (big bang) release approaches


Conclusions: Reference Data

• Temporal model vs. versioned data– Temporal – provides longitudinal view of single version,

preferable for frequent content changes– Versioned – necessary for multiple views of a single table

to co-exist• Recommendation – Versioned/temporal


Conclusions: Versioning Implementation

• Implement for software components, business rules, XML schemas, software distributions, API integrations and reference data content

• Implement as needed for database schemas and metadata

• Make versioned vs. incremental release decisions in Release and Configuration Mgt. (not development)

• Create tools to manage runtime version consumption• Establish test process for both versioned and

incremental release paths


Next Steps

• Establish organizational consensus• Define versioning standard or policy development

teams must follow• Define software test/release process• Create development cookbook for meeting versioning

standard• Develop runtime version consumption mapping tools

VistA Instances

Hines

PSIM

ADR/IDR

AAC

MPI

Atlanta

HEC

IVM

MVR

VistA 1 VistA 2 VistA 3 VistA 4 VistA 127 VistA 128

. . .VistA 5 VistA 6 VistA 126VistA 125

EDB

VIEHines

VIE 1 VIE 2 VIE 3 VIE 4 VIE 5 VIE 6 VIE125

VIE126

VIE127

VIE128

TODAY

VIEAAC

Site Personnel

HEC User

IMDQ User


VistA Instances

Hines

PSIM

ADR/IDR

AAC

MPI

Atlanta

HEC

IVM

MVR

EDB

VIEHines

June 2006

ADR

IDR

VIEAAC

PS, DSNDS, SDS, other CS

ESR

Failover

VistA 1 VistA 2 VistA 3 VistA 4 VistA 127 VistA 128

. . .VistA 5 VistA 6 VistA 126VistA 125

VIE 1 VIE 2 VIE 3 VIE 4 VIE 5 VIE 6 VIE125

VIE126

VIE127

VIE128

IMDQ User

HEC User

Site Personnel


Regional Data Center 2 thru N-1

Regional Data Center NRegional Data Center 1

Hines

PSIM

ADR/IDR

AAC

MVR

VIEHines

June 2008

ADR

IDR

VIEAAC

PS, DSNDS, SDS, other

ESR

Failover

VistA 1 VistA 2 VistA 3 VistA 4

VIER1

VistA 127 VistA 128VistA 126VistA 125

VIERn

. . .VistA 5 VistA 6

VIERxx




ADR

ADR

ADR

IDR

IDR

IDRRSA

CDS, CPRS,Other HeV

RSA,CDS, CPRS,Other HeV

RSA, CDS, CPRS,Other HeV

Failover Failover

Site Personnel

HEC User

IMDQ User


Regional Data Center 2 thru N-1

Regional Data Center NRegional Data Center 1

Hines

PSIM

ADR/IDR

AAC

MVR

VIEHines

June 20XX

ADR

IDR

VIEAAC


ESR

Failover

VIER1

VIERn

VIERxx




ADR

ADR

ADR

IDR

IDR

IDRRSA

CDS, CPRS,Other HeV

RSA,CDS, CPRS,Other HeV

RSA, CDS, CPRS,Other HeV

Failover Failover

Site Personnel

HEC User

IMDQ User


Delivery Service

NationalPSD

Service

NationalADR DataBase

13. PSD Update to National ADR

Dynamic Routing Service

Subscribers forADR Updates

Example: Scheduling

PSD Messaging Architecture Scenario-S2:“A31” Message Flow [Transitional State With

ADR-Lite and Legacy VistA]

Consuming Applications

12. DS invokes PSD’s “A31Update” listener when sender=”HeV”

[PUB/SUB from 8]

14. PSD posts “gold” “A31Update” messagewith Sender=”ADR” [PUB/SUB]

16. DS invokes other Subscribers for “A31Update” when Sender=”ADR”

[PUB/SUB from 14]

15. DS obtains Sites of Interestlist for the person updated from the Dynamic Routing Service

[PUB/SUB from 14]

24. PSD posts “gold” “A31Restore” message with National ADR payload

with Sender=”ADR” [PTP to 25]

PSD API

Institution-A

File-200 Field-Level Trigger

LocalPSD

ServiceVistA

Process

ADR Lite for Site-A[Cache] VistA Database

Institution-A

Legacy Vista Message Queue

(VIE)

Consuming Applications

3. File 200 update

4. HL7 “A31” message

FIRE

Local Delivery Service

2. ADR Liteupdate

27. ADR “gold” restore

7. LegacyVistA sync-up

PSD API

Local Subscribers

9A. Invoke “A31Update” Listeners w/Sender=”HeV”

[PUB/SUB from 8]

29A. Invoke “gold” “A31Restore” Listeners

w/Sender=“HeV”

1. Initiate PSD update using

PSD API

8. Post “A31Update” w/Sender=”HeV”

[PUB/SUB]6. Invoke Local

PSD [PTP from 5]

9B. National DS listens for “A31Update” sender=”HeV”messages [PUB/SUB from 8]

25. DS invokes the Local PSD for the originating Site for

“A31Restore” sender=”ADR” restoration messages [PTP from 24]

Site-B

Local PSD

Service

ADR Lite Site-B

[Cache]

VistA Process

File-200 Field-Level

Trigger

VistA Database

Institution-A

Legacy Vista Message Queue

(VIE)

19. ADR “gold” update

PSD API

Local Delivery Service

18. Invoke local PSD service for “A31Update”

w/Sender=”ADR”

Local Subscribers

20. Post “A31UpdateLocal”w/Sender=”HeV” (PUB/SUB)

21A. Invoke Listeners for “A31UpdateLocal” w/Sender=”HeV”

[PUB/SUB from 20]

17. National DS invokes local Delivery service for each

Site that has subscribed for “A31Update” w/Sender=”ADR” and

is in the Sites of Interest list. [PUB/SUB from 14+15]

26. Invoke PSD[PTP from 24]

28. Post “gold” “A31Restore”

w/Sender=”HeV” [PUB/SUB]

31. File 200ADR “gold”

restore

11. File 200ADR-Litesync-up

10. Invoke VistA process for “A31Update” w/Sender=”HeV”

[PUB/SUB from 8]

30. ADR “gold” “A31Restore”

X23. File 200ADR Litesync-up

22. File 200ADR-Lite sync-up

29B. Relay to VIE for ‘gold” “A31Restore” w/Sender=”HeV”

[PUB/SUB from 28]5. Local DS listens to

legacy Vista Messaging

9C. Relay to VIE for “A31Update” w/Sender=”HeV”

[PUB/SUB from 8]

21B. Relay to VIE for “A31UpdateLocal” w/Sender=”HeV”

[PUB/SUB from 20]


Local Site 2

Person Service

Rehosted App

VistA

BD

???

2/00

Person Service

Central Site

Rehosted App

BD

SFLocal Site1

Person Service VistA

SF

???

2/00

FileMan

Rehosted App

BD

Msg Service

queue

Msg Service

queue

Msg Service

queue

FileMan

SF

External System

1. Update local system: update locally, add to local queue for central processing, publish to local sites

Scenarios

1.1

1.2

1.7

1.3

1.4

1.5

1.8

1.6

1.9

1.10

1.11


Local Site 2

Person Service

Rehosted App

VistA

BD

???

2/00

Person Service

Central Site

Rehosted App

BD

SFADRLocal Site1

Person Service VistA

SF

???

2/00

FileMan

Rehosted App

BD

Msg Service

queue

Msg Service

queue

Msg Service

queue

FileMan

SF

External System

1. Update local system (VistA): update locally, add to local queue for central processing, publish to local sites

Scenarios

2. Update local system (RApp): update locally, add to local queue for central processing, publish to local sites3. Update central system: Update central site then publish

MPI1.1

1.2

1.7

1.3

1.4

1.5

1.8

1.6

1.9

1.10

1.11

1.5

1.10

1.11

1.6

1.9

2.1

2.2

2.3

2.4

2.5

2.6

2.6

2.72.7

2.8

2.9

2.10

2.10

2.11

2.12

2.12

2.11

3.1

3.2

3.3

3.4

3.5

3.6

3.6

3.6

3.7

3.7

3.7

3.7

3.83.8

3.83.8


Local Site 2

Rehosted App

BD

Person Service

Central Site

Rehosted App

BD

SFLocal Site1

Person Service

SF

Rehosted App

BD

Msg Service

queue

Msg Service

queue

Msg Service

queue

Person Service

SF

External System

1. Update local system: Check central site before updating locally, add to local queue for central processing2. Update central system: Update central site then publish

Scenarios

3. Update external system: Update central site, then publish

ADR

MPI

VistA

???FileMan

VistA

???FileMan

2/00

2/00

2.1

2.2

2.3

3.2

3.3

3.4

3.4

3.5

3.5

3.6

3.6

3.1

2.4

2.5

2.6

2.6

2.8

2.7

2.7

2.8

1.4

1.1

1.2

1.3 1.5

1.6

1.7

1.8

1.9

1.10

1.11

1.12

Documents

Veterans Health Administration - OMG · dotNet, etc. CAIP Java service sharing methodology Shared Services Architecture. ... Common Services Development Perspectives. October 27,