SOW Attachment A4.1 Bureau Reporting Sub System ADR.docx

AIDS Drug Assistance Program (ADAP) Data Report (ADR) Web-Based Data Entry System

Detailed Design Document Attachment A4.1

Health Resources and Services Administration Office of Information Technology 5600 Fishers Lane Rockville, MD 20857 iii

Table of Contents

List of Figures

List of Tables

Table 1: Server Specifications 11

ADR Web Application Detailed Design Document

Introduction To meet the names-based reporting requirements and to comply with the Government Performance and Results Act (GPRA), the Human Immunodeficiency Virus (HIV)/ Acquired Immunodeficiency Syndrome (AIDS) Bureau (HAB) has developed the AIDS Drug Assistance Program (ADAP) Data Reporting (ADR) web application to measure performance of the Bureau's Part B programs. The ADR supports the information and analytic needs of key decision-makers at several levels within the Bureau. The ADR data will be used for several activities related to performance, including (1) monitoring and measuring; (2) analyzing and assessing; (3) reviewing processes and taking action to improve program operations; and (4) identifying successes and problems.

A key difference between the ADR and its predecessor system, the ADAP Quarterly Reporting (AQR) is that the ADR is designed to facilitate client-level data reporting (as opposed to the aggregate data collected by AQR).

Background The ADR web application provides an online data collection and reporting system through which Grantees can report their performance data in a single submission. Grantees can submit their data once a year using the ADR web application.

Purpose and Scope The purpose of this document is to provide a detailed description of how the ADR web application is implemented as of the April 2016 release. Specifically, this document describes the following aspects of the ADR web application:

· system architecture

· software design

· database design

· external interfaces

This document describes Leidos' approach to implementing the capabilities and functions of the proposed system and satisfying all of the requirements enumerated in the ADR Requirements Definition Document.

System Overview The ADR web application allows users to enter/upload, modify, submit, and approve ADR data. Users of the ADR web application include:

· Grantees receiving funds from HAB.

· HAB’s data contractor, WRMA/CSR, Incorporated.

· HAB’s Project Officers (PO).

· HAB staff members.

· Leidos’ development team tasked with developing, testing, and maintaining the system.

· HRSA’s Operations and Maintenance contractor.

Users may access the ADR web application using a standard web browser (e.g., Microsoft Internet Explorer Version 11.0 or higher). The system servers (i.e., Web server, .Net Application server, and Database server) are hosted by the Health Resources and Services Administration's (HRSA) Office of Information Technology (OIT) department.

The ADR web application requirements are defined in detail in the ADR Requirements Definition Document. The ADR web application:

· Allows Grantee users to enter ADR Grantee report data.

· Allows Grantee users to validate ADR Grantee reports using pre-defined validation rules.

· Allows Grantee users to perform workflow tasks (e.g., submit/un-submit, approve, etc.) on ADR Grantee reports.

· Allow users to print ADR Grantee reports in Portable Document Format (PDF).

· Allow users to view and print workflow reports.

· Allow users to view and print client-level data summary reports, such as the Client-Level Data Completeness Report, the Client-Level Data Upload Confirmation Report, etc.

· Allow users to perform automatic data validation based on pre-established rules.

· Allow users to review and comment on their Grantee reports.

· Automates the workflow process of collecting, validating, and storing ADR data.

· Allows users to upload an electronic ADR client data in Extensible Markup Language (XML) format, which is compliant with the published ADR XML schemas for a given reporting period.

· Allows Project Officers to review and approve the Grantee reports.

The ADR web application employs the following technologies, as described in more detail elsewhere in this document:

· Microsoft .Net Framework 4.5 ASP.NET 4.0, C#

· Extensible Markup Language (XML)

· Microsoft Structured Query Language (SQL) Server 2012

· Microsoft SQL Server Reporting Services 2012

· Microsoft SQL Server Integration Services 2008 R2

· Microsoft Internet Information Server 7.X

· JavaScript, JQuery

· Telerik ASP.NET User Controls

· NHibernate 3.0 Document Organization After the Introduction section, this document is divided into the following sections and appendices:

1. The System Architecture section provides an overview of the hardware, software, sub-systems, associated systems, and external interfaces that comprise the HAB ADR web application.

2. The Software Design section provides a detailed description of the custom software built and maintained by the Leidos project team.

3. The Database Design section addresses the relational database that stores ADR web application data.

4. The External Interfaces section describes the various ways the ADR web application communicates with outside systems and databases.

5. The Appendices consist mostly of detailed technical diagrams and tables. These are referenced in the body of this document.

Change Control During the initial and subsequent development cycles, the technical details of the HAB ADR web application may change over time as functionality is added, enhanced, removed, or otherwise changed. Even during the application maintenance phases, the design changes from time to time. As a result, this document will remain a “living” document that the development and maintenance teams will strive to keep up to date.

Once HAB has accepted the initial version of this document, it will be considered under change control. All subsequent updates will be documented in the Document History table. HAB will be notified of all changes and will be provided an updated electronic copy of each future version.

Target Audiences This document will be principally used by two groups of software developers:

· Those who implement the ADR web application.

· Those who are responsible for enhancing and maintaining it after it has been deployed.

Assumptions This document was written based on the assumptions listed in the following section.

Data Migration, Initialization, and Database Access The following are actions necessary to prepare the system for the reporting period:

· The ADAP Medication Formulary information of the Grantees will be initialized using the previous reporting period data when users with the appropriate permissions create Grantee reports. The medication added checkbox will be cleared and the medication added date will be reset to blank.

· The ADAP Numbers of the Grantees will be consistent with the ADAP numbers used in the AQR application.

· An updated list of Grantees and deliverables will be provided in electronic form by WRMA/CSR to the Leidos development team before the deployment phase begins.

Environments, Setup, and Maintenance The following are actions necessary for environments, setup, and maintenance:

· OIT will install the operating system on the production and test web and database servers.

· The ADR web application development team will be given administrator access on all application and database servers used in this development environment.

· OIT will obtain and install Secure Sockets Layer (SSL) certificates on production and test web servers.

· OIT will do firewall configuration, as necessary, to allow secure traffic from Grantees on the internet, through the firewall to the test and production servers on the default secure port (443).

· OIT will provide sufficient computer hardware and network bandwidth to accommodate peak expected usage on the HAB database server and web application web server.

· The HRSA Electronic Handbooks (EHBs) will not implement significant changes that effect how the RSR web application will integrate with EHBs.

· End-user workstations must have, at a minimum, a Pentium 133 MHz processor with Microsoft Windows 7/8 operating systems.

· End-user workstations will be set to a screen resolution of at least 1024x768.

References The following documents were referenced in the development of the system and/or this document:

· ADR web application at https://performance.hrsa.gov/hab/AdrExternal/App/UI/adr.aspx.

· ADR Registration and Login Application at

· https://performance.hrsa.gov/hab/RegloginApp/admin/login.aspx

· The Ryan White HIV/AIDS Services Report, Requirements Definition Documents, and change requests.

· ADR Instruction Manual at https://careacttarget.org/library/adr-instruction-manual.

Design Considerations Goals and Guidelines

· Better user experience

· Navigation

· Performance

· Simplicity

· Technical

· .NET Framework 4.5

· Fluid/Responsive design

· Core application logic in application

· Parallel processing

· Asynchronous processing - server side and client

· Maintenance

· Maintainability

· Better system for troubleshooting, auditing, etc.

· Scalability

· Support for server farm/load balancing

· Integration

· Better integration with EHBs: more integration points

· Retrieve more EHBs data

· Documentation

· Simple, but complete documentation Development Methods The ADR web application development team uses an adapted Agile Scrum Development Methodology. With Agile Scrum Methodology, the Product Owner works closely with the development team to identify and prioritize system functionality in the form of a “Product Backlog”. The Product Backlog consists of many work items including features, bug fixes, and non-functional requirements. With priorities driven by the Product Owner, the team estimates and agrees to deliver increments of software during successive sprints. Once a sprint has been completed and the work items delivered, the Product Backlog is analyzed and reprioritized, if necessary, and the next set of work items are selected for the next sprint.

System Architecture Overview The ADR web application is deployed as a .NET web application. Figure 1 provides an architecture overview, including servers, clients, sub-systems, databases, and communication among them.

Figure 1: Architecture Overview

The web/application server will reside in the Demilitarized Zone (DMZ), between two firewalls. Users outside of the HRSA network (i.e., WRMA/CSR, Grantees, Vendors, Help Desk, etc.) will access the site through encrypted Hypertext Transfer Protocol (HTTP) SSL (HTTPS), communication. Users inside the HRSA network will access the site through standard HTTP requests.

The .NET application can be configured to use Microsoft State Server, running in a separate process, to maintain session information, or it can store session information in-process. The application is designed such that either of these methods can be used so that HRSA can easily scale-up the application by adding hardware without redesigning the software. As long as the application is deployed on a single application server, it will be configured to store session information in-process. If it is later determined that the system needs to boost performance or accommodate increased load, HRSA can add a load-balancer and a second application/web server. The ADR web application will be able to run unchanged in this distributed environment once the .NET Application configuration is changed to use State Server. This is especially important because HRSA is deploying multiple applications on the same server.

External Interfaces Figure 2 summarizes the ADR web application’s external interfaces. External Interfaces are described in more detail in Section 6.0. The following are five main external interfaces:

1. Email alerts are sent out for the registration process and throughout the workflow process.

2. For print-friendly ADR Grantee reports, the system uses SQL Server Reporting Services to create a PDF version of ADR.

3. Certain applications, including CAREWare, can generate ADR client-level data output files in XML format that are compliant with the HAB ADR XML schema definitions. These files are uploaded to the web application file system and processed immediately by the application and their data is moved into the ADR web application database.

4. Custom reports for HAB, WRMA/CSR, and Leidos are implemented as standard web pages in HyperText Markup Language (HTML) format.

5. Interface with HRSA’s Electronic Handbooks (EHBs) to get and update deliverable and other statuses, as well as to get Grantee contact information.

Figure 2: External Interfaces Hardware Architecture The ADR web application is deployed on four Compaq ProLiant Servers, two application servers, and two database servers. Each environment (e.g., Quality Assurance, staging, and Production) consists of one application and one database server. The production server specifications are as follows.

Production Database Server:

· HAB-DB-PROD2, virtual machine

· 4 CPUs

· 64 GB of RAM

· 150 GB hard drive for operating system

· 200 GB hard drive for structured data storage

· 100 GB for temporary storage of structured files such as backup files.

· 100 GB for unstructured data storage (e.g., MS Word, etc.)

Production Application Server:

· Perf-app-p3.hrsa.gov, virtual machine

· 4 CPUs

· 16 GB RAM

· 100 GB hard drive for operating system

· 200 GB hard drive for data storage The servers are deployed across the environments as shown in Figure 4. HRSA OIT maintains these servers.

Figure 3: Environment

HRSA OIT maintains these servers. Table 1 further describes these servers and how they are configured.

Table 1: Server Specifications

SOFTWARE SPECIFICATIONS

(Software needed to configure the database, web and application servers)

• Internet Explorer 11 or later

• Windows 2012

• MDAC 2.8

• IIS 7.5

· ODBC Drivers (for MS Access)

· Telerik for ASP.NET Control Library .NET

· AJAX Server Extensions 1.0

· ADR Web-Interface application code (provided by developers)

· Platform Lite integration code (provided by REI)

· Need at least one Administrator Account/Remote Desktop Account

* The Microsoft .NET Framework can be downloaded or execute ‘Dotnefx.exe’ from the Windows component CD. (Note: See below for detailed minimum software and hardware requirements for installing Microsoft .NET.)

HARDWARE SPECIFICATIONS

(includes 10/100/1000 NIC)

System Software Architecture The ADR web application consists of the following software components:

· Microsoft Windows 2012 standard (64x)

· Microsoft Internet Information Server 7.x

· World Wide Web (www) server

· Simple Mail Transport Protocol (SMTP) server

· Microsoft .Net Framework 4.0

· Microsoft SQL Server 2012

· Microsoft AJAX Server Extensions 1.0

· Telerik for ASP.NET

In addition, the Leidos development team is using the following development tools:

· Microsoft Visual Studio .NET 2010

· Microsoft SQL Server Management Studio 2012

· Microsoft SQL Server 2012 Business Intelligence Development Studio

· XMLSpy 2010 Professional

· ERWin from AllFusion

· ReSharper from JetBrains

· Telerik for ASP.NET User Controls

· NHibernate 3.0 – an open source Object-Relation mapper tool

Custom software developed by the Leidos development team includes:

· ADR web application.

· HRSA Performance System Registration and Login Application.

· Various Windows services that support the ADR web application.

· Various SQL Server Reports.

· SQL Server Integration services scheduled to process ADR Client level data upload and client level data aggregation.

· Gateway project to interface with EHBs on deliverables.

The ADR web application supports Microsoft Internet Explorer, Version 11.0 (and above) using the SSL protocol.

Figure 4: Software Components

Software Design The HAB ADR web application consists of various modules and sub-systems. This section addresses the development team’s approach to these various tasks. This framework is described in Section 4.2, Grantee Report Data Entry – SMARTForm.

This framework employs an “n-tiered” design approach wherein the software components are separated into multiple tiers and layers as described below.

1. HRSA Integration Layer:

a. Hrsa.Common

b. Hrsa.DataAccess

c. Hrsa.Integration.Domain

d. Hrsa.Integration.PlatformLite

e. Hrsa.Integration.PlatformLite.Service

f. Hrsa.Integration.UnitTest

g. Hrsa.Utils

h. SSRS

2. HAB Integration Layer

a. Hab.Integration

3. ADR Presentation Layer

a. Adr.Web

4. ADR Service Layer

a. Adr.Service

5. ADR Repository Layer

a. Adr.DomainModel

b. Adr.Entity

c. Adr.Specification

d. Adr.UnitTest

e. Adr.Validation

6. ADR Data Access Layer

a. Adr.DataAccess

7. ADR Cross-cut

a. Adr.Utils

8. SMARTForm Layer

a. Saic.Web.UI.Interfaces

b. Saic.Web.UI.WebControls

By separating the code into these layers, we reduce interdependencies between them. This allows each area of code to have clear, simple, and specific responsibilities on which developers can focus without needing detailed knowledge about all other components of the system. The team is able to implement clear divisions of labor and responsibility, and work together on a limited number of interfaces between system components.

The single largest area of functionality in the HAB ADR web application is data collection. The ADR data collection module is implemented with a SMARTForm approach. Generally speaking, data collection includes:

· Retrieving the appropriate data from the database.

· Rendering that data into an HTML form to display to the user.

· Validating data entered by the user on the client (i.e., web browser).

· Saving data entered by the user to the database.

· Validating data on the server.

The data collection process also relies heavily on a group of “business process classes.” The business process class is responsible for handling logic that is specific to HAB’s business needs.

Several other areas of software design are also addressed in this section. Refer to the diagrams in Appendix C for the following sections.

ADR System Components Figure 5 depicts the ADR system components.

Figure 5: ADR System Components Grantee Report Data Entry – SMARTForm See Appendix D for the SMARTForm detailed design.

Client-Level Data Upload This section describes the client level data upload process.

Client-Level XML File Check Figure 6 depicts the client-level XML file check process.

Figure 6: Client-Level XML File Check Process Client-Level XML Upload The Client-Level XML Upload process is performed by Window Service after the XML file passes the Client-Level XML Schema Check process.

ADR Workflow Figure 7 depicts the ADR workflow.

Figure 7: ADR Workflow ADR Workflow Deadlines Figure 8 depicts the ADR Workflow deadlines process, which includes the PO Reject Report process and the Set Report Extension Date after PO rejection.

Figure 8: ADR Workflow Deadlines Process Middle-Tier Service Classes ADR application has a Service Layer, which is dedicated to handle the business logics and process the actual database communications. This layer will also be shared between the ADR web application and other windows services applications to ensure same business process implemented across the system, so that the behavior from different components will be consistent. The following services are included in this middle-tier:

· Comment Service

· Email Service

· Grantee Service

· Menu Service

· Meta Data Service

· Report Service

· System Message Service

· Un-submit Report Service

· Upload Service

· Validation Service

· Workflow Service EHBs Organization Synchronization Figure 9 depicts the EHBs-HAB Organization synchronization process.

Figure 9: EHBs-HAB Organization Synchronization Process ADR ETL Process ADR utilizes the SQL Server Job “ADR ETL UCR DCR” to get an Extract, Transform, and Load (ETL) process in place to prepare data for the Upload Confirmation Report and Data Completeness Report.

For the ADR Upload Confirmation Report, aggregated data are prepared and populated in the ADR_UcrAggregateData table and the ADR_UcrAggregateMedData table with ADR_UcrCategoryLkup and ADR_UcrSubCategoryLkup tables serving as look up tables for the report. The SQL Server Reporting Service gets data from these tables to generate the Upload Confirmation Report.

For the ADR Data Completeness Report, aggregated data are prepared and populated in the ADR_DcrAggregateData table, with ADR_DcrCategoryLkup, ADR_DcrSectionLkup, and ADR_DcrSubCategoryLkup tables serving as look up tables for the report. The SQL Server Reporting Service report gets data from these tables to generate the Upload Confirmation Report.

SQL Job “ADR ETL UCR DCR” is scheduled to run every 3 minutes to check for data changes and prepare the aggregated data for these reports.

Code Base The ADR web application is a .NET application. The code includes:

· C# classes

· ASP.Net forms (only as a conduit with all the code for generating output in the C# ASP.Net code behind classes)

· XML files

· .JAVASCRIPT (.js) files

· HTML files

· HELP files

· SQL Server Database Code:

· Tables

· Lookup data

· Stored procedures

· Views

· User Functions

· Triggers

· Constraints

· Indexes

The code base is comprised of one web-based application, three back-end Windows services, a database, as well as the following:

· Adr.web.dll – This is the main web application.

· RegLogin – This web application has the code for registering users to the site and logging into the ADR web application.

· Utilities Adr.Web Namespaces / Directories Each of the namespaces under Adr.Web corresponds to a folder name in the file system. The following are the namespaces used by the ADR web application project:

· Admin - Data entry forms for administration. These all inherit from AdrBase.AdminForm or its descendants.

· Base - Base classes

· DataEntry - SMARTForm data entry file

· Configs - Web.config and other files that need to be deployed to the various environments.

· Help - AdrHelp.html and various other HTML files that are used for help.

· Images - Images for use throughout the site

· js - JavaScript files

· Logs - Log files are written here by the application.

· MasterPages

· Platform

· Reports

· Scripts

· Styles

· UC - All user control (UC) files

· UI - Such as ASPX files, AdrHandler.cs, HTML files, and a PDF template

· Utils - General utilities

· Workflow

· XML - XML files

· XMLSchema - ADR XML Schema definition files that define the client and grantee XML data file structures. Upload-able XML RSR data files, such as those generated by CAREWare and other vendor systems, are created based on these XML schema definition files.

The following files are in the root folder:

· Global.asax

· index.htm

· log4net.dll

· Web.config

For a complete list of each namespace and their files, please refer to Appendix F: ADR Web Application Namespace and Files and Appendix G: CAT Integration Layers Namespaces and Files: .

RegLogin Namespaces / Directories The RegLogin application directory structure is as follows:

Root:

· ASPX files

· global.asax

· web.config

· ADAP - ADAP specific files

· ADR - ADR specific files

· Admin - Administration related files

· AETC - AIDS Education and Training Centers (AETC) specific files

· RSR - RSR specific files

· Base - Base classes

· Help - Help files

· Images - All images used in the registration and login application

· Js - JavaScript files

· XML - XML files

· XSL - XML Stylesheet Language Transformations (XSLT) files

Database Design The database design is shown in detail in the Database Entity-Relationship Diagrams, which can be found in Appendix D, and the Data Dictionary, which can be found in Appendix E.

Ad-hoc Requests Summary Data by State Report The HIV/AIDS Bureau requires the Data and Report Technical Assistance (DART) Team to contact grantees with data completeness rates below their desired minimum completeness rates. To facilitate that task, the DART Team prepares data summary reports. These reports are sent to each grantee in advance of its outreach calls. Leidos provides the DART Team with the data required to prepare these reports.

To retrieve this data a report has been created. This report can currently be accessible on the DEV reporting server only under HAB ADR Admin reports.

Report Name: SummaryReport Stored Procedure used: adrAdmin.usp_ADR_SummaryByStateReport

External Interfaces This section describes the interfaces between the ADR application and its external interfaces.

Email Notifications Depending on each stage of the ADR Grantee report workflow, each involved Grantee, Project Officer, and ADR Administrator will be notified by email. HAB’s IIS SMTP server will send the following emails:

· When a Grantee submits an ADR Grantee Report, an email will be sent to the Grantee user and carbon copied (CC'd) to the corresponding Project Officer.

· When a Project Officer Approves or Rejects a Grantee Report, an email will be sent to the Grantee and CC'd to the Project Officer.

· When a Grantee makes/cancels an Un-submit request of the Grantee Report, an email confirmation will be sent to the Grantee and CC'd to Data Support for the un-submit approval.

· When a Grantee’s Un-submit request is approved or rejected, an email will be sent to the Grantee and CC'd to Data Support.

The email message and recipients are configurable through the Email.xml configuration file under the XML folder of the ADR web application.

EHBs Integration ADR is integrated with the EHBs through Platform Lite, a new integration framework that provides a consistent look and feel with the EHBs as well as backend integration such as deliverable status updates, etc. The version of the Platform Lite used is 2.35.25. All features of the application need to work in this framework.

A Platform Lite integration layer was created to help all Bureau Reporting Systems (BRS) to integrate with the Platform. This layer deals with general activities and functions that are common to all applications. These activities and functions include a consistent mechanism for top and left menu rendering and user authentication, etc. This layer is called the HRSA Integration Layer. Please refer to the EHBs New UI Integration Design Document for detailed design of this layer. The EHBs New UI Integration Design Document is embedded below.

Besides the HRSA Integration, which provide generic integration service to all BRS systems for their integration needs, HAB systems has its own integration layer, called HAB Integration Layer. The HAB Integration layer provides integration needs specific for HAB systems. This layer inherits from the HRSA Integration Layer and provides additional activities and functionalities such as initializing the HRSAUser object with appropriate information that is relevant to the user. Some of this information includes user contact information, report information, authorized resources of the systems, for both EHBs users and non-EHBs users, Access Control, and HAB grantee organization synchronization with the EHBs of grantee of records, report header information rendering, report initialization, etc.

The HAB Integration Layer provides integration services mainly through a base class called HabBasePage. HabBasePage inherits from the HrsaBasePage class, which is part of the HRSA Integration Layer. The HrsaBasePage class inherits from a Platform Lite base page class which ultimately inherits from the Page class of ASP.NET. The HabBasePage class is the base class of all classes that need to have access to the functionalities the base class provides. The hierarchy of the base class inheritance is shown in Figure 10.

Figure 10: HAB Base Class Inheritance

Another class in the HAB Integration Layer is a base master page called HabMainMaster. This class inherits from the HrsaMainMaster class in the HRSA Integration Layer, which inherits from the base master page that Platform Lite provides. The HrsaMainMaster class provides access to the control properties on the Master page that is provided through Platform Lite. This class also implements an interface called IHabMainMaster, which was created to facilitate the abstraction of the HAB layer integration only. The master base page inheritance hierarchy is shown in Figure 11.

Figure 11: HAB Master Page Inheritance XML Imports The ADR web application supports importing XML files for the client-level data. Each XML file must conform to the published XML schema definitions.

Client-Level XML Upload Client-level data must be uploaded and imported using an XML file that conforms to the Client-Level Data XML schema definitions. There are two formats for uploading client-level data: 1) an XML file; and 2) a Zip file containing an XML file.

The user uploads an XML file or a compressed Zip file containing a single XML client-level data file. The file is validated against the XML schema definitions. This process is referred to as the “schema check”. If the XML file fails the schema check, then the detailed information will be displayed on the web page. If the XML file passes the schema check, then it is parsed using the XmlReader class. The XmlReader class is used instead of the Document Object Model (DOM)-based XmlDocument class for performance reasons.

All client-level Data XML requests are queued in the HabAdmin.Hab_CLDUploadInfo table and are processed in the order that they are inserted into the table by a standalone Windows service, ADR.XmlImportService.

There are two different kinds of client-level data XML upload requests that users can submit. These requests are processed by ADR.XmlImportService.

1. Upload Client Level Data XML Request - ADR.XmlImportService will process a client-level data XML upload request.

2. Clear Old Data and Upload Request - ADR.XmlImportService will clear the data previously uploaded prior to processing the new upload request.

The Client-level Data XML Import process will first use a wrapper class, XmlSerializationWrapper, to de-serialize the XML data in to a client-level data XML schema based object, ROOT. ROOT is a collection of client-level data in an object base representation. The process then extracts new data records from ROOT by comparing the ClientUci field in ROOT with the ClientUci fields that are in database. If the ClientUci in ROOT does not exist in the database, the process uses the ADO.Net SqlBulkCopy class to insert the new data records into the database. If the ClientUci in ROOT matches a ClientUci in the database, the process will apply the client data merge to update the data records in the database with information from the records in ROOT.

Appendix A: Acronyms

Appendix B: Class Diagrams

This appendix contains class diagrams for classes, which support the ADR web application.

Figure 12: ADR.Web Namespace Class Diagram

Figure 13: ADR.Service Namespace Class Diagram

Figure 14: Validation Class Diagram

ADR Web Application Detailed Design Document Figure 15: Domain Model Namespace Class Diagram

Appendix C: SMARTForm Detailed Design

The SMARTForm detailed design is contained in the following embedded document.

ADR SMARTForm Design Document

Appendix D: Database Entity-Relationship Diagrams

The Entity Relationship Model is contained in the following embedded PDF file.

ADR Data Model

Appendix E: Data Dictionary

The Client Level Data Dictionary is contained in the following embedded file.

Appendix F: ADR Web Application Namespace and Files

This appendix contains files from all ADR web application namespaces.

+---Adr.BatchPrintService | | Adr.BatchPrintService.csproj | | Adr.BatchPrintService.csproj.vspscc | | Adr.BatchPrintService.sln | | AdrBatchPrintProcess.cs | | AdrBatchPrintService.cs | | AdrBatchPrintService.Designer.cs | | App.config | | log4net.config | | Program.cs | | ProjectInstaller.cs | | ProjectInstaller.Designer.cs | | ProjectInstaller.resx | \---Properties | AssemblyInfo.cs +---Adr.DataAccess | | Adr.DataAccess.csproj | | Adr.DataAccess.csproj.vspscc | | AdrRepository.cs | \---Properties | AssemblyInfo.cs +---Adr.DomainModel | | Address.cs | | Adr.DomainModel.csproj | | Adr.DomainModel.csproj.user | | Adr.DomainModel.csproj.vspscc | | Adr.DomainModel.sln | | AdrClientSchema.cs | | AdrUser.cs | | AdrWorkflowRequest.cs | | AdrWorkflowResponse.cs | | AppEnum.cs | | ClassDiagram1.cd | | CLDUploadRequest.cs | | CLDUploadReqUpdate.cs | | CLDUploadResponse.cs | | ClearCLDRequest.cs | | ClearCLDResponse.cs | | CurrentGranteeReportInfo.cs | | EhbDeliverableRequest.cs | | EhbDeliverableResponse.cs | | GranteeReportDataModel.cs | | GranteeReportModel.cs | | IEhbDeliverable.cs | | KeyValuePairInfo.cs | | ReportDataModel.cs | | ReportHeaderInfo.cs | | ReportValidationRequest.cs | | ReportValidationResponse.cs | | SingletonList.cs | | UnsubmitReportRequest.cs | | UnsubmitReportResponse.cs | | UnsubmitRequestModel.cs | | WorkflowHistoryInfo.cs | | WorkflowTaskModel.cs | +---Ehb | | EhbDeliverable.cs | | EhbUser.cs | | GranteeInfo.cs | +---Extensions | | AdrClientReportExtension.cs | | AdrClientSchemaExtension.cs | | GranteeReportDataExtensions.cs | | GranteeReportExtension.cs | | HabDeliverableExtension.cs | | ReportValidationResultExtensions.cs | | ResourceRoleRelExtensions.cs | | RoleLkupExtensions.cs | | RoleRelExtensions.cs | | StatusLkupExtension.cs | | UnsubmitStatusLkupExtension.cs | | WorkflowActionExtension.cs | | WorkflowExtension.cs | +---Properties | | AssemblyInfo.cs | +---SessionStorage | \---Specifications | AdrQuestion.cs | AdrQuestionBlock.cs | AdrSpecification.cs | AtLeastOneCheckedSpecification.cs | AtLeastOneSpecification.cs | CheckWithOtherSpecSpecification.cs | ClientDynamicChildRangeSpecification.cs | ClientDynamicInterdependentSpecification.cs | ClientDynamicRangeSpecification.cs | ConditionalAtLeastOneSpecification.cs | InterdepdentSpecification.cs | IsCheckedSpecification.cs | IsNumericAndGreaterThanZeroSpecification.cs | IsNumericSpecification.cs | OnlyOneCheckedSpecification.cs | RequiredSpecification.cs | TotalGreaterThanZeroSpecification.cs | ValidateDateRangeSpecification.cs | XorSpecification.cs +---Adr.Entity | | AcUserSecurity.cs | | AcUserSecurityMap.cs | | Adr.Entity.csproj | | Adr.Entity.csproj.user | | Adr.Entity.csproj.vspscc | | AdrClientReport.cs | | AdrClientReportAsianSubgroup.cs | | AdrClientReportAsianSubgroupMap.cs | | AdrClientReportDisenrollmentRsn.cs | | AdrClientReportDisenrollmentRsnMap.cs | | AdrClientReportHispanicSubgroup.cs | | AdrClientReportHispanicSubgroupMap.cs | | AdrClientReportInsuranceAsstRcvd.cs | | AdrClientReportInsuranceAsstRcvdMap.cs | | AdrClientReportMap.cs | | AdrClientReportMedicalInsurance.cs | | AdrClientReportMedicalInsuranceMap.cs | | AdrClientReportMedication.cs | | AdrClientReportMedicationMap.cs | | AdrClientReportNhpiSubgroup.cs | | AdrClientReportNhpiSubgroupMap.cs | | AdrClientReportRace.cs | | AdrClientReportRaceMap.cs | | AdrDisenrollmentReasonLkup.cs | | AdrDisenrollmentReasonLkupMap.cs | | AdrMedicalInsuranceLkup.cs | | AdrMedicalInsuranceLkupMap.cs | | AdrRaceLkup.cs | | AdrRaceLkupMap.cs | | AdrYesNoLkup.cs | | AdrYesNoLkupMap.cs | | AsianSubgroupLkup.cs | | AsianSubgroupLkupMap.cs | | Bookmark.cs | | BookmarkMap.cs | | CLDUploadInfo.cs | | CLDUploadInfoMap.cs | | ClearClientDetailInfo.cs | | ClearClientDetailInfoMap.cs | | ClientReport.cs | | ClientReportMap.cs | | ClientReportMedication.cs | | ClientReportMedicationMap.cs | | Comment.cs | | CommentMap.cs | | CommentTypeLkup.cs | | CommentTypeLkupMap.cs | | ControlTypeLkup.cs | | ControlTypeLkupMap.cs | | DataTypeLkup.cs | | DataTypeLkupMap.cs | | DcrAggregateData.cs | | DcrAggregateDataMap.cs | | Deliverable.cs | | DeliverableMap.cs | | DisenrollmentReasonLkup.cs | | DisenrollmentReasonLkupMap.cs | | EhbGrantUserLkup.cs | | EhbGrantUserLkupMap.cs | | EnrollmentStatusLkup.cs | | EnrollmentStatusLkupMap.cs | | EthnicityLkup.cs | | EthnicityLkupMap.cs | | FilterDataSystem.cs | | FundSrcLkup.cs | | FundSrcLkupMap.cs | | GenderLkup.cs | | GenderLkupMap.cs | | GranteeFundSrcRel.cs | | GranteeFundSrcRelMap.cs | | GranteeReport.cs | | GranteeReportData.cs | | GranteeReportDataMap.cs | | GranteeReportMap.cs | | HabPage.cs | | HabPageMap.cs | | HabRaceLkup.cs | | HabRaceLkupMap.cs | | HabReportBinary.cs | | HabReportBinaryMap.cs | | HabReportTypeLkup.cs | | HabReportTypeLkupMap.cs | | HabResourceLkup.cs | | HabResourceLkupMap.cs | | HabResourceRoleRel.cs | | HabResourceRoleRelMap.cs | | HabUser.cs | | HabUserMap.cs | | HabYesNoLkup.cs | | HabYesNoLkupMap.cs | | HispanicSubgroupLkup.cs | | HispanicSubgroupLkupMap.cs | | HivAidsStatusLkup.cs | | HivAidsStatusLkupMap.cs | | ILkupWithPriority.cs | | InsuranceAsstTypeLkup.cs | | InsuranceAsstTypeLkupMap.cs | | MedicalInsuranceLkup.cs | | MedicalInsuranceLkupMap.cs | | NhpiSubgroupLkup.cs | | NhpiSubgroupLkupMap.cs | | PageInstructionLkup.cs | | PageInstructionLkupMap.cs | | PageItemHeader.cs | | PageItemHeaderMap.cs | | PageMetaData.cs | | PageMetaDataMap.cs | | PageVisitedRel.cs | | PageVisitedRelMap.cs | | PovertyLevelLkup.cs | | PovertyLevelLkupMap.cs | | PregnancyLkup.cs | | PregnancyLkupMap.cs | | RaceLkup.cs | | RaceLkupMap.cs | | Report.cs | | ReportMap.cs | | ReportPeriodLkup.cs | | ReportPeriodLkupMap.cs | | ReportTypeLkup.cs | | ReportTypeLkupMap.cs | | ReportValidationResult.cs | | ReportValidationResultMap.cs | | ReportValidationResultView.cs | | ReportValidationResultViewMap.cs | | RequestStatus.cs | | RequestStatusMap.cs | | RoleBasedMenuMap.cs | | RoleLkup.cs | | RoleLkupMap.cs | | SexAtBirthLkup.cs | | SexAtBirthLkupMap.cs | | SMARTFormMetaData.cd | | SpecificationLkup.cs | | SpecificationLkupMap.cs | | SSRSSetting.cs | | SSRSSettingMap.cs | | StateLkup.cs | | StateLkupMap.cs | | StatusLkup.cs | | StatusLkupMap.cs | | TransgenderLkup.cs | | TransgenderLkupMap.cs | | UnsubmitRequest.cs | | UnsubmitRequestActionRel.cs | | UnsubmitRequestActionRelMap.cs | | UnsubmitRequestMap.cs | | UnsubmitStatusLkup.cs | | UnsubmitStatusLkupMap.cs | | UserRoleRel.cs | | UserRoleRelMap.cs | | ValidationCheckLkup.cs | | ValidationCheckLkupMap.cs | | ValidationRequest.cs | | ValidationRequestMap.cs | | ValidationRuleLkup.cs | | ValidationRuleLkupMap.cs | | ValidationRuleset.cs | | ValidationRulesetMap.cs | | WorkflowAction.cs | | WorkflowActionMap.cs | | WorkflowTaskLkup.cs | | WorkflowTaskLkupMap.cs | | YesNoLkup.cs | | YesNoLkupMap.cs | \---Properties | AssemblyInfo.cs +---Adr.Service | | Adr.Service.csproj | | Adr.Service.csproj.vspscc | | AdrReportPeriodService.cs | | AdrServiceFactory.cs | | AdrXmlUploadService.cs | | BatchPrintFileManager.cs | | BatchPrintService.cs | | CacheService.cs | | ClientValidationService.cs | | CommentService.cs | | DataConfiguration.cs | | EmailService.cs | | FileManagerBase.cs | | FormSection.cs | | GranteeFundSourceService.cs | | GranteeService.cs | | GrantService.cs | | HabResourceRoleService.cs | | HabUserService.cs | | MenuService.cs | | MetaDataService.cs | | ReportAccessService.cs | | ReportPeriodService.cs | | ReportService.cs | | RequestService.cs | | SsrsService.cs | | SubSection.cs | | SystemMessageService.cs | | TableHeaderItem.cs | | UnsubmitReportService.cs | | UploadService.cs | | ValidationService.cs | | WorkflowService.cs | \---Properties | AssemblyInfo.cs +---Adr.Specification | | Adr.Specification.csproj | | Adr.Specification.csproj.vspscc | | AndSpecification.cs | | ClassDiagram1.cd | | ISpecification.cs | | NotSpecification.cs | | OrSpecification.cs | | SpecificationExtensionMethods.cs | \---Properties | AssemblyInfo.cs +---Adr.UnitTest | | Adr.UnitTest.csproj | | Adr.UnitTest.csproj.vspscc | | AdrValildationTest.cs | | App.config | | BatchPrintServiceTest.cs | | ClientReportValidationTest.cs | | GetTaskRequests.cs | | GranteeReportTest.cs | | HabUserTest.cs | | LazyNHSingleSessionContext.cs | | LoadGranteeReport.cs | | LoadLeftMenu.cs | | RulesEngineTest.cs | | StatusTest.cs | | Test1.cs | | TestBase.cs | | TestReportStatus.cs | | TestResources.cs | | TestXMLDeSerialization.cs | | ValidationRuleLkupDynamicCreatedTest.cs | | ValidationRuleLkupTest.cs | | ValidationRuleTest.cs | +---Properties | | AssemblyInfo.cs | \---Specifications | AdrQuestion.cs | AdrQuestionBlock.cs | AdrSpecification.cs | AtLeastOneCheckedSpecification.cs | AtLeastOneSpecification.cs | ConditionalAtLeastOne.cs | InterdepdentSpecification.cs | IsCheckedSpecification.cs | IsNumericAndGranterThanZeroSpecification.cs | IsNumericSpecification.cs | OnlyOneCheckedSpecification.cs | RequiredSpecification.cs | SpecificationDiagram.cd | TotalGreaterThanZeroSpecification.cs | ValidateDateRangeSpecification.cs | XorSpecification.cs +---Adr.Utils | | Adr.Utils.csproj | | Adr.Utils.csproj.vspscc | | AppEnum.cs | | AppIni.cs | | ConfigAttribute.cs | | CustomIdentity.cs | | CustomPrincipal.cs | | Encryption.cs | | SendEmail.cs | | XmlUtil.cs | | XsdValidator.cs

| +---BLL

| | ContactInfo.cs | | ErrorRslt.cs | | IContactInfo.cs | | IError.cs | \---Properties | AssemblyInfo.cs +---Adr.Validation | | Adr.Validation.csproj | | Adr.Validation.csproj.vspscc | | ClassDiagram1.cd | | EntityValidatorBase.cs | | IEntityValidator.cs | | IValidationRule.cs | | SpecificationRuleBase.cs | | ValidationError.cs | | ValidationResult.cs | | ValidationRule.cs | \---Properties | AssemblyInfo.cs +---ADR.ValidationService | | Adr.ValidationService.csproj | | Adr.ValidationService.csproj.user | | ADR.ValidationService.csproj.vspscc | | Adr.ValidationService.sln | | AdrValidationProcess.cs | | AdrValidationService.cs | | AdrValidationService.Designer.cs | | App.config | | ClassDiagram1.cd | | log4net.config | | Program.cs | | ProjectInstaller.cs | | ProjectInstaller.Designer.cs | | ProjectInstaller.resx | +---Properties | | app.manifest | | AssemblyInfo.cs | \---Service References +---Adr.Web | | Adr.aspx | | Adr.aspx.cs | | Adr.aspx.designer.cs | | Adr.Web.csproj | | Adr.Web.csproj.user | | Adr.Web.csproj.vspscc | | Adr.Web.Publish.xml | | Class1.cs | | CustomDictionary.xml | | Global.asax | | Global.asax.cs | | log4net.config | | Web.config | | Web.Debug.config | | Web.Perf-test-Release.config | | Web.RCK-Release.config | | Web.Release.config | | Web.UnitTest.config | +---Admin | +---App_Data | | nhibernate.config | +---App_Themes | | \---AdrSkin | | AdrSkin.skin | +---Base | | AdrBase.cs | | CrossItem.cs | | DataEntryBase.cs | | NonDataReportBase.cs | | WorkflowBase.cs | +---ClientXml | +---DataEntry | | CldUpload.aspx | | CldUpload.aspx.cs | | CldUpload.aspx.designer.cs | | CoverPage.aspx | | CoverPage.aspx.cs | | CoverPage.aspx.designer.cs | | DataEntryClosed.aspx | | DataEntryClosed.aspx.cs | | DataEntryClosed.aspx.designer.cs | | GranteeDataEntry.aspx | | GranteeDataEntry.aspx.cs | | GranteeDataEntry.aspx.designer.cs | +---Help | | | ADR Help File.log | | | ADR_CheckYourXML.fw.png | | | ADR_ClearClients.fw.png | | | ADR_ClientUpload.fw.png | | | ADR_CoverPage.fw.png | | | ADR_Help_File.glo | | | ADR_Help_File.hhc | | | ADR_Help_File.hhk | | | ADR_Help_File.htm | | | ADR_Help_File.lng | | | ADR_Help_File.ppf | | | ADR_Help_File.stp | | | ADR_Help_File_csh.htm | | | ADR_Help_File_hha.hhk | | | ADR_Help_File_rhc.htm | | | ADR_Inbox.fw.png | | | ADR_LeftNavigationMenu.fw.png | | | ADR_Q1.fw.png | | | ADR_Q2.fw.png | | | ADR_Q5.fw.png | | | ADR_Q6.fw.png | | | ADR_Q7a.fw.png | | | ADR_Q7b.fw.png | | | ADR_Q7c.fw.png | | | ADR_Q8-10.fw.png | | | ADR_Submit.fw.png | | | ADR_UnSubmit.fw.png | | | Check_Your_XML.htm | | | Clear_Clients.htm | | | Client_Level_Data_Upload.htm | | | Comments.htm | | | Cover_Page.htm | | | cshdat_robohelp.htm | | | cshdat_webhelp.htm | | | Data_Entry.htm | | | default.css | | | ehlpdhtm.js | | | Entering_the_ADR.htm | | | Inbox.htm | | | Login_Logout_Procedures.htm | | | Merge_Rules.htm | | | Print.htm | | | Question_1.htm | | | Question_2-4.htm | | | Question_5.htm | | | Question_6.htm | | | Question_7a-c.htm | | | Question_8-10.htm | | | Reference.htm | | | Registration.htm | | | Reports.htm | | | Requesting_to_Un-Submit_the_ADR.htm | | | RoboHHRE.lng | | | SearchOptions.xml | | | Submitting_the_ADR.htm | | | Validating_the_ADR.htm | | | Validation.htm | | | Welcome_ADR.htm | | | whbrs.xml | | | whcshdata.htm | | | whcsh_home.htm | | | whestart.ico | | | whfbody.htm | | | whfdhtml.htm | | | whfform.htm | | | whfhost.js | | | whform.js | | | whframes.js | | | whgbody.htm | | | whgdef.htm | | | whgdhtml.htm | | | whghost.js | | | whhost.js | | | whibody.htm | | | whidhtml.htm | | | whiform.htm | | | whihost.js | | | whlang.js | | | whmozemu.js | | | whmsg.js | | | whnjs.htm | | | whphost.js | | | whproj.htm | | | whproj.js | | | whproj.xml | | | whproxy.js | | | whres.xml | | | whrstart.ico | | | whskin_banner.htm | | | whskin_blank.htm | | | whskin_ep_ins.xml | | | whskin_ep_start.htm | | | whskin_frmset01.htm | | | whskin_frmset010.htm | | | whskin_homepage.htm | | | whskin_info.htm | | | whskin_mbars.htm | | | whskin_pdhtml.htm | | | whskin_pickup.htm | | | whskin_plist.htm | | | whskin_tbars.htm | | | whskin_tw.htm | | | whstart.ico | | | whstart.js | | | whstub.js | | | whst_topics.xml | | | whtbar.js | | | whtdhtml.htm | | | whthost.js | | | whtopic.js | | | wht_abge.jpg | | | wht_abgi.jpg | | | wht_abgw.jpg | | | wht_abte.jpg | | | wht_abti.jpg | | | wht_abtw.jpg | | | wht_fts_h.gif | | | wht_fts_n.gif | | | wht_glo_h.gif | | | wht_glo_n.gif | | | wht_go.gif | | | wht_hide.gif | | | wht_idx_h.gif | | | wht_idx_n.gif | | | wht_logo1.gif | | | wht_logo2.gif | | | wht_next.gif | | | wht_next_g.gif | | | wht_prev.gif | | | wht_prev_g.gif | | | wht_spac.gif | | | wht_sync.gif | | | wht_tab0.gif | | | wht_tab1.gif | | | wht_tab2.gif | | | wht_tab3.gif | | | wht_tab4.gif | | | wht_tab5.gif | | | wht_tab6.gif | | | wht_tab7.gif | | | wht_tab8.gif | | | wht_toc1.gif | | | wht_toc2.gif | | | wht_toc3.gif | | | wht_toc4.gif | | | wht_toc_h.gif | | | wht_toc_n.gif | | | wht_ws.gif | | | wht_ws_g.gif | | | whutils.js | | | whver.js | | | Workflow.htm | | | xmlreadhelper.js | | +---resource | | | resource.xml | | +---WebHelp_Skin_Files | | | \---Default | | | Default.skn | | +---whdata | | | whgdata.js | | | whglo.htm | | | whglo.js | | | whidata.js | | | whidx.htm | | | whidx.js | | | whtdata.js | | | whtdata0.htm | | | whtoc.htm | | | whtoc.js | | \---whxdata | | packageindex.xml | | package_0.xml | | synonym.xml | | topictableindex.xml | | topictable_0.xml | | whfts.xml | | whglo.xml | | whidx.xml | | whtdata0.xml | | whtoc.xml | +---Images | | adobe.png | | calendarbg.png | | clearCLD.gif | | createnew.gif | | createNewReport.png | | excel.jpg | | favicon.ico | | help.png | | icon-PrinterFriendly.gif | | iconComments.gif | | iconCommentsTxt.gif | | iconCompleted.gif | | iconDataEntry.gif | | iconDoc.gif | | iconHistory.gif | | iconHistoryTxt.gif | | iconPdf.gif | | iconPdfTxt.gif | | iconPencil.gif | | iconProcess.gif | | iconProcessReturn.gif | |…