Department of Veterans Affairs Veteran’s Enterprise Management System

Download 321.93 Kb.
Date conversion29.04.2016
Size321.93 Kb.
1   ...   4   5   6   7   8   9   10   11   12


This document assumes the following:

The provider of hosting services in the cloud will support a service level agreement (SLA) that aligns with the policies of the VA and the performance metrics required by the OSDBU business unit.

The commercial off-the-shelf (COTS) software will be accepted and secured to achieve an Authority To Operate (ATO)

Call Center technology in the customer's call center can be easily integrated into the standards-based integration points for the solution. The VA security team will approve the integration of end-user identity information required by hosting the solution and the cloud.

The solution will comply with the VA-One TRM.

The solution will receive an approval from the VA's System Engineering Design Review (SEDR).

The customer and the VA's enterprise architecture teams will collaborate with the project implementation team to minimize impediments with the design, development, and deployment of the solution.

2.4.Legacy System Retirement

The design of the proposed VEMS system allows for parallel operation of the legacy system until such time that the OSDBU group confirms that the legacy system can be retired. Integration of existing VCMS data into the VEMS system will be accomplished by loading extracts of legacy data that has been mapped to match its corresponding logical entities in the new system. The project development team will leverage COTS software tools and the data integration methods available from the Microsoft CRM platform wherever possible to minimize the associated costs of extensive data integration and data cleansing efforts that will significantly reduce their workloads as a result of the design and deployment of this system.

Transition Engineering

The transition from the legacy system to the new VEMS architecture will be defined in the project’s Transition documentation. Transition planning will define the enhancements necessary to the As-Is model of the system to supports the functionality defined in the new VEMS system. This alignment will come from the process flow analysis, the definition of data/content standards, the development of ETL capabilities, and the utilization of COTS tools for data ETL and content loading (documents/attachments). Through the use of SharePoint metadata tagging, batch document loading, batch account creation, and other COTS mechanisms, we can ensure parallel operations. This will be vital for parallel system testing to ensure data quality, process flow conformance, and user acceptance.

Transition Architecture

Both Dynamics and SharePoint have the ability to batch load excel documents, PDFs, word documents, and other artifacts. This loading will be performed in batch and then incrementally as required to align with the transition plan. Documents loaded will be metadata tagged and validated to ensure no duplication and zero content loss.

For SQL Server direct data integration, the solution will use SSIS, SSAS, SSRS to validate the state of batch-loaded data and ensure conformance with data integrity, data quality, and data security requirements.

Data Integrity and Cutover Planning

Parallel planning as documented in the transition deliverable(s) will focus on ETL, content loading, automated parallel processing (to avoid redundant user activities unnecessarily), and data quality testing. Test planning will be vital to prove that the enhanced data and content processes meet all requirements, transition all legacy data, ensure zero data loss, and guarantee 100% data quality. Until these criteria are met and final user acceptance is achieved, parallel processing will be supported to guarantee provision of capabilities to users during this period.

3.Conceptual Design

This section of this document provides details about the following topics:

Conceptual Application Design

Conceptual Data Design

Conceptual Infrastructure Design.

3.1.Conceptual Application Design

Conceptual application design offers an overview of core functional components in the VEMS ecosystem without itemizing specific design characteristics or physical architecture. This is focused on logical design and what components and subcomponents of logical functionality are required to meet all VEMS requirements and gain user acceptance.

Application Context

The following figure represents a high-level context in which the solution will exist that is commensurate with the Conceptual Design required by ProPath.
application context diagram for the vems solution

Figure : Application Context Diagram for the VEMS Solution

The following table provides details for this diagram.

Table 7: VEMS Application Context Diagram




Interface Name

Interface System


VA Network

The secured VA network and collection of servers, services, and identity management accounts.

  • Active Directory Synchronization Services,

  • Secured Web services

VEMS Cloud Solution


VEMS Cloud Solution

The secured VEMS solution hosted by a FedRAMP-certified cloud provider.

VA Network


Public Internet

The unsecured public internet

  • Secured Web services

VEMS Cloud Solution

Table 8. Interfaces External to OIT



Related Object

Input Messages

Output Messages

External Party


Active Directory Federated Services

VA Network

Active Directory Synchronization Messages

Active Directory Synchronization Messages

VEMS Cloud Solution


Secured Web Services

VA Network

Secured XML-based data queries

Secured XML-based data result sets

VEMS Cloud Solution


Secured Web Services

VEMS Cloud Solution

Secured XML-based data queries

Secured XML-based data queries

  • Public Internet

  • Lexis/Nexis

  • Experian

  • D&B

  • WestLake Legal

High-Level Application Design

This High-Level Application Design identifies the major components of the VEMS solution and the relationships of the major application components to each other and to the surrounding applications. The major components of the application are at the subsystem or top-level service area. Lower-level services will be defined and documented in the Logical Application Design. Core architecture tenets include:

  • Utilization of COTS for CRM and Content Management-VEMS is being built on top of the COTS capabilities of CRM and SharePoint content management. These functions will be maximized as COTS functions to ensure maximum benefit from the defined architecture and for VA investment. This aligns with the design principles of other VA enterprise initiatives such as VRM and FCMT

  • Loose coupling across components-for all COTS and custom components, the principles of loose coupling will be utilized to maximize the possibility of further enhancements. To meet this design direction, VEMS will maximize the use of standard-based interactions and limit the use of proprietary data interchange

  • SOA-VEMS is being built to enterprise SOA standards and will act as both a service consumer and provider

    • Service consumer-Where possible, VEMS will utilize existing VA service initiatives such as BGS and MVI to consume relevant data and to ensure properly governed service utilization and minimal development and sustainment costs are incurred. An analysis of VLER services for possible reuse will be performed during further elaboration of the requirements.

    • Service provider-where functions must be developed to support VEMS requirements, VEMS will publish and act as a service provider for these functions.

Security Architecture Overview

VEMS will utilize unified identity management and will leverage MVI services for user identity, Veteran identity; the following example highlights basic MVI integration patterns.

These are the primary methods used to integrate with MVI:

1) To do an initial search (correlation) for a veteran/person between VEMS and existing authoritative systems.

2) To retrieve current ID’s for integration purposes, and display current data for a veteran/person from the existing authoritative systems.

GetCorrespondingIDs (Patient Registry Get Identifiers Query - 1309/1310)

GetCorrespondingIDs is an operation of the MVI Service, used to retrieve all known MVI Identifiers as they relate to a source identifier. The transaction grouping for this interaction is a 1309 Request and 1310 Response.

Search Person (Patient Registry Find Candidates Query – 1305/1306)

Search Person is an operation of the MVI service, used to retrieve all known MVI Identifiers as they relate to a source identifier. The transaction grouping for this interaction is a 1305 Request and 1306 Response.

There are 2 different types of 1305 Request that can be submitted for this operation:

Match criteria in queryByParameter, with person trait data to be searched for in parameterList.

Correlation identifier in parameterList – either ICN or IEN (one or the other, but not both). No person trait data is supplied for this type of request. These two types of requests differ in format and content of the queryByParameter element, as described below. Both request types return a 1306 Response.
There is also another option to a 1305 Search Person request. This 1305 Search Person request will return the results from a call to 1309 GetCorrespondingIDs if the person is found. This option eliminates the need to make a separate call to GetCorrespondingIDs later in a session. The 1305 Search Person call with the GetCorrespondingIDs results is referred to in this document as a 1305 Search Person Composite call. This call can only be made as an unattended search.

Auditing in CRM

Microsoft Dynamics CRM provides an auditing capability where entity and attribute data changes within an organization can be recorded over time for use in analysis and reporting purposes. Auditing is supported on all custom and most customizable entities and attributes. Auditing is not supported on metadata changes, retrieve operations, export operations, or during authentication.

The following list identifies the supported auditing features for Microsoft Dynamics CRM:

  • Audit of customizable entities

  • Audit of custom entities

  • Configure entities for audit

  • Configure attributes for audit

  • Area wise auditing

  • Privilege based audit trail viewing

  • Privilege based audit summary viewing

  • Audit log deletion for a partitioned SQL database

  • Audit log deletion for a non-partitioned SQL database

  • Microsoft Dynamics CRM SDK programming support

  • Audit of record create, update, and delete operations

  • Audit of relationships (1:N, N:N)

  • Audit of audit events

  • Audit of user access

  • Adherence to regulatory standards

The following list identifies the data and operations that can be audited:

  • Create, update, and delete operations on records

  • Changes to the shared privileges of a record

  • N:N association or disassociation of records

  • Changes to security roles

  • Audit changes at the entity, attribute, and organization level. For example, enabling audit on an entity.

  • Deletion of audit logs

When (date/time) a user accesses Microsoft Dynamics CRM data, for how long, and from what client

Desktop Virtualization

VEMS will utilize desktop virtualization (Citrix XenApp) to provide unified desktop capabilities for case management functions. In order to unify and secure all of the components including Outlook, Lync/LiveMeeting, call center, etc. into a seamless desktop in a cloud hosted environment, the desktop will be published to ensure a unified experience for the users with fully controlled access.

This functionality will minimize the opportunities for data leakage and will provide a consistent user interface for creating and editing Microsoft Office documents. These documents will be stored on virtualized network drives and/or in the VEMS document management repository (SharePoint).

VEMS Application Architecture Diagrams

The following diagrams and component/interface summaries show the components and subcomponents that comprise the VEMS solution.

application context diagram for the vems solution Figure : Application Context Diagram for the VEMS Solution

The following table provides details about the entities and interfaces presented in this diagram.

Table 9: Objects in the High Level Application Design



External Interface Name

External Interface ID

Internal Interface Name

Active Directory Federation Services

Synchronizes secured identity management systems


VA AD FS Services

  • Active Directory Federated Services


Lookup identity and corresponding system IDs



  • MVI

Outlook plugin or web interface

Presents data to the end user compliant with the devices/systems requesting data

Presentation-Centric Secured Web Services


  • Presentation Services

Security Services

Authorizes and Authenticates requests for data to end users and external systems

Security-centric Web Services


  • Active Directory Federated Services

  • Data Aggregation Services

MS Office Suite

The Microsoft Office Productivity Suite, including Outlook, Word, Excel, and PowerPoint


  • Active Directory Federated Services

  • Presentation Services,

  • Analytical Services

  • Persistent Storage Services (Email, Document Management, and SQL)

MS Dynamics CRM Services

The Microsoft Dynamics CRM application and services



  • CRM Services

MS SharePoint

SharePoint content management and document storage



  • SharePoint Services

CRM Plug-ins

Functionality-specific software components to the Dynamics application



  • PowerSearch

  • eSignature

Analytical Services

Software components to deliver business intelligence functionality on CRM-related data and process metrics



  • CRM Analytical Services

Email Routing Services

Software components to integrate email to the CRM services



  • Microsoft Email Router for Dynamics CRM

Data Aggregation Services

Secured data services to retrieve VEMS-specific data for integration in to the verification process and the VEMS databases

VEMS Data Aggregation Services

VEMS Data Aggregation Services

  • SAM Web Services

  • Lexis/Nexis Web Services

  • Experian Web Services

  • Dun & Bradstreet (D&B) Web Services

  • WestLaw Legal Web Services

Table 10: Internal Data Components



Data Stored




Email Storage

Email and email attachments

VEMS Cloud Provider

Create, Retrieve, Update, Delete


Document Storage

Digital Documents

VEMS Cloud Provider

Create, Retrieve, Update, Delete


Structured Data

Structured data and related metadata

Process metrics

Workflow rules

VEMS Cloud Provider

Create, Retrieve, Update, Delete

The following diagram demonstrates the subcomponent architecture that creates the VEMS ecosystem and identifies major interaction points and interfaces.

vems component architecture

Figure : VEMS Component Architecture
Major data interactions include but are not limited to:

Table 11: Major Data Interactions and Payloads

System A

System B

Interaction/Payload Content

VIP Portal Website

VIP Application Services


VIP Application Services

VIP Database

Staging and cache data

VIP Application Services

External Validation Services

SOAP/REST Services

Published Desktop (Citrix)



VIP Application Services


Content Management (docs, attachments)

VIP Application Services


Content Management (docs, attachments)

TS Quality

Dynamics CRM

Content Management (docs, attachments) with OCR content and metadata

Dynamics Application Server

AutoMerge for Dynamics

CRM entities, MS Word documents

Dynamics Application Server

B-S Connects for Dynamics

VOIP data

Dynamics Application Server


Mail integration

Dynamics Application Server


Instant Messaging Integration

VEMS Components


Authentication and Authorization Services

Dynamics Application Server


Content Management

Application Locations

The VEMS hosting solution will based on a Cloud Computing Model as defined in National Institute of Standards and Technology (NIST) Special Publication 800 145, “The NIST Definition of Cloud Computing.” The VEMS application will be hosted in a cloud location that meets a FISMA Security Categorization of Moderate. The datacenter(s) hosting the VEMS servers will meet the VA Information Assurance (IA) requirements and obtained a FedRAMP Provisional ATO to ensure FISMA Moderate security controls are implemented and certified by a FedRAMP-approved Third Party Assessment Organization (3PAO).
The VEMS application cloud solution will utilize both Infrastructure as a Service (IAAS) and/or Platform as a Service (PaaS) hosting services from the cloud provider in order to minimize l costs to sustain computing, network, storage, server, and operating system hardware/software components. Each separate VEMS application environment -- Development, Preproduction, and Production -- will be managed in the cloud to maintain consistent deployment, operations, maintenance, and upgrades throughout the application lifecycle. VEMS will use these benefits to utilize network access from a heterogeneous mix of thin or thick client platforms (mobile phones, tablets, laptops, and workstations) and access cloud services measured by resource usage such as bandwidth, processing, storage, and number of active user accounts.
The VEMS cloud architecture will incorporate a hybrid deployment model that includes both public cloud services to SDVOSB as well as private cloud capability for VA internal administration, and external VA partners. The hybrid structure allows for separate private cloud network transmissions between the cloud provider and VA community networks that adhere to signed interconnection security agreements ensuring secure transmission and information system access controls are strictly enforced. For example, the VA call center VoIP network will have an interface to VEMS web services for interacting with the user community and have its own interconnect security agreement with the VEMS system.
The cloud location hosting provider must sign SLAs to ensure that VEMS data remains secure and available while adhering to all VA data protection regulations. Cloud provider security mechanisms will be enforceable to protect VEMS personally identification information (PII) transactions through FIPS 140-2 approved data encryption in transit, in use, and at rest. The cloud services model itself is designed to have inherent availability mechanisms through systems virtualization, redundant backup systems, and disaster recovery processes that are each independently verified and validated during the FedRAMP ATO accreditation process.
The cloud service cost model characteristics appeal to the need to balance the application usage costs over time using a ‘pay on demand’ approach versus spending a large amount of initial funds on hardware, software and staff to manage datacenter services. Moreover, using a cloud services model will be enable the VA to allocate common IT costs per VEMS system usage across internal VA office units, VEMS Government agency partners, and VEMS commercial partners. This usage model provides flexible options for more predictable budgeting activities in future years of operation. In addition, the VEMS information system will inherit a large number of security control protections from the cloud services FedRAMP certification that will reduce the costs of the compliance-related authorization for VEMS and IA sustainment.

Application Users

Many users will have access to the VEMS system to participate in the verification process. The users are listed below along with a brief description and an indication of if they are internal to the VA or external. Each type of user will access each component of the system with the exception of the users that are external to the VA. These users will not access the Microsoft Dynamics CRM components.

Table 12: Application Users



VA Internal or External

      1. Veteran

As the owner of the business entity requiring verification, the Veteran is the initiator of the verification process and responsible for ensuring that the CVE team has sufficient and verifiable information to process a verification application successfully.


      1. Enrollment Counselor

An individual from a preselected and trained group of subject matter experts who assist Veterans with the information requirements and education about the verification process.


      1. Business Owner

A senior stakeholder in a business; for the verification process often ‘the Veteran’ or a designated proxy. Also, someone who is interested in the verification process and seeks more information prior to submitting an application for verification. The Business Owner is used as the primary Actor in this document because not all applicants are Veterans and this usage allows us to refer to one actor without condition.


      1. Initiator

A CVE team member who is responsible for collecting and verifying the Veteran’s application prior to review by CVE team members. Initiators want to minimize data errors or omissions during the application process that will affect the team’s ability to determine a business’s applicability for a successful CVE determination.


      1. Pre Screener

A CVE team member who is responsible for the first look at the Veteran’s application when it is submitted.

      1. Initiation Supervisor

A CVE team member who is responsible for a staff of Initiators and Pre Screeners. This actor’s goal is to oversee the process of verifying the Veteran’s application.

      1. Examiner Level 1

A CVE team member who is responsible for an initial review of an applicant’s documentation.

      1. Examiner

A CVE team member who is responsible for preparing the applicant’s documentation and performing an initial risk assessment prior to review by the CVE team members.


      1. Examination Supervisor

A CVE team member who is responsible for a staff of Examiners. This actor’s goal is to oversee the process of accepting and verifying application and performing preliminary guidance on the applicant’s data.


      1. Evaluator

A CVE team member who is responsible for reviewing the applicant’s business regarding legal, policy, and relevant risk parameters. The goal of this actor is to prepare the legal argument for the recommended disposition.


      1. Evaluation Supervisor

A CVE team member who is responsible for a staff of Evaluators. This actor’s goal is to oversee the process of reviewing the applicant’s business regarding legal, policy, and relevant risk parameters.


      1. Site Visitor

A CVE team member responsible for visiting the business on-site to research compliance with VOSB and SDVOSB regulations.


      1. Site Visit Coordinator

A CVE team member who is responsible for a staff of Site Visitors and for coordinating the schedule of on-site visits.


      1. Federal Reviewer

A government-employed CVE team member acting as a reviewer who reviews the recommendations and predetermination activities of a contracted employee on the CVE team. The goal of this actor is to provide government oversight and extra verification of eligibility work performed by a team member who is not a federal employee.


      1. Risk Manager

A CVE team member who is responsible for evaluating and mitigating risk in the companies applying for certification.


      1. Risk Management Supervisor

A CVE team member who is responsible for a staff of Risk Managers. This actor’s goal is to oversee the process of evaluating and mitigating risk in companies applying for certification.


      1. Customer Support Representative

A CVE team member who engages with the applicant (or their designated proxy) to answer questions about the data, the verification process, and the technical aspects of the data submission process.


      1. Customer Support Supervisor

A CVE team member who is responsible for a staff of Customer Support Representatives. This actor’s goal is to oversee the process of engaging with the applicants to answer questions and provide support.


      1. Quality Assurance Staff Member

A CVE team member who is responsible for ensuring the quality of the processes and procedures of the CVE organization.


      1. Auditor

A CVE team member who is responsible for auditing the CVE teams to ensure they are complying with their documented processes and procedures.


      1. Quality Assurance Supervisor

A CVE team member who is responsible for a staff of Quality Assurance Staff Members and Auditors. This actor’s goal is to oversee the process of ensuring the quality of the processes and procedures of the CVE organization and that CVE teams are complying with their documented processes and procedures.


      1. CVE Deputy Director

A CVE team manager who is responsible for the policies, procedures, and operations of various CVE teams.


      1. CVE Director

A CVE team executive who can provide direction and executive signature to verification process determinations.


      1. CVE Executive Director

A CVE team executive who can provide direction and executive signature to verification process determinations.


      1. Office of General Council Staff

A member of the Office of General Counsel organization who represents the VA in legal matters.


      1. VA Contracting Officer

A VA employee tasked with collecting data from and evaluating prospective business owners to satisfy a business need. The VA Contracting Officer offers solicitations to business owners (or their designated representatives) for proposals to solve business needs for the VA.

1   ...   4   5   6   7   8   9   10   11   12

The database is protected by copyright © 2016
send message

    Main page