PWS__ERMOS_4_May_2015_DRAFTl.pdf

DRAFT

PERFORMANCE WORK STATEMENT (PWS)

ELECTRONIC RESEARCH MANAGEMENT AND OVERSIGHT SYSTEM (ERMOS)

OPERATIONS AND MAINTENANCE

4 MAY 2015

Requiring Activity Name: Defense Health Services Systems (DHSS)

1. SCOPE

The Contractor shall provide a Commercial-Off-The-Shelf (COTS) based solution (i.e., ERMOS) to manage committee submissions, review and oversight processes, communications, approvals, and related processes in support of regulatory reporting and innovation efforts for Department of Defense (DoD) Institutional Review Boards (IRBs) for Human Subjects biomedical and social/behavioral research, Institutional Animal Care and Use Committees (IACUCs), Institutional Biosafety Committees (IBCs), Radiation Safety, Cooperative Research and Development Agreements (CRADA)/grants, Scientific Review and Publication Clearance, as well as unique DoD review needs (e.g., Headquarters Panel reviews and Headquarters Level Review for the Components). This solution shall accommodate the requirements of DoD and a diverse research community. The ERMOS technical solution chosen by the Government shall include IRB/IACUC COTS application software license ownership or usage, as well as operations and maintenance support for that application and all other system COTS software components (e.g., operating system, database, etc.), ongoing compliance with DoD Instruction (DoDI) 8500.01, “Cybersecurity, March 2014” and DoDI 8510.01, “Risk Management Framework (RMF) for DoD Information Technology (IT), March 2014” requirements, functional and training support, creation of system and security documentation, and other associated services. ERMOS shall be accessible to users via Common Access Card (CAC) as well as username and password. The current system serves nearly 14,000 users across more than 300 DoD research sites and compliance boards, and hosts over 280,000 electronic documents in support of more than 14,000 research projects.

The solution the Government selects shall be scalable to accommodate and extend beyond the current user, research site and compliance board, electronic documentation, and project baselines.

1.0.1 Background

The DHSS is a health information technology management program within the Defense Health Agency (DHA).

DHSS provides clinical, logistic decision support and resource management support applications to the Armed Services healthcare community. These applications are necessary at the front lines of healthcare delivery at Military Treatment Facilities, and for decision-makers in the offices of Lead Agents, the Managed Care Support Contractors, and at corporate levels to optimize delivery of healthcare, improve access to care, and support readiness. Corporate level includes Intermediate and Major Subordinate Commands, unified and specified Commands, Surgeons General, the Defense Health Agency, and Office of the Assistant Secretary of Defense Health Affairs.

DHSS will provide programmatic management and technical support for the ERMOS, the DoD approved enterprise system for managing the lifecycle research review and oversight processes for DoD IRBs for Human Subjects biomedical and social/behavioral research, IACUCs, IBCs, Radiation Safety, CRADA/Grants, Scientific Review and Publication Clearance, as well as unique DoD review needs (e.g., FHP&R Program Manager Network, etc.).

ERMOS automates these processes, allowing the Government to streamline document submission and review, decrease paper waste, reduce time spent routing work and/or locating misplaced work, and minimize administrative overhead thus allowing staff to focus on complex issues and support to the DoD research innovation community.

ERMOS gathers data to support enterprise level strategic decisions regarding regulatory system performance, resource utilization, and research portfolio management across the DoD. The system facilitates collaboration and data sharing amongst Researchers and Administrators via a secured web environment.

The ERMOS system shall allow the researcher, oversight support offices at various interacting regulatory levels, IRBs, and other research/non research related committees to:

Streamline document submission and review processes.

Reduce paper use; i.e., distribution packets and mailings.

Reduce time wasted routing work or locating misplaced paperwork.

Reduce administrative tasks to allow staff to focus on complex issues and support the innovation community.

Facilitate clear, coordinated communications and track correspondence.

Enable registered system users, Researchers and Administrators to collaborate and access/share data seamlessly and securely in real time, anytime, anywhere.

Manage research and related meetings and committees, and meeting materials and minutes availability.

Increase process transparency.

Increase data security.

Maintain a clear audit trail (with appropriate documentation and versioning) of review and oversight processes, including capture of associated electronic signatures.

Improve the quality of documentation and study design.

Improve ability to measure processes – i.e., system produced metrics.

Produce metrics reports.

Enable multi-center innovation work.

Facilitate ability to implement and enforce consistent innovation experience across the DoD research community.

Facilitate ability to implement and enforce standardization of business processes and practices across the

DoD research community.

Facilitate improved coordination of submission, review, management and oversight of multi-site studies capabilities.

1.0.2 Objectives

The Government seeks a web-based COTS solution to manage submissions, functions and associated work processes for management and oversight of human and animal subject research for DoD IRBs, IACUCs, IBCs, Radiation Safety, CRADA/Grants, Scientific Review and Publication Clearance, as well as unique DoD research review needs. The COTS solution shall facilitate the regulatory review process from the creation and submission of innovation projects at the investigator level, through the various approval regulatory steps encompassing the entire life cycle management of the protocols including institutional review board approvals, annual reviews, and audits.

Lifecycle management functions include, but are not limited to, project planning and closure, publication, quality management, communications, reporting, and approvals necessary to support innovation efforts and regulatory compliance within the DoD research community. Accessibility shall be via CAC authentication as well as user name and password.

Functional Objectives: The COTS based solution the Government will select for the ERMOS shall meet the following functional objectives:

1.0.2.1 Support/automate IRB and IACUC compliance functions

Biomedical research Social/behavioral research Human subject research Animal subject research

1.0.2.2 Support/automate Direct Electronic Submission from Investigators, Research Coordinators and other authorized project team members.

1.0.2.3 Allow compliance staff to define authorization and user access levels for each authorized IRB/IACUC committee member and reviewer.

1.0.2.4 Support Multi-Site Research across multiple review models, and secure cross-site and cross-board collaboration.

1.0.2.5 Support individual committee member and staff reviews, and record, store and make accessible electronically, individual reviewer recommendations, comments, checklists and other reviewer documentation.

1.0.2.6 Support/Provide secure online collaboration, sharing, communication and messaging, including visibility of meeting comments, for committee members, compliance staff and other reviewers.

1.0.2.7 Generate automated notifications to compliance staff when designated committee members, compliance experts or other reviewers complete individual or group reviews.

1.0.2.8 Electronically distribute determination and approval letters and other committee documentation to research teams.

1.0.2.9 Provide online reference documentation, form libraries and guidance for Committee Members.

1.0.2.10 Support/Provide ability to hold online electronic meetings, and create online agendas and minutes.

Automatically pull in data to build agendas and minutes based on submission and review activity.

1.0.2.11 Provide online search capabilities for protocols, investigators, submissions, projects and other ad hoc needs.

1.0.2.12 Provide a complete online record of Protocol/Study History including submissions, document revisions, board actions and decision letters, project status and communication.

1.0.2.13 Allow compliance staff to electronically maintain online reference documentation, form libraries and guidance for both research teams and Committee Members.

1.0.2.14 Support/Capture data necessary for the measurement of "actual" Researcher, Staff and Committee

Member operational performance.

1.0.2.15 Provide user capability to track training for Investigators and other personnel.

1.0.2.16 Provide user capability to verify credentials of Investigators and other personnel.

1.0.2.17 Provide web accessibility to:

Reviewers Entities outside of DoD (e.g. Academia) DoD principal investigators and their teams

1.0.2.18 Provide ability to support IRB Multi-Site Research across multiple review models, secure cross-site, and cross-board collaboration.

1.0.2.19 Provide ability to track, manage and document data (e.g., reviews, comments, checklists, recommendations, etc.) placed into an IRB solution.

1.0.2.20 Provide ability to track, manage and document IACUC reviews.

1.0.2.21 Provide ability to support IACUC, IBC, Grants/CRADA, radiology, scientific review, and publication clearance functions.

1.0.2.22 Allow scalability to accommodate >20K users.

1.0.2.23 Provide ability to collect, store and make accessible to designated users, mandatory data for annual reports and audits.

1.0.2.24 Provide ability to report/generate reports on Business Process Flows (BPFs). This gives audit information on the status of all process steps and activities.

1.0.2.25 Provide ability for online Human Research Protection Office (HRPO) reviews.

Technical Objectives: The COTS based solution the Government will select for the ERMOS shall meet the following technical objectives:

1.0.2.26 Provide a 100% COTS-based technical solution capable of fulfilling all ERMOS functional objectives, inclusive of an IRB/IACUC COTS application, operating system (OS), database (DB), and all other software components necessary for a fully operational system.

1.0.2.27 Hardware agnostic system software components.

1.0.2.28 IRB/IACUC COTS application that is software agnostic with regard to all other system software components (e.g., OS, database, etc.); i.e., the IRB/IACUC COTS functionality shall not be negatively impacted when other system COTS are upgraded.

1.0.2.29 Hundred percent (100%) web-based access

Compatible with the current released version of Internet Explorer and at least one additional common browser technology (e.g., Chrome, Safari, Firefox, etc.).

User access to the Internet without requiring desktop software (e.g., Citrix) to access the application.

1.0.2.30 Compatible with a variety of desktop configurations.

1.0.2.31 Capable of full virtualization.

1.0.2.32 Includes single sign-on Public Key Infrastructure (PKI) authentication, permitting user access via common access card (CAC), as well as a secondary authentication for users who are unable to obtain CACs (e.g., DoD soft certificates or user name and password) without reliance upon other non-DHSS systems (e.g., Army Knowledge Online).

1.0.2.33 COTS application that can be fully maintained and operated by Contractors other than the COTS software vendor.

1.0.2.34 Contractor integration of the COTS IRB/IACUC application with all other required system COTS software components required for an operational ERMOS.

1.0.2.35 COTS IRB/IACUC application capable of integration with the DHA SharePoint system as required.

1.0.2.36 Creation of multiple ERMOS system environments including, Production, Development/Test.

The Development/Test environment shall closely mirror the Production environment, including compatibility with all Security Technical Implementation Guides (STIGs).

1.0.2.37 Hosted in a government controlled secure hosting site (e.g., DHA Enterprise Infrastructure, DISA, etc.) or Federal Risk and Authorization Management Program (FedRAMP) Compliant Cloud System. System may be migrated during a future option period to a different government-controlled secure hosting site or FedRAMP Compliant Cloud system.

Operations and Maintenance Support Objectives: The COTS based solution the Government will select for the ERMOS shall meet the following operations and maintenance support objectives:

1.0.2.38 Contractor performance and execution of all tasks necessary to maintain and sustain ERMOS, including coordinating and working with the host site’s operations staff, as necessary.

1.0.2.39 Incremental and full system backups.

1.0.2.40 Database and workload sizing.

1.0.2.41 System performance tuning and optimization.

1.0.2.42 Configuration management, including maintaining a current and up-to-date ERMOS system baseline (i.e., all descriptive and operational ERMOS system documentation).

1.0.2.43 Testing and validation in a non-production environment of all ERMOS changes prior to insertion into production.

1.0.2.44 Insertion of all ERMOS changes (e.g., upgrades, patches, configuration changes) into all ERMOS environments.

1.0.2.45 Delivery, on demand, of all documents and/or data stored within the ERMOS system in a format that preserves file system information and is capable of importation into another data repository (e.g., SharePoint, etc.) or automated information system.

1.0.2.46 Tier II and III help desk support integration with the DHA Global Service Center.

1.0.2.47 Ability to quickly join or assimilate current processes/data and merge new DoD research institutions into a DoD-wide program.

Technical Security Objectives: The COTS based solution the Government shall select for ERMOS shall be capable of obtaining and maintaining, throughout the life of the system, a DHA RMF System Authorization, without customization of the COTS application by modification of the code, and without Government acceptance of risk for Very High or High security vulnerabilities.

1.0.2.48 Scan and provide evidence via scan results (e.g., Fortify, WebInspect, AppDetective, ACAS and/or others as specified by the Government) and analysis, within 30 days of contract award, that the COTS based solution contains no Very High or High security vulnerabilities.

1.0.2.49 Attain a DHA RMF System Authorization within 60 days or less of contract award.

1.0.2.50 Continuous and on-going compliance with requirements provided in DoDI 8500.01, DoDI

8510.01 and DHSS cybersecurity requirements.

1.0.2.51 Continuous cybersecurity monitoring via quarterly scans (e.g., Fortify, WebInspect and similar tools as required by DoDI 8500.01 and DoDI 8510.01 or otherwise specified by the Government).

1.0.2.52 Mitigation of findings from scans within timeframes specified by the Government.

1.0.2.53 The contractor shall perform necessary patches to maintain an acceptable security posture consistent with DoD regulations and requirements of the DoD. At the direction of the Government, the contractor shall perform software upgrades to address discovered security vulnerabilities.

1.0.2.54 Continuously updated ERMOS security documentation in accordance with DoDI 8500.01, DoDI

8510.01 and DHSS cybersecurity requirements. Per DoD and RMF security requirements, the contractor shall support accreditation activities and provide qualified technical personnel to provide content to DoD mandated Information Assurance artifacts.

Training Objectives: The Contractor shall collaborate with the Government to develop a comprehensive training program that includes the ability to deliver training virtually or in person by a live trainer, as directed by the

Government. The training program shall encompass initial and refresher training for ERMOS users. The Contractor shall also create all ERMOS training materials and aids to include at a minimum: teacher guides, student guides, release notes for functional users, course materials, training manuals, distance learning tools and computer-based tools.

1.0.2.55 Offer initial ERMOS training for the current user-base within 30 days or less of contract award.

Complete this initial ERMOS training within 60 days or timeframe provided by the Government.

1.0.2.56 Provide ongoing training via various delivery mechanisms (e.g., online, Virtual Classroom Training (VCT), Frequently Asked Questions (FAQs), etc.) for new users, as well as refresher training for existing users, over the duration of the period of performance.

1.0.2.57 Provide user training on new ERMOS functional features whenever they become available.

1.0.2.58 The Contractor shall deliver training materials and aids electronically in reproducible format, readily available and accessible to users.

Transition Support Objectives: The Contractor shall coordinate with the Government and the incumbent Contractor to plan and implement a complete transition from the current IRB/IACUC automated systems to the ERMOS within 60 days of contract award. The transition shall encompass importing documents and other data within the current systems, as well as all existing individual users and institutions. At the conclusion of the Transition-In period, all data available to users of the legacy IRB/IACUC system must be available to users in the ERMOS. Transition-in activities shall include an orientation phase and program to familiarize the Government’s personnel, programs, and users with the Contractor’s team, tools, methodologies, and business processes.

1.1 Non-Personal Services

This award identifies services that are strictly non-personal in nature.

1.2 Severable / Non-Severable Services

This award identifies services that are severable in nature.

1.3 Inherently Governmental Functions

This requirement has been reviewed and contains no services that are inherently governmental functions.

1.4 Acquisition Functions Closely Associated with Inherently Governmental Functions

Not applicable for this task.

2.0 ERMOS REQUIREMENTS

2.1 Task Management

The Contractor shall provide sufficient management to ensure that this task is performed efficiently, accurately, on time, and in compliance with the requirements of this document. Specifically, the Contractor shall designate a single manager to oversee this task and supervise staff assigned to this task. The Contractor shall ensure that a Monthly Progress Report is submitted outlining the expenditures, billings, progress, status, and any problems/issues encountered in the performance of this task.

2.1.1 Monthly Progress Report (MPR) – Deliverable 3, 8

The Contractor shall ensure that a Monthly Progress Report (MPR) (Deliverable 3) is submitted outlining the expenditures, billings, technical progress, status, any problems/ issues encountered in the performance of this task, and any perceived risks to the Contractor that might prevent performance of tasks and fulfillment of requirements included in this PWS. The MPR shall include the labor hours expended, by labor category, for each task and sub-task.

The Contractor shall include an updated Government Furnished Equipment (GFE) Inventory Report (Section 2.2.8.1.2, Deliverable 81) in each MPR that includes the location of all equipment included in the inventory.

The Contractor shall require all subcontractors to provide input to the MPR where there are critical or significant tasks related to the prime contract. Critical or significant tasks shall be defined by mutual agreement between the Government and Contractor.

The Contractor shall include a Subcontract Expenditures Report (Deliverable 8) in the MPR that discloses actual subcontract expenditures by company name, business size standard (i.e. Woman Owned Business, Veteran Owned Business, etc.), and other socioeconomic programs (i.e. Indian Incentive Program, Historically Black Colleges and Universities and Minority Institutions, etc.).

2.1.2 Task Management Plan (TMP) – Deliverables 2, 9, 73

The Contractor shall create a TMP (Deliverable 2) for Government approval. Following Government approval of the plan, it shall be applied by the Contractor to manage, track and evaluate the project or task performance. The TMP shall consist of control policies and procedures in accordance with standard industry practices for project administration, execution and tracking. The TMP shall include an Acceptance Criteria Plan (ACP) (Deliverable

73) and provision for the following:

Identification of milestones where Government information, activity, equipment, material, facilities, etc. is required and timeline dependencies for subsequent Contractor activities;

An Integrated Master Plan (IMP) – Details an event-based technical approach to executing the program, as defined in the Task Order, and identifies key program events, significant accomplishments, and associated completion criteria. The names for events, significant accomplishments, criteria, and tasks should be descriptive, concise, and specific to the program;

A detailed staffing plan with key personnel to be approved by the Government;

As applicable, a separate Subcontract Management Plan (Deliverable 9) outlining plans and goals for use of subcontractors, if subcontractors are utilized.

2.1.3 Integrated Master Schedule (IMS) – Deliverable 6

The Contractor shall establish and maintain an IMS (Deliverable 6) to be used to verify the attainability of task order objectives, to evaluate progress toward meeting program objectives, and to integrate the program schedule activities with all related components. The IMS shall depict task order milestones, accomplishments, and discrete tasks/activities from task order award to the completion of task order. The schedule shall be an integrated, logical network-based schedule that correlates to the CWBS and the PWS. The IMS shall be compatible with Microsoft Project version 2010.

2.1.4 Earned Value Management (EVM)

Not applicable for this task.

2.1.5 Integrated Baseline Review (IBR) – Deliverables 2, 6, 10, 75

The Government shall convene an IBR meeting within 60 days of contract award to verify the technical content and the realism of the related performance, budgets, resources, and schedules. The IBR shall provide for a mutual understanding of the inherent risks in the Contractor’s performance plan as described in the TMP (Section 2.1.2, Deliverable 2), and formulation of a strategy for handling risks. The IBR process provides a baseline for the Governments to ongoing assessment of the Contractor’s performance throughout the period of performance. The Contractor shall provide an initial IMS (Section 2.1.3, Deliverable 6) and Meeting Agenda (Deliverable 10) prior to the IBR, and Meeting Minutes (Deliverable 75) following the IBR.

2.1.6 Transition Support

a. Incoming Transition Plan– Deliverable 13

The Contractor shall provide a draft Incoming Transition Plan (Deliverable 13) for 60 days incoming transition from contract to contract. The Contractor shall coordinate with the Government in planning and implementing a complete transition to the Contractor's support model. The Contractor shall collaborate with the Government to create an Incoming Transition Plan. The Government will designate a transition period for the incoming Contractor to coordinate and work with the incumbent Contractor. The Transition-In Plan shall include but not be limited to:

Coordination with Government representatives Review, evaluation, and transition of current support services Transition of historic data and documents from legacy system to ERMOS Government-approved training and certification process Orientation phase and program to introduce Government personnel, programs, and users to the Contractor's team, tools, methodologies, and business processes Distribution of Contractor purchased Government owned assets, including computer equipment, etc.

Transfer of GFE, GFI, and GFP, and GFE/GFI/GFP inventory management assistance, as applicable Applicable DHA briefing and personnel in-processing procedures, Coordinate with the Government to account for government keys, ID/access cards, and security codes Integrated Master Schedule for first 30 days of planned activities in support of the transition-in tasks.

b. Option Item: Outgoing Transition Support Plan – Deliverable 14

The Contractor shall provide an Outgoing Transition Plan (Deliverable 14) for 60 days of outgoing transition for transitioning work from an active task order to a follow-on contract/order or government entity. This transition may be to a government entity, another Contractor, or to the incumbent Contractor under a new contract/order. In accordance with the government-approved plan, the Contractor shall assist the Government in planning and implementing a complete transition from this Contract to a successful provider. This shall include formal coordination with government staff and successor staff and management. It shall also include delivery of copies of existing policies and procedures, and delivery of required metrics and statistics. This transition plan shall include, but is not limited to:

Coordination with government representatives, Review, evaluation and transition of current support services, Transition of historic data to new Contractor system, Government-approved training and certification process, Transfer of hardware warranties and software licenses, Transfer of all system/tool documentation to include, at a minimum: user manuals, system administration manuals, training materials, disaster recovery manual, requirements traceability matrix, configuration control documents, knowledge management data / FAQs, configuration data and diagrams, system specifications, data definitions, Enterprise Architecture artifacts, cybersecurity-related system and applications documentation, test scripts, test procedures, test data sets, and previous Test Reports, and all other documents required to operate, maintain and administer systems and tools, If another Contractor replaces the Incumbent in providing operations and maintenance support for ERMOS, the Incumbent shall provide for 60 days a software engineer (or person of comparable skill level) with sufficient experience working with ERMOS, to assist the new Contractor, Transfer of COOP plans, activations and fall back procedures, testing procedures and results, and any related documentation, Orientation phase and program to introduce Government personnel, programs, and users to the Contractor's team, tools, methodologies, and business processes, Disposition of Contractor purchased government owned assets, including facilities, equipment, furniture, phone lines, computer equipment, etc., Transfer of GFE, GFI, and GFP, and GFE/GFI/GFP inventory management assistance, as applicable Applicable DHA debriefing and personnel out-processing procedures, Turn in of all government keys, ID/access cards, and security codes.

2.1.7 Kick-off Meeting and Program Reviews – Deliverables 10, 11, 75

The Contractor shall plan, schedule and conduct a Kick-Off meeting in coordination with the Government within 5 days after contract award. At the Kick-Off meeting the Contractor shall meet with the Government to present an overview of their approach, schedules, procedures, and points of contact necessary to conduct the tasks outlined herein. This meeting shall not exceed two hours in length. The primary outcome of this meeting is to come to an agreement on the cost, schedule, and performance baselines. At the Kick-Off meeting, the Government shall give the Contractor copies of DHSS policies, processes and procedures applicable to the work the Contractor will perform to fulfill the requirements for this PWS.

The Contractor shall plan and conduct regular, routine program review meetings with a frequency of not less than weekly (frequency subject to revision as mutually agreed upon) with the Government to review progress and status of activities under this task order. Each review shall provide insight into expenditures, staffing, progress, risks, and status of GFE, including Contractor purchased, government owned items. The Contractor shall provide project briefings addressing cost/price, schedule, performance, and status of each key element of this task order, noting any problems or risks and alternative and recommended solutions.

The Contractor shall ensure that a Meeting Agendas (Deliverable 10) and Program Review Meeting Materials (Deliverable 11) are provided to Government participants prior to the meeting, and that data presented at program reviews is current within not more than five (5) days. Meeting materials include, but are not limited to, technical briefing, action items lists, risks summaries, etc. The Contractor shall produce Meeting Minutes (Deliverable 75) following the Program Review meeting.

2.1.8 Quality Control Plan (QCP) – Deliverable 12

The Contractor shall prepare and adhere to a Quality Control Plan (QCP) (Deliverable 12). A draft QCP shall be delivered with Contractor’s proposal and shall be updated following award. The QCP shall document how the Contractor will meet and comply with the quality standards established in this PWS. At a minimum, the QCP must include a self-inspection plan, an internal staffing plan, and an outline of the procedures that the Contractor will use to maintain quality, timeliness, responsiveness, customer satisfaction, and any other requirements set forth in this solicitation. The QCP should:

Reflect and demonstrate a collaborative approach between the QCP and successful accomplishment of all QASP metrics.

Identify processes, procedures, and metrics which are likely to result in successful outcome within the time allotted and on schedule.

Provide for crosschecks of quality regarding the clarity, accuracy, validity, and consistency of each deliverable.

Describes the quality control approach to include processes, procedures, metrics, and reporting the metrics.

Demonstrate how the Contractor will implement Capability Maturity Model Integration (CMMI) and

Institute of Electrical and Electronics Engineers (IEEE) principals in the quality management processes of this effort.

2.1.9 Contingency Operations Plan (COP) – Deliverable 38

The Contractor shall create and submit a COP (Deliverable 38) to the Government to specify planning for the remediation of specific systems, equipment, software, and/or operations in the event of critical impact affecting either the Contractor or the Government, resulting from natural, accidental, or intentional events. The COP shall be due ten (10) calendar days after the contract start date, and shall be updated on a quarterly basis. The COP shall document Contractor plans and procedures to maintain ERMOS support during an emergency. The COP shall include the following:

A description of the Contractor’s emergency management procedures and policy A description of how the Contractor will account for their employees during an emergency Planned temporary work locations or alternate facilities How the Contractor will communicate with DHA during emergencies

A list of primary and alternate Contractor points of contact, each with primary and alternate telephone numbers and email addresses:

Procedures for protecting GFE (if any) Procedures for safeguarding sensitive and/or classified government information (if applicable)

2.1.10 Operations during Emergency Situations

Individual contingency operation plans as documented in the Contingency Operations Plan shall be activated immediately after determining that an emergency has occurred, shall be operational within twelve (12) hours of activation, and shall be sustainable until the emergency situation is resolved and normal conditions are restored or the contract is terminated, whichever comes first. When any disruption of normal, daily operations occurs, the Contractor Task Manager shall promptly open an effective means of communication with the COR and verify:

Key points of contact (Government and Contractor) Temporary work locations (alternate office spaces, telework, virtual offices, etc.)

Means of communication available under the circumstances (e.g. email, webmail, telephone, FAX, courier, etc.)

Essential work products expected to continue production by priority

The Contractor Task Manager, in coordination with the COR, shall make use of the resources and tools available to continue DHA contracted functions to the maximum extent possible under emergency circumstances. Regardless of contract type, and of work location, Contractors performing work in support of authorized tasks within the scope of their contract shall charge those hours accurately in accordance with the terms of this contract.

2.1.11 Contractor Personnel Performance/Replacement

Key personnel are full time staff and shall be available during standard east coast business hours. Substitutions of proposed Key Personnel shall not be allowed for a period of six (6) months after award, except under extreme circumstances. Any substitution or replacement Key Personnel should have qualification equal to or greater than the individuals proposed. For temporary and/or permanent replacement of Key Personnel, the Contractor shall provide a resume for each individual to the COR. Resumes should be provided at least two weeks (or as mutually agreed upon) prior to making any personnel changes. The Government reserves the right to pre-approve any replacement or substitution of Key Personnel. Contractor personnel must submit necessary information to be issued a clearance prior to reporting for performance.

2.2 Specific Tasks

2.2.1 Program Management Support Services

Not applicable for this Task

2.2.2 Studies and Analysis

Not applicable for this Task

2.2.3 Performance Based Budgeting / Financial Management

Not applicable for this Task

2.2.4 Business Process Improvement

Not applicable for this Task

2.2.5 Functional Validation and Verification

Not applicable for this Task

2.2.6 Records Management

Not applicable for this Task

2.2.7 Information Management

Not applicable for this Task

2.2.8 ERMOS Operations and Maintenance

2.2.8.1 Technical Management

2.2.8.1.1 Certification and Accreditation (C&A) Support – Deliverables 66, 72

The Contractor shall provide documentation, data, and access as required to any components of federal information systems that it supports to assist the Government in attaining Certification and Accreditation in accordance with OMB Circular A-130, “Management of Federal Information Resources." All Contractor personnel working on government networks shall complete the ADP Security package and shall be approved for working information systems. Additionally, the Contractor shall provide documents, data, and access as required for any systems the Contractor supports that undergo major changes and require recertification. Further, the Contractor shall provide access to documents, data, and facilities as required for annual systems reviews.

The contractor shall ensure that the ERMOS is compliant with all the applicable Department of Defense (DoD) Security Technical Implementation Guides (STIGs) as specified by the Government (e.g., Fortify, WebInspect, AppDetect, ACAS, SCAP, etc.). The contractor shall perform and execute all applicable application and database STIGs for all DHSS applications quarterly. The contractor shall deliver the Applicable STIG and Scan Findings (Deliverable 66) to the Government.

The contractor shall document the technical procedures to bring the applications into compliance with the DoD STIGS. The contractor shall provide this document to the government in the form of an Application Security Vulnerability Mitigation Report (Deliverable 72).

The contractor shall treat the changes that result from the application of the STIGs as a software update and follow the processes outlined in those sections of this PWS.

2.2.8.1.2 Program / System Security – Deliverables 15, 81

The Contractor shall identify as security-critical those core items (hardware, software, or business process) whose failure could lead to a breach of system security. For each risk identified, the Contractor shall develop a security assurance strategy to ensure that the requirements, design, implementation, and operating procedures for the identified product minimize or eliminate the potential for breaches of system security. The Contractor shall record the strategy in the Security Management Plan (Deliverable 15), implement the strategy, and produce evidence, as part of required designs, that the security assurance strategy has been carried out.

The Government requires that contractor employees use CAC-enabled GFE laptops.

DHSS systems require contractor personnel to have at least an ADP/IT II position sensitivity designation. ADP/IT II positions are those positions in which the contractor is responsible for the direction, planning, design, operation, or maintenance of computer systems (both hardware and software). All contractor personnel working on government systems shall have successfully completed a NACLC (National Agency Check with Local Agency and Credit) resulting in ADP/IT-II position sensitivity designation. The contractor shall designate personnel who are ADP/IT-I cleared or have a Secret clearance who shall be responsible for the maintenance and upkeep of GFE laptops.

DoD 8570.01-M defines the training and certification for individuals in the cybersecurity workforce. By the definitions in section C2.1.6, a person is included in the cybersecurity workforce if they are involved a number of tasks, including, to name a few, the review of system usage audit data, assessment and implementation of patches and fixes to address Information Assurance Vulnerability Management, maintaining system and application configuration logs, etc. For any tasks that require cybersecurity certified staff per the 8570.01M requirements, the Contractor must offer staffing that complies with the 8570.01M requirements.

Contractors shall use CAC Enabled GFE laptops to remotely (from any domain other than .mil) perform administration and operational support, and test within the government-controlled ERMOS environments. The GFE will be preconfigured to include VPN clients, encryption at rest software, a host based firewall product, and an Antivirus software package. Additional software will be furnished as required. The Contractor shall assign a POC responsible for the GFE acceptance and distribution of the GFE to the required administrators, developers, and/or testers. Concerning government furnished laptops:

It is the responsibility of the Contractor to ensure that all GFE is up to date with all available security patches and updates;

It is the responsibility of the Contractor to keep the Laptop maintained utilizing the supplied GFE maintenance contract;

The Contractor shall report quarterly as to the status and location of assigned laptops in a GFE Inventory Report (Deliverable 81);

The assigned laptops will be periodically inspected at the Government's discretion;

It is the responsibility of the Contractor to ensure that the required security features and configurations remain enabled and unchanged;

It is the responsibility of the Contractor to ensure that only DHSS approved software is installed or used.

Prior written consent is required for new software installs;

It is the responsibility of the Contractor to perform all subsequent administrative tasks (troubleshooting, defragging, "sanitizing" when transferred to new users, reinstalling OS or software, etc.);

The laptops are only to be used in the performance of required government tasks. The laptops remain the property of the Government and must be returned on demand.

2.2.8.1.3 Cybersecurity Testing

2.2.8.1.3.1 Application Security Vulnerability Baselines – Deliverable 24 The Contractor shall execute government furnished tools to develop a security vulnerability baseline for each application or common service component covered by this PWS. The Government will provide direction to the Contractor on the order of the applications to analyzed. The baseline results shall be analyzed by the Contractor and a recommended plan to mitigate the vulnerabilities shall be created by the Contractor. The baseline findings, analysis, and recommended plan will be submitted individually for each application as Application Security Vulnerability Baseline (Deliverable 24).

2.2.8.1.3.2 Application Security Vulnerability Validation Recommendation – Deliverable 25 Prior to the Government accepting software for placement into the CM library, the Contractor shall execute the government furnished tools to create a security vulnerability assessment for each package proposed for delivery to CM. The assessment results shall be analyzed by the Contractor to determine whether vulnerabilities have been addressed appropriately and a recommendation made to the Government whether to accept or reject the software package based on the assessment results. The assessment findings, analysis and recommendation shall be delivered to the Government as Application Security Vulnerability Validation Recommendation (Deliverable 25).

2.2.8.1.3.3 Information Assurance Vulnerability Message Compliance – Deliverable 65 Contractor shall register and subscribe to U.S. CERT and the security center websites to be alerted to all released security advisories and security alerts for the application software products. Contractor shall maintain and sustain compliance with all vendor-released security patches including applicable Information Assurance Vulnerability Messages (IAVM) to include, but not be limited to:

Testing Responses to IAVM data calls Creation and submission of Change Request in compliance with DHSS Configuration Management (CM) process Step-by-Step implementation/test procedures and detailed test results for applying the IAVM to the application.

Implementation of the IAVM in all environments.

Notification to CM once the security patch has been deployed.

All security patches will be implemented on the Development/Test environment before implementation in Production. The contractor SHALL NOT implement and test any security patches on contractor owned equipment, unless pre-approved by the Government in writing. The Contractor shall scan the environments quarterly. The Contractor is required to address and mitigate the environment findings quarterly so the cybersecurity posture is maintained and up to date. Should DoD Regulations require more frequent scanning, the contractor shall be required to match the required scanning frequency.

The Contractor shall submit to the Government a list of patches applied with a description of the vulnerability each patch addressed in the form of a Security Patch Implementation Report (Deliverable 65).

2.2.8.1.4 Configuration Management (CM) –Deliverables 16, 54, 57 The Contractor shall follow industry standard configuration management (CM) practices throughout the ERMOS lifecycle activities, and shall create and maintain a current and up-to-date product baseline inclusive of all descriptive and operational documentation required to create and sustain the ERMOS.

The Contractor shall conduct CM on all software, systems, and documentation called for hereunder, and submit a release package of updated product baseline components (i.e., new &/or modified code including application patches and/or upgrades, and new/updated technical documentation) in accordance with the DHSS CM Master Plan and CM Policy. The plan and policy documents shall be provided at the task order kick-off meeting. The Contractor shall develop a Configuration Management Compliance Plan (Deliverable 16), describing procedures and policies that will ensure that the Contractor, as well as all subcontractors performing under this contract, shall perform in full compliance with the government approved CM Compliance Plan.

In accordance with the Government’s CM processes and procedures, the Contractor shall submit a release package for Government approved modifications to the product baseline. The release package shall include as applicable:

New or modified COTS upgrades/patches (Deliverable 54) New or updated Technical Documentation (Deliverable 57) defining the configuration, and describing the operations and maintenance requirements of the production system. Updated Technical Documentation shall reflect all changes included in the production release

Test and Evaluation Report (see Section 2.2.8.1.12.4.2) Release Notes (see Section 2.2.8.1.12.6) Updated Application Configuration Report (see Section 2.2.8.1.4.3)

All items included in the Contractor’s release package shall be considered Configuration Items and shall therefore be under Government control from the time they are delivered. From receipt of the Contractor’s release package following testing, DHSS shall utilize the electronic CM tools, Serena Business Manager and Version Manager, to maintain Government control of all modified and new components of product baselines as they progress from testing to insertion into the Production environment.

2.2.8.1.4.1 Change Control (CC)

The Contractor shall work under the guidance of the Government designated Configuration Management Lead to ensure that all changes to the ERMOS application or ERMOS system components occur within DHSS’s government approved change control processes. Changes subject to DHSS change control processes include both scheduled and changes necessitated by incidents resulting in unplanned downtime.

The Contractor shall use DHSS change control and workflow management systems, processes, and procedures in working all application and database administration tasks under this order. All changes to ERMOS must be authorized in accordance with the DHSS Configuration Control Board approval process.

2.2.8.1.4.2 Release Authorization

The Contractor shall receive documented notification of Government release authorization prior to deploying any software, including upgrades and patches, to operational systems.

2.2.8.1.4.3 Application Configuration Report – Deliverable 84 The Contractor shall document the configuration of each application component of the ERMOS and deliver an Application Configuration Report (Deliverable 84). The report shall be updated to reflect any configuration changes. The documentation shall contain but not be limited to:

Operating System Version Web/App server Version Database Version 3rd Party Products and Versions, Editions and platforms File System mount points and Partition Sizes Last date of software support i.e. end of life Full configuration settings/installation instructions

The Contractor shall assist in creating and updating the DHSS Requirements Worksheets (DRWs) encompassing all environments.

2.2.8.1.5 Risk Management – Deliverable 71

The Contractor shall establish and maintain a Risk Management Program. The identified risks, risk assessments, and risk mitigation strategies must be documented in a Risk Management Plan (RMP) (Deliverable 71). The RMP shall assess identified risks by 1) the probability and consequences of occurrence, and 2) the impact of the identified risks on cost, schedule and performance. Risk mitigation strategies shall be developed and implemented for all risks identified.

2.2.8.1.6 Service Level Management – Deliverables 91, 92

The Contractor shall sign a Service Level Agreement (SLA) (Deliverable 91) negotiated with the Government within 30 days of contract award. The Service Level Agreement shall be reviewed and updated at least annually.

At a high level, service level management shall contain:

Service Levels Definition Uptime and availability requirements; unless specified otherwise in the SLA, it shall be assumed that

ERMOS shall be operational 24x7x365 and that all planned maintenance activities requiring downtime shall occur on weekends

Mean Time To Recover from specific failures Mean Time Between Failures of specific components Performance requirements (e.g. number of concurrent sessions, average response times) Problem resolution metrics Currency of data available within system (transactional, query /facts, and reference / master data)

The Contractor shall track the metrics contained in the Service Level Agreement and shall report on them based on the frequency agreed in the Service Level Agreement, but not less frequently than quarterly. The Service Level Attainment Report (Deliverable 92) list the levels attained for each measure for ERMOS or individual components as identified in the negotiated SLA. For metrics that consistently fail to meet the desired service level, the Contractor shall provide a remediation plan or provide an analysis of why the service level cannot be attained.

2.2.8.1.7 Availability Management

Availability is a critical aspect of user satisfaction and is part of the Service Level Agreement. Availability management requires the Contractor to take proactive measures to maximize system uptime and performance (restricted to ERMOS assets under management of the Contractor), track and report on attainment of the availability thresholds and objectives (metrics) established and documented in the SLA, and mitigate issues that interfere with meeting those objectives. Attainment and analysis of ERMOS availability shall be reported in the Service Level Attainment Report, including the Contractors methodology for maximizing ERMOS availability, as well as recommendations to the Government.

2.2.8.1.8 Test Program – Deliverables 18

The Contractor shall develop and implement a test and evaluation program to ensure that all services, deliverables, and documents called for under this award meet DHA and DHSS requirements prior to delivery to the Government.

The Contractor shall create a Test Evaluation Program Plan (TEPP) (Deliverable 18), in accordance with the Government’s Test Plan provided at the task order kick-off meeting, to describe the methodology and approach that will be used by the Contractor to validate product performance internally.

2.2.8.1.9 System Updates

Contractor shall deploy…