SOW Attachment A4.4 Bureau Reporting Sub System RSR.docx

Ryan White HIV/AIDS Services Reporting (RSR) Web Application Project Detailed Design Document

Attachment A.4.4

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

RSR Web Application Detailed Design Document

Table of Contents

List of Tables Table 1: Server Specifications 14

List of Figures

RSR Web Application Detailed Design Document iii

Introduction The Human Immunodeficiency Virus (HIV) / Acquired Immunodeficiency Syndrome (AIDS) Bureau (HAB) developed the Ryan White HIV/AIDS Services Reporting (RSR) web application to measure performance of the Bureau's Part A, B, C, and D programs. In addition, it was developed to meet the names-based reporting requirements of the Ryan White Treatment Modernization Act of 2006 and to comply with the Government Performance and Results Act (GPRA). The RSR supports the information and analytic needs of key decision-makers at several levels within HAB. The RSR data is 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 RSR application and its predecessor system, the Ryan White Data Report (RDR), is that the RSR is designed to facilitate client-level data reporting as opposed to the aggregate data collected by the RDR.

Background The RSR web application provides an online data collection and reporting system through which grantees and providers, funded under Parts A, B, C, and D of the Ryan White legislation, can report their performance data annually. Rather than submitting data separately under each part, providers funded under multiple program parts can submit their data in a single submission.

The RSR web application:

· Allows users to enter and modify RSR data through a standard web browser.

· Allows users to generate RSR reports in printer-ready portable document format (PDF).

· Performs automatic data validation based on pre-established rules.

· Allows grantees to review and comment on their providers’ entries, and to accept provider submissions or return them for changes.

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

· Allows electronic uploads of RSR reports in Extensible Markup Language (XML) format, which is compliant with the published RSR XML schemas for a given reporting period.

All entered data is stored in a central database located on a server administered by Health Resources and Services Administration’s (HRSA) Office of Information Technology (OIT).

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

· System Architecture

· Software Design

· Database Design

· External Interfaces

This document describes Leidos' approach to implement the capabilities and functions of the proposed system and to satisfy all of the requirements enumerated in the RSR Requirements Definition Documents.

System Overview The RSR web application allows users to enter/upload, modify, submit, and approve RSR data for Part A, B, C, D grants with activity codes of H12, H76, H89, and X07. Users of the RSR web application include:

· Grantees receiving funds from HAB.

· Providers who provide services funded by HAB grants.

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

· HAB staff members.

· Leidos’ development team tasked with building and maintaining the system.

· HAB’s Project Officers (PO).

Users access the RSR web application using a standard web browser (i.e., Microsoft Internet Explorer [IE] Version 11.0). The system servers (i.e., Web Server, .Net Application Server, and Database Server) are hosted by HRSA’s OIT.

The RSR web application requirements are defined in detail in the RSR Requirements Definition Documents. The following summarizes the functionality of the RSR web application:

· Enter RSR Grantee and Provider Report data.

· Import RSR client-level data.

· Validate RSR Grantee and Provider Reports using pre-defined validation rules.

· Perform workflow tasks (i.e., Submit/Un-submit, Accept, Reject, Approve, etc.) for RSR Provider Reports.

· Print RSR Grantee and Provider Reports in PDF format.

· View and print workflow reports.

· View and print client-level data summary reports, such as the Client Data Completeness Report and the Client Data Upload Confirmation Report.

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

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

· XML and Extensible Stylesheet Language Transformation (XSLT)

· Microsoft SQL Server 2012

· Microsoft SQL Server Reporting Services (SSRS)

· Microsoft Internet Information Server 7.x

· JavaScript

· Infragistics NetAdvantage ASP.NET User Controls

· NHibernate

· Bootstrap Document Organization This document is divided into several sections and appendices:

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

· The Detailed System Design section provides a detailed description of the custom software built and maintained by the Leidos Development team.

· The Database Design section addresses the relational database that stores RSR web application data.

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

· 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 RSR web application changed 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 will be a “living” document that the Leidos team will 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. OIT and 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 used by two main groups of software developers:

· Implementers of the RSR web application.

· Maintainers of the RSR web application after it is deployed.

This document will be reviewed by HRSA and Leidos managers responsible for overseeing the project.

Assumptions This document was written based on the following assumptions.

The following assumptions relate to the actions necessary to prepare the RSR web application for the reporting period and to cover data initialization and database access:

· An updated list of Part A, B, C, and D Grantees and deliverables will be provided in electronic form by WRMA/CSR to the development team before the deployment phase begins.

· The RSR Grantee Report list of providers and services will be initialized for all grantees.

The following assumptions were also made regarding environments, setup, and maintenance:

· OIT will install the operating system on the Production and other environment web and database servers.

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

· OIT will obtain and install Secure Sockets Layer (SSL) certificates on Production and other environment web servers.

· OIT will do firewall configuration, as necessary, to allow secure traffic from providers and grantees on the Internet, through the firewall to the Production and other environment servers on the default secure port (i.e., 443).

· OIT will provide sufficient computer hardware and network bandwidth to accommodate peak expected usage on the RSR database server and web application 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 a Microsoft Windows XP operating system.

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

References The following documents were referenced in the development of this document:

· RSR Web Application: https://performance.hrsa.gov/hab/RsrExternal/App/UI/rsr.aspx

· RSR Registration and Login Application: https://performance.hrsa.gov/RegLoginApp/Admin/Login.aspx

· The Ryan White HIV/AIDS Services Report Requirements Definition Documents and Change Requests.

· RSR Instruction Manual available in Adobe Acrobat Reader format at https://careacttarget.org/library/ryan-white-hivaids-program-services-report-rsr-instruction-manual

Design Considerations Goals and Guidelines

· Better user experience

· Navigation

· Performance

· Simplicity

· Support the three main browsers: IE, Chrome, and Firefox

· Technical

· .NET 4.5

· Object-Oriented Programming (OOP) – Follow Single responsibility, Open-closed, Liskov substitution, Interface segregation, and Dependency inversion (SOLID) design principles

· Service-Oriented Architecture (SOA) – Distributed architecture that allows machine to machine client data upload, upload confirmation report, and data completeness report using WCF Streaming capability

· Unit test coverage: 50%

· HTML5 - WebSocket

· 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 RSR 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.

Architectural Strategies SOA Ready Application The RSR web application is an SOA ready application. SOA is a software design and software architecture design pattern based on distinct pieces of software providing application functionality as services to other applications.

The RSR web application will have a service layer, which will consist of different service modules such as the Client Upload Service. Each of the services is designed and developed in a way that allows the services to be accessible through Windows Communication Foundation (WCF) services for future enhancement. Some of these services include client data upload, validation, and reporting.

The RSR web application can use the internal service directly or use it through the WCF service passing required credentials. If using it through the WCF service, security will be enforced and provided through WCF’s strong built-in security features. WCF comes with strong out of the box security features including transfer security, access control, and auditing.

Figure 1 depicts the proposed RSR web application architecture.

WCF

TRAX

CAREWare Other Vendors with Authentication Authorization

SSL

with Authentication

SSL

RSR

Presentation Layer UI Components Logging Utils Exception Handling Business Layer Cross cutting EHBs Gateway Data Services Services Authenti cation Authoriz ation Validation Workflow Data Process Entities Domain Objects Data Layer

SQL

Server Data Access

SSRS

Integration Windows Services Validat ion Service Client Upload Service Email Service EHBs Request Service Wraps Client Validation Service Client Validation Service Wraps Client Upload Service Client Upload Service Wrapper More Services Authorization

Figure 1: RSR Application Architecture

The following approach was used to implement the SOA for the RSR web application:

Step 1: Design and code each main module as an internal service. The RSR web application will consume these services directly. These internal services are designed to be used in the future by outside consumers.

Step 2: Develop the WCF service to expose the services that need to be exposed. The service will require extra security such as username and password.

Step 3: Develop a guide and code samples for vendors who may want to use the WCF service.

Step 4: Vendors modify their applications to consume the WCF service.

The following benefits may be gained by using SOA for the RSR web application:

1. Logic in services will be written only once as part of the RSR solution, but it can be available to different applications/vendors.

2. The vendors will have the option to use the Client Upload Service to develop a batch upload feature in their application.

3. Provider/Grantee users using an application programmed with the WCF service can upload their client data directly from the vendor application rather than having to generate XML files and upload through the RSR web application.

Leidos developed the RSR web application as an SOA ready application (refer to Step 1). Becoming an SOA ready application will make RSR more flexible, easier to provide more features to users, and potentially available for Business-to-Business (B2B) features.

Shared HAB Administrative Feature The Administrative features like downloading a log file, user management, and system message posting are directly accessible from the RSR web application as well as from other HAB web applications.

System Administrators, Data Support, and HRSA Contact Center (HCC) users have access to the administrative feature area of the RSR web application.

System Architecture The RSR web application is deployed as a .NET application.

Overview Figure 2 provides an architecture overview, including servers, clients, sub-systems, databases, and the communication between them. The web/application server will reside in the Demilitarized Zone (DMZ), between two firewalls. Users outside of the HRSA network (e.g., WRMA/CSR, grantees, providers, Help Desk, etc.) will access the site through encrypted Hypertext Transfer Protocol (HTTP) SSL, or Hypertext Transfer Protocol Secure (HTTPS) communication. Users inside the HRSA network will access the site through standard HTTP requests.

Figure 2: Architecture Overview

The .NET application may 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 so either of these methods can be used and 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 RSR 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.

The RSR web application will allow some users to upload electronic versions of their RSR data in XML format through the site.

External Interfaces Figure 3 summarizes the application’s external interfaces. External interfaces are described in more detail in Section 7 of this document. There are five main external interfaces:

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

2. For print-friendly RSR Provider and Grantee Reports, the system uses SSRS to create a PDF version of the RSR.

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

4. Custom reports for HAB, WRMA/CSR, and Leidos are implemented as SSRS ReportViewer reports.

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 3: External Interfaces Hardware Architecture The RSR 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 4: Environment

Table 1 further describes these servers and how they will be configured.

Table 1: Server Specifications

SOFTWARE SPECIFICATIONS

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

• Internet Explorer 9 or later

• Windows 2012

• MDAC 2.8

• IIS 7.x or later

· ODBC Drivers (for MS Access)

· Infragistics NetAdvantage for ASP.NET Control Library .NET 2008 Vol. 3 CLR 2.0

· AJAX Server Extensions 1.0

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

· Platform Lite integration code (provided by a HAB Contractor)

· Need at least one Administrator Account/Remote Desktop Account

· .NET runtime 2.0 – 4.0

* 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

Application Server

VWare

System Software Architecture The RSR web application consists of the following software components, which are illustrated in Figure 5:

· Microsoft Internet Information Server 7.0

· 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

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

· Microsoft Visual Studio .Net 2010.0 for SQL Server Reports

· Microsoft Visual Studio .Net 2012

· Microsoft SQL Server Management Studio 2012

· XmlSpy 2010 Professional

· ERWin from CA

· Telerik Controls

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

Custom software developed by the Leidos Development Team includes:

· RSR Web Application

· HRSA Performance System Registration and Login Application

· Configurable Data Conversion Application

· Various Windows services that support the RSR Web Application

· Various SQL Server Reports

The RSR web application supports Microsoft Internet Explorer Version 11.0, Google Chrome, and Mozilla Firefox using the SSL protocol.

Figure 5: Software Components RSR Application Layers The RSR web application consists of the following six layers:

1. HRSA Integration Layer: Provides generic integration service to all BRS systems.

2. HAB Integration Layer: Provides common integration needs specific to all HAB systems.

3. RSR Presentation Layer: Contains RSR web application user interfaces.

4. RSR Service Layer: Contains all RSR specific services modules.

5. RSR Domain Layer: Defines all RSR business domain objects.

6. RSR Infrastructure Layer: Contains all crosscuts, utilities, etc.

The HRSA Integration Layer provides generic integration service to all BRS systems.

HAB systems have their own integration layer, called the HAB Integration Layer. This layer provides integration needs specific for HAB systems and inherits from the HRSA Integration Layer. In addition, the HAB Integration Layer provides additional activities and functionalities such as initializing the HrsaUser object with appropriate information that is relevant to the user. This information consists of user contact information, report information, authorized resources of the systems (both EHBs users and non-EHBs users), access control, 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. This class 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 that are provided by the base class. The hierarchy of the base class inheritance is shown in Figure 6.

Figure 6: 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. This class provides access to the properties of the controls on the Master page that is provided through Platform Lite. It also implements an interface called HabMainMaster, which is created to facilitate the abstraction of the HAB layer integration only.

The master base page inheritance hierarchy is shown Figure 7.

Figure 7: Master Base Page Inheritance Subsystem Architecture Subsystem architecture consists of the following services:

· RSR Client-level Data Upload Windows Services

· RSR Validation Windows Service

· RSR Batch Print Windows Service

· HAB Email Process Windows Service

· EHBs Request Windows Service

Detailed System Design The RSR web application consists of the following components:

1. Grantee Contract Management System (GCMS)

2. Client-level Data Upload Engine

3. Validation Engine

4. Workflow Engine

5. EHBs Request Engine

6. Email Engine Grantee Contract Management System (GCMS) RSR grantee users access the GCMS module through the RSR web application to add/update contracts between grantees and providers.

Responsibilities GCMS stores the central source of data for HAB grantee contracts.

Constraints All grantee contract information is maintained in GCMS, and information will be synchronized to the RSR by a grantee user on the Program Information page.

Uses/Interactions The GCMS user interface is developed in the UserControls project as user controls, which are shared by multiple applications (e.g., Program Terms Report [PTR], RSR, and Expenditures Report).

Resources GCMS initial contracts data are populated from RSR for Part C and D, and from PTR for Part A and B. Grantee users will continue to use GCMS as a central source location to enter and maintain the contract data.

Processing HAB contract data are centrally stored in GCMS. When an RSR grantee report is created, a copy of the contract data that overlaps the RSR reporting period will be copied over to RSR and stored in the RSR Contract tables. RSR grantees will be prompted to review the contract data once any difference is detected between RSR and GCMS after the grantee report creation. Grantee users have a choice to synchronize or not to synchronize the difference.

Client-level Data Upload Engine Responsibilities The Client-level Data Upload Engine allows users to upload client-level data XML files and generate Client-level Data Reports as an outcome.

Constraints Client-level data must be uploaded and imported using an XML file that conforms to the client-level data XML schema definitions. Users can upload a single client-level data XML file. If the file is a compressed Zip file, then a directory is created based on the user’s organization and the content is extracted into this directory after deleting any existing XML files, but preserving any existing ZIP files.

Uses/Interaction Users will be redirected to the RSR Client-level Data Upload page to upload their client-level data.

Processing The RSR Client-level Data Upload page will validate the uploaded XML file against the XML schema definitions. This process is referred to as the “schema check.” If it fails the schema check, the user is notified with an error message that is shown on the screen, which is being used to upload client-level Data.

All client-level data XML requests are queued in HabAdmin. The HAB_CldUploadRequest table records the requests and requests are processed in the order that they are inserted into the table by a standalone Windows service, Leidos RSR ClientUpload 2015 v1.0.

The following three (3) different kinds of client-level data XML upload requests can be submitted by users and processed by the Client-level Data Upload Engine:

1. Upload Client-level Data XML Request – Client-level Data Upload engine will process a client-level data XML upload request.

2. Clear Data by Organization User Request – Client-level Data Upload engine will clear the data that were previously uploaded by the organization and reprocess all upload requests that were previously made except the ones selected by the organization who made the Clear Data by Organization User Request.

3. Clear Data by System Administrator Request – System Administrators can see all previous upload requests and select which data files that s/he wants to remove. The Client-level Data Upload Engine will clear the data that were previously uploaded and reprocess all upload requests that were previously made except the ones selected by the System Administrator who made the Clear Data by System Administrator Request.

The Client-level Data Upload Engine will first use a wrapper class, XmlSerializationWrapper, to de-serialize the XML data into 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 the 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 functionality to update the data records in the database with information from the records in ROOT based on the HAB merge rules.

After completing the processing of a XML upload request, the Client-level Data Upload Engine will generate the following reports for each individual upload request as well as for the entire set of reported data:

· Upload Confirmation Report

· The Upload Confirmation report reflects aggregate data that resulted from the upload.

· After the XML data for each upload request is processed by the Client-level Data Upload Engine, the RSR web application will aggregate the data and provide the total count and percentage for each data element.

· Data Completeness Report

· The Data Completeness Report provides details on the completeness of the uploaded client-level data.

· After the XML data for each upload request is processed by the Client-level Data Upload Engine, the RSR web application will aggregate the data and provide the statistic for each data element.

· Validation Report

· The Validation Report reflects the compliance of uploaded data with the defined validation rules. From the Validation Report, users can easily and quickly identify the errors in their data and how to fix them. Users can correct and re-upload the corrected XML until they determine that they are ready to submit the data to HAB.

· After the XML data for each upload request is processed by the Client-level Data Upload Engine, the RSR web application uses the Validation Engine to validate the data against a list of check codes.

Validation Engine Responsibilities The Validation Engine is designed to validate the Grantee Report, the Provider Report (Including the Client Report), and the Check Your XML Report.

Processing Each Validation Rule is defined as a Check Code. Grantee Reports, Provider Reports, and client-level data files, all have their own Check Code lists. The Validation Engine will use the “Report Id” to figure out the right report type and load up the corresponding list of Check Codes. Then the Validation Engine runs the list of Check Codes against the reported data. Each unsatisfied Check Code yields a validation error, warning, or alert. Validation results are saved in the [habAdmin].[HAB_ValidationResult] table.

All the Check Codes are saved in the [habAdmin].[HAB_ValidationCheckCode] table, “IsActive” flag is used to include / exclude the check code in the validation process.

Workflow Engine RSR has the following workflow processes requirement:

· Grantee Report Workflow (Figure 10)

· Provider Report Workflow (Figure 11)

· Validation Workflow (Figure 12)

· Provider Report Review Process Workflow (Figure 13) RSR Workflow Engine Design The design of the workflow engine adapts the chain-of-responsibility design pattern. The chain-of-responsibility pattern is a design pattern consisting of a source of command objects and a series of processing objects. Each processing object contains logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain. In the RSR Workflow Engine design (Figure 8), we chain a list of workflow status objects in the proper sequence and start looping each workflow status object to match with the request status. If a match is found, the workflow status object will process the tasks: (1) update the request (report) status, (2) queue a request to update EHBs deliverable status, and (3) log the workflow action. Otherwise, the process will pass on to the next workflow status object in the chain to repeat the matching process.

Figure 8: RSR Workflow Engine Design RSR Workflow Engine Implementation When a workflow action is initialized, a WorkFlowRequest object will be created and processed by a WorkflowProcessService object as shown below.

In the above code snippet, a grantee report workflow status change request from “Not Started” to “In Progress” is created. Lines 284 to 293 show the RsrWorkflowRequest creation and lines 295 to 296 for processing the request by a WorkflowProcessService object.

The constructor of a WorkflowProcessService object defines the chain of report workflow status as below.

Each workflow status object defines a ProcessRequest method to perform the proper action for the workflow process. The ProcessRequest method will perform the following:

1. Update workflow status.

2. Queue an EHBs request to update the EHBs deliverable status.

3. Log the workflow action.

In the above example, line 18 shows workflow status has been updated to “Working”. Lines 19 to 26 show queuing a request to update the EHBs deliverable status. Line 27 logs the workflow action.

When the workflow process gets started, it will loop through each workflow status object defined in the workflow chain to find a match with the current workflow status. If a match is found, the corresponding ProcessRequest method of the workflow status object will be triggered to perform the workflow action. The loop to find the match workflow status object in the chain is shown below.

The sequence diagram (Figure 9) below shows the participants that are involved in the status change described above – the status of a RSR grantee reports changes from “Not Started” to “In Progress”, and the methods that are called from each participant.

Figure 9: Participants involved in a Status Change Request

Figure 10: Grantee Report Workflow

Figure 11: Provider Report Workflow

Figure 12: Validation Workflow

Figure 13: Provider Report Review Process Workflow Email Engine Responsibilities The Email Engine sends out email to the recipients based on the email request set up.

Processing All email requests will be submitted and stored in the HabAdmin.HAB_EmailRequest table. The Email Engine is a standalone window service. The Email Engine parses out all email required fields such as email recipients and email body content from each email request. This engine uses the SmtpClient in the System.Net.Mail namespace to send out the email. After the email is sent, the Email Engine will update the ProcessStartTime, ProcessEndTime, and RequestStatus to reflect the process duration and the request status for the corresponding email request.

Database Design The RSR database design diagrams are embedded at the end of this section.

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

Email Notifications Depending on each stage of the RSR Provider Report workflow, each involved provider, grantee, and RSR Administrator will be notified by email. For example, when a user returns an RSR Provider report for changes, an email will be sent to the affected users. HAB’s Internet Information Services (IIS) SMTP server will send all emails.

EHBs Integration The RSR web application is integrated with the EHBs through Platform Lite, an integration framework that provides consistent look and feel with the new EHBs as well as backend integration such as deliverable status updates (Figure 14). The version of the Platform Lite used is 2.35.25.

Figure 14: EHBs Integration

Figure 15: Platform Lite Integration

A Platform Lite integration layer is created to help all Bureau Reporting Systems (BRS) to integrate with Platform Lite (Figure 15). 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. This layer is called the HRSA Integration Layer. Please refer to the EHBs New User Interface (UI) Integration Design Document embedded at the end of this section, for the detailed design of this layer.

image82.png image83.png image84.png image85.png image86.png image87.emf image88.emf image89.png image90.emf image91.emf image92.png image93.emf image94.emf image95.emf image96.emf image97.emf image98.emf image50.emf

Microsoft_Visio_2003-2010_Drawing.vsd Server

Workstation

Firewall

View

Drag the side handles to change the width of the text block.

Compaq Server 1 Application Server

Compaq Server 2 Database Server

WRMA/CSR

Grantees & Providers

HRSA Contact Center

WAN

Internet Information Server (IIS)

Web Server

SMTP Server

RSR Web Interace .Net Application

Security / Authentication .Net Application

Other .Net Applications

DMZ

HRSA Network

SQL Server HAB Database

HAB

Leidos Development Team https http smtp

Native SQL Server

Named Pipes

File System Write

.Net State Server

Security / Auth Database

Other Databases file system / docroot image63.emf image1.png

Microsoft_Visio_2003-2010_Drawing1.vsd The height of the text box and its associated braces increases or decreases as you add text. To change the width of the comment, drag one of the side handles.

Platform Lite Integration

Platform Lite

HAB Application

Date Updated: 10/13/2015

EHBs Environment

EHBs Gateway

EHBs EIS

Seamless User Interface

Real-Time System Communications

EHBs WCF Service

EHBs GEMS

Leidos Components

HAB Core Components

Legend

Leidos EHBs Integration Architecture image68.emf

Microsoft_Visio_2003-2010_Drawing2.vsd MCHB DB Server (perf-db-prod2)

HAB DB Server (hab-db-prod2)

GEMSDB1

EHBs Prod image71.emf

Microsoft_PowerPoint_97-2003_Presentation.ppt

IIS

Web Server

.Net

Framework

SQL Server www smtp

HAB/RSR

Web Application

HAB/RSR

Web Database

SSRS

Software

Components

Third-party

Software

Custom

Software

IE

Web

Browser

RSR Form image72.png image73.png image74.emf image75.png image76.png image77.png image78.png image82.emf

Microsoft_Visio_Drawing.vsdx image83.emf

Microsoft_Visio_2003-2010_Drawing3.vsd

Grantee logs in and navigates to the report via the EHBs

Grantee selects “start” to access the RSR System#

EHBs Status: Not Started RSR Status: Not Started HRSA Review Status: Not Applicable image84.emf

Microsoft_Visio_2003-2010_Drawing4.vsd

Start

Provider accesses RSR System as appropriate*

RSR Provider Report Status: Not Started

Selects “Create” to begin the Report

RSR Provider Report Status: Working

Provider completes the online form

Provides Client Services?

Yes

Provider selects the “submit” link in menu

Provider Report Review Process:

Grantee(s) review the report image85.emf

Microsoft_Visio_2003-2010_Drawing5.vsd

Provider Completes Report

Provider validates report

RSR Status: Working

Errors Found?

No

End

All Warnings Have Comments?

Warnings Found?

Provider enters warning comments image86.emf

Microsoft_Visio_2003-2010_Drawing6.vsd

Grantee(s) review Provider Report

Report is approved?

Last required approval?

Provider Report status updated to “Submitted”

Provider Report Workflow

Provider Report Status: Working image89.emf

RSR Grantee Report.pdf habAdmin.HAB_Report

ReportId: Number IDENTITY

DataSystemId: Number NOT NULL DeliverableId: Number NULL DateCreated: Datetime NOT NULL CreatedByUserId: Number NOT NULL (FK) DateLastModified: Datetime NULL DateLastValidated: Datetime NULL ModifiedByUserId: Number NULL (FK) ReportPeriodId: Number NULL (FK) StatusId: Number NOT NULL (FK) OrgId: Number NOT NULL (FK) ExtensionDate: Datetime NULL ContactName: String NULL ContactTitle: String NULL ContactPhone: String NULL ContactFax: String NULL ContactEmail: String NULL OrgName: String NULL Ein: String NULL Duns: String NULL Street: String NULL City: String NULL Zip: String NULL StateId: Number NULL (FK) SubReportPeriodId: Number NULL (FK) habAdmin.HAB_Contract

HabContractId: Number IDENTITY

CmsContractId: Number NOT NULL PrimeContractId: Number NULL (FK) ReportId: Number NOT NULL (FK) OrgId: Number NOT NULL (FK) StartDate: Datetime NOT NULL EndDate: Datetime NOT NULL Reference: String NULL IsLeadAgency: Number NOT NULL LeadAgencyTypeId: Number NULL (FK) IsSubcontractor: Number NOT NULL ProvideDirectService: Number NOT NULL habAdmin.HAB_ContractService

ContractServiceId: Number IDENTITY

AwardAmount: Number NULL MAIAwardAmount: Number NULL ServiceId: Number NOT NULL (FK) HabContractId: Number NOT NULL (FK) BaseSupplementAmount: Number NULL EcAwardAmount: Number NULL ConsortiaAmount: Number NULL DirectServiceAmount: Number NULL rsrAdmin.RSR_GranteeReport

GranteeReportId: Number NOT NULL (FK)

ReceiveMaiFund: Number NULL MaiPercentage: Number NULL QualityManagementId: Number NULL (FK) rsrAdmin.RSR_QualityManagementLkup

Id: Number NOT NULL

Value: String NOT NULL SortOrder: Number NOT NULL IsActive: Number NOT NULL habAdmin.HAB_Org

OrgId: Number IDENTITY

Description: String NULL OrgName: String NULL OrgTypeId: Number NOT NULL IsActive: Number NOT NULL TaxPayerId: String NULL RegistrationCode: Number NOT NULL DunsNumber: String NULL DateLastModified: Datetime NULL ModifiedByUserId: Number NULL EhbOrgId: Number NULL Street: String NULL City: String NULL Zip: String NULL StateId: Number NULL (FK) DateCreated: Datetime NULL CreatedByUserId: Number NULL (FK) habAdmin.HAB_Deliverable

DeliverableId: Number IDENTITY

EhbDeliverableId: Number NOT NULL EhbUserId: Number NULL EHBStatus: String NULL DateStarted: Datetime NULL DateLastUpdated: Datetime NULL EhbStatusUpdateSuccess: Number NOT NULL GrantId: Number NULL (FK) ReportPeriodId: Number NULL (FK) EhbAwardNumber: Number NULL rsrAdmin.RSR_Exemption

ExemptionId: Number IDENTITY

ProviderId: Number NOT NULL (FK) GranteeReportId: Number NOT NULL (FK) Comment: String NOT NULL habAdmin.HAB_ReportPeriodLkup

ReportPeriodId: Number NOT NULL

DataSystemId: Number NOT NULL PeriodName: String NOT NULL PeriodStartDate: Datetime NOT NULL PeriodEndDate: Datetime NOT NULL ReportStartDate: Datetime NOT NULL ReportEndDate: Datetime NOT NULL DueDate: Datetime NOT NULL ExtensionDate: Datetime NOT NULL RejectDeadline: Datetime NULL ApproveDeadline: Datetime NULL IsActive: Number NOT NULL ClientReportPeriodStartDate: Datetime NULL ClientReportPeriodEndDate: Datetime NULL IsCheckYourXml: Number NOT NULL habAdmin.HAB_Provider

OrgId: Number NOT NULL

ProviderOwnershipId: Number NULL ProviderTypeId: Number NULL IsFaithBased: Number NULL CreatedByOrgId: Number NOT NULL ProviderTypeOther: String NULL OwnershipStatusOther: String NULL Received330FundingId: Number NULL (FK) IsActive: Number NOT NULL habAdmin.HAB_Grantee

OrgId: Number NOT NULL isActive: Number NULL habAdmin.HAB_Grant

GrantId: Number IDENTITY

EhbGrantId: Number NOT NULL CoreGrantNumber: Number NOT NULL GranteeId: Number NOT NULL (FK) habAdmin.HAB_FundSrcLkup

FundSrcId: Number IDENTITY

FundSource: String NOT NULL IsCAREActTitle: Number NOT NULL SortOrder: Number NOT NULL AppliesToHIP: Number NOT NULL ActivityCode: String NOT NULL

Hab -- ER_Diagram_10383 / RSR GranteeReport

1 / 1 -- 6:23:22 PM , 10/7/2015

image92.emf

RSR Provider Report.pdf

HAB_Report

ReportId: INTEGER IDENTITY

DataSystemId: INTEGER NOT NULL (FK) ReportPeriodId: INTEGER NULL (FK) SubReportPeriodId: INTEGER NULL (FK) StatusId: INTEGER NOT NULL (FK) OrgId: INTEGER NOT NULL (FK) DeliverableId: INTEGER NULL (FK) ExtensionDate: DATE NULL OrgName: VARCHAR(150) NULL ContactName: VARCHAR(200) NULL ContactTitle: VARCHAR(200) NULL ContactPhone: VARCHAR(200) NULL ContactFax: VARCHAR(200) NULL ContactEmail: VARCHAR(200) NULL DateCreated: DATE NOT NULL CreatedByUserId: INTEGER NOT NULL (FK) DateLastModified: DATE NULL ModifiedByUserId: INTEGER NULL (FK) DateLastValidated: DATE NULL Ein: VARCHAR(11) NULL Duns: VARCHAR(9) NULL Street: VARCHAR(200) NULL City: VARCHAR(200) NULL StateId: INTEGER NULL (FK) Zip: VARCHAR(10) NULL

HAB_Provider

OrgId: INTEGER NOT NULL (FK)

ProviderTypeId: INTEGER NULL (FK) ProviderTypeOther: VARCHAR(150) NULL ProviderOwnershipId: INTEGER NULL (FK) OwnershipStatusOther: VARCHAR(150) NULL IsFaithBased: INTEGER NULL Received330FundingId: INTEGER NULL (FK) CreatedByOrgId: INTEGER NOT NULL (FK) IsActive: BOOLEAN NOT NULL

HAB_StatusLkup

StatusId: INTEGER IDENTITY

Status: VARCHAR(50) NOT NULL IsFinalStatus: SMALLINT NOT NULL Description: VARCHAR(200) NULL DataSystemId: INTEGER NOT NULL (FK) Enum: VARCHAR(16) NOT NULL SortOrder: INTEGER NULL

HAB_ProviderTypeLkup

Id: INTEGER IDENTITY

Value: VARCHAR(60) NOT NULL SortOrder: INTEGER NOT NULL Enum: VARCHAR(16) NULL

HAB_ReportPeriodLkup

ReportPeriodId: INTEGER NOT NULL

DataSystemId: INTEGER NOT NULL PeriodName: NVARCHAR(50) NOT NULL PeriodStartDate: TIMESTAMP NOT NULL PeriodEndDate: TIMESTAMP NOT NULL ReportStartDate: TIMESTAMP NOT NULL ReportEndDate: TIMESTAMP NOT NULL DueDate: TIMESTAMP NOT NULL ExtensionDate: TIMESTAMP NOT NULL RejectDeadline: TIMESTAMP NULL ApproveDeadline: TIMESTAMP NULL IsActive: SMALLINT NOT NULL ClientReportPeriodStartDate: TIMESTAMP N ClientReportPeriodEndDate: TIMESTAMP NU IsCheckYourXml: BOOLEAN NOT NULL

HAB_Org

OrgId: INTEGER IDENTITY

EhbOrgId: UNIQUEID NULL OrgTypeId: INTEGER NOT NULL (FK) IsActive: SMALLINT NOT NULL Description: VARCHAR(200) NULL OrgName: VARCHAR(150) NULL TaxPayerId: VARCHAR(11) NULL RegistrationCode: INTEGER NOT NULL DunsNumber: VARCHAR(9) NULL Street: VARCHAR(200) NULL City: VARCHAR(200) NULL StateId: INTEGER NULL (FK) Zip: VARCHAR(10) NULL DateLastModified: TIMESTAMP NULL ModifiedByUserId: INTEGER NULL (FK) DateCreated: TIMESTAMP NULL

HAB_StateLkup

StateId: INTEGER IDENTITY

StateShort: VARCHAR(2) NOT NULL StateFull: VARCHAR(50) NOT NULL StateFips: INTEGER NULL

HAB_User

UserId: INTEGER IDENTITY

GlobalLogin: VARCHAR(20) NULL

UserHasSeenWelcome: SMALLINT NOT NULL EhbUserID: UNIQUEID NULL AcUserID: INTEGER NULL IsEhbAccount: SMALLINT NOT NULL DatetimeCreated: TIMESTAMP NULL IsActive: SMALLINT NULL

HAB_OwnershipLkup

Value: VARCHAR(50) NOT NULL

HAB_AgencyCategoryLkup

Id: INTEGER NOT NULL

Value: VARCHAR(150) NOT NULL

Enum: VARCHAR(20) NULL

HAB_YesNoLkup

Value: VARCHAR(100) NULL

RSR_ProviderReportService

ServiceId: INTEGER NULL (FK) ProviderReportId: INTEGER NULL (FK)

HAB_ServiceLkup

ServiceCategoryId: INTEGER NOT NULL (F ServiceCollectionTypeId: INTEGER NOT NU Value: VARCHAR(100) NOT NULL

DataDictionaryId: INTEGER NULL

HAB_ProviderSite

ProviderSiteId: INTEGER IDENTITY

ProviderId: INTEGER NOT NULL (FK) SiteName: VARCHAR(200) NOT NULL SiteStreet: VARCHAR(200) NOT NULL SiteStreet2: VARCHAR(200) NULL SiteCity: VARCHAR(200) NOT NULL SiteStateId: INTEGER NOT NULL (FK) SiteZipCode: VARCHAR(10) NOT NULL SitePhone: VARCHAR(20) NULL OperationHours: VARCHAR(500) NOT NULL WebsiteUrl: VARCHAR(200) NULL

HAB_ProviderSiteService

ServiceId: INTEGER NOT NULL (FK) ProviderSiteId: INTEGER NOT NULL (FK) IsActive: INTEGER NOT NULL

HAB_SiteServiceLkup

Id: INTEGER NOT NULL (FK)

HAB_SystemDate

SystemDateId: INTEGER NOT NULL

ReportPeriodId: INTEGER NOT NULL (FK) SubReportPeriodId: INTEGER NULL (FK) SystemDateCategoryId: INTEGER NOT NULL (FK) SystemDate: DATE NOT NULL Description: VARCHAR(250) NOT NULL Message: VARCHAR(250) NOT NULL

HAB_OrgContact

OrgContactId: INTEGER IDENTITY

IsMainContact: SMALLINT NOT NULL ContactEmail: VARCHAR(200) NULL ContactFax: VARCHAR(15) NULL ContactPhone: VARCHAR(15) NULL ContactTitle: VARCHAR(70) NULL ContactPrefix: VARCHAR(6) NULL ContactFirstName: VARCHAR(20) NULL ContactLastName: VARCHAR(20) NULL ContactDegree: VARCHAR(50) NULL ContactSuffix: VARCHAR(3) NULL ContactContactMI: VARCHAR(1) NULL ContactPhoneExt: VARCHAR(5) NULL ContactFullName: VARCHAR(200) NULL DateLastModified: TIMESTAMP NULL LastModifiedBy: INTEGER NULL (FK)

HAB_Lock

ReportId: INTEGER NOT NULL (FK)

UserId: INTEGER NOT NULL (FK)

RSR_ProviderReport

ProviderReportId: INTEGER NOT NULL (FK)

ClientCount: INTEGER NULL ProviderTypeId: INTEGER NULL (FK) ProviderTypeOther: VARCHAR(150) NULL OwnershipId: INTEGER NULL (FK) OwnershipStatusOther: VARCHAR(150) NULL IsFaithBased: BOOLEAN NULL QualityManagementId: INTEGER NULL (FK) Received330FundingId: INTEGER NULL (FK) ReviewedFundingSource: BOOLEAN NULL OralHealthCareExpendedAmount: INTEGER NULL PaidFte: FLOAT NULL PositiveMedicalReferral: INTEGER NULL ProvidedHctService: BOOLEAN NULL TestedHiv: INTEGER NULL TestedHivPositive: INTEGER NULL TestedHivNegative: INTEGER NULL PostTestCounselingNegative: INTEGER NULL PostTestCounselingPositive: INTEGER NULL

HAB_ProviderAgencyCategoryRel

ProviderAgencyCategoryRelId: INTEGER IDENTITY

ProviderId: INTEGER NOT NULL (FK) AgencyCategoryId: INTEGER NOT NULL (FK)

RSR_ProviderReportAgencyCategoryRel

ProviderReportAgencyCategoryRelId: INTEGER IDENTITY

ProviderReportId: INTEGER NOT NULL (FK) AgencyCategoryId: INTEGER NOT NULL (FK)

RSR_ServiceLkup

RSR_QualityManagementLkup

Value: VARCHAR(200) NOT NULL

Hab -- ER_Diagram_7995 / RSR ProviderReport

1 / 1 -- 6:24:00 PM , 10/7/2015

image99.emf

RSR Client Report.pdf

RSR_ClientReport

ClientReportId: INTEGER IDENTITY

ClientUci: CHAR(41) NOT NULL EnrollmentStatusId: INTEGER NULL (FK) BirthYear: INTEGER NULL EthnicityId: INTEGER NULL (FK) SexAtBirthId: INTEGER NULL (FK) GenderId: INTEGER NULL (FK) TransgenderId: INTEGER NULL (FK) PovertyLevelId: INTEGER NULL (FK) HousingStatusId: INTEGER NULL (FK) HivAidsStatusId: INTEGER NULL (FK) HivDiagnosisYear: INTEGER NULL RiskScreeningProvidedId: INTEGER NULL (FK) PrescribedPcpProphylaxisId: INTEGER NULL (FK) FirstAmbulatoryCareDate: TIMESTAMP NULL PrescribedArtId: INTEGER NULL (FK) ScreenedHepatitisCSinceHivDiagnosisId: INTEGER ScreenedMentalHealthId: INTEGER NULL (FK) ScreenedHepatitisBSinceHivDiagnosisId: INTEGER ScreenedSubstanceAbuseId: INTEGER NULL (FK) ScreenedTBSinceHivDiagnosisId: INTEGER NULL…