SOW Attachment A4.2 Bureau Reporting Sub System PIMS.pdf

Performance Improvement Measurement System (PIMS) Web Application

Detailed Design Document Attachment A4.2

Health Resources and Services Administration

Office of Information Technology 5600 Fishers Lane

Rockville, MD 20857 ii

Table of Contents 1 Overview

1.1 System Overview

1.2 Document Organization

1.3 Change Control

1.4 Target Audiences

1.5 Assumptions

1.6 Referenced Documents

2 Design Considerations

2.1 Goals and Guidelines

2.2 Development Methods

3 Projects

3.1 General Functionality

3.2 User Interface Logic

4 Software Tasks

4.1 Database Schema

4.2 Data Access Layer

4.3 Project Officer Module Interface

4.4 Authentication and Authorization Module/Active Directory Interface

4.4.1 The Core Project

4.4.2 OHIT-Rural Project

4.4.3 OHIT/ORHP Project

4.4.4 Database Tables

4.5 Navigation Framework

4.5.1 Database Tables

4.5.2 Classes

4.6 Validation Framework

4.6.1 Client Side Validation

4.6.2 Server Side Validation

4.6.3 Field Level Validation

4.6.4 Cross Field Validation

4.7 Workflow Logic

4.7.1 OHIT-Rural Grant Processing Workflow

4.7.2 Sequence Diagram

4.7.3 Report Access with EHBs

4.7.4 Workflow Matrix

4.8 Comments Module

4.9 Email Notification Module

4.10 OAT User Interface

4.10.1 OAT Master Page

4.10.2 OAT Forms

4.11 ORHP User Interface

4.11.1 ORHP Master Page

4.11.2 ORHP Forms

4.12 PDF Form Generation

4.13 Roles Module

iii

4.14 PDF Archive Module

4.15 SMARTForm Approach

4.15.1 Form Meta data

4.15.2 Form Rendering

4.15.3 Form Data Saving

4.15.4 Form Validation

4.15.5 Server Control Development

4.16 OAT Data Extracts

4.16.1 Report Generation Tool

4.16.2 Report Generation Class

4.16.3 Design of Report Generation Class

4.16.4 Data Extract SQL Server Files

4.17 Telehealth Resource Center Grant Program (TRC)

4.17.1 TRC Reports

4.18 ORHP Reports

5 External Interfaces

5.1 Email Notifications

5.2 EHBs UI Integration

5.2.1 Hrsa.Integration.PlatformLite

5.2.2 Platform Lite

5.2.3 Left Menu and Top Menu Implementation

5.2.4 Top Menu

5.2.5 MasterPage

Appendix

List of Figures Figure 1: OHIT-Rural Software Architecture Figure 2: OHIT-Rural Data Access Layer Figure 3: OHIT-Rural Authentication Logical Flow Figure 4: OHIT-Rural Workflow Figure 5: Report Submission Process Figure 6: Workflow for Determining Read/Write Access Figure 7: Email Notification Module Figure 8: Form Metadata Object Model Figure 9: Retrieval of Form Metadata from the PIMS Database Tables Figure 10: SMARTForm Meta Data Figure 11: Class Structure of the SMARTForm Figure 12: Sample Code for Creating a Textbox Custom Control Figure 13: OAT Report Data Extracts Figure 14: TRC Program Data Model Figure 15: EHBs UI Integration Architecture Figure 16: Integration Classes Figure 17: SmartForm Meta Data Database Diagram Figure 18: SMARTForm Data Saving Database Diagram Figure 19: SMARTReport Database Diagram iv

List of Tables

Table 1: Validator Types Table 2: Workflow States Table 3: OAT Data Collection Period Dropdown Table 4: Report Generation Class Table 5: Design of Report Generation Class Table 6: Report Generation Class Method and Purpose Table 7: OAT Reports Table 8: TRC Program Reports Table 9: ORHP Reports

1 Overview This document describes the high-level architecture of Health Resources and Services Administration's (HRSA) Federal Office of Rural Health Policy (FORHP) Performance Improvement and Measurement System (PIMS).

1.1 System Overview

PIMS is used to collect performance data from Grantees that have received awards from FORHP programs. The system provides a data entry interface for Grantees to report required data and performance information. The system also includes reporting features that allow FORHP staff to review Grantee submissions as well as reports that aggregate (“rollup”) data across years and programs, permitting the user to visualize performance data to support FORHP’s analytical needs. PIMS currently supports the following FORHP programs:

• Allied Health Training (AHT)

• Black Lung Clinics (BlackLung)

• Delta Health Initiative (DHI)

• Delta States Development Network (DSDN)

• Frontier Extended Stay Clinic (FESC)

• Medicare Rural Hospital Flexibility (Flex)

• Flex Monitoring Team (FMT)

• Health Information Technology (HIT)

• Medicare Beneficiary Quality Improvement Program (MBQIP)

• Network Development Program (NDP)

• Office for the Advancement of Telehealth (OAT)

• Public Access to Defibrillation Devices Program (PADDP)

• Rural Access to Emergency Devices (RAED)

• Rural Benefits Counseling (RBC)

• Radiation Exposure Screening and Education Program (RESEP)

• Rural Care Coordination (RCC)

• Rural Health Care Services Outreach (RHCSO)

• Rural Health Information Technology Network Development Program (RHITND)

• Rural Health Network Development (RHND)

• Rural Health Research Center (RHRC)

• Rural Opioid Overdose Reversal (ROOR)

• Rural Veterans Health Access Program (RVHAP)

• Small Health Care Provider (SHCP)

• State Offices of Rural Health (SORH)

• Targeted Research (TR)

• Telehealth Resource Center (TRC)

• Rural Health Information Technology Workforce (Workforce)

The PIMS web application employs the following technologies:

• Microsoft .NET Framework 4.6, 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 8.x

• JavaScript

• Infragistics NetAdvantage ASP.NET User Controls

• NHibernate

• Bootstrap

1.2 Document Organization

This document is divided into several sections:

• The Design Consideration section describes criterion used while developing and evaluating the PIMS web application.

• The Projects section describes the various projects contained in PIMS and the system architecture.

• The Software Tasks section describes the detailed components that make up the PIMS application. This includes the Database Schema, Data Access Layer, Project Officer Module Interface, Authentication and Authorization Module/Active Directory Interface, Navigation Framework, Validation Framework, Workflow Logic, Comments Module, Email Notification Module, OAT User Interface, ORHP User Interface, PDF Form Generation, Roles Module, PDF Archive Module, SMARTForm Approach, OAT Data Extracts, and Telehealth Resource Center Grant Program (TRC).

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

• The appendix contains detailed database diagrams.

1.3 Change Control

During the initial and subsequent development cycles, the technical details of the PIMS 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 the initial version of this document is accepted, it will be considered under change control. All subsequent updates will be documented in the Document History table. OIT will be notified of all changes and will be provided an updated electronic copy of each future version.

1.4 Target Audiences

This document will be used by two main groups of software developers:

• Implementers of the PIMS web application.

• Maintainers of the PIMS web application after it is deployed.

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

1.5 Assumptions

This document was written based on the following assumptions.

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

• 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 PIMS database server and web application server.

• The HRSA Electronic Handbooks (EHBs) will not implement significant changes that effect how the PIMS 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.

1.6 Referenced Documents

The following documents were referenced in the creation of this document:

• Office of Health Information Technology (OHIT)-Rural Architecture.vsd

• OHIT-Rural Release 1 0 System Requirements Document_Draftv0 2.doc

• FORHP Rural Opioid Overdose Reversal Grant Program (ROOR) Grant Program

User Stories Document

• Previously approved versions of the PIMS Detailed Design Document.

2 Design Considerations

2.1 Goals and Guidelines

• Better user experience o Navigation o Performance o Simplicity

• Technical o .NET Framework 4.6 o Object-Oriented Programming (OOP) – Follow Single responsibility, Open-closed, Liskov substitution, Interface segregation, and Dependency inversion (SOLID) design principles o Service-Oriented Architecture (SOA) – Distributed architecture that allows machine to machine client data upload and creation of the upload completeness report using WCF Streaming capability o Unit test coverage: 50% o HTML5 - WebSocket o Fluid/Responsive design o Core application logic in application o Parallel processing o Asynchronous processing - server side and client

• Maintenance o Maintainability o Better system for troubleshooting, auditing, etc.

• Scalability o Support for server farm/load balancing

• Integration o Better integration with EHBs: more integration points o Retrieve more EHBs data

• Documentation o Simple, but complete documentation

2.2 Development Methods

The PIMS 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.

3 Projects The PIMS, or the OHIT-Rural application as it is referenced in this document, will include the following projects: HRSACore, OHIT, and the ORHP. Figure 1 contains a Microsoft Visio diagram that depicts the high-level architecture of these projects.

ASPX Pages Master Page

Global.ASX

OHIT

ASPX Pages Master Page

Global.ASX

ORHP

OHIT-Rural DB Schema

Stored procedures

Data Access Layer

HttpModule

Generic ASPX Pages (Standard Errors, Login, etc)

HRSACore

WebCommands (Base Class) Renderer Base Class

AuthorityManager

EHB Wrapper

«subsystem»

EHB

Firewall

O u a So t a e c tectu e

Utilities Common Web Controls

Email Notifications

Database tables

Login App

Generic ASPX Pages (Standard Errors, Login, etc)

Code Share Code Share

Figure 1: OHIT-Rural Software Architecture

3.1 General Functionality

This document contains general functionality, which can be used by the ORHP project.

This functionality is not intended for use by other applications.

3.2 User Interface Logic

This document contains the user interface logic, which is specific to the ORHP application. This includes forms for all programs under the ORHP project.

4 Software Tasks

4.1 Database Schema

The database schema in ERWIN format is defined in the following documents:

• OAT.erwin

• ORHP.erwin

• ORHPReport.erwin

The schema is also defined in tabular form in the documents, which are embedded below.

• Data Dictionary PIMS 9.1 Release.docx

Data Dictionary PIMS

9.1 Release.docx

• PIMS OAT Data Dictionary.rtf

PIMS OAT Data Dictionary.rtf

• Erwin_OAT.pdf

Erwin_OAT.pdf

• Erwin_Core.pdf

Erwin_Core.pdf

4.2 Data Access Layer

Figure 2 depicts the data access layer for OHIT-Rural.

Figure 2: OHIT-Rural Data Access Layer

OHIT-Rural DB Schema

Database tables

SQLConnection DataSetDataAdapter

DataTable DataTable

DataTable

TableDataObject TableDataObject(SqlConnection _sqlConnection, string _formIDString, string _tableNameString) QueryTableData(System.Collections.Generic.Dictionary<string, object> ar)

UpdateTableData() ClearData()

FormDataObject FormDataObject(SqlConnection _sqlConnection, string _formID) FormDataObject(SqlConnection _sqlConnection, string _formID, List<string> tableNames) QueryData(System.Collections.Generic.Dictionary<string, Object> keys)

UpdateData()

ASPX Page

FormQueries.xml

XMLForDBQueries

HRSACore

ADO.Net

4.3 Project Officer Module Interface

The following class defines the interface with the Electronic Handbooks (EHBs):

CORE.Utilities.EISWrapper: file Thecore\Utilities\EISWrapper.cs

Methods:

public EISWrapper(ICoreIni iCore) public XmlDocument execute_getAll(EHB_XmlTemplate iXmlTemplate, string iType, string iID) public XmlDocument execute_getAll( EHB_XmlTemplate iXmlTemplate, string iOuterType, string iOuterID, string iInnerType, string iInnerID) public string GetDeliverableName(string iEHBGrantID, string iEHBDeliverableID) public EHB_ScheduleStatus GetStatus(string iEHBGrantID, string iEHBDeliverableID) public void UpdateStatus(EHB_ScheduleStatus iNewStatus, string iEHBGrantID, string iEHBDeliverableID, string iEHBUserID, string iReportStatus, string iExternalID) public Hashtable GetUserInfo(string iEHBUserID) public XmlDocument GetRoleInfo(string iEHBGrantID, int iRoleID) public string GetPDEmail(string reportInstanceID) public string GetAOEmail(string reportInstanceID) public XmlDocument execute(XmlDocument xmlDoc, EHB_DataAction iMethod) public bool GetFullGrantDetails(string iEHBGrantID, out string organizationName, out string contactName, out string contactEmail, out string contactPhone, out string contactStreet, out string contactCity, out string contactState, out string contactZip, out string contactFax) public bool GetGrantState(string iEHBGrantID, out string contactState) public bool GetGrantNo(string iEHBGrantID, out string activityCode, out string grantNo) public bool GetGrantDetails(string iEHBGrantID, out string organizationName, out string contactName, out string contactEmail)

4.4 Authentication and Authorization Module/Active Directory Interface Figure 3 depicts the logical flow of the Authentication for the OHIT-Rural Application.

Figure 3: OHIT-Rural Authentication Logical Flow

The following sections describe the classes that will manage the authentication.

4.4.1 The Core Project

HRSA.Core.UI.AuthorityManager

1. Call HRSA.Core.EHBAccess to request login information from EHBs.

2. If EHBs Login, call HRSA.Core.EHBAccess to request roles for user.

3. If not an EHBs login, call module specified by <authAppBase> and

<loginPath> for local login.

4. If not an EHBs login, read AC_UserRole_Rel table to retrieve roles.

5. Read AC_ResourceRole_Rel table to retrieve permissions for each command or login, use the highest permission level for all user roles.

Core.Security.AuthorityManager is an existing component which will manage the non- EHBs login.

Dependencies:

• Orhp.DataAccess

Page Request Is Internal User

Load Roles For User From DB

Display Error Page

Display Page

Yes

No

No

Display Login Page

Login Successful?

Is Authenticated?

Request Login Info from EHB/AD

Authenticated?

Yes

No

Get EHB Permissions

No

Yes

Yes

Try to get Active Directory

Permissions

In Active Directory? NoYes

• Orhp.Domain

• REISys.PlatformLite.Core

• REISys.PlatformLite.Security

• REISys.PlatformLite.Services

Core.Utilities.EHBServices is a component which will manage the interface to EHBs.

4.4.2 OHIT-Rural Project

HRSA.OHITRural.Common.ASPXHandlerModule

1. Intercept each request and call the Authentication and Authorization logic.

2. Call AuthorityManager to get login information.

3. If successful, call AuthorityManager again to get authorization for page.

HRSA.OHITRural.RegLoginApp.Login

• ASPX Form which performs non-EHBs logins

4.4.3 OHIT/ORHP Project

Web.Config:

1. <authAppBase> and <loginPath> tags will direct the application to use the HRSA.OHITRural.RegLoginApp.Login form for non-EHBs logins.

2. Specify the ASPXHandlerModule in the <httpModules> section.

4.4.4 Database Tables

The following tables are used for authentication and authorization:

• AC_User

• AC_ResourceID

• AC_Role_Lkup

• AC_UserProgram_Rel

• AC_Applications_Lkup

• AC_LoginAudit

• AC_ResourceRole_Rel

• AC_Resource_Type_Lkup

• AC_UserRole_Rel

• AC_SessionInfo

• AC_Applications_Lkup

• AC_UserApplication_Rel

4.5 Navigation Framework

The following sections describe the database tables and classes that make up the Navigation framework.

4.5.1 Database Tables

CORE.AC_Resource ResourceID smallint Resource varchar(200) ResourceTypeID smallint

CORE.Form_Lkup FormID smallint FormTitle varchar(100) MenuTitle varchar(100) IsRequiredforSubmission bit FormLevel varchar(50) FormName varchar(50) IsConfig bit ToolTip varchar(500)

CORE.FormGuidance_Rel FormID DataCollectionPeriodID FormGuidanceRelID SortOrder ResourceID ParentFormID // determines children. If 0, root item

// permissions for resources/URLs CORE.AC_User CORE.AC_Role_Lkup CORE.AC_UserRole_Rel CORE.AC_ResourceRole_Rel

4.5.2 Classes

The Core Project Public class CORE.CoreObjects.FormNavigationData private int formID;

private string formName;

private string formURL;

private FormStateEnum formState;

private string formTitle1;

private string formTitle2;

private string formTitle3;

private string formInstructionText;

private List< FormNavigationData> childForms;

public int FormID { get ; set ; } public string FormName { get ; set ; } public FormStateEnum FormState{ get; set; } public string FormURL { get ; set ; } public string FormTitle1 get ; set ; } public string FormTitle2 { get ; set ; } public string FormTitle3 { get ; set ; } public string FormInstructionText { get ; set ; } public List< FormNavigationData> ChildForms {get; } public AddChild(FormNavigationData childForm);

public FormNavigationData(int _formID, string _formName, string _formURL, string _formTitle1, string _formTitle2, string _formTitle3, string _formInstructionText, List< FormNavigationData>childForms);

This data object stores the navigation attributes of a single form.

CORE.CoreObjects.NavigationManager:

Create(); // Reads navigation database tables to determine which forms are accessible to the user, and in which order.

FormNavigationData GetNextForm (string currentPage, bool includeCompletedPages);

//Based on the current page, return the URL of the next page // If form is not a root form, the next form will be the form’s PARENT bool GotoNextForm(string currentPage, bool includeCompletedPages, HttpResponse response);

// Perform redirect() to the next page, as determined // by GetNextForm

System.Collections.Generic.List<FormNavigationData> GetAllForms() // returns a list of all forms

CORE.Controls.ReportWebControl: inherits from WebCustomControl Call NavigationManager to retrieve Read state from TablesForReportStatus For each table, if AuthorityManager indicates the user has authority, then creates a link to each table’s home ASPX page, to TableURL Create icon based on TablesForReportStatus

CORE.Controls. LeftCol_Tools: inherits from System.Web.UI.UserControl

Master Page:

Contains a ReportWebControl and a LeftCol_Tools control in the left hand ContentPlaceHolder.

4.6 Validation Framework

4.6.1 Client Side Validation

Client side validation will be performed by ASP.NET client controls. This form of validation will be used when the validation produces an error (rather than a warning) and it does not require comparison against data in the database. Table 1 contains a list of Validator types and their definition.

Table 1: Validator Types

Type Definition RequiredFieldValidator To require that data has been entered into a field RangeValidator For numeric values with specific ranges (i.e., percentages) RegularExpressionValidator For fields which need to match a pattern of characters CompareValidator To compare the numeric value of one field on the form with another field on the form CustomValidator Other validation which can be done on the client side

4.6.2 Server Side Validation

All validations, which produce warnings rather than errors, and all validations which require complex calculations or comparisons against stored data or data from other forms, shall be done using Server Side validation.

4.6.3 Field Level Validation

All field level validation checks for SMARTForm are stored in the database in the ValidationRulesetID field contained in the Core.Form_Section_SubSection_Item_Rel table.

Associated tables are:

1. ValidationRule_Lkup: stores all single validation rules.

2. ValidationRuleset: stores all validation rule sets that will be used in the data entry form.

3. ValidationRulesetRule_Rel: relationship table that identifies the rules for each rule set.

The SMARTForm web controls all inherit from the base class, SAICCustomControlBase, which implements the IValidator interface.

public abstract class SaicCustomControlBase : CompositeControl, IValidator

Each web control overrides the EvaluateIsValid() method, where all the validation logic are performed, including Internal check, Regular Expression check, and Required checks.

protected override bool EvaluateIsValid()

4.6.4 Cross Field Validation

Cross field validation checks for SMARTForm are configured in the validation.xml file.

Each custom element represents a single cross field validation check. SMARTForm creates CustomValidator on the form while rending the data entry form based on the configuration in the validation.xml file. The SecID and SubsecID indicate the location where the CustomValidator is going to be placed on the SMARTForm. The PartialID allows multiple IDs, delimited with a comma to be passed to the ValidationHandler to perform the validation checks.

<Custom ID="6_9" SecId="6" SubsecId="9" Name="v6_9" ErrorDisplayName="Alternate sources of revenue, other than grants, as a part of the sustainability plan - "> <PartialId>6-9-894,6-9-868</PartialId> <ErrorMessage>Please provide dollar amount if network has alternate sources of revenue, other than grants, as a part of the sustainability plan.</ErrorMessage> <ValidatorHandler>CheckReqNumIfParentAnswersYes</ValidatorHandler> </Custom>

4.7 Workflow Logic

4.7.1 OHIT-Rural Grant Processing Workflow

Figure 4 illustrates the OHIT-Rural workflow.

Figure 4: OHIT-Rural Workflow

Grantee registers with EHB for access to the OHIT-Rural system

Grantee assigns grant’s access and works on report

Does the report pass all data validation rules ?

Submit report to the Project Officer (notification is sent via email)

NO

YES

Project Officer requests changes?

Enter comments for corrections to be made and email notification of the returned report

Yes

No

Report Status: N/A GU Access : N/A EHB Status: Not Started

Report Status: Submitted GU Access : Read Only PO Access: Read Only EHB Status: Submitted By: Grantee For: PO

Report Complete

Grantee navigates to the portfolio’s other deliverables page

PO - Project Officer GU - Grantee User

Grantee user picks the returned report from EHB and works on it

Report Status: ChangeRequested GU Access : Read Only PO Access : Read Only EHB Status: Change Requested By: PO For: Grantee

Grantee clicks on Start Submission and switches to

OHIT-Rural Application

Report Status: InProgress GU Access : Read/Write EHB Status: In Progress By: Grantee For: Grantee

Grantee user enters data

4.7.2 Sequence Diagram

Figure 5 illustrates the report submission process.

Figure 5: Report Submission Process

EHB Grantee Project Officer (PO)

Action: Submit epo t Sub ss o ocess

Action: Return

Action: Submit

OHIT-Rural:

In Progress EHB Status:

In Progress

OHIT-Rural: Submitted EHB Status: Submitted

OHIT-Rural:

Change Requested

EHB Status:

Change Requested

OHIT-Rural: Submitted EHB Status: Submitted

EHB Status:

Not Started OHIT-Rural:

NULL

Action: Start

4.7.3 Report Access with EHBs

Figure 6 illustrates the workflow for determining read/write access for a grant number.

Figure 6: Workflow for Determining Read/Write Access

Start

Access = Read/ Write

Is the report status

"Working" or “Re-Working”

Access = Read

End Loop

No

Yes

Stop

Determining Read/Write Access for a Grant Number

Has the report due date passed?

No

Yes

Get reports due for that grant number

For Each Report

Yes

Is grant for current guidance year

No

No

User has EHB Edit Privilege?

Yes

Grantee user? No

Yes

4.7.4 Workflow Matrix

Table 2 describes the workflow states accessible from each current workflow state.

Table 2: Workflow States

EHBs Status Current Status Eligible Action Action Performer* New Status Not Started NULL Start GU InProgress In Progress InProgress Submit GU Submitted Submitted Submitted Return PO ChangeRequested Change Requested ChangeRequested Submit GU Submitted

* GU = Grantee User; PO = Project Officer

4.8 Comments Module

The following custom user controls have been created for each application to manage comments:

• For OHIT: HRSA.OHITRural.UserControls.Comments

• For ORHP: HRSA.OHITRural.ORHP.Shared.UserControls.Comments

4.9 Email Notification Module

Figure 7 illustrates the email notification module.

Figure 7.a: Email Notification Module

Does Service Start Time = Now?

Email ServiceAlways running on server

No The service compares the current time with the service start time set in the configuration file once every second.

Yes

Get list of all OHITRural grants that have due dates in the future or within the past

30 days.

This is returned as a list of Report objects, each Report storing all relevant information about that particular grant report.

Is EHB PD registered?

Reminder? Delinquency? Resubmission?No No

For each Report in list No

Build Email Body and Subject with notification that no PD is registered

No

Build Email Body and Subject

Yes

Send Email To Both EHB Project Director (PD) and

Project Officer

(PO)

Send Email To Project Officer

(PO)

Is this a Delinquency or Resubmission?

No Send Email To EHB Project Director (PD)

Yes

Reminders are sent at 30, 14, and 7 days before Due

Date

Delinquency Emails Are sent at 7 and 14 days past Due

Date

Resubmission Due Date is the later of original due date or 7 days after the return date. They are sent at 7 and 14 days past this new Due

Date

OHITRural Email Services 1.0

04/10/2008Fiscal Year 2008-2009

Retrieve PD Email address thru EHB EIS web services

End Process

Even though the process has stopped the Email Service continues running on the server. It will start the process again at the same time the next day

Create a data Collection Period

Pull Grants Associated to

Collection Period from GEMSODS

Gets email address, build emails based on dates

a. Notification when period opens.

b. reminder before report due date

c. after due date.

Check if weekly reminder email was sent today Sleep until Next Day

Send email

FORHP Collection Period Opening Release (Scheduled, Monthly)

Notification Service Runs Daily

Get current date

Creates a range from 30 days prior to 60 days after

Get all Grants associated with Data Collection

Period (from

Core.Grants)

Next Day

FORHP Collection Period Notification System Update

Remove Grants Not Reporting

Create Deliverables

Email Services 2.0 January 2016

Figure 8.a: Email Notification Module

4.10 OAT User Interface

4.10.1 OAT Master Page

The same master page class is used for OAT only. Each form specifies the form name and enables and disables tabs and display items depending on context, userid, and role.

4.10.2 OAT Forms

A custom ASPX page has been created for each OAT form. All forms inherit from a shared master page.

4.11 ORHP User Interface

4.11.1 ORHP Master Page

The same master page class is used for all ORHP programs. Each form specifies the form name and enables and disables tabs and display items depending on context, userid, and role.

4.11.2 ORHP Forms

For Hospital Division and OAT, each program contains its own subfolder in the ORHP project. All ORHP forms consist of a separate ASPX page which uses the same master page.

The Community Based Division programs use the SMARTForm approach and share one generic data entry form, which generates the data entry form dynamically depending on the form configuration in the database. Administrative and Project Officer Forms are common to all programs and are stored in a “Shared” directory.

4.12 PDF Form Generation

A Portable Document Format (PDF) is generated using Structured Query Language (SQL) Server Reports. The OHIT/Shared/PDF.aspx and ORHPared/PDF.aspx pages invoke the SQL Reports interface. The following files constitute the SQL Reports:

\Code\Apps\OHITRural\MAINLINE\PDFReport\ OhitPdf\

PDF.rdl BlackLung.rdl OAT.rdl RVHAP.rdl SORH.rdl SubPD_ CrossTb.rdl SubPDF_ Form.rdl SubPDF_ FormSection.rdl SubPDF_ TbCheck.rdl SubPDF_ TbCurrency.rdl SubPDF_ TbDesc.rdl SubPDF_ TbDescNum.rdl

SubPDF_ TbEcoTool.rdl SubPDF_ TbNumber.rdl SubPDF_ TbNumberNT.rdl SubPDF_ TbOrgPro.rdl SubPDF_ TbPercent.rdl SubPDF_ TbPharmacy.rdl SubPDF_ TbQuestion.rdl SubPDF_ TbResep_EEO.rdl SubPDF_ TbSinLine.rdl SubPDF_ TbSinLineN.rdl SubPDF_ TbTotMem.rdl ohitpdf.rptproj ohitpdf.rptproj.user ohitpdf.sln ohitpdf.vssscc ohit_dev.rds ohit_rural.rds ohit_testing.rds orhp_dev.rds

4.13 Roles Module

The AC_Role_Lkup table contains the following entries:

1 Project_Director 2 Grantee_User 3 Project_Officer 4 Help_Desk 5 System_Administrator 6 Bureau_User 7 Lead_Project_Officer 8 Analyst 9 Data Entry 0 Default

Modified Classes:

Core.Security.AuthorityManager

New Classes:

HRSA.OHITRural.ORHP.Shared.RoleAssignment HRSA.OHITRural.OHIT.Shared.RoleAssignment HRSA.OHITRural.ORHP.Shared.AccountSettings HRSA.OHITRural.OHIT.Shared.AccountSettings

4.14 PDF Archive Module

The PDF Archive Module was implemented in the PIMS 1.0 Release.

The following database table was created to store archive locations:

Core.PDFArchive

ReportInstanceID: bigint Path: varchar(max)

The DataCollectionPeriod table will include the following field:

PeriodStatusID: smallint

This field will be related to the following table:

Core.PeriodStatus_Lkup PeriodStatusID: smallint PeriodStatus

PeriodStatus_Lkup will contain the following entries:

1 Closed 2 Open 3 Archived

A file system structure was created to store the PDF images:

[ORHP] \ [Program] \ [Collection Period Label]\

Modified classes include:

HRSA.OHITRural.ORHP.Shared.Admin. _Default HRSA.OHITRURAL.ORHP.Shared.Grantee._Default HRSA.OHITRural.ORHP.Shared.Admin.CollectionPeriod HRSA.OHITRural.ORHP.Shared.PDF

4.15 SMARTForm Approach

The following FORHP programs are implemented using the SMARTForm approach:

• AHT

• DSDN

• Flex

• FMT

• HIT Workforce

• NDP

• PADDP

• RAED

• RBC

• RESEP

• RHCSO

• RHITND

• RHND

• ROOR

• SHCP

• TRC

4.15.1 Form Meta data

A data structure with appropriate hierarchy was created to support the structure that forms typical have (i.e., section, sub-section, and section items.) Figure 8: Form Metadata Object Model shows different parts and the associations among them.

Figure 9: Form Metadata Object Model

This structure shows that the form section is on the top of the hierarchy. The structure has a name and instruction property. The structure may have more than one sub-section. Like the form section, a sub-section also has a name and instruction property, but it may also have other properties that are related to sub-sections grouping and layout. A sub-section can have any number of control items of different types. A control item represents a control on a web form. Each control has properties for name, type, size, CSS class, label, instructions, validators, etc., and anything else that is needed to create the control.

This data model is sufficient for the form metadata, which includes the information a web form needs for sections, sub-sections, and controls.

Determining how to create controls based on the form metadata is handled next. This process must allow controls to be created and placed on web forms dynamically, and centralize the logic of form rendering and processing.

In executing this task, the SMARTForm gets the form metadata from the database Core.Form_Section_SubSection_Item_Rel table. Figure 9 illustrates this process.

Figure 10: Retrieval of Form Metadata from the PIMS Database Tables

A view called vwFormDisplayInfo in the FORHP database was created to capture all information needed for the form. The NHibernate Domain class is illustrated below and was also created to ???.

protected virtual IList<IFormSection> GetFormInfo()

// Get Form Meta data from vwFormDisplayInfo var formControls = thisForm.FormDisplayInfos.Where(f => f.DataCollectionPeriodID == _dataCollPdId);

// Build the FormSection Interface List

CustomValidators = GetCustomValidators();

return fsList;

4.15.2 Form Rendering

SMARTForm renders a form based on the structure described in the following:

Dynamic Rendering For each Section For each Subsection CustomControlCreator.datasource = Subsection.ControlItems;

CustomControlCreator.databind();

End for each End for each

SMARTForm goes through each section of a given form and its sub-sections to create every custom control as specified in the data source. Figure 10 illustrates the SMARTForm Meta Data structure. See Figures 17 and 18 for SMARTForm database diagrams.

protected virtual void DisplayForm(Control phForm) var fsList = GetFormInfo();

// Process page bookmark for each subsection // Loop through FormSections //Section - Add Instruction // Loop through SubSections // Create myFieldSet for each SubSection and add to myPlaceHolder.

// Add Custom Validators to check at least one.

// Add SubSection Instruction // Bind data for all sectionItems under the subsection.

// OR… Bind data at subsection level (for 2D tables)

Figure 11: SMARTForm Meta Data

// Section Item level binding var allControls = new SaicCompositeControl { DataSource = subsec.ControlItems };

allControls.Layout = subsec.Layout;

allControls.DataBind();

myFieldSet.Controls.Add(allControls);

// subsection level binding IList<ISubSection> mysubsec = new List<ISubSection>();

mysubsec.Add(subsec);

var allControls = new SaicCompositeControl { DataSource = mysubsec };

allControls.DataBind();

myFieldSet.Controls.Add(allControls);

protected override void OninitComplete(EventArgs e) RetrieveAllCompositeControls();

protected void Page_Load(object sender, EventArgs e) if (!IsPostBack) BindDataToInputControls();

PageLoad();

4.15.2.1 Control-Agnostic Binding/Processing

After a web form is created, it is easy to programmatically retrieve all of the custom controls from the form and store them in a data structure that is easy to loop through. In .NET, this data structure is normally a list that stores type objects. Although a web form may contain any number of custom controls of different types, they are all from the same base type. Because the controls are designed following the Liskov Substitution Principle (LSP), all of the derived controls can be stored as their base type which provides a common interface through which the properties that the processing and binding logic needs are available – hence the control agnostic processing.

4.15.2.2 Data Binding

After all the controls are dynamically created and placed on a web form, data for each control, if any, needs to be sent to them so that the web form is ready in the latest state.

This is the data binding process. The pseudo-code for the binding process is as follows:

For each control in BaseControlList control.Value1 = ControlValue1 control.Value2 = ControlValue2 control.Value3 = ControlValue3 End for each where ControlValue1, ControlValue2 and ControlValue3 have been automatically set with data automatically retrieved from the database.

This is all the code needed to send data to each control on any form that is based on the SMARTForm design. The addition or removal of a custom control to a web form does not require any change in this logic, and requires only a modification of the form metadata in the database.

4.15.3 Form Data Saving

The Form Data controls inherit from SaicCustomControlBase and implement IDataControl save data. The process of handling form submission is just the reverse of the data binding process. Below is the pseudo-code for this process:

For each control in BaseControlList ControlValue1 = control.Value1 ControlValue2 = control.Value2 ControlValue3 = control.Value3 End for each where the values of the variables ControlValue1, ControlValue2 and ControlValue3 will be persisted to database automatically through data mapping.

4.15.3.1 Control Naming Convention

An important aspect of the SMARTForm design is the use of a naming convention for custom control IDs. This design follows the “coding by convention” design paradigm.

The centralized control rendering logic guarantees that every control is named properly and consistently. This design makes automatic form submission processing (i.e., control-agnostic processing) possible.

Another option was to use a mapping strategy through configuration files, but this option was not chosen due to evidence across the industry that excessive use of configuration files can generate an unwieldy number of files to manage and maintain, making an application unnecessarily complicated.

4.15.4 Form Validation

SMARTForm reads validation from the existing validation.xml file as follows:

• All controls implement the IValidator interface.

• Validation rules are attached to the controls in control creation process.

• Error messages are displayed through ValidationSummary control.

The following pseudo code can be used for this validation:

This code would perform the following activities:

• Implement IValidator.

• ASP.NET runs the validation.

• ASP.NET displays validation messages.

Detailed implementation in each control is as follows:

4.15.5 Server Control Development

Figure 11 depicts the class structure of the SMARTForm.

Figure 12: Class Structure of the SMARTForm

The following describe the server controls:

• SaicCustomControlBase:

o Base class of all custom controls o Inherited from CompositeControl o Implements IValidator o Defines all common properties and methods

• Data entry controls o Inherit from the base control o Implementation of validation checking

• Validation Mechanism o Internal validation check o Accepts custom validation rules o Validation mechanism tied to built-in ASP.NET validation mechanism

• Custom Control Creator:

o Composite DataBound Control o Responsible for creating custom controls o Accepts custom controls collection as its data source

Figure 13: Sample Code for Creating a Textbox Custom Control

4.16 OAT Data Extracts

This module explains the design used to generate OAT SQL Server reports. The reports reflect the legacy OAT reports except that it uses the modified new SQL Server table structures and it allows a user to either open the report in Microsoft Excel or PDF format. A report generation tool and a generalized report class were developed to generate the reports as shown in Figure 13.

-SelectReportingPage() : string +ExecuteReport() : void

+programId : int = 0 +dataCollectionPeriodId : int = 0 +reportInstanceId : int = 0 +fundingTypeId : int = 1 +outputType : string +reportURL : string +dollarAmountPerMile : double = 0

SSReports.cs

ReportingService.cs DataExtracts

Reporting Tool

PDF/Excel Report

Figure 14: OAT Report Data Extracts

4.16.1 Report Generation Tool

OAT Reports can be accessed from the web application by the Reporting Tool link on the left hand side of the application.

The Report generation tool allows a user to select the data extract to display, Program (read only for Grantee, pre-selected with that Grantee’s Program), Funding Type (Pre-selected to All Funding Type), Report Period, and Report Type (either Excel or PDF).

When the Submit Report option is invoked, the report generation class is invoked along with setting the properties for the class.

On the Reporting Tool page, there are several dropdowns, which allow a user to customize the reports. The following subsections describe these dropdowns.

4.16.1.1 Summary Report Dropdown

The Summary Report dropdown feature allows the user to choose and view several summary report options. The value of the dropdown selection is set to the actual report file name (e.g., rdl file) in the report server. Each report calls a specific stored procedure by passing in the required input parameters (i.e., programId, fundingTypeId, and ReportPeriodID).

4.16.1.2 Program Dropdown

The Program dropdown is generated from the Core.OrganizationLkup table. The value is pre-selected and access is set to read only when any Grantee User invokes the Reporting Tool. When a Project Officer or an Administrator invokes the Reporting Tool, they have the privilege to select the organization from the dropdown.

4.16.1.3 Data Collection Period Dropdown

The Data Collection Period dropdown is generated from the Core.DataCollectionPeriod table by filtering for just the OAT program.

Table 3 shows the method/event Handler and purpose when generating the Data Collection Period for the OAT program.

Table 3: OAT Data Collection Period Dropdown

Method/Event Handler Purpose GetDataSet The lookup tables core. OrganizationLkup and core.DataCollectionPeriod are opened and bound to a dataset.

btnGenerateReport_Click The btnGenerateReport_Click method creates an instance of the report generation class SSReports and sets the class property values for reportingPageType, programId, dataCollectionPeriodId, fundingTypeId, reportInstanceId, outputType, and reportURL = "/OHITReports/" + ddlSummaryReport.SelectedValue (the selected summary report dropdown value).

After setting the property values, the Reporting Tool method ExecuteReport is invoked.

4.16.2 Report Generation Class

The Report Generation class was created to handle the generation of different OAT data extracts reports with customized parameters settings from the reporting tools page.

Table 4 shows the report generation class and descriptions.

Table 4: Report Generation Class

Report Generation Class Description Location The CORE\SSRS\SSReports.cs Tool that invoke this class OAT Reporting Tool link under Tools Section on the left hand side of the application.

Purpose Sets the properties programId, DataCollectionPeriodId, reportInstanceId, fundingTypeId, dollarAmountPerMile, outputType, and reportURL by the values passed in by the calling method. The ExecuteReport method calls the report server configurations and opens up the report either in MS Excel or PDF depending on the outputtype value set. This class will be used both by OHIT and ORHP after possible modification to include additional required properties.

4.16.3 Design of Report Generation Class

Table 5 shows the property, type, and values for the design of the report generation class.

Table 5: Design of Report Generation Class

Property Type Value programId int OrganizationID in Core.Organization_Lkup table.

This is the unique ID for a Grantee organization.

dataCollectionPeriodId int DataCollectionPeriodID in Core.DataCollectionPeriod table.

This is a unique Data Collection Period ID.

reportInstanceId int Unique representation of the Grantee in a particular data collection period.

fundingTypeId int FundingTypeID in OAT.FundingType_Lkup table.

1 Any OAT Funded 2 OAT Competitive Grant 3 OAT Congressionally Mandated 4 Non-OAT Funded outputType string EXCEL or PDF reportURL string "/ORHP_Reports/" + rdl File Name from the above table Or "/OHITReports/" + /OAT_HomeCareSavingsReport dollarAmountPerMile double This is the user input value for dollar amount per mile.

This property is only required for the Homecare Savings report.

reportingPageType HomeCareSavingsReport or ReportingTool.

Table 6 shows the method and purpose of the report generation class.

Table 6: Report Generation Class Method and Purpose

Method Purpose SelectReportingPage Values are set depending on the ReportingPageType property. For

HomeCareSavingsReport, the property values ReportPeriodID and DollarAmountPerMile are set and for the ReportingTool, ProgramID, ReportPeriodID and FundingTypeID are set.

ExecuteReport 1. ReportingService class in the location TheCore\Utilities\ is instantiated.

2. URL and Credential properties are set for the ReportingService class.

3. Depending on the outputType either the report is rendered in MS Excel or PDF format.

4.16.4 Data Extract SQL Server Files

The location of the SQL Server .rdl files are OHITRural\Mainline\DataExtracts\. The shared data source folder contains data source files (.rds) and the Reports folder contains SQL Server report files (rdl). A separate rdl file was created using the SQL Server Reporting Tool for each report. The layout and data are set for the reports.

Additional information on report building can be located in the SQL Server reporting tutorial.

Table 7 shows the report name, the name of the rdl file in the report server, and the SQL Stored Procedure name.

Table 7: OAT Reports

Summary Report RDL File Name SQL Stored Procedure Total and Type of Programs per Period

OAT_TotalAndTypeOfProgra mPerPeriod

RPT_OAT_TotalTypeOfProgramPer Period

Total and Type of Sites per Period

OAT_TotalAndTypeOfSitesP erPeriod

RPT_OAT_TotalTypeOfSitesPerPeri od

Total Sites Reporting per Form OAT_TotalSitesReportingPer Form

RPT_OAT_TotalSitesReportingPerF orm

Total Programs Reporting per Form

OAT_TotalProgramsReportin gPerForm

RPT_OAT_TotalProgramsReporting PerForm

Form 1 - Encounters by Specialty

OAT_TypesOfEncountersByS pecialty

RPT_OAT_TypesOfEncountersBySp ecialty

Form 1 - Encounters in MHPSAs by Specialty

OAT_Form1InMHPSAsBySp ecialty

RPT_OAT_Form1MHPSAs_BySpeci alty

Form 1 - Encounters by Setting OAT_Form1BySetting RPT_OAT_Form1BySetting Form 1 - Encounters by Type OAT_Form1ByType RPT_OAT_Form1EncountersByTyp e Form 1 - Interactive vs. Store Forward

OAT_Form1InteractiveVsStor eForward

RPT_OAT_Form1InteractiveVsStore Forwards

Form 2 - Specialty/Service Availability

OAT_Form2 RPT_OAT_Form2

Form 2 - Specialty/Service OAT-funded Only

OAT_Form2a RPT_OAT_Form2a

Form 3 - Patient Travel Saved OAT_Form3 RPT_OAT_Form3 Form 4a - Practitioners Referring by Specialty

OAT_Form4a RPT_OAT_Form4a

Form 4b - Practitioners Referring by Referrals

OAT_Form4b RPT_OAT_Form4b

Form 5 - Supervision of Students/Trainees

OAT_Form5 RPT_OAT_Form5

Form 6 - Informal Supervision and Mentoring

OAT_Form6 RPT_OAT_Form6

Form 7a - Other Uses of System OAT_Form7a RPT_OAT_Form7a Form 7b - Clinical Vs. Other Sessions

OAT_Form7b RPT_OAT_Form7b

Form 8 - Clinical Travel OAT_Form8 RPT_OAT_Form8 Form 9 - Telehealth Consultants Continuing Participation

OAT_Form9 RPT_OAT_Form9

Form 10 - Referring Practitioners Continuing Participation

OAT_Form10 RPT_OAT_Form10

Form 11a - Homecare Savings by Program

OAT_Form11a RPT_OAT_Form11a

Form 11b - Homecare Savings by Period

OAT_Form11b RPT_OAT_Form11b

Form 14 - Patients and Diabetes by Program

OAT_Form14 RPT_OAT_Form14

4.17 Telehealth Resource Center Grant Program (TRC)

The TRC was a program that was added in Release 5.1. Figure 13 illustrates the data model for the TRC program, which is used to capture the data from TRC Data Entry Screen.

Figure 15: TRC Program Data Model

4.17.1 TRC Reports

The two reports available in the TRC program are listed in Table 8.

Table 8: TRC Program Reports

Report Name RDL File Name TRC Program Rollup Measures SummaryRpt.rdl TRC Originating Sites by State Report TRC_OriginatingSitesByState.rdl

TRC Report rendering code is as follows:

e

4.18 ORHP Reports

ORHP Reports use SMARTReports to generate reports with different types of data and charts, including the SummaryRpt, StatisticRpt, and TrendRpt for all Community Based Division (CBD) programs. State Office of Rural Health (SORH) and Flex reports are the traditional SQL Server Reporting Services (SSRS) reports. Table 9 lists the ORHP reports. See Figure 19 for the SMARTReport database diagram.

Table 9: ORHP Reports

Summary Report RDL File Name Summary Report SummaryReport.rdl Statistic Report StatisticRpt.rdl Trend Report TrendReport.rdl SORH TA Client by State Summary Report SORH_TaClientByStateSummary SORH TA Client by State Trend Report SORH_TaClientByStateTrending MHF EMS Measures Trend Report MHF_EmsMeasuresTrending Workforce Rollup Report Workforce_RollupRpt BLCP GPRA Report BlackLung_GPRARpt.rdl BLCP Summary Program Rollup Report BlackLung_SummaryRpt.rdl RHCSO Comparison Summary Report NCRSummaryReport.rdl RHCSO Comparison Trend Report NCRTrendReport.rdl

5 External Interfaces

This section describes the interfaces between the PIMS web application and its external interfaces.

5.1 Email Notifications

Depending on each stage of the PIMS Report workflow, each involved user will be notified by email. For example, when a Project Officer returns a report for changes, an email will be sent to the affected users. The Internet Information Services (IIS) SMTP server will send all emails.

5.2 EHBs UI Integration

5.2.1 Hrsa.Integration.PlatformLite

Hrsa.Integration.PlatformLite is a common component project, which is used to interface with PlatformLite. The project structure is as follows:

Hrsa.Integration.PlatformLite\Hrsa.Integration.PlatformLite Platform\

HttpModule\ HrsaHttpApplication.cs NavigationItem.cs HrsaBasePage.cs HrsaBaseMasterPage.cs

5.2.2 Platform Lite

The EHBs User Interface (UI) implemented in the PIMS 9.1 Release is based on ASP.NET’s Master to ensure a consistent look and feel. In order for Leidos to build common functionalities for all applications that integrate with the EHBs using the UI and at the same time reduce or eliminate the dependency of the grants systems on the Platform Lite, Leidos implemented the structure illustrated in Figure 15. This process is an iteration of a larger process, Integration Architecture.

Figure 16: EHBs UI Integration Architecture

The top box in the diagram above is where three fundamental classes are created to inherit from their corresponding classes in the Platform Lite’s UI implementation. These classes and their inheritance are shown in Figure 16.

Figure 17: Integration Classes

These classes are from the namespace, Hrsa.Integration.PlatformLite. All Leidos classes designed for HRSA program-wide use will have the word “Hrsa” as their prefix.

Class HrsaBaseMasterBase inherits from BaseMasterPage, which is the base class of the code-behind of the master page and it inherits from the ASP.NET’s built-in MasterPage class. The code-behind of Leidos’ master page inherits from HrsaBaseMasterBase.