Occupational_Health_and_Safety_Software_work_statement.docx

Division of Occupational Health and Safety Occupational Health and Safety Software Suite

Table of Contents

1.0 BACKGROUND

The National Institutes of Health (NIH), is the primary federal agency responsible for conducting and supporting medical research. The NIH mission is “to seek fundamental knowledge about the nature and behavior of living systems and the application of that knowledge to enhance health, lengthen life, and reduce illness and disability.” Scientists and support staff at the NIH perform a broad range of activities to fulfill this mission. These activities include basic and clinical research, administrative support functions, and facilities operations and maintenance.

The Office of Research Services, Division of Occupational Health and Safety (DOHS), serves the NIH through the development and administration of policies, standards and procedures in occupational health and safety.

Services and programs are primarily provided at the main campus in Bethesda, MD., the Bayview Research Center in Baltimore, MD., the Integrated Research Facility in Frederick, MD., Rocky Mountain Laboratories in Hamilton, MT., and National Institute of Environmental Sciences in Research Triangle Park, NC.

2.0 PURPOSE

The purpose of this contract action is to acquire software licensing, help desk services, and operations and maintenance support for a suite of integrated, modular applications using state of the art technologies. To minimize disruption of safety services provided to the agency, the application sought through this contract action must be deployable at the time of licensing without extensive customization. The application provided by the vendor must demonstrate integration across the individual modules to ensure a streamlined workflow between the agency’s safety activities. The biological registration module is the centerpiece of the NIH safety database and must be able to cross-check with occupational health records. Other examples of integration include 1) association between the registration of biological material with laboratory and/or animal spaces to ensure that timely and accurate safety inspections are performed; and 2) injury reports are seamlessly entered and assigned to safety staff (or employee supervisor) to conduct investigations and record findings back into the application. Through integrating injury investigations with the clinical module, the Occupational Medical Service (OMS) clinic can identify employees that may not have received required or recommended medical services. The lab survey module must be able to identify laboratories requiring surveys based on the laboratory’s registered materials in the biological registration module. Biosafety levels and agent information should also be viewed in the lab survey module. Personnel training requirements based on the assignments of personnel to specific biological pathogens (and animals) must be present in the lab survey module.

3.0 SCOPE

The DOHS currently uses a rich-client based platform, that interconnects the following services: (1) analytics; (2) animal exposure and research reporting; (3) asbestos abatement plans; (4) registration of potentially hazardous biological materials; (5) lab safety surveys and clearance inspections; (6) respiratory fit testing; (7) vaccination records; (8) electronic medical records, (9) clinical appointment scheduling and tracking, (10) clinical medical records, (11) medical surveillance; and (12) injury and illness reporting.

These interconnecting functions assist NIH to meet regulatory requirements and support DOHS’s efforts to identify and manage occupational risk. The integrated, modular electronic occupational health and safety system will use a Microsoft SQL compatible database. Database and application servers hosting the Occupational Health and Safety Software suite will be housed within the Office of Research Services, Information Technology Branch, Application Hosting Environment (ORS, ITB, AHE). The modules will provide a simplified user interface that is intuitive and straightforward for the safety staff and scientists and accessible via web browser and secure login.

Ideally, the integrated, modular application will provide the following components and functions:

Central Product Functions

1) Analytics This function will:

a) Allow the analysis of information to be retained within DOHS components inside the application to be displayed as a central dashboard.

b) Have the capacity to display analytical results in standard graphical formats (examples are: pivot tables, bar graphs and scatter plots, pie, spider, and bubble charts).

c) Allow reports to be exported in multiple file formats, including Word, Excel and, Adobe Acrobat.

d) Allow the selection of data from programs/sources for the generation of a variety of charts e.g. bar, scatter, bubble and spider; to monitor trends, analyze disparate information for root cause analysis.

e) Preferred ability to upload and utilize a monthly NIH Official Census (MS Excel) (organization, assigned personnel, sites, buildings, room numbers, etc.) as part of a centralized system to tie all programs/sources together (injury location, injured employee demographics, etc.).

f) Ability to capture and incorporate 3D Computer Aided Design (CAD) images of NIH buildings, rooms, equipment, ventilation systems, etc.

g) Calculate injury and illness rates, identification of locations (visually) of types injuries and illnesses, hazardous conditions and/or materials, and other metrics.

2) Document Management This function will support multiple file and image types for uploading and viewing external documents. Examples of file types include Word, Excel, .pdf, .rtf and text formats. Support for image files will include JPG, GIF, PNG and TIFF file formats.

3) Email Notification Management The function will:

a) Support general inboxes for DOHS functional groups. An example is a group inbox for the respiratory fit program.

b) Have the capability to send individual and group notifications for multiple purposes (e.g., training expirations, clinical scheduling, and surveillance program compliance information).

4) Report Management This function will:

a) Allow creation of reporting templates (i.e. a library) for generation of commonly used reports.

b) Permit on-the-fly data reporting by any column heading (data element) within the application modules. Examples include, institute or center, building and room, date, injury, laboratory name, principal investigator, and contact name.

c) Allow report to be exported and printed in multiple formats including PDF, Word and Excel.

5) Training Management This function will:

a) Provide the capability for DOHS to create customized training in text and video format.

b) Have the ability to customize, store and record results of verification (i.e. tests and quizzes) materials.

c) Support the updating of training compliance records for all modules.

d) Retrieve training compliance records (training subject, completion date, employee demographics) from existing third-party software

6) Asbestos Abatement Registration This function will:

a) Support federal and state recordkeeping requirements for asbestos removal and exposure including:

· Occupational Safety and Health Administration 29 CFR Parts 1910.1001, 1926.1101, and 1910.134.

· Environmental Protection Agency 40 CFR Part 763, Subpart E, Part 763, and National Emission Standard for Hazardous Air Pollutants (NESHAP), 40 CFR Part 61.

· Maryland Department of the Environment, COMAR 26.11.21 and 26.11.2

· Creates a National Emission Standard for Hazardous Air Pollutants (NESHAP) form generated from data inputted into the module by the abatement contractor.

· Generate a printable NESHAP form.

b) Have the ability for contractors to create asbestos removal registrations by uploading CAD/CAM plans and other documents to the site.

c) Allow the Asbestos Program Manager to approve, or disapprove abatement plans, and communicate by email with registrants.

7) Respirator Fit The Respirator Fit Function will:

a) Have the capability to provide and document employee respirator training after an employee is deemed medically qualified.

b) Track employee training expiration and notify the employee via automated email notification.

c) Document employees’ respirator type and size, potential exposure agent, and where necessary, other relevant data.

d) Will have the ability to view/input/edit compliance records and generate automated messages.

8) Other Functions The OHSS application will:

a) Have the capability to securely e-sign documents using signature certificates on government issued personal identity verification cards and lock the document, once signed or countersigned (as needed).

b) Ensure compatibility with Macintosh (Safari) and PC browsers (e.g., Internet Explorer, Google Chrome, and Mozilla Firefox).

Laboratory Safety Functions

1) Animal Exposure Program Viewer

a) Provides forms and stores records related to research conducted with animals.

b) The documentation includes husbandry and experimental protocols followed for experiments using animals.

c) The program viewer allows viewing and reporting of all registrations that include animal-related research.

d) Captures electronic medical record data (e.g., immunizations) to determine compliance with medical requirements for animal contact.

e) Indicates if employees have complied with training requirements.

2) Animal Care and Use Committee (ACUC) Viewer

a) A central repository for viewing all active animal research registrations.

b) Management console for assigning animal committee roles

· Configurable roles

· Simple assignment criteria

c) Role-based access to ensure access to relevant business data

· Administrative access

· Institute/Center specific oversight

d) Configurable forms to capture specific relevant data

3) Biological/Recombinant DNA Material Registrations

a) Principal Investigators (PI’s) and/or their prox(y)ies have the ability to submit, amend, manage and review initial submissions, and provide required annual updates and reviews of registrations. Examples of information required are PI’s contact information, laboratory personnel, laboratory location, material type, associated animal work, strain information and experimental protocols followed.

b) The system must also allow capture of data regarding animal use in research and associate specific animal species with individual researchers associated with the registration.

c) Integration with electronic medical records to identify who is working with what biological agent and inform Principle Investigators whether compliant with medical requirements (e.g., immunizations and TB screening).

d) Biosafety Officers will be able to approve, disapprove, make notations to registrations and communicate with registrants.

e) The system will allow document queuing for Institutional Biosafety Committee reviews and approvals.

f) DOHS specified triggers will result in email notifications to appropriate groups. For example, email to PI and proxy upon initial registration approval and annual notice to renew registration.

g) A record of changes made to the registration will be maintained, including who made the change, when it was approved and by whom, date and time stamp.

4) Laboratory Safety Surveys and Clearances

a) Lab surveys and clearances will be assigned to safety specialists to monitor visible research-related hazards of laboratories. All laboratories identified in the biological registration module will auto-populate the list of labs to be surveyed. The labs associated with each survey will be auto-assigned to the lead safety specialist assigned to each respective institute. However, any safety specialist will be able to access any lab survey, at any time.

b) Lab surveys and inspections will include

i. Hazard assessment, including chemical, biological and physical hazards;

ii. Evaluation of work practices and procedures;

iii. Verification on the availability of safety equipment;

iv. Verification that staff have completed the required safety training courses.

c) Laboratories will populate a list of required surveys when associated with an approved biological registration.

d) Laboratories require annual, auto populated surveys.

e) The system will generate predefined notifications to the Principle Investigators of the laboratory informing the PI that deficiencies have been identified.

f) Principle Investigators will be reminded, on a periodic basis, to address outstanding deficiencies that they have not corrected.

g) The system will accommodate labs where multiple Principle Investigators are working, and for deficiencies that may require one or more of those Principle Investigators to respond, but only those responsible for the specific deficiency.

h) The system will maintain records of safety deficiencies, corrective actions, reports and reminders sent to the Principle Investigators, and the turnaround time for deficiencies.

i) Lab clearances requires laboratory location, and contact information, type and purpose of clearance

i. Clearances contain questions related to clearing hazardous substances and disinfecting equipment (for example radioactive substances and biosafety cabinets).

ii. Clearance forms enable the safety specialist to return the request for further action by the requestor.

j) The updating and storage of surveys and clearances for DOHS will be allowed for a specified time period.

5) Injury and Illness Incident Manager

a) The Illness and Incident Manager allows information communication with the Electronic Medical Records function to allow population for the Occupational Medical Service initial intake report.

b) The collection of injury or illness data will include, but is not limited to, person injured, their contact information, what the injury was and where it happened.

c) The injury or illness report, with an accession number, will be sent to the Safety Operations and Support Branch Chief for staff assignment

d) The module will have the ability to assign an illness or injury report to a safety specialist (or employee’s supervisor) for investigation

e) The safety specialist who investigates the injury or illness will have the ability to enter pertinent information about root causes, contributing factors, and recommendations to help prevent a similar incident from re-occurring.

f) Information concerning suggested changes will be permitted to be entered to prevent a similar incident from happening again, if applicable, and the incident is closed

g) The Safety Operations and Support Branch Chief will review the investigation notes, provide comment and approve the final investigation or return it to the safety specialist for further investigation.

h) OSHA reporting standards according to 29 CFR 1904, will be supported. This includes providing fillable Adobe Acrobat forms (i.e., .pdf format), OSHA forms 300, 300A, and 301, as well as data generated OSHA 300, 300A and 301 forms.

i) Reports of injury and illness data will be generated, including reports that assist in the analysis of safety personnel performance (e.g., status reports of open investigations, average turnaround times, etc.)

Electronic Medical Records manager

1) Administrative database and scheduler This function will:

a) Import employee demographics from the NIH Enterprise Directory to generate a medical record and inactivate records of individuals no longer affiliated with the NIH.

b) Import patient sign-in by scanning his or her NIH-issued personal identification verification card.

c) Schedule patient visits and select the appropriate healthcare provider(s) for the visit.

d) Provide managers with the ability to enter two-week schedules for individual providers.

e) Provide managers and staff with the ability to view all appointments scheduled for the day as well as appointments for workgroups and individual healthcare providers for the day.

f) This module includes comprehensive reports and capabilities for the set-up of recalls in support of medical surveillance programs and training courses.

g) Workload statistics will be provided.

h) At the time of a patient’s appointment, OMS staff is notified of overdue immunizations and requirements for compliance with the provisions of surveillance programs.

i) Electronic communications with the worker and supervisor will be enabled (e.g., appointment reminders, forwarding electronic copies of OMS counseling documents, etc.,).

j) Employee medical records module integrates medical components of an employee's chart. An inbox and reminders will assist the clinician to capture a quick review of the patient's medical profile and support the ability to document quickly and concisely with a minimum of the following capabilities and processes:

i) Access at the user lever will be permitted permit adding and editing patients to the system

ii) The patient records database will be searchable by DOHS specified terms (for example, last name, first name, last four social security number (SSN), last 4 SSN, former name), the worker’s NIH badge number, and personal identity verification card.

k) Patient records will consist of NIH specified fields, in a customized, NIH fillable format including but not limited to:

i) Lab and Procedures (examples are blood tests, x-rays, and audiograms).

ii) Visit notes, including injury or illness reports. The fields will utilize a standard medical SOAP format, include spell-check, the note is locked when saved, notes that require review and co-signature are forwarded to the appropriate reviewer for action.

iii) Common visit notes are formatted for ready use (e.g., the triage visit, emergency medical visit).

iv) Surveillance program entries will include elements outlined in the relevant OMS SOP.

v) Patient declination of recommended immunizations will be record and immunizations will be documented (e.g., TB testing, radiographic testing) services received elsewhere will also be documented.

l) The capability to scan and upload paper records will be available. This capability will use an NIH compatible system with naming conventions to facilitate linking to a record and identification of the record without opening it.

m) The OMS approach to performing and documenting preplacement medical evaluations, including administering appropriate vaccines will be mirrored to enroll workers in relevant OMS surveillance programs. Data will be collected, and appropriate forms generated. Examples forms include: Medical Qualification Determination Questionnaire (NIH Form 750-3), Request for Medical Determination and Report of Findings (NIH Form 750-2), Clinical Record/Face Sheet (NIH Form 2110), and Report of Medical History (GSA Form SF 93).

n) Return to Work Evaluations will be a formatted clinical record entry and include electronic communication with the employee and supervisor regarding the OMS healthcare provider’s recommendations for functional restrictions or a possible work absence. This communication is formatted like a Medical Evaluation of Work Status form (Blue Slip).

o) International Travel processes and procedures will be supported including medical-based travel recommendations such as travel immunizations based upon information in Travax.

p) The patient records portal will allow patients’ access to NIH OMS medical records including immunization records.

q) Patient records will be stored indefinitely, and according to Federal, HHS and NIH security and privacy regulations.

2) Medical Surveillance Support With all surveillance programs: capability of generating compliance reports for each type of surveillance: from the list of enrollees, who is not compliant with surveillance program requirements.

a) Animal exposure program identifies the type of animals contacted, occupationally indicated immunizations, and any relevant testing.

b) The asbestos medical surveillance program contains the elements of the evaluation (e.g., questionnaire, clinical evaluation, radiographic and pulmonary function testing and interpretation) that will be captured in the record entry.

c) The Police Officers and Firefighter evaluations will include medical testing and items that are outlined in the relevant OMS SOPs.

d) The Hearing Conservation Program provides monitoring for employees who may be exposed to noise levels at or exceeding threshold limits values for noise exposure in accordance with Occupational Safety and Health Administration (OSHA) Standards (29 CFR 1904) and (29 CFR 1910). The system will provide support for the standards listed above.

e) The Tuberculosis Surveillance Program (TBSP) will capture the complex guidance for testing workers and can interpret the resulting test findings.

f) Respirator fit testing records the worker’s responses to the OSHA questionnaire and the OMS healthcare providers’ recommendation for fit testing and training by a safety representative. The system will support these requirements as outlined in the Respirator Fit Testing SOP.

Questionnaires - This module will allow creation of various types of questionnaires used for medical, safety, and industrial hygiene purposes. This module will also allow data fields not present in the module but required by the client to be captured through questionnaire methodology to be added.

Vaccine Manager:

a) The immunization inventory will include the capability to record current vaccine inventory using a barcode reader.

b) The annual Influenza Immunization Program will be supported with historical patient contact numbers of approximately 15,000.

c) Vaccine Manager can track multiple immunization types.

d) Vaccination certifications will be available for employees to access at will.

e) Immunization records will provide, at a minimum, date the vaccine was administered, the vaccine manufacturer, the vaccine lot number, and the name, address, title of the person administering the vaccine, and where the vaccine is administered. Data relevant to vaccine information and employee administered will be imported by scanning the employee’s personal identity verification card.

f) Tracks completion of multiple dose immunization series. The employee’s compliance with required annual boosters or titers with ability to produce a report listing those not in compliance and send electronic recall notices to employee’s when a related medical service is clinically indicated.

4.0 OBJECTIVES

Software acquired under this task order must be capable of importing historical data retained in a Microsoft SQL database. Acquiring licensing under this task order must integrate current electronic processes and automate processes currently managed by manual processes (paper or manual entry into spreadsheets). Further, this licensing agreement will enable data exchange and analytics between current electronic and previously manual processes. To ensure that this application continues operation in the event of unforeseen circumstances and/or acts of God, a Contingency Plan will be developed in conjunction with the security deliverables in APPENDIX C. Applicable licensing language is included in this SOW to clarify the rights and limitations of the Government’s access to technical information. Further, a Service Level Agreement (SLA, APPENDIX D) accompanies this document so that the task order will be administered according to federal, information security regulations, policies and guidelines. The SLA document may be used in place of, or as a guideline for, the Contractor’s SLA.

Additional expected benefits from this acquisition are:

· Improved efficiency and reduced transcription errors from automating existing manual processes;

· Increased availability of data as a result of integrating manual processes into an interconnected suite of modules;

· Reduced implementation, operation and maintenance costs due to standardized software acquisition and development processes;

· Increased customer service responsiveness created by an updated, integrated modular application; and

· Improved site accessibility resulting from implementation of Section 508 requirements.

5.0 GENERAL REQUIREMENTS

Flexible. The system will meet Contractor and NIH agreed on requirements and allow for adjustments to meet programmatic changes.

Secure. The protection of data is essential. The system must meet or exceed the Federal Information System Management Act (FISMA) security requirements, Privacy Act of 1974, 5 U.S.C. § 552a, and the Clinger-Cohen Act of 1996. In addition, the application will meet all additional applicable federal, Health and Human Services (HHS), and National Institutes of Health (NIH) security requirements. It is the Contractor’s responsibility to stay abreast of the changes in security requirements. APPENDIX A contains the complete NIH, ORS generated security requirements.

Project Management. The contractor will have the capability to provide several general classes of services including, program management and reporting, systems engineering, software design and development, requirements and risk analysis, coding, quality assurance testing and software deployment. These services require careful interaction with the government Contracting Officer’s Representative (COR), enterprise system project management staff, other contractors, product vendors, and management.

6.0 TASKS

6.1 Task 1 - Data Migration and Integration Services

1) Migrate the existing application data into Contractor specific format.

2) Support the development and deployment of integrated information systems, to include the integration of technical components, information technology components, organizational components and documentation.

6.2 Task 2 - Program and Project Management

1) The contractor will develop, coordinate, update and maintain all project management deliverables including:

· Quarterly Quality Control Report, and

· Final Task Order Report.

2) The contractor will perform risk analyses, and other life cycle activities.

6.3 Task 3 - Training.

1) The contractor will provide training support in the areas of system administration and technical use of the modules to aid in determining best practices. The classroom training will be sufficient time and explanation to ensure DOHS staff are competent in use of the modules.

2) The Contractor will develop application specific, accessible online Application User’s Guides.

3) The Contractor will develop application accessible online help videos in an agreed upon standard video format (examples are AVI, WMV and MOV file formats).

6.4 Task 4 - System Documentation

1) Generate, develop, coordinate, update and maintain all System Documentation including:

a. Implementations Plans,

b. Transition Plan, and

c. Security documentation as required in Appendix A.

6.5 Task 5 – Final Requirements Document

1) Contractor will meet with project stakeholders to determine final project requirements

2) Stakeholders will be considered to include:

a. DOHS staff

b. DOHS Information Cybersecurity Manager,

c. ITB Security,

d. ITB COTS Software Group, and

e. ITB Network Systems Group.

3) Prepare Final Requirements document

6.6 Task 6 - Ongoing Maintenance and Improvement

1) Ensure that passwords (or personal identification numbers) for applicable accounts are updated

2) Confirm that application technologies are updated as necessary to support network operating system and other supporting infrastructure upgrades

3) Address DOHS’s continued requirements for application customization.

6.7 Task 7 - Help Desk and User Support

The contractor will:

1) Provide helpdesk service, at a minimum, from 8:00 AM to 5:00 PM EST, Monday through Friday, excluding Federal Holidays;

7.0 DELIVERABLES

The delivery schedule of products is outlined below in the Table entitled Deliverables Schedule. Other written and technical deliverables will be submitted according to the schedules identified in the approved Contract Management Plan developed under this SOW.

The Contractor will deliver the following:

Application Architecture and Graphical User Interface- The service provider should specify the proposed software client/server interface standards or environments, interface definitions for linking complementary systems, application architecture (i.e., how the application is structured between common components), graphical user interface, multiple tier architecture, and modularity.

Data Dictionary - The data dictionary, data structure – physical and logical data models utilized in the solution must be provided. Minimum information included must be:

· Database table names and their schemas (schema diagram);

· Details of database tables (owners, security constraints, etc.);

· Where the tables are stored and how;

· Table constraints such as primary and unique keys; and

· Specific fields for all tables (e.g., field name, description, field size, data type, etc.).

Transition Plan –The Plan will include a Transition-in phase to ensure that services currently running will remain uninterrupted. The Plan will also address a Transition-out phase. The Transition-out phase will ensure that, if the Contractor cannot perform the duties necessary to support the application, DOHS can deliver the required uninterrupted level of service.

Service Level Agreement – An example Agreement is included that may be used in place of, or as a guideline for, the Contractors own Agreement.

Quarterly Quality Control Report – The Contractor will submit a Quarterly Quality Control Report. The Quarterly Report will be submitted by the 10th calendar day of the third month following the initial contract signing date. The Quarterly Report will be a compilation of management issues experienced during the quarter reported.

The form and content of the Quarterly Report must include the following:

· Work and deliverables completed during reporting period;

· Summary of tasks performed under section 5.0 Tasks;

· Status of ongoing activities, including percentage of completion;

· Problems or issues projected or identified;

· Help Desk ticket report, including number and tier of issues, length of time to resolution and number of unresolved issues;

· Alternatives and/or recommended solution(s) for identified or projected problems or issues;

· Status of project funds including monthly and total expenditures and funds remaining;

· Activities/Work planned for the following period; and

· Known or projected resource (staff and funding) and schedule impact.

Other Deliverables – The Contractor will prepare and submit final copies of other deliverable analysis, evaluation, review, and report products necessary to meet the requirements of technical tasks and activities performed in the provision of this Statement of Work. All written deliverable products will be delivered in electronic format. See Deliverables: Due Dates. An example is an Implementation plans for the change management process.

Final Contract Report - The contractor will provide a final Report to the COR at the conclusion of the period of performance. This Report will summarize objectives achieved, significant issues, problems, and recommendations to improve the process in the future.

Final Requirements Document- DOHS has developed a Draft Requirements Plan that will be finalized by the Contractor.

Line Item 1: Software Licensure The vendor shall provide cost to support the following number of users per occupational health and safety module:

· Analytics: 50 users

· Respiratory Fit Testing: 15 users

· Biological Registrations: 1000 users

· Asbestos Abatement Plan Review: 5 users

· Clinical Appointment Scheduling and Tracking: 50 users

· Clinical Access Manager: 50 users

· Animal Exposure Program Viewer: 30 users

· Injury and Illness Incident Manager: 45 users

· Lab Clearance/Lab Survey Manager: 1,000 users

· Animal Care and Use Viewer: 1,000 users

· Training Manager: (n/a)

· Vaccine Manager: 15,000 users Line Item 2: Programming Labor The vendor shall identify labor costs to develop customized services that are not considered to be standard to the occupational health and safety module. This line item is available to adjust/customize the software should NIH needs change after task order award. Customization to meet the requirements of this document shall be included in the software license fee.

Programming labor shall be presented by title, responsibility, and hourly rate.

Line Item 4: Training Development The Contractor will provide written application specific (accessible online) Application User’s Guides. Cost to develop the user guide shall be included in the software licensure fee. Line item 4 is for costs for classroom and video-based training, which require visual demonstration or expanded discussion than afforded through written media.

Based on the contractor’s experience with existing customers, the contractor shall identify which topics, procedures, or functions would benefit from online help videos.

Safety staff

Safety staff

General user

7.1 - Delivery Schedule The contractor shall provide the following deliverables by the due date specified in the table:

Table 1 - Deliverables Schedule

7.2 - Assumptions The Contractor will adhere to the following expectations defined in other sections of this SOW.

Business Justification: The business value and justifications for funding includes the ability to administer the contact as an information technology (IT) project according to IT best practices. In addition, the task order aligns with Reimagine HHS strategic shifts, Leveraging the Power of Data to enable accessible, integrated data as an enterprise asset and Making HHS More Innovative and Responsive by revolutionizing the agency's technology and creating new resource deployment using innovative models.

Change Management: DOHS and ORS change management or release processes and procedures must be followed by the Contractor throughout the project.

Communication Requirements: The success of this project depends on clear, timely communication between the Contractor, the COR, and the ORS Information Technology Branch (ITB), the NIH ITB COTS deployment team, the ITB Customer Relationship Manager (CRM), ORS/ITB Security teams, and all DOHS components.

Prior existence of a legal agreement or relationship: Any and all prior legal agreements or relationships are negated by the signing of this task order.

Quality: Deliverables meet quality assurance standards as specified in this SOW, including scheduling timelines.

Security: Security standards specified throughout the SOW are implemented.

Software Licenses: Contractor grants software licenses in accordance with Federal Acquisition Regulations (FAR) and the current language in GSA schedule 70 licensing agreement, if applicable. The licensing language that is least limiting to the Government between the FAR and Schedule 70, if applicable, takes precedence. The Government is entitled to full access to information collected by any contractor application. This means that the Contractor consents to FAR licensing language that allows the government copies of source code and/or script for installation and back up purposes, database, architecture, and installation documentation and any other necessary information to restore the database and application to full access.

Vendors and Procurement: The anticipated performance of the Contractor is to deliver goods and services according to the task order and project requirements. The completion of this task order assumes that the vendor will be able to supply the required skills and meet the human resource demands of this SOW. If any of these assumptions change, the SOW will need to be modified and the project will be at risk.

Assumptions will be monitored through the risk management process.

7.3 - Notice Regarding Late Delivery As soon as it becomes apparent to the contractor, that a scheduled delivery will be late, the contractor will notify the COR. The notification will include the rationale for late delivery, the expected date for the delivery and the project impact of the late delivery. Such notification in no way limits the Government's right to any and all rights and remedies up to and including termination.

7.4 - COR Responsibilities All work under this task order will be monitored by the COR, who will act as the primary technical representative of the Government. Final inspection and acceptance of all work performed, reports and other deliverables will be performed at the place of delivery by the COR.

The COR, with the assistance of affected Program and Project Managers, is responsible for:

· Setting task priorities, revising task priorities when necessary;

· Communicating these priorities to the contractor;

· After consultation with the Contracting Officer when appropriate, modifying delivery dates; and schedules, o that the revised priorities can be met, and

· Formally assessing the level of contractor performance and ascribing the extent to which quality assurance and acceptable performance levels have been met.

7.5 - General Acceptance Criteria General business quality measures will be applied to each work product received from the contractor under this statement of work. For example, work products must be consistent with SOW requirements, contain accurate content, be submitted on or before the due date, and submitted electronically unless specifically specified. All text and image files must be modifiable by the government.

1) The COR will determine acceptability of product (reports, product improvements, security and other documentation) that the Contractor submits. Product rejection means that the Contractor resubmits the product for re-approval within five (5) business days for re-approval. Absence of any comments by the COR will not relieve the Contractor of the responsibility for complying with the requirements of this SOW.

2) All documentation will be in a Microsoft Word compatible format or other agreed upon format.

3) The contractor will provide the following documentation for the application:

· System Documentation.

· Installation Documentation of application and database for the Information Systems Branch (ITB) (as required by FAR by 52.227-14 Rights in Data—General).

· Application Defect Correction analysis method to be used for Tier 3 and 4 escalation of service.

· Other documents deemed necessary by the COR.

8.0 PERSONNEL

The Contractor is responsible for ensuring proper staffing and skill set coverage to fully support the task activities and requirements in this SOW. The contractor will provide a single point of contact to serve as the project manager for the life of the task order.

9.0 GOVERNMENT FURNISHED EQUIPMENT AND INFORMATION

Laptops will be made available to access the NIH VPN.

10.0 PLACE OF PERFORMANCE

The application will support employees and contractors on the Main campus in Bethesda MD, the Bayview Research Center (BRC), Baltimore, MD, the Integrated Research Facility (IRF), Frederick, MD, Rocky Mountain Laboratories (RML), Hamilton, UT, and Research Triangle Park (RTP), NC campuses. Monthly meetings take place at the main NIH campus in Bethesda Maryland, Building 13, Room 3K04.

11.0 TRANSITION PLAN

In the event that this task order ends, due to any cause, Contractor will provide NIH with any required documentation or other requested information within seven (7) days of the end of the task order. In addition, Contractor will submit a transition plan as part of the required documentation within three (3) months of the contract signing.

The Contractor will provide a transition plan that outlines the designated time and period and strategy to transition into the specific tasks as the Contractor and to transition out of the contract at the end of the period of performance.

Note: The transition period will not exceed thirty (30) days.

12.0 DATA RIGHTS

The government owns full rights to any software code developed under a federal government contract. FAR 52.227.14 Rights in Data –General applies to all other software.

13.0 COMPLIANCE REQUIREMENTS

The Contractor is expected to comply with all applicable Federal Acquisition Regulations (FAR), Health and Human Services Acquisition Regulations (HHSAR), Federal, Agency and OPDIV (NIH) laws, regulations, guidelines, and policies.

APPENDIX A – SECURITY REQUIREMENTS[footnoteRef:2] [2: Health and Human Services Department, Office of the Chief Information Officer, HHS Cybersecurity Program, HHS Information Systems Security and Privacy Policy (June 26, 2017, ver. 2.0). Retrieved from https://intranet.hhs.gov/it/strategy-policy-governance/policies-standards-guides/policies/index.html on 1/23/2018 ]

Baseline Security Requirements

1) Applicability. The requirements herein apply whether the entire contract or order (hereafter “contract”), or portion thereof, includes either or both of the following:

a. Access (Physical or Logical) to Government Information: A Contractor (and/or any subcontractor) employee shall have or shall be given the ability to have, routine physical (entry) or logical (electronic) access to government information.

b. Operate a Federal System Containing Information: A Contractor (and/or any subcontractor) shall operate a federal system and information technology containing data that supports the HHS mission. In addition to the Federal Acquisition Regulation (FAR) Subpart 2.1 definition of “information technology” (IT), the term as used in this section includes computers, ancillary equipment (including imaging peripherals, input, output, and storage devices necessary for security and surveillance), peripheral equipment designed to be controlled by the central processing unit of a computer, software, firmware and similar procedures, services (including support services), and related resources.

2) Safeguarding Information and Information Systems. In accordance with the Federal Information Processing Standards Publication (FIPS)199, Standards for Security Categorization of Federal Information and Information Systems, the Contractor (and/or any subcontractor) shall:

a. Protect government information and information systems in order to ensure:

· Confidentiality, which means preserving authorized restrictions on access and disclosure, based on the security terms found in this contract, including means for protecting personal privacy and proprietary information;

· Integrity, which means guarding against improper information modification or destruction, and ensuring information non-repudiation and authenticity; and

· Availability, which means ensuring timely and reliable access to and use of information.

b. Provide security for any Contractor systems, and information contained therein, connected to an HHS network or operated by the Contractor on behalf of HHS regardless of location. In addition, if new or unanticipated threats or hazards are discovered by either the agency or contractor, or if existing safeguards have ceased to function, the discoverer shall immediately, within one (1) hour or less, bring the situation to the attention of the other party.

c. Adopt and implement the policies, procedures, controls, and standards required by the HHS Information Security Program to ensure the confidentiality, integrity, and availability of government information and government information systems for which the Contractor is responsible under this contract or to which the Contractor may otherwise have access under this contract. Obtain the HHS Information Security Program security requirements, outlined in the HHS Information Security and Privacy Policy (IS2P), by contacting the CO/COR or emailing fisma@hhs.gov.

d. Comply with the Privacy Act requirements and tailor FAR clauses as needed.

3) Information Security Categorization. In accordance with FIPS 199 and National Institute of Standards and Technology (NIST) Special Publication (SP) 800-60, Volume II: Appendices to Guide for Mapping Types of Information and Information Systems to Security Categories, Appendix C, and based on information provided by the ISSO, CISO, or other security representative, the risk level for each Security Objective and the Overall Risk Level, which is the highest watermark of the three factors (Confidentiality, Integrity, and Availability) of the information or information system are the following:

Based on information provided by the ISSO, Privacy Office, system/data owner, or other security or privacy representative, it has been determined that this solicitation/contract involves:

[ ] No PII [ X ] Yes PII

Personally, Identifiable Information (PII). Per the Office of Management and Budget (OMB) Circular A-130, “PII is information that can be used to distinguish or trace an individual's identity, either alone or when combined with other information that is linked or linkable to a specific individual.” Examples of PII include, but are not limited to the following: social security number, date and place of birth, mother‘s maiden name, biometric records, etc.

PII Confidentiality Impact Level has been determined to be: [ ] Low [ X ] Moderate [ ] High

4) Controlled Unclassified Information (CUI). CUI is defined as “information that laws, regulations, or Government-wide policies require to have safeguarding or dissemination controls, excluding classified information.” The Contractor (and/or any subcontractor) must comply with Executive Order 13556, Controlled Unclassified Information, (implemented at 3 CFR, part 2002) when handling CUI. 32 C.F.R. 2002.4(aa) As implemented the term “handling” refers to “…any use of CUI, including but not limited to marking, safeguarding, transporting, disseminating, re- using, and disposing of the information.” 81 Fed. Reg. 63323. All sensitive information that has been identified as CUI by a regulation or statute, handled by this solicitation/contract, shall be:

a. marked appropriately;

b. disclosed to authorized personnel on a Need-To-Know basis;

c. protected in accordance with NIST SP 800-53, Security and Privacy Controls for Federal Information Systems and Organizations applicable baseline if handled by a Contractor system operated on behalf of the agency, or NIST SP 800-171, Protecting Controlled Unclassified Information in Nonfederal Information Systems and Organizations if handled by internal Contractor system; and

d. returned to HHS control, destroyed when no longer needed, or held until otherwise directed. Destruction of information and/or data shall be accomplished in accordance with NIST SP 800-88, Guidelines for Media Sanitization.

5) Protection of Sensitive Information. For security purposes, information is or may be sensitive because it requires security to protect its confidentiality, integrity, and/or availability. The Contractor (and/or any subcontractor) shall protect all government information that is or may be sensitive in accordance with OMB Memorandum M-06-16, Protection of Sensitive Agency Information by securing it with a FIPS 140-2 validated solution.

6) Confidentiality and Non-disclosure of Information. Any information provided to the contractor (and/or any subcontractor) by HHS or collected by the contractor on behalf of HHS shall be used only for the purpose of carrying out the provisions of this contract and shall not be disclosed or made known in any manner to any persons except as may be necessary in the performance of the contract. The Contractor assumes responsibility for protection of the confidentiality of Government records and shall ensure that all work performed by its employees and subcontractors shall be under the supervision of the Contractor.