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

1. De-Branded, Extensible HeV: HealtheVet-VistA Multinational Extensibility Level-of-Effort Analysis Presentation Brown Bag Presentation: May 9, 2006 Presenter: Bert R. Kosier

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

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. • FHS HVV Multinational Extensibility LOE Analysis

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 • FHS HVV Multinational Extensibility LOE Analysis

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 • FHS HVV Multinational Extensibility LOE Analysis

6. HVV Open Source Governance Services HVV Governance Model Scope: • FHS HVV Multinational Extensibility LOE Analysis

7. HVV Open Source Governance Services HVV Sources of Change Requests: • FHS HVV Multinational Extensibility LOE Analysis

8. Direction Setting Request Initiation HVV Contributors VA HPMO Contributions Release Planning Request Processing Approval Change Management Vetting Enrollment Communications Moderation Monitoring Collaborations HVV Development Environment Change Management Full Release Release Management Direction Setting Evangelization Distribution Management Communications OpenHealth Releases Contributions (Partial Release) Environment Moderation HVV Open Source Governance Services Key Processes: • FHS HVV Multinational Extensibility LOE Analysis

9. HVV Open Source Governance Services 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 • FHS HVV Multinational Extensibility LOE Analysis

10. HVV Open Source Governance Services Automating the Change Management Process: • FHS HVV Multinational Extensibility LOE Analysis

11. HVV Open Source Governance Services Key Roles: • FHS HVV Multinational Extensibility LOE Analysis

12. HVV Open Source Governance Services 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 • FHS HVV Multinational Extensibility LOE Analysis

13. HVV Multinational/Multilingual Services and Generic Services HVV Multinational/Multilingual Services: • 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 • FHS HVV Multinational Extensibility LOE Analysis

14. HVV Multinational/Multilingual Services and Generic Services Generic HVV Services: • LOE required to design HVV services that are organizationally agnostic (i.e. allow the customization, configuration, and extension of business functionality) • Business functionality includes the following: Business Object Model/Data Model Events Business Rules Messages (inter-process communication) Processing Flow/Logic Security/Privacy Roles and Access Control • A Generic Health Information Model (GHIM), defining the information elements that supply the business functionality, shall meet the needs of generic healthcare providers and provide the basis for VHA-specific functionality which falls into 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 the service access model, use of infrastructure services, operational aspects, or anything related to the technology stack (e.g. App Server, Database) • FHS HVV Multinational Extensibility LOE Analysis

15. HVV Multinational/Multilingual Services and Generic Services Multinational/Multilingual Extensibility Design: • Provider User Design elements • Design the system to support a configurable base language • Enable the ability to change the default language/locale of the system • Patient User Design Elements • Design HVV to support N number of languages/locales for patient directed information • For select patient-directed data elements, allow the information to be input, stored, and retrieved in multiple languages (e.g. the default language of the system, and the chosen language of the user) • Provide for the automatic conversion of weights, measures, currencies, etc. from the native representation of the system into the desired representation of the user as specified by their chosen locale • Common Design Elements • Allow the entry and display of information using character sets specific to the given locale • Permit the replacement of static information elements (e.g. text, labels, prompts, icons, bitmaps, etc.) with locale-specific alternatives • Allow the insertion of specialized Graphical User Interface (GUI) widgets to handle locale specific issues such as sorting, collating, line/character spacing, and spell checking • FHS HVV Multinational Extensibility LOE Analysis

16. HVV Multinational/Multilingual Services and Generic Services Design: Basic M/M Conversion Pattern System Locale Token defines row System Locale defines column (i.e. Token) Token Dictionary Service Logical Name Token English Spanish Token Table 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 information • FHS HVV Multinational Extensibility LOE Analysis

17. HVV Multinational/Multilingual Services and Generic Services Design: Leveraging Model-View-Controller (MVC) Pattern Token Dictionary Service Locale-Specific Representation Locale Agnostic Token GUI (View) Presentation Service (Model) Application Service Business Service Locale Specific GUI Widgets Labels, Prompts, Messages, Icons/Bitmaps, Audio Files, Etc. Reference Data Controlled Vocabularies Logically Referenced Entities MVC Pattern describes the architectural context for the basic conversion pattern and the inclusion of locale-specific GUI widgets • FHS HVV Multinational Extensibility LOE Analysis

18. HVV Multinational/Multilingual Services and Generic Services Design: Patient-Directed Data Token Dictionary Service Information Architecture will define which Reference Information and Patient Specific Information is required by the Patient Locale-Specific Representation Token, Locale GUI (View) Patient Presentation Service (Model) PatientApplication Service Reference Information Patient Specific Information Official Version Translated Copy Measurement Service Patient directed data, via the Patient Application Service further extends the model to provide measurement conversion and presentation of transactional data (EHR) in a secondary language Weights Lengths Volumes Currency • FHS HVV Multinational Extensibility LOE Analysis

19. HVV Multinational/Multilingual Services and Generic Services Recommendations: Common to Both Areas • Establish the principle/policy of building generic components first, VA-specific customizations second • Build the architectural foundation (architecture specifications, common services, frameworks, etc.) that prescribes how services will be constructed (i.e. HVV Platform) • Create the common services to explicitly enable extensibility for both M/M and Generic Services • Assemble Examples and Training Material to demonstrate architectural or extensibility concepts • Train both Management and Technical Staff • Begin Application Development only after 1-5 are completed • FHS HVV Multinational Extensibility LOE Analysis

20. HVV Multinational/Multilingual Services and Generic Services Recommendations: Multinational/Multilingual Services • Design HVV to only support a single base language1 for all 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 patient 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 • FHS HVV Multinational Extensibility LOE Analysis

21. HVV Multinational/Multilingual Services and Generic Services Recommendations: Generic 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 • FHS HVV Multinational Extensibility LOE Analysis

22. HVV 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 • FHS HVV Multinational Extensibility LOE Analysis

23. HVV Extensibility Architecture Drives Organization: • The best method to achieve reuse/extensibility (internal or external) is to separate the responsibility organizationally • Individual competencies drive organizational alignment • FHS HVV Multinational Extensibility LOE Analysis

24. HVV Extensibility Model Drives Savings and Innovation: Initial Construction of Generic Services Effort/Cost Construction of HVV Platform Evolution of Generic Services More funds available for VA extensions VA, Administration-Specific Extensions Generic Services Time Not shown, but none the less expected, is that a decrease in the timeline for Generic Services corresponds to an inverse curve depicting the industry involvement and adoption of Generic Services. 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. • FHS HVV Multinational Extensibility LOE Analysis

25. HVV Platform Build the HVV Platform: • Create 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 Services • Initialization Service • Lifecycle Service • Logging Service • Management Service • Scheduling Service (processes) • Session Service • Cache Service • Etc. • FHS HVV Multinational Extensibility LOE Analysis

26. HVV Platform 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 Service Business Logic consume Business Objects produce Rules Service Interface Security Messages produce Process Flow consume Events produce • FHS HVV Multinational Extensibility LOE Analysis

27. HVV Platform Build Business Extensibility Common Services: • Business Objects: Database Foundation, Data Service • Events: Event Service, Event Typing • Messaging: Messaging Service, Transform Service, Messaging Foundation • Rules: Business Rules Service, Business Rules Foundation • Security (RBAC)1: Security Service, Directory Service, Permission2 Service • Workflow: 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 • FHS HVV Multinational Extensibility LOE Analysis

28. HVV Multinational Extensibility Level-of-Effort Analysis Project Status Current Status: • Project completed 3/2006. • Management briefings conducted • Discussion regarding “Open Source Software Development / Deployment” underway • EDM being prepared • FHS HVV Multinational Extensibility LOE Analysis

29. Design Area HealtheVet SOA Internationalize HVV Architecture & Requirements Complete System Architecture Specification Complete Information Architecture for Patient directed information Platform Build Services Development Kit (SDK) including Service Factory Service demonstrating service Construction and use of Common Services Build Services required to support Service life cycle Including Initialization, Life Cycle, Logging, Session, Management, Scheduling, Cache, User Profile, etc. Common Services Business Extensibility Services Build the Business Object Model (BOM), Data Model, Data Services, Generic Event Model, Event Service, Messaging Service, Business Rules Service, Workflow Service, Security Service, Permission/ Authorization Service, Directory Service Message Transform Service, VA-specific functionality Including: BOM, Services, Rules, Messages (types, Transforms), Events, O-R mappings Multilingual/Multinational Services Build Token Dictionary Service, Design GUIs and methods retrieving reference data to use symbolic names, build token translation tables, token conversion application (optional), measurement conversion services, Patient Application Services, Locale descriptions, reference data translations Example Applications & Services Example Services: Business, Application, Data Access, and Presentation Example Application to include full software dev life cycle activities (code standards, documentation, testing, building) Specific Examples demonstrating extensibility areas Including: extending/replacing BOM, Services, Rules, Messages, Events, and Workflow Training Build multiple training curriculums for management and development staff including architectural specialization courses Build specific extensibility examples to augment core training curriculum Summary • FHS HVV Multinational Extensibility LOE Analysis

30. Discussion Questions/Comments? ? FHS HVV Multinational Extensibility LOE Analysis