2016N17778Attachments.pdf

ATTACHMENTS

ATTACHMENT A

Screen Shots of the Data Portal and CAT

1. Portal Entry and Administrative Overview

2. MMP Overview

3. NHBS Overview

4. Issues Management Tool (formerly known as TIMS)

5. Contact Attempt Tracking

1. Portal Entry and Administrative Overview

2. MMP Overview

3. NHBS Overview

4. Issues Management Tool (formerly known as TIMS)

5. Contact Attempt Tracking (CAT)

ATTACHMENT B

High Level Functional Requirements Document for Enhanced Data Portal:

Web-based Medical Monitoring Project (MMP) Tracking Module

1.0 INTRODUCTION

The purpose of this document is to provide a general framework of the business processes, the main functionalities, core data elements, and key features typically required to operate the MMP Tracking Module.

2.0 SYSTEM DESCRIPTION

In the current process, MMP project collects five types of data: tracking data, contact data, interview data, abstraction data, and information on all sampled persons for the minimum dataset. Of which, tracking and contact data have been collected using the

Contact Attempt Tracking (CAT) and The Data Portal Tracking System.

Tracking data consist of project operational information collected in order to recruit persons for participation in MMP, and will be used to inform project staff regarding progress of data collection and provide dispositions to CDC to create statistical weights for data analysis.

Contact data consist of data involving how and when the project areas contact sampled persons, as well as the outcome and responses to these contact attempts. These data will be used to monitor the burden of locating sampled persons on the project area staff and to determine best practices for locating and recruiting sampled persons.

The tracking, interview, abstraction, and minimum dataset data will be used by the contractor to create analytic data files, which will be used by CDC and the project sites to describe the populations of HIV-infected persons and address project-related questions.

MMP project partners have been using two data collection and management tools to collect contact and tracking data. Contact Attempt

Tracking (CAT), a Windows based Microsoft Access tool, is used for collection of contact and tracking data locally; and the Data

Portal Tracking System, a web-based application, is for collection of subset of contact and tracking data.

The rationale for building the CAT was to provide project partners with an electronic tool to maintain and manage sample and contact data at local level. Thus no any personal identifiable information (PII) could be accessed by other partners. Even though the CAT is not required by MMP, the majority of project sites have been using it to manage and track contact attempts in the 2015 cycle.

The Data Portal Tracking System provides project partners with the ability to enter non-PII containing contact and tracking data into the system. Based on these information, MMP team determines the progress and burden of the project at each site and identify the best practices for future improvements.

Currently, there are no any other methods to effectively exchange data between the CAT and the Data Portal Tracking System.

Therefore, those project sites where using both tools have to enter the same information separately to each system, which is a burden to the project partners.

The other limitations of the current system set-up are:

annual installation of updated software at site level, limited CDC resources on trouble shooting software issues, and potential inconsistencies of data between CAT and the Data Portal Tacking System.

To address these limitations, MMP needs to enhance the web based Data Portal Tracking System by incorporating functionalities of the two existing systems described above, and using the available IT technology to address these limitations. The enhanced Data

Portal Tracking System will be renamed as The MMP Tracking Module, which needs to:

combine existing functionalities that the CAT and the Data Portal Tracking System have, integrate with the current Data Portal Tracking System, keep all PII and localized data locally, allow data entry when not online, allow customization at the local level, provide access and page view based on user roles and privileges, and meet the information security guidance described in the Contract.

As an enhancement of the existing Data Portal, the MMP Tracking Module allows project partners to track and manage potential participants’ contact attempts and to eliminate the need to enter the subset data into a separate system. Access to the module is based on user roles and privileges. User can only access the dataset within their granted roles and privileges. For example, individual project site can only access the data that belongs to their site. Further, the MMP Tracking Module must save PII and localized data to corresponding local site and not allow any access from the MMP Tracking Module central server or any other systems and modules.

However, all software updates and fixes must be pushed from the MMP Tracking Module of the Data Portal.

3.0 WEB-BASED MMP TRACKING MODULEBUSINESS PROCESS

At beginning of each MMP data collection cycle year, CDC provides every project site with sample datasets extracted from Enhanced

HIV/AIDS Reporting Systems (eHARS). Project sites will import their own sample datasets into the MMP Tracking Module which saves data into two different locations depending on the nature of the variables: data containing PII are saved to corresponding local session of the MMP Tracking Module at local level; non-PII data are saved to the central database server of the MMP Tracking

Module which is a part of the Data Portal.

After sample datasets are imported into the MMP Tracking Module, the Module allows project sites to do the following at site level:

view sample person;

add/edit/delete events for each sample;

search sample persons and track leads and contact attempts;

save/submit data, which saves PII and local specific data to local database and saves rest of the data to centralized database of the MMP Tracking Module; and generate and view dynamic reports.

The Module also allows CDC user to view non-PII data which are stored at the central database server of the MMP Tracking Module and to dynamically generate CDC level tracking reports.

The diagrams below provide an overview of the high level data flows between user inputs and databases.

1) This diagram shows import process at site level and destination of data with or without PII.

2) This diagram below shows how the MMP Tracking Module responds to users with different roles and privileges

3) The diagram below shows how the module responds to user when internet connection is or is not available when performing data entry.

In summary, at site level the MMP Tracking Module allows project sites to upload and view site specific eHARS data on sample persons, tracks attempts to find or contact sampled persons, provides users with the ability to conduct data entry activities on one view which combines data stored locally and at the

Data Portal server, and allows continued data entry when internet connection is not available.

In addition, the Module provides CDC and the Contractor with the ability to view subset of the data (non- PII) at site and national levels, has the ability to push all updates and fixes from the MMP Tracking Module server, and adheres to information security requirements described in the Contract.

Depending on roles and privileges, users use the MMP Tracking Module to perform following activities to manage data and progresses.

1) Management of four types of data

• eHARS information for each sampled person

• Additional leads useful for locating sampled persons

• Attempts to use leads to locate and contact sampled persons

• Recruitment, interview, and medical record abstraction (MRA) disposition and tracking information

2) Management of progresses

• Organize the work of location and recruitment

• Evaluate progress in locating and recruiting sampled persons

• Monitor individual staff effort and performance

• Identify most effective lead sources

• Identify recruitment opportunities that may not have been fully utilized

3) Management of progresses of each project site

• Verify that staff are performing their duties as required

• Provide recommendations for improvement

4.0 CORE REQUIREMENTS

4.1 User Roles and Privileges

To protect personal identifiable information (PII), access to the MMP Tracking Module is restricted to pre-approved users with valid login ID and password. Only the following four types of users are granted access: pre-approved MMP project site users, CDC users, ICF developers and system administrators, and ICF technical support and testers. The module displays the page view and functionality based on their user roles and privileges. When site level users access the module, the module webpage displays information pulled from local database and the Data Portal server. Similarly, when site level users save or submit data, the module sends data to local server if it contains PII and sends data to the Data Portal if it does not contain PII. See the table below for details on the user roles and privileges.

The table-1, User Roles and Privileges

Project Site Users CDC Users

The Contractor

Developer /Admin Technical Support/Tester

Site

Specific Site

Specific National

Site Specific

Site Specific

National Site

Specific Site

Specific National

Site Specific

Site Specific

National

Local Server

(PII)

Data Portal (Non-

PII)

Data Portal (Non-

PII)

Local Server

(PII)

Data Portal (Non-

PII)

Data Portal (Non-

PII)

Local Server

(PII)

Data Portal

(Non-PII)

Data Portal (Non-

PII)

Local Server

(PII)

Data Portal

(Non-PII)

Data Portal (Non-

PII)

eH A

R S

S am p le

D at a Import Yes Yes

Add

Delete

Edit Yes Yes

View Yes Yes Yes Yes Yes Yes Yes Yes Yes

Search Yes Yes Yes Yes Yes Yes Yes Yes Yes

Dynamic Reports

Yes Yes Yes Yes Yes Yes Yes Yes Yes

C o n ta ct A tt em p t

E ve n ts

Add Yes Yes

Delete Yes Yes

Edit Yes Yes

View Yes Yes Yes Yes Yes Yes Yes Yes Yes

Search Yes Yes Yes Yes Yes Yes Yes Yes Yes

Dynamic Reports

Yes Yes Yes Yes Yes Yes Yes Yes Yes

C D

C S u b

D at as et

Add Yes Yes

Delete Yes Yes

Edit Yes Yes

View Yes Yes Yes Yes Yes Yes Yes Yes Yes

Search Yes Yes Yes Yes Yes Yes Yes Yes Yes

Dynamic Reports

Yes Yes Yes Yes Yes Yes Yes Yes Yes

T ra ck in g D at a

Add Yes Yes

Delete Yes Yes

Edit Yes Yes

View Yes Yes Yes Yes Yes Yes Yes Yes Yes

Search Yes Yes Yes Yes Yes Yes Yes Yes Yes

Dynamic Reports

Yes Yes Yes Yes Yes Yes Yes Yes Yes

P se u d o D at a

Import Yes Yes Yes Yes Yes Yes Yes Yes Yes

Add Yes Yes Yes Yes Yes Yes Yes Yes Yes

Delete Yes Yes Yes Yes Yes Yes Yes Yes Yes

Edit Yes Yes Yes Yes Yes Yes Yes Yes Yes

View Yes Yes Yes Yes Yes Yes Yes Yes Yes

Search Yes Yes Yes Yes Yes Yes Yes Yes Yes

Dynamic Reports

Yes Yes Yes Yes Yes Yes Yes Yes Yes

D ev el o p m en t/

U p d at es

Import Yes Yes Yes

Add Yes Yes Yes

Delete Yes Yes Yes

Edit Yes Yes Yes

View Yes Yes Yes

Search Yes Yes Yes

Dynamic Reports

Yes Yes Yes

4.2 Technical Requirements

The MMP Tracking Module is an enhancement to the existing Data Portal by integrating the functionalities from two disparate applications into one module which aims to improve the current working processes. See below for the high level technical requirements:

1) Internet connection capabilities

a) MMP Tracking Module needs to have the capability to connect to landline or cellular network

b) Workstation needs to have either Internet Explorer or Google Chrome as browser

2) Web-based Offline capabilities:

To meet the requirements described above in the business processes, and to present the content correctly on the web pages, HTML5 is an essential tool for the development of the MMP Tracking Module.

a. The Local Session feature allows PII containing data and localized data to be stored at local level

b. The Online/Offline Application feature allows continuous data entry when internet connection is not available. Data automatically synchronize with the Data Portal server when internet/WiFi connection is resumed.

3) Backend data storage and management

a) MMP Tracking Module uses SQL server database for data storage and management

b) MMP Tracking Module data must be linked with the entire existing MMP data stored at the Data Portal

c) MMP Tracking Module allows users to save data into local directory for PII containing data and into the Data Portal for non-PII containing data

4) Graphic User Interface(GUI) design

Refer to the attachment H: Current MMP Tracking system - Project-Site View and attachment I: Current MMP Tracking system - CDC View.

a) User friendly graphic interface provides easy navigation.

b) The interface integrates with the exiting Data Portal Tracking System with consistent style sheets.

c) Tabs or dashboard buttons are available for user to navigate through different sections of the module

5) Core features

a) Users have access to multiple sections of the main menu items simultaneously

b) Columns of all line list tables are sortable by descending or ascending order.

c) Rows of the entire sample can be selectable when selecting consecutive rows or using Control key (on the key board) to select random rows; one can then apply functions to the selected sample.

c) Filters can be applied to show a subset of the entire sample.

d) Filters can be canceled by a Clear Filters button.

e) Print function is available for printing case based form, line list sampled person, active pages, and reports.

f) Download is available for project site to download site level data. This site level data consist of data stored at both local and the Data Portal levels.

g) Browser standard toolbars and navigation arrows are available for user to navigate pages and to conduct basic actions, e.g., printing function.

h) Users with View privilege is able to view information only but not be able to edit/delete/ save/submit any data records.

i) Users with Add privilege can add new events to a selected sample person record.

j) Users with Edit privilege can modify data records.

k) Users with Delete privilege can delete events created for the sampled person, e.g. delete contact attempts events, delete facilities associated to the sampled person.

l) Save function: Data can be saved to appropriate databases when there are validations pending or when required data fields are blank.

m) Submit: Data are submitted to appropriate databases when all validations are passed. A submission status message is available to user on whether the record submitted was saved or submitted.

n) Import: The module allows appropriate users to import data into local directory for PII containing data and into the Data

Portal for non-PII containing data.

o) Data security and section 508 requirements are required as described in the contract.

p) C&A documents needs to be updated to reflect changes to the Data Portal and require approval from CDC before deployment.

6) Customization of local databases for project sites

The module allows project sites to customize content specific to their needs. However, all core content and features specified in this document and the attachments H and I cannot be modified by the site users. In addition, all localized content must be saved to the local database which can only be accessed by the corresponding project site. To be specific, the module allows project sites to

a) Create new fields or edit existing fields

b) Create new reports or edit existing reports

c) Customize drop-down menus

4.3 Site Level Page View Requirements: Refer to the attachment H: The Current MMP Tracking Systems - Project-Site View

CDC MMP project partners currently use two systems to conduct their contact attempt tracking activities. One is the Contact

Attempt Tracking (CAT, Microsoft Access) and the other is the Tacking System of the Data Portal (Web-based). Details are described in the attachment containing the core features and pages views. For each core activity, further explanation is provided on CAT view and the Data Portal view. For the new module, beside new requirements described in this document, the enhanced

MMP Tracking Module shall incorporate all existing features and functionalities described in the attachments H and I.

Main Menu

Main Menu can be displayed after users log into the Data Portal MMP Tracking module. The menu contains the following features: Import, Search (“find record”), Data Management, Progress Tracking, and Reports.

1) Import data

There are three sources of data which need to be imported:

a. Site specific eHARS sample data (containing PII)

b. Sample data generated by CDC (containing PII)

c. Data from other lead sources (containing PII)

At beginning of each project cycle, when users log into the MMP Tracking module for the first time, users can only access the Import function; after the sample data are successfully imported into the appropriate database tables, the rest of the features will become active. The module will not allow to create or delete person records once sample data are imported into the MMP Tracking module. Import function shall allow updates to be made through out the cycles.

2) Search and Manage data

Site level page view for project sites will display combined site specific data stored locally and at the Data Portal.

Correspondingly, when data are submitted or saved, they will be saved to local location for PII containing data and to the

Data Portal for non-PII.

a. Users are able to conduct following activities on individual person records

a) Search by name, lead, or ParID

b) Browse records

c) Edit individual person records

i. Create/Edit/View/Delete events for all tables that store data related to case information, contact information, lead searches, contact attempts, and disposition tracking.

ii. These person events must be linked with all tables that store data related to the person records.

d) Prohibit creating or deleting person records

b. Users are able to conduct the following activities on facility records

a) Search for a facility by ID or name

b) Browse records

c) Edit individual facility records

i. Create/Edit/View/Delete events for all tables that store data regarding facilities, including creating, editing, and deleting records of individual facilities.

ii. These facility events must be linked with all tables that store data related to the person records. This feature is described in the Tracking section in the site view document.

3) Progress Tracking and Reports

a. Track sampled person and facility

Report data submissions status for interviews, MRAs, re-abstractions, participation and person dispositions

b. Run, display, and export reports (see appendixes A and B for existing reports)

c. Reports for project sites will combine data stored locally and at the Data Portal. There are three types of site level reports:

a) Summary reports

b) Line lists

c) Details of single cases

Additional types of reports may be identified when the contract is awarded.

4.4 CDC/Contractor Page View Requirements: Refer to the attachment I, Current MMP Tracking Systems - CDC View.

CDC and the Contractor are permitted to view data that are stored at the Data Portal. These data should not contain PII. The

Main Menu display active features based on the user roles and privileges. The Module allows these users to

a. View data stored at the Data Portal,

b. Run, display, and export reports (see the attachment I, Current MMP Tracking Systems - CDC View for existing reports)

a) Reports for CDC will use data only stored at the Data Portal

Please also refer to the table-1: User Roles and Privileges

4.5 Database requirements

The data in the MMP Tracking Module must be dynamically linked with the data stored in other MMP database tables from the

Data Portal, e.g., MMP Tracking data link with the Interview and the MRA dynamically and in real time.

The module can log user activities, e.g. log on histories, date and time stamps of changes.

When a variable is deleted/modified from the MMP Tracking Module, the database needs to perform cascading deletes/changes in the database tables to reflect all changes that need to be made.

4.6 Infrastructure requirements

As an enhancement module to the Data Portal, the MMP Tracking Module uses the existing server infrastructure for application development, testing, staging, and deployment. Testing accounts for CDC, the contractor testers, and selected project sites (TBD) are available throughout the development life cycle.

5.0 DATA DESCRIPTION AND MANAGEMENT

5.1 Datasets import

The sources of the import datasets are generated from CDC and sites. All datasets contain Personal Identifiable Information (PII).

The approximate numbers of cases, data tables, and variables per table in the existing CAT and DCC tables are shown in the table below.

Existing CAT Existing Tracking system in Data portal

Cases 200-800 per site; approximately 10,000 total 200-800 per site; approximately 10,000 total

Number of data tables 45 44

Mean number of variables per table

10 13

5.2 Data linkage and quality

Data linkage shall be established among MMP Tracking, Interview and MRA databases with validations that identify record status and validity. The validations shall be applied at variable, page, and record levels to ensure data quality at the source level.

6.0 PERFORMANCE

The module shall handle at least 50 users simultaneously with acceptable page response time.

Glossary

a) Contact Attempt –when you use a given lead to try to find a sampled person (e.g. using a phone number to call a sampled person is a contact attempt).

b) Contact Method – ways that one might use to contact a sampled person.

c) Contact Outcome – outcomes for contact attempt

d) eHARS – Enhanced HIV/AIDS Reporting System is a browser-based application provided by CDC for HIV surveillance and reporting.

e) Event – any activity that would create an entry in a table.

f) Lead Source – origin of the lead

g) Lead Search – when you search a data source for a lead, whether or not you find one.

h) Lead Type – types of information you may encounter in your searches.

i) Lead – a piece of information such as a phone number, street address, or care facility name that might help you locate a person.

j) Roles – positions held by project area staff whose work will be tracked in the CAT.

k) StateNo – unique record ID used in eHARS

l) Unsuccessful Search – attempt to find a lead which does not result in new information.

ATTACHMENT C

MMP Operations Resources: http://www.cdc.gov/hiv/statistics/systems/mmp/resources.html

ATTACHMENT D

NHBS Operations Resources: http://www.cdc.gov/hiv/statistics/systems/nhbs/operations.html http://www.cdc.gov/hiv/statistics/systems/mmp/resources.html http://www.cdc.gov/hiv/statistics/systems/nhbs/operations.html

ATTACHMENT E

ASSURANCE OF CONFIDENTIALITY

FOR THE NATIONAL HUMAN IMMUNODEFICIENCY VIRUS (HIV) SURVEILLANCE SYSTEM (NHSS)

AND SURVEILLANCE-RELATED DATA (INCLUDING SURVEILLANCE INFORMATION,

CASE INVESTIGATIONS SUPPLEMENTAL SURVEILLANCE PROJECTS,

RESEARCH ACTIVITIES, AND EVALUATIONS)

The National HIV Surveillance program is being coordinated by the HIV Incidence and Case Surveillance Branch (HICSB) and the Behavioral and Clinical Surveillance Branch (BCSB) of the Division of HIV/AIDS Prevention (DHAP), in the

National Center for HIV/AIDS, Viral Hepatitis, STD and TB Prevention (NCHHSTP), a component of the Centers for

Disease Control and Prevention (CDC), an agency of the United States Department of Health and Human Services. The surveillance information requested by CDC consists of reports of persons with suspected or confirmed HIV infection at any clinical stage of disease, including children born to mothers infected with HIV, and reports of persons enrolled in studies designed to evaluate the surveillance program. The information collected by CDC is abstracted from laboratory, clinical, and other medical or public health records of suspected or confirmed HIV cases; and from surveys or investigations that interview persons in recognized HIV risk groups or known to have a diagnosis of HIV.

Surveillance data collection is conducted by state and territorial health departments which forward information to CDC after deleting patient and physician names and other identifying or locating information. Records maintained by CDC are identified by computer-generated codes, patient date of birth, and a state/city assigned patient identification number. The data are used for statistical summaries and research by CDC scientists and cooperating state and local health officials to understand and control the spread of HIV. In rare instances, expert CDC staff, at the invitation of state or local health departments, may participate in research or case investigations of unusual transmission circumstances or cases of potential threat to the public health. In these instances, CDC staff may collect and maintain information that could directly identify individuals.

Information collected by CDC under Section 304 and 306 of the Public Health Service Act (42 U.S.C. 242b and 242k) as part of the HIV surveillance system that would permit direct or indirect identification of any individual or institution on whom a record is maintained, and any identifiable information collected during the course of an investigation on either persons supplying the information or persons described in it, is collected with a guarantee that it will be held in confidence, will be used only for the purposes stated in this Assurance, and will not otherwise be disclosed or released without the consent of the individual or institution in accordance with Section 308 (d) of the Public Health Service Act (42 U.S.C. 242m(d)). This protection lasts forever, even after death. Information that could be used to identify any individual or institution on whom a record is maintained by CDC will be kept confidential. Full names, addresses, social security numbers, and telephone numbers will not be reported to this national HIV surveillance system. Medical, personal, and lifestyle information about the individual, and a computer-generated patient code will be collected.

Surveillance information reported to CDC will be used without identifiers primarily for statistical and analytic summaries and for evaluations of the surveillance program in which no individual or institution on whom a record is maintained can be identified, and secondarily, for special research investigations of the characteristics of populations suspected or confirmed to be at increased risk for infection with HIV and of the natural history and epidemiology of HIV. When necessary for confirming surveillance information or in the interest of public health and disease prevention, CDC may confirm information contained in case reports or may notify other medical personnel or health officials of such information; in each instance, only the minimum information necessary will be disclosed.

No CDC HIV surveillance or research information that could be used to identify any individual or institution on whom a record is maintained, either directly or indirectly, will be made available to anyone for non-public health purposes. In particular, such information will not be disclosed to the public; to family members; to parties involved in civil, criminal, or administrative litigation, or for commercial purposes; to agencies of the federal, state, or local government. Data will only be released to other components of CDC, or to agencies of the federal, state, or local government, or to select members of the public for public health purposes in accordance with the policies for data release established by the Council of State and

Territorial Epidemiologists.

Information in this surveillance system will be kept confidential. Only authorized employees of DHAP in HICSB, BCSB, and in the Quantitative Sciences and Data Management Branch (QSDMB), their contractors, guest researchers, fellows, visiting scientists, authorized external collaborating researchers, research interns, and graduate students who participate in activities jointly approved by CDC and the sponsoring academic institution, and the like, will have access to the information.

Authorized individuals are required to handle the information in accordance with procedures outlined in the Confidentiality

Security Statement for the National Human Immunodeficiency Virus (HIV) Surveillance System (NHSS) and Surveillance-

Related Data (including surveillance information, case investigations, supplemental surveillance projects, research activities, and evaluations).

ATTACHMENT F

Data Security and Confidentiality Guidelines for HIV, Viral Hepatitis, Sexually Transmitted Disease, and Tuberculosis Programs: Standards to Facilitate Sharing and Use of Surveillance Data for Public

Health Action:

http://www.cdc.gov/nchhstp/programintegration/docs/PCSIDataSecurity Guidelines.pdf http://www.cdc.gov/nchhstp/programintegration/docs/PCSIDataSecurity%20%20Guidelines.pdf

ATTACHMENT G

Certification and Accreditation (C&A) Requirements and

Section 508 of the Rehabilitation Act (29 USC 794d).

Section 508 of the Rehabilitation Act of 1973 (29 U.S.C. 794d), as amended by the Workforce Investment Act of 1998, and the

Architectural and Transportation Barriers Compliance Board Electronic and Information (EIT) Accessibility Provisions (36 CFR part

1194), require that, unless an exception applies, all EIT products and services developed, acquired, maintained, or used by any Federal department or agency permit:

(1) Federal employees with disabilities to have access to and use information and data that is comparable to the access and use of information and data by Federal employees who are not individuals with disabilities; and

(2) Members of the public with disabilities seeking information or services from a Federal agency to have access to and use of information and data that is comparable to the access and use of information and data by members of the public who are not individuals with disabilities.

Accordingly, any vendor submitting a proposal/quotation/bid in response to this solicitation must demonstrate compliance with the established EIT accessibility provisions. Information about Section 508 provisions is available at http://www.section508.gov/. The complete text of Section 508 Final Provisions can be accessed at http://www.access- board.gov/sec508/provisions.htm.

The Section 508 standards applicable to this solicitation are identified in the Statement of Work/Specification/Performance Work

Statement. In order to facilitate the Government’s evaluation to determine whether EIT products and services proposed meet applicable Section 508 accessibility standards, offerors must prepare an HHS Section 508 Product Assessment Template, in accordance with its completion instructions, and provide a binding statement of conformance. The purpose of the template is to assist

HHS acquisition and program officials in determining that EIT products and services proposed support applicable Section 508 accessibility standards. The template allows vendors or developers to self-evaluate their products or services and document in detail how they do or do not conform to a specific Section 508 standard. Instructions for preparing the HHS Section 508 Product Assessment

Template may be found at http://508.hhs.gov.

Respondents to this solicitation must also provide any additional detailed information necessary for determining applicable Section

508 standards conformance, as well as for documenting EIT products and/or services that are incidental to the project, which would constitute an exception to Section 508 requirements. If a vendor claims its products and/or services, including EIT deliverables such as electronic documents and reports, meet applicable Section 508 standards in its completed HHS Section 508 Product Assessment

Template, and it is later determined by the Government – i.e., after award of a contract/order, that products and/or services delivered do not conform to the described accessibility in the Product Assessment Template, remediation of the products and/or services to the level of conformance specified in the vendor’s Product Assessment Template will be the responsibility of the Contractor at its expense.

The applicable provisions of this solicitation are: 1194.21, .22, .24, .31, and .41.

Security Compliance

The contractor must have the ability to host and maintain a system for data collection, management, use, and reporting to support activities funded by the federal government. We provide the following information to assist in the preparation of documents necessary for the Certification and Accreditation (C&A) of an Information System. The EGovernment Act of 2002, (Federal Information

Management Act) and the below federal policies dictate the framework for assuring information security for data systems operated by or on behalf of the Federal government. These are summarized below.

OMB Circular A-130 (http://www.whitehouse.gov/omb/Circulars_a130_a130trans4/) establishes policy for the management of

Federal information resources, pursuant to a number of laws and regulations, including the Paperwork Reduction Act of 1980

(amended in 1995), the Computer Security Act of 1987, and other laws. Circular A-130 requires all federal information systems to have security plans, emergency response capabilities, designated individuals who are responsible for security, security awareness training, and regular review of the system. Appendix III of Circular A-130, entitled “Security of Federal Automated Information http://www.section508.gov/ http://www.access-board.gov/sec508/provisions.htm http://508.hhs.gov/ http://www.whitehouse.gov/omb/Circulars_a130_a130trans4/

Resources,” establishes a minimum set of controls to be included in Federal automated information security programs; assigns Federal agency responsibilities for the security of automated information; and links agency automated information security programs (such as the DHHS AISSP) with OMB Circular No. A-123

The Federal Information Security Management Act of 2002 (P.L. 107-347) (FISMA) (http://csrc.nist.gov/policies/FISMA-final.pdf) requires each agency to develop, document, and implement an agency-wide information security program to safeguard information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor (including sub-contractor), or other source. The National Institute of Standards and Technology (NIST) has issued a number of publications that provide guidance in the establishment of minimum security controls for management, operational, and technical safeguards needed to protect the confidentiality, integrity, and availability of a Federal information system and its information.

Pursuant to Federal and HHS Information Security Program Policies the following standards and guidelines apply:

FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems

(http://csrc.nist.gov/publications/fips/fips200/FIPS-200-final-march.pdf), FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems

(http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf)

NIST Special Publication 800-18, Guide to Developing Security Plans for Federal Information Systems

(http://csrc.nist.gov/publications/nistpubs/800-18-Rev1/sp800-18-Rev1-final.pdf)

NIST Special Publication 800-60, Guide for Mapping Types of Information and Information Systems to Security Categories

Vol. 1 (http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol1-Rev1.pdf) and Vol. 2

(http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdf).

NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems and Organizations

(http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final-errata.pdf).

NIST Special Publication 800-63, Electronic Authentication Guideline (http://csrc.nist.gov/publications/nistpubs/800-

63/SP800-63V1_0_2.pdf)

The System Security Plan (SSP) is part of the Certification and Accreditation (C&A) process required by the EGovernment Act of

2002 and NIST Special Publication 800-18, 800-37, and will include selected mandatory controls required by NIST Special

Publication 800-53, and NIST Special Publication 800-60 Volume I & II. The successful contractor in conjunction with the

NCHHSTP Information System Security Officer (ISSO) will submit C&A documentation to the CDC Chief Information Security

Officer (CISO). The successful completion of the C&A documents will result in an award of an Authority To Operate. Based on guidance in FIPS 199 and NIST SP 800-60 the system will be assigned an overall security category (SC) of LOW or MODERATE based on (confidentiality, LOW/MODERATE), (integrity, LOW/MODERATE), and (availability, LOW/MODERATE) impact levels.

These impact levels will be initially determined by the NCHHSTP ISSO and confirmed by the CDC OCISO Certifying Authority as part of the Certification and Accreditation process.

The successful contractor is responsible for providing pertinent security information to the NCHHSTP ISSO and Security Staff and assisting in completing the below CDC Certification and Accreditation documents to include Annual Assessments, Annual Business

Continuity Plan, Re-Certifications and applicable significant/non-significant change requests. Appropriate security templates will be provided to the successful Contractor by the NCHHSTP Security Staff. Completed documents will be sent to the CDC Chief

Information Security Office (CISO) for review, approval and subsequent issuance of an Authority To Operate (ATO)

Baseline System Information (BSI)

Privacy Impact Assessment (PIA)

System Security Plan (SSP) http://csrc.nist.gov/policies/FISMA-final.pdf http://csrc.nist.gov/publications/fips/fips200/FIPS-200-final-march.pdf http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf http://csrc.nist.gov/publications/nistpubs/800-18-Rev1/sp800-18-Rev1-final.pdf http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol1-Rev1.pdf http://csrc.nist.gov/publications/nistpubs/800-60-rev1/SP800-60_Vol2-Rev1.pdf http://csrc.nist.gov/publications/nistpubs/800-53-Rev3/sp800-53-rev3-final-errata.pdf http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf

Business Continuity Plan (BCP)

Risk Assessment Report (RAR)

Deliverable Table

BSI, PIA, SSP, BCP, RAR (C&A) Completed Documents due to

NCHHSTP ISSO 60 days prior to desired System Production date

Completed Documents Due to CDC

Chief Information Security Office

45 days prior to desired System production date

Recertification (required every 3 years or when significant change occurs

Completed Documents due to

NCHHSTP ISSO 60 days prior to current ATO expiration date

Completed Documents Due to CDC

Chief Information Security Office

45 days prior to current ATO expiration date

Annual Assessment/Business

Continuity Plan (BCP)

Completed Documents due to

NCHHSTP ISSO 20 days prior to date of annual renewal

Completed Documents Due to CDC

Chief Information Security Office 1 day prior to date of annual renewal

Non Significant Change Requests

(OS or application version change, change in data variables)

Completed documentation due to

ISSO for signature prior to change implementation

Completed documentation due to

OCISO for approval prior to change implementation

The Contractor shall respond to the following seven security–associated requirements in the application:

(1) Position Sensitivity Designations

CDC requires a Public Trust Level 5 for the following

The following position sensitivity designations and associated clearance and investigation requirements apply under this licensing contract:

Level 5: Public Trust - Moderate Risk (Requires Suitability Determination with NACIC, MBI or LBI). Licensor employees assigned to a Level 5 position with no previous investigation and approval shall undergo a National Agency Check and Inquiry Investigation plus a Credit Check (NACIC), a Minimum Background Investigation (MBI), or a Limited Background Investigation (LBI).

Upon award, the Licensor will be required to submit a roster of all staff (including sub-contractor staff) working under the contract that will have the ability to access sensitive NCHHSTP information from the system. The roster shall be submitted to the Project

Officer/technical monitor, with a copy to the Contracting Officer, within 14 calendar days of the effective date of the contract. Any revisions to the roster as a result of staffing changes shall be submitted within 15 calendar days of the change. The Contracting

Officer shall notify the licensor of the appropriate level of suitability investigations to be performed, but Licensor employees and subcontractors who have met investigative requirements within the last five years may only require an updated or upgraded investigation. An electronic template, “Roster of Employees Requiring Suitability Investigations,” is available for contractor use at:

http://ais.nci.nih.gov/forms/Suitability-roster.xls. Upon receipt of the Government’s notification of applicable suitability investigations required, the Licensor shall complete and submit the required forms within 30 days of the notification.

Non-Disclosure Agreements

The Contractor and any sub-Contractors or employees are forbidden from sharing any technical or logistical information they may gain in conjunction with matters related to this task order that could jeopardize the physical or information security of CDC or its employees, projects, or information systems.

The following apply to Licensor employees and their subcontractors associated with the project:

1) Personnel may not begin work under the contract until the contractor has submitted the employee roster and non-disclosure agreements as described above.

http://ais.nci.nih.gov/forms/Suitability-roster.xls

2) Personnel without necessary background investigations will not have access to sensitive project data.

3) Violation of these conditions may lead to termination of the contract.

It is the Contractor's responsibility to ensure that all employees have met CDC and federal requirements, such as, for example, completion of background checks, before gaining or utilizing access to CDC information technology resources.

(2) Privacy Compliance

Licensor in conjunction with CDC Center ISSO shall conduct and maintain an initial Privacy Impact Assessment (PIA) as defined by

Section 208 of the E-Government Act of 2002. Periodic reviews shall be conducted by the system owner, with assistance from the

CDC Center ISSO and contractor, to determine if a major change to the system has occurred, and if a PIA update is needed.

(3) Contractor’s Official Responsible for Information Security

The contractor shall include in the “Information Security” part of the Technical Proposal the name and title of its official who will be responsible for all information security requirements should the contractor be selected for an award.

(4) Rules of Behavior

The contractor’s employees and subcontractors shall comply with the HHS Information Technology General Rules of Behavior.

(5) Information Security Training

HHS policy requires that contractors and subcontractors shall receive security training commensurate with their responsibilities for performing work under the terms and conditions of their contractual agreements. The successful contractor shall be responsible for assuring that each employee, including subcontractors, has completed the HHS Computer Security Awareness Training course (or another course designated by CDC) prior to performing any contract work, and thereafter completing the HHS-specified annual refresher course during the period of performance of the contract. This would be provided at the Contractor's expense and would be the Contractor's responsibility to plan and arrange.

The successful contractor shall maintain a listing of all individuals who have completed this training and shall submit this listing to the project officer.

(6) HSPD-12 Compliance

Federal Information Processing Standard 201 (FIPS-201) (vii) compliant, Homeland Security Presidential Directive 12 (HSPD-12) card readers shall: (a) be included with the purchase of servers, desktops, and laptops; and (b) comply with FAR Subpart 4.13, Personal Identity Verification.

(7) Encryption

All sensitive CDC-funded data stored on desktop computers used on behalf of HHS shall be secured either through a FIPS 140-2 compliant encryption solution or through adequate physical security and operational controls at the desktop’s residing location.

All mobile devices, portable media and transfer data files that contain sensitive CDC- data shall be encrypted using FIPS 140-2 compliant algorithms.

ATTACHMENT H

Current MMP tracking systems – Project-Site View

All data contained in this attachment are mock data

Current MMP tracking systems

– Project-Site View

Contents Landing Page

CAT

Data Portal

Tracking screens

CAT

Person View eHARS Data

Lead and Contact Attempt Tracking

Data Portal

Dashboard View

Calendar Scheduling Utility

Facility Tracking Page

Sampled Persons Tracking Page

Reports

CAT

Field Summary

Lead searches by week

Contact attempts by week

Unsearched sources

Successful sources

Overall progress

Progress by data collector

Query builder

Sample line list

Supervisor tracking log

Facility lists

Confirmed leads

Data Portal

Landing Page

CAT

The Main Menu page is displayed on startup. There are buttons on the main menu contained in 3 general sections: navigation (“find record”), data management, and reports.

Data Portal The following is the main page for the data portal. You can search for a facility by ID or name and search for a person by PARID.

Tracking screens

Person View

The “person view” form is an individual person’s record. This form will allow you to view and enter information on a given sampled person.

The top section of the Person View page is a display of some important identifying information imported from eHARS.

More eHARS data can be viewed by clicking the “view additional information” button; this page is described below.

Under the eHARS information is a box listing all leads associated with this case and some summary information associated with the lead. Data is not directly editable from this table. One can open up the detailed “leads and contact attempts” page for a given lead by double clicking on the lead, or open up a blank “leads and contact attempts” page by clicking the “enter new lead” button. The “leads and contact attempts” page is described below.

The “All Contact Attempts” table lists all attempts made to contact the sampled person in reverse chronological order. Data is not directly editable from this table.

The “Unsuccessful Lead Searches” table is intended to be used to record instances when you search for a sampled person in a database but do not find any leads in that database. Data is directly editable from this table.

We provide an additional opportunity to collect data about a sampled person in the data entry windows related to recruitment, interview, MRA, and linkage and re-engagement. Most of these data entry fields are not required, but may be useful for project management purposes. The only field that is required is the “Staff assigned to recruitment” field in the “Recruitment” section. This field is necessary in order to properly generate the “Lead searches by lead and staff” and “Contact attempts by lead and staff” reports.

The disposition, interview, and MRA data in particular, while not required, enhance some of the CAT reports by providing additional information and context to the leads and contacts data. Additionally, many of the fields are duplicates of those found in the DCC portal. Entering this data in the CAT is not a substitute for entering the data into the DCC portal – there is no automated way to transfer data between the two systems, though the CAT provides a report to help with DCC data entry.

eHARS Data

This screen condenses all of the tables exported from eHARS from the sample draw and the local contact information generation programs.

The topmost section of this form is general information – things like names, date of birth, and stateno in the

MMP jurisdiction of sampling. Under that are two tables. The Aliases table provides you with every name, date of birth, and social security number associated with this person. The All Statenos table is a list of all of the jurisdictions that have reported this person as a case. This may help stafffind the person, figure out where they get care, or just elucidate where they’ve lived over time.

If you scroll down under the general information, you’ll see information on all addresses and phone numbers associated with the sampled person in eHARS at the time the local contact information generation program is run. We pull out a few pieces of information – the most recent complete address, the most recent address (which may or may not contain all of the components of a complete address), and the most recent phone number, as well as the most recent residence according to national data. Under that, though, we give you a table that summarizes all of the address information for your reference.

At the bottom of this form is the section on care information, including a list of all facilities and all labs associated with the person in the form of a table in case you need that information as well. We pull out the information on the facility or provider that was used most frequently in the year prior to sampling.

Lead and Contact Attempt Tracking

The Leads and Contact Attempts form is where staff can record all information about a given lead, including the sources of that lead and contact attempts associated with that lead. Please note that all fields are editable with the exception of the ParID, leadID, and name fields.

Lead field: The actual lead (email address, phone number, etc.) goes in this field. This field is required for the form to save the lead information.

Lead Type: This field is intended to be used to document the kind of lead the given lead is. This is a drop-down menu.

Reaction to contact: The field ‘reaction to contact’ is intended to capture only sampled person’s reaction to contact.