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

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

Table of Contents

List of Figures

List of Tables

iv

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).

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

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.

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.

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.

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.

Design Considerations Goals and Guidelines

· Better user experience

· Navigation

· Performance

· Simplicity

· Technical

· .NET Framework 4.6

· 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 and creation of the upload 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 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.

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.

Figure 1: OHIT-Rural Software Architecture 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.

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.

Software Tasks 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

· PIMS OAT Data Dictionary.rtf

· Erwin_OAT.pdf

· Erwin_Core.pdf

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

Figure 2: OHIT-Rural Data Access Layer

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 EHB_ScheduleStatus GetStatus(string iEHBGrantID, string iEHBDeliverableID) public void UpdateStatus(EHB_ScheduleStatus iNewStatus,

string iExternalID)

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)

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.

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

· Orhp.Domain

· REISys.PlatformLite.Core

· REISys.PlatformLite.Security

· REISys.PlatformLite.Services

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

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

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

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

Database Tables CORE.AC_Resource

CORE.Form_Lkup

CORE.FormGuidance_Rel

// permissions for resources/URLs CORE.AC_User CORE.AC_Role_Lkup CORE.AC_UserRole_Rel CORE.AC_ResourceRole_Rel 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.

Validation Framework 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

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.

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() 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> Workflow Logic OHIT-Rural Grant Processing Workflow Figure 4 illustrates the OHIT-Rural workflow.

Figure 4: OHIT-Rural Workflow

Sequence Diagram Figure 5 illustrates the report submission process.

Figure 5: Report Submission Process

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

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

Table 2: Workflow States

* GU = Grantee User; PO = Project Officer 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 Email Notification Module Figure 7 illustrates the email notification module.

Figure 7.a: Email Notification Module

Figure 7.a: Email Notification Module

OAT User Interface 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.

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

ORHP User Interface 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.

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.

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 Roles Module The AC_Role_Lkup table contains the following entries:

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 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:

The DataCollectionPeriod table will include the following field:

PeriodStatusID: smallint

This field will be related to the following table:

PeriodStatus_Lkup will contain the following entries:

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

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

Modified classes include:

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

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 8: 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 9: 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;

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

Dynamic Rendering For each Section

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 10: 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)

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.

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

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.

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

End for each where the values of the variables ControlValue1, ControlValue2 and ControlValue3 will be persisted to database automatically through data mapping.

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.

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:

Server Control Development Figure 11 depicts the class structure of the SMARTForm.

Figure 11: Class Structure of the SMARTForm The following describe the server controls:

· SaicCustomControlBase:

· Base class of all custom controls

· Inherited from CompositeControl

· Implements IValidator

· Defines all common properties and methods

· Data entry controls

· Inherit from the base control

· Implementation of validation checking

· Validation Mechanism

· Internal validation check

· Accepts custom validation rules

· Validation mechanism tied to built-in ASP.NET validation mechanism

· Custom Control Creator:

· Composite DataBound Control

· Responsible for creating custom controls

· Accepts custom controls collection as its data source

Figure 12: Sample Code for Creating a Textbox Custom Control 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.

Figure 13: OAT Report Data Extracts 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.

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).

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.

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

core.DataCollectionPeriod are opened and bound to a dataset.

reportURL = "/OHITReports/" + ddlSummaryReport.SelectedValue (the selected summary report dropdown value).

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

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

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.

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

This is the unique ID for a Grantee organization.

This is a unique Data Collection Period ID.

Or "/OHITReports/" + /OAT_HomeCareSavingsReport

reportingPageType

HomeCareSavingsReport or ReportingTool.

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

Table 6: Report Generation Class Method and Purpose

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.

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

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 14: TRC Program Data Model TRC Reports The two reports available in the TRC program are listed in Table 8.

Table 8: TRC Program Reports

TRC Report rendering code is as follows:

e 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

External Interfaces

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

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.

EHBs UI Integration 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 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 15: 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 16: 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. Functionalities that are common to all grants systems and are related to the master page will be implemented in this class so that they can be shared among different grants systems. Common features include side and top menus, among others.

The HrsaBasePage class inherits from BasePage which in turn inherits from the built-in ASP.NET page class. The code-behind class of every ASP.NET page of each grant system will inherit from it. Functionalities that are page specific and common to all grants systems will be implemented in this class so that common functionalities will have only one implementation.

The HrsaHttpApplication class inherits from the REISys.Platform.Web.PlatformApplication, which inherits from the System.Web.HttpApplication. Application-level initializations of Platform Lite are in REISys.Platform.Web.PlatformApplication. Application-level initializations that are common to all grants systems level are set in HrsaHttpApplication. Grants system specific application level settings are initialized in their respective global.asa.cs which inherits from HrsaHttpApplication.

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.

Left Menu and Top Menu Implementation Platform Lite’s left and top menu are implemented using Telerik’s RadPanelBar.

Data Structure Class Hrsa.Integration.PlatformLite.NavigationItem inherits from REISys.Platform.Services.Layout.NavigationItemModel, which has the following definitions:

public class NavigationItemModel : BaseNavigationItemModel public NavigationItemModel();

[XmlElement("navigation")] public List<NavigationItemModel> ChildNavigationItems { get; set; } public string IconImageUrl { get; set; } public int PrivilegeId { get; set; } public string ResourceId { get; set; } [XmlElement("roleid")] public string RoleId { get; set; }

Its base class, BaseNavigationItemModel, has the following definitions:

public class BaseNavigationItemModel : DisableableControlModel public BaseNavigationItemModel();

[XmlAttribute] public int AcessKey { get; set; } [XmlAttribute("class")] public string Class { get; set; } [XmlAttribute("destination")] public string Destination { get; set; } [XmlAttribute("navigationItemId")] public string Id { get; set; } [XmlAttribute("isHeader")] public bool IsHeader { get; set; } [XmlAttribute("markupID")] public string MarkupId { get; set; } [XmlAttribute("parentID")] public string ParentNavigationItemId { get; set; } [XmlAttribute("target")] public string Target { get; set; } [XmlAttribute("displayValue")] public string Text { get; set; } [XmlAttribute("description")] public string ToolTip { get; set; }

This is the data structure that renders the Platform Lite’s left menu and top menu. Leidos created a class, Hrsa.Integration.PlatformLite.NavigationItem, which inherits from the base class, REISys.Platform.Services.Layout.NavigationItemModel, and leaves room for adding common functionalities. This is a simple and straightforward structure which allows the option to create multiple levels of hierarchies.

Originally, Platform Lite required that only authenticated users have any menus. Due to the need to support non-EHBs users, the requirement was removed from Platform Lite. With this requirement removed, the Grants systems have the freedom to use the Telerik control to create their own menus. In order to have a consistent way of rendering both the left and top menus, a public property was created on the SAICBaseMasterPage class to store the menu data as a collection of type, Hrsa.Integration.PlatformLite.NavigationItem. The following illustrates this:

public IList<NavigationItem> SideMenuItems get { return _sideMenuItems; } set { _sideMenuItems = value; }

A private method RenderLeftMenu () is created on the SAICBaseMasterPage class to actually render the left menu using the data stored in SideMenuItems. As seen from the code below, this method simply translates each data element stored in SideMenuItems into the type of its base class REISys.Platform.Services.Layout.NavigationItemModel and creates the menu down to the third level.

foreach (var ni in SideMenuItems) Layout.LeftMenu.FlattenedItems.Add(new NavigationItemModel {Text = ni.Text, Id = ni.Id});

if (ni.ChildNavigationItems.Count > 0) foreach (var ci in ni.ChildNavigationItems) Layout.LeftMenu.FlattenedItems.Add(ci);

foreach (var cii in ci.ChildNavigationItems) Layout.LeftMenu.FlattenedItems.Add(cii);

To create a left menu, a Grant system simply inherits from the SAICBaseMasterPage class, then gets menu data and transforms the data so that the data can be stored in SideMenuItems. This is all a Grant system needs to create a left menu.

Top Menu The top menu is created in a way that is slightly different from the left menu in that the top menu has items that are carried over from the EHBs, circumventing the need to create a brand new top menu.

From Platform Lite source code, each top menu item is identified by the top most item. For example, the menu “Support” is identified by the item represented by “Support”. To append an item to the Support menu, a menu item of type, NavigationItem, was created as shown below:

var contactOrhp = new NavigationItem() Id = item.Id, MarkupId = item.MarkupId, Text = item.Text, Destination = item.Destination

In addition, the parent top menu and add the menu item as its new child is shown below:

Layout.Header.TopMenu.Items.Single(i => i.Text == item.ParentMenu).ChildNavigationItems.Add(contactOrhp);

MasterPage All integrated web pages in PIMS use the SAICMasterPage, which is a nested master page that inherits from the PlatformLite Base MasterPage.

Appendix

Figure 17 displays the SMARTForm Meta Data…