H E A L T H I N F O R M A T I O N Brown Bag Presentation: May 9, 2006 Presenter: Bert R. Kosier De-Branded, Extensible HeV : HealtheVet-VistA Multinational

H E A L T H I N F O R M A T I O N

Brown Bag Presentation: May 9, 2006Presenter: Bert R. Kosier

De-Branded, Extensible HeV : HealtheVet-VistA Multinational Extensibility Level-of-Effort Analysis

Presentation

Click to edit Master title style

HEALTH INFORMATION

2

Agenda

Project Overview HVV Open Source Governance Services HVV Multinational/Multilingual Services and

Generic Services HVV Extensibility HVV Platform Project Status Summary

FHS HVV Multinational Extensibility LOE Analysis


HEALTH INFORMATION

3

Project Overview

Background: Purpose: to provide VHA with the objective, evidence-

based criteria necessary for informed decision making regarding the extent to which HVV should be treated as an ‘open source’ product.

Perot Systems Corporation (Perot Systems) was asked to assist this effort by providing graduated LOE resource estimations and analysis in three specific areas:

• Governance Model • Generic Services (Business Extensibility)• Multinational/Multilingual Extensibility

Results of LOE for Governance Model, Generic Services, and Multinational/Multilingual Extensibility are covered by this presentation.



HEALTH INFORMATION

4

Project Overview

Project Goals and Constraints: Determine Level of Effort (LOE) required to enable:

• A governance model to accommodate change request receipt and disposition from VA and non-VA communities

• An HVV design that facilitates Generic Services for business extensibility

• Design and maintenance of a Generic Health Information• HealtheVet-Vista (HVV) for Multinational/Multilingual (M/M)

extensions

Constraints: • Recommendations must be made in the context of a Service

Oriented Architecture (SOA)• Recommendations should not be constrained or influenced

by current HVV design



HEALTH INFORMATION

5

HVV Open Source Governance Services

HVV Development communities: HVV Development: identifies, schedules, and builds the

components/applications funded and staffed by the VA (i.e. the official HVV components):

VA Development Contact Vendors

HVV Contributors (Private Open Source): processes proposed change requests to the official HVV components from external communities and/or organizations and develops extensions to HVV components to address approved change requests:

VA Sites / VA Regions Trusted 3rd Parties

Open Health (Public Open Source): develop components and applications that will benefit the greater healthcare community:

DoD / HHS / CMS / IHS / Other Government Agencies Medical Universities & other Public Sector Healthcare Institutions



HEALTH INFORMATION

6


HVV Governance Model Scope:



HEALTH INFORMATION

7


HVV Sources of Change Requests:



HEALTH INFORMATION

8


Key Processes:Key Processes:


HVVDevelopment

HVVDevelopment

HVVContributors

HVVContributors

OpenHealthOpenHealth

Release Management

DistributionManagement

Enrollment

Request Initiation

Vetting

Collaborations

Releases

Moderation

DirectionSetting

DirectionSetting

Moderation

Communications

Approval

Monitoring

ReleasePlanning

Evangelization

Request Processing

Communications

ChangeManagement

VA HPMO

Change Management

Contributions (Partial Release)

Contributions

Environment

Environment

Full R

eleas

e


HEALTH INFORMATION

9


Automating the Change Management Process::• Services Oriented Architecture creates many ‘components’

that can be extended• Automation is required to achieve process goals • Automation requires formal Change Request and

Component classification mechanism• Classifications are used to route work/tasks to competency-

based teams and/or individuals• Classifications are also used to provide constrained

distributions of HeV components• Fosters consistent and timely feedback & reporting• Forms the basis for Project-based budgeting/planning



HEALTH INFORMATION

10


Automating the Change Management Process::



HEALTH INFORMATION

11


Key Roles::



HEALTH INFORMATION

12


Key Enablers:Key Enablers: Classification Model

– Change Requests– HVV Services/Components

Workflow– Uses Classifications to queue, route, and track change requests– Enables advanced reporting and notification of state change

events Portals

– Provides tools for community participants to enroll, collaborate, and contribute components

– Provides tools for community management (steering committees, moderators) to manage the community as a whole



HEALTH INFORMATION

13

HVV Multinational/Multilingual Services and Generic Services

HVV Multinational/Multilingual Services:HVV Multinational/Multilingual Services: LOE Analysis estimates provided for 3 distinct areas:LOE Analysis estimates provided for 3 distinct areas:

• Patient directed information in one or more secondary languages

• The ability for each provider-user to access HVV in their specified language, allowing simultaneous support of two or more languages within a single instance of HVV:

» Structured Information Only» Unstructured (i.e. Free Form) Information

• HVV extensions to support additional base languages/localizations including the ability to support multiple character sets, language dialects, and other locale specific constraints



HEALTH INFORMATION

14


Generic HVV Services:Generic HVV Services: LOE required to design HVV services that are LOE required to design HVV services that are

organizationally agnosticorganizationally agnostic (i.e. allow the customization, configuration, and extension of business functionality)

• Business functionality includes the following:Business Object Model/Data Model EventsBusiness Rules Messages (inter-process communication)Processing Flow/Logic Security/Privacy Roles and Access Control

A Generic Health Information Model (GHIM), defining the A Generic Health Information Model (GHIM), defining the information elements that supply the business functionality, information elements that supply the business functionality, shall meet the needs of generic healthcare providers and shall meet the needs of generic healthcare providers and provide the basis for VHA-specific functionality which falls provide the basis for VHA-specific functionality which falls into one of two classificationsinto one of two classifications:

• Incorporation of additional data elements (e.g. military service-related attributes)

• VHA-specific instantiation (e.g. organizational structure) Generic Services recommendations/LOE are out of scope for Generic Services recommendations/LOE are out of scope for

the service access model, use of infrastructure services, the service access model, use of infrastructure services, operational aspects, or anything related to the technology operational aspects, or anything related to the technology stack (e.g. App Server, Database)stack (e.g. App Server, Database)



HEALTH INFORMATION

15


Multinational/Multilingual Extensibility Design:Multinational/Multilingual Extensibility Design: Provider User Design elementsProvider User Design elements

• Design the system to support a configurable base languageDesign the system to support a configurable base language• Enable the ability to change the default language/locale of the Enable the ability to change the default language/locale of the

systemsystem Patient User Design ElementsPatient User Design Elements

• Design HVV to support N number of languages/locales for patient Design HVV to support N number of languages/locales for patient directed informationdirected information

• For select patient-directed data elements, allow the information to be For select patient-directed data elements, allow the information to be input, stored, and retrieved in multiple languages (e.g. the default input, stored, and retrieved in multiple languages (e.g. the default language of the system, and the chosen language of the user)language of the system, and the chosen language of the user)

• Provide for the automatic conversion of weights, measures, Provide for the automatic conversion of weights, measures, currencies, etc. from the native representation of the system into the currencies, etc. from the native representation of the system into the desired representation of the user as specified by their chosen localedesired representation of the user as specified by their chosen locale

Common Design ElementsCommon Design Elements• Allow the entry and display of information using character sets Allow the entry and display of information using character sets

specific to the given localespecific to the given locale• Permit the replacement of static information elements (e.g. text, Permit the replacement of static information elements (e.g. text,

labels, prompts, icons, bitmaps, etc.) with locale-specific alternativeslabels, prompts, icons, bitmaps, etc.) with locale-specific alternatives• Allow the insertion of specialized Graphical User Interface (GUI) Allow the insertion of specialized Graphical User Interface (GUI)

widgets to handle locale specific issues such as sorting, collating, widgets to handle locale specific issues such as sorting, collating, line/character spacing, and spell checkingline/character spacing, and spell checking



HEALTH INFORMATION

16


Design: Design: Basic M/M Conversion PatternBasic M/M Conversion Pattern


Logical NameToken

DictionaryService

TokenDictionary

Service

System Locale

Token English Spanish

(i.e. Token)

Token Table

Token defines rowSystem Locale defines column

Value from table is either an actual value or a URL representing the actual value

Pattern is applicable to both provider and patient directed applications to convert static informationPattern is applicable to both provider and patient directed applications to convert static information


HEALTH INFORMATION

17


Design: Leveraging Model-View-Controller (MVC) Pattern


TokenDictionary

Service

TokenDictionary

Service

GUI(View)GUI

(View)

PresentationService(Model)

PresentationService(Model)

ApplicationService

ApplicationService

BusinessService

BusinessService

Labels, Prompts, Messages,

Icons/Bitmaps, Audio Files, Etc.

Reference DataControlled

VocabulariesLogically

ReferencedEntities

TokenLocale-SpecificRepresentation

Locale Agnostic

Locale SpecificGUI Widgets

MVC Pattern describes the architectural context for the basic conversion pattern and the inclusion of locale-specific GUI widgets

MVC Pattern describes the architectural context for the basic conversion pattern and the inclusion of locale-specific GUI widgets


HEALTH INFORMATION

18


Design: Patient-Directed Data


TokenDictionary

Service

TokenDictionary

Service

GUI(View)GUI

(View)

PatientPresentation

Service(Model)

PatientPresentation

Service(Model)

PatientApplication

Service

PatientApplication

Service

Token, LocaleLocale-SpecificRepresentation

MeasurementService

MeasurementService

OfficialVersion

TranslatedCopy

Patient Specific Information

Reference Information

Information Architecture will define which Reference Information and

Patient Specific Information is required by the Patient

WeightsWeights LengthsLengths VolumesVolumes CurrencyCurrency

Patient directed data, via the Patient ApplicationService further extends the model to providemeasurement conversion and presentation oftransactional data (EHR) in a secondary language

Patient directed data, via the Patient ApplicationService further extends the model to providemeasurement conversion and presentation oftransactional data (EHR) in a secondary language


HEALTH INFORMATION

19


Recommendations: Recommendations: Common to Both AreasCommon to Both Areas1.1. Establish the principle/policy of building generic components Establish the principle/policy of building generic components

first, VA-specific customizations secondfirst, VA-specific customizations second2.2. Build the architectural foundation (architecture Build the architectural foundation (architecture

specifications, common services, frameworks, etc.) that specifications, common services, frameworks, etc.) that prescribes how services will be constructed (i.e. HVV prescribes how services will be constructed (i.e. HVV Platform)Platform)

3.3. Create the common services to explicitly enable extensibility Create the common services to explicitly enable extensibility for both M/M and Generic Servicesfor both M/M and Generic Services

4.4. Assemble Examples and Training Material to demonstrate Assemble Examples and Training Material to demonstrate architectural or extensibility conceptsarchitectural or extensibility concepts

5.5. Train both Management and Technical StaffTrain both Management and Technical Staff6. Begin Application Development only after 1-5 are

completed



HEALTH INFORMATION

20


Recommendations: Recommendations: Multinational/Multilingual Services Design HVV to only support a single base languageDesign HVV to only support a single base language11 for all for all

provider-users of the system:provider-users of the system:The inherent risk to patient safety, timeliness and delivery of care, plus the additional associated operating costs prohibit a recommendation to support multiple languages for provider-users in a single instance of HVV.

Design HVV to support N number of secondary languages for Design HVV to support N number of secondary languages for patient directed informationpatient directed information

The value of involving the patient in care management, along side VHA success with personal health records (MyHealtheVet) strongly suggests that this is an area where the Veteran can benefit from multilingual functionality.


Enabling multilingual/multinational capability also relies on the adoption of the Generic Services recommendations

Enabling multilingual/multinational capability also relies on the adoption of the Generic Services recommendations


HEALTH INFORMATION

21


Recommendations: Recommendations: Generic ServicesGeneric Services Design Principle - “Generic Components First” Based on

defined HVV Platform Services. Architectural Model drives the Organizational Model:

• Method to achieve reuse/extensibility (internal or external) is to separate the responsibility organizationally

To achieve reuse, you must segregate it organizationally



HEALTH INFORMATION

22

HVV Extensibility

Enabling Extensibility:Enabling Extensibility: Developing a program that promotes extending HeV

Services/Components1 requires the creation of a platform from which all HeV business and application services are derived


1 This applies equally, if not more importantly, to internal HeV development


HEALTH INFORMATION

23

HVV Extensibility

Architecture Drives Organization:Architecture Drives Organization: The best method to achieve reuse/extensibility (internal or

external) is to separate the responsibility organizationally Individual competencies drive organizational alignment



HEALTH INFORMATION

24

HVV Extensibility

Model Drives Savings and Innovation:Model Drives Savings and Innovation:


Time

Effort/Cost

Generic Services

VA, Administration-Specific Extensions

Construction of HVV Platform

Initial Construction of Generic Services

Evolution of Generic Services

More funds available for VA extensions

Not shown, but none the less expected, is that a decrease in the timeline for Generic Servicescorresponds to an inverse curve depicting the industry involvement and adoption of GenericServices. The more the industry adopts the Generic Services, the more the VA can reduce costs for their continued evolution, focusing staff and funds on VA specific (or Administration specific)functionality.

Not shown, but none the less expected, is that a decrease in the timeline for Generic Servicescorresponds to an inverse curve depicting the industry involvement and adoption of GenericServices. The more the industry adopts the Generic Services, the more the VA can reduce costs for their continued evolution, focusing staff and funds on VA specific (or Administration specific)functionality.


HEALTH INFORMATION

25

HVV Platform

Build the HVV Platform:Build the HVV Platform: Create the Services FrameworkCreate the Services Framework

• Create a Services Development Kit that defines how each service is created, initialized/configured, managed, and accessed

• Multiple access paradigms should be supported including EJB local and remote access, SOAP, Messaging/MDB, local java access, etc.

Create Platform Common ServicesCreate Platform Common Services• Initialization Service• Lifecycle Service• Logging Service• Management Service• Scheduling Service (processes)• Session Service• Cache Service• Etc.



HEALTH INFORMATION

26

HVV Platform

Build Business Extensibility Common Services:Build Business Extensibility Common Services:

Extensibility can take the form of a component being extended (added onto), configured, or replaced

Replacement provides a different implementation for the given component interface (e.g. new Person Service, same interface)

Configuration requires flexibility in the design of the component to allow multiple instantiations (e.g. organizational structure) without changing the component implementation

Extension allows specialization through augmentation of the existing component interface and/or implementation


Se

rvic

e I

nte

rfa

ce

Se

rvic

e I

nte

rfa

ce

Service

Business ObjectsRules

Process FlowMessages

Events

Business Logicconsumeproduce

produce

produce

Se

cu

rity

consume


HEALTH INFORMATION

27

HVV Platform

Build Business Extensibility Common Services:Build Business Extensibility Common Services: Business Objects: Database Foundation, Data ServiceBusiness Objects: Database Foundation, Data Service Events: Event Service, Event TypingEvents: Event Service, Event Typing Messaging: Messaging Service, Transform Service, Messaging: Messaging Service, Transform Service,

Messaging FoundationMessaging Foundation Rules: Business Rules Service, Business Rules FoundationRules: Business Rules Service, Business Rules Foundation Security (RBAC)Security (RBAC)11: Security Service, Directory Service, : Security Service, Directory Service,

PermissionPermission22 Service Service Workflow: Workflow Service, Workflow FoundationWorkflow: Workflow Service, Workflow Foundation

• Business Process Management Component

1 Security in this context only includes Role Based Access Control (RBAC). Other Security functions such as Authentication, Audit, Encryption/Cryptography, Key Management, Digital Signatures, and Non-Repudiation are also required as part of a robust security service. The focus of this effort was on the business related information controlled by a Security Service (e.g. Roles and their associated privileges as manifested through access control lists that limit access to services based upon the service name, service interfaces methods, or data values/patterns within a specific interface method).

2 Permission service is logically equivalent to Authorization and Access Control Service as defined in the VHA’s Security SOA



HEALTH INFORMATION

28

HVV Multinational Extensibility Level-of-Effort Analysis Project Status

Current Status:Current Status: Project completed 3/2006. Management briefings conducted Discussion regarding “Open Source Software Development /

Deployment” underway EDM being prepared



HEALTH INFORMATION

29

Summary


Architecture &RequirementsArchitecture &Requirements

PlatformPlatform

Common ServicesCommon Services

Business Extensibility Services

Business Extensibility Services

Multilingual/Multinational Services

Multilingual/Multinational Services

Example Applications &Services

Example Applications &Services

TrainingTraining

Complete System Architecture SpecificationComplete System Architecture Specification

Design Area HealtheVet SOA Internationalize HVVComplete Information Architecture for Patientdirected informationComplete Information Architecture for Patientdirected information

Build Services Development Kit (SDK) includingService Factory Service demonstrating service Construction and use of Common Services

Build Services Development Kit (SDK) includingService Factory Service demonstrating service Construction and use of Common Services

Build Services required to support Service life cycleIncluding Initialization, Life Cycle, Logging, Session,Management, Scheduling, Cache, User Profile, etc.

Build Services required to support Service life cycleIncluding Initialization, Life Cycle, Logging, Session,Management, Scheduling, Cache, User Profile, etc.

Build the Business Object Model (BOM), DataModel, Data Services, Generic Event Model, Event Service, Messaging Service, Business Rules Service, Workflow Service, Security Service, Permission/Authorization Service, Directory Service

Build the Business Object Model (BOM), DataModel, Data Services, Generic Event Model, Event Service, Messaging Service, Business Rules Service, Workflow Service, Security Service, Permission/Authorization Service, Directory Service

Example Services: Business, Application, Data Access, and PresentationExample Application to include full software devlife cycle activities (code standards, documentation,testing, building)

Example Services: Business, Application, Data Access, and PresentationExample Application to include full software devlife cycle activities (code standards, documentation,testing, building)

Build multiple training curriculums for managementand development staff including architectural specialization courses

Build multiple training curriculums for managementand development staff including architectural specialization courses

Message Transform Service, VA-specific functionalityIncluding: BOM, Services, Rules, Messages (types,Transforms), Events, O-R mappings

Message Transform Service, VA-specific functionalityIncluding: BOM, Services, Rules, Messages (types,Transforms), Events, O-R mappings

Build Token Dictionary Service, Design GUIs andmethods retrieving reference data to use symbolicnames, build token translation tables, tokenconversion application (optional), measurementconversion services, Patient Application Services,Locale descriptions, reference data translations

Build Token Dictionary Service, Design GUIs andmethods retrieving reference data to use symbolicnames, build token translation tables, tokenconversion application (optional), measurementconversion services, Patient Application Services,Locale descriptions, reference data translations

Specific Examples demonstrating extensibility areasIncluding: extending/replacing BOM, Services, Rules, Messages, Events, and Workflow

Specific Examples demonstrating extensibility areasIncluding: extending/replacing BOM, Services, Rules, Messages, Events, and Workflow

Build specific extensibility examples to augment coretraining curriculumBuild specific extensibility examples to augment coretraining curriculum


HEALTH INFORMATION

30

Discussion

Questions/Comments?


Documents

H E A L T H I N F O R M A T I O N Brown Bag Presentation: May 9, 2006 Presenter: Bert R. Kosier De-Branded, Extensible HeV : HealtheVet-VistA Multinational