HSS26045-PCMDCAS_AppB.pdf

i

STATE OF DELAWARE

DELAWARE HEALTH AND SOCIAL SERVICES

OFFICE OF THE SECRETARY

1901 N. DuPont Highway New Castle, DE 19720

Scope of Work and Technical Requirements Appendix B

REQUEST FOR PROPOSAL NO. HSS-25-023

FOR

Patient Clinical Monitoring, Data Capture, and Alert System

Approved Business Case Number: BC0002680 ii

Table of Contents 1 Project Overview

1.1 Background and Purpose

2 DHSS Program and System Overview

2.1 DHSS

2.2 The Division

2.3 Support/Technical Environment

2.3.1 Information Resource Management (IRM)

2.3.2 Department of Technology and Information (DTI)

2.3.3 Division Business Analyst Group

3 DHSS Responsibilities

3.1 Staffing Roles

3.1.1 Project Organization Chart

3.2 DHSS Staff Participation

3.3 Resource Availability

3.4 Change Control

3.5 Deliverable Review

3.6 Implementation

4 Contractor Responsibilities/Project Requirements

4.1 Staffing

4.1.1 On-Site Staffing Requirement

4.1.2 Project Director Requirement

4.1.3 Project Manager Requirement

4.1.4 Project Help Desk Staff Requirement

4.2 Project Management

4.3 Requirement to Comply with HIPAA Regulations and Standards

4.4 Security Requirements

4.4.1 Authorizations

4.4.2 Architecture Requirements

4.4.3 DHSS Hosting Requirements

4.4.3.1 Requirement to Comply with State Policies and Procedures

4.4.3.2 Standard Practices

4.4.3.3 Confidentiality and Data Integrity

4.4.3.4 Security Controls

4.4.3.5 Cyber Security Liability

4.4.3.6 Information Security

4.4.3.7 Mandatory Inclusions

4.4.3.7.1 Network Diagram

4.4.3.7.2 List of Software

4.4.3.7.3 3rd Party Authentication

4.4.3.7.4 Password Hashing

4.4.3.7.5 Data Encryption

iii

4.4.3.7.6 Securing DHSS Data

4.4.4 Mandatory Inclusions for Cloud/Remote Hosting

4.4.4.1 Network Diagram

4.4.4.2 List of Software

4.4.5 DTI’s Terms and Conditions Agreement

4.4.5.1 Agreement Exceptions

4.4.6 Subcontractor Requirements

4.4.7 Standard Practices

4.4.8 Additional Security Requirements

4.4.8.1 Encryption of Data at Rest

4.4.8.2 Encryption of Data in Transit

4.4.8.3 DHSS Data Rights

4.4.9 UAT and Training Environments

4.4.10 Masking of Production Data in Lower Environments

4.4.11 Offsite Project Work

4.4.12 Offshore Prohibitions

4.4.13 Other Technical Considerations

4.5 Reporting

4.6 Performance

4.7 Customizable COTS Solutions

4.8 Backup and Recovery

4.9 Disaster Recovery

4.10 Specific Project Tasks

4.11 Project Deliverables

4.11.1 Deliverable Review Process

4.11.2 Project Deliverables by Phase

4.11.2.1 Phase 1

4.11.2.2 Phase 2

4.11.2.3 Phase 3

4.11.2.4 Phase 4

4.11.2.5 Phase 5

4.11.2.6 Phase 6

4.12 Project Expectations

4.12.1 Site Requirements

4.12.2 DHSS Hosted Solutions

4.12.3 Remotely Hosted Solutions

4.12.4 Environment Responsibilities

4.12.5 Unit Testing

4.12.6 System Integration Testing

4.12.7 User Acceptance Testing (UAT)

4.12.8 Production Implementation

4.12.9 Legacy Data Conversion

4.12.10 Training

4.12.10.1 System User

4.12.10.2 Technical

iv

4.12.11 Maintenance and Operations (M&O)

4.12.12 Documentation

4.12.13 Software Escrow Agreement

4.12.14 Copyrighted/Proprietary Software Inclusion

4.12.15 Miscellaneous Requirements

5 Proposal Evaluation/Contractor Selection

5.1 Process

5.2 Proposal Evaluation and Scoring

5.2.1 Mandatory Requirements

5.2.2 Technical Proposal Scoring

5.2.3 Business Proposal Consideration

5.2.4 Contract Negotiation

6 Contractor Instructions

6.1 Submission Information

6.1.1 RFP and Final Contract

6.1.2 Proposal and Final Contract

6.1.3 Modifications to Proposals

6.1.4 Alternative Solutions

6.2 Technical Proposal Contents

6.2.1 Transmittal Letter (Section A)

6.2.2 Technical Proposal Required Forms (Section B)

6.2.3 Executive Summary (Section C)

6.2.4 Contract Management Plan (Section D)

6.2.5 Project Requirements (Section E)

6.2.6 Staff Qualifications and Experience (Section F)

6.2.7 Firm Past Performance and Qualifications (Section G)

6.2.8 Policy Memorandum Number 70 (Section H)

6.2.9 RFP Exhibits (Section I)

6.3 Business Proposal Contents

6.3.1 Project Cost Information (Section A)

6.3.2 Software and Hardware Information (Section B)

6.3.3 Contractor Stability and Resources (Section C)

7 Terms and Conditions

7.1 Payment for Services Rendered

7.2 Contractor Personnel

7.3 Funding

7.4 Confidentiality

7.5 Contract Transition

7.6 Professional Services Agreement (PSA) Template

7.7 Contract Amendments

8 Exhibits v

A. General Terms and Conditions B. Certification Sheet and Statement of Compliance C. Website Links (in alphabetical order) D. Key Position Resume E. Project Cost Forms F. Mandatory Submission Requirements Checklist G. Crosswalk of RFP Section 4 H. Contractor Project Experience I. Deliverable Acceptance Request (DAR) J. Contractor Contact Information K. Criminal Background Check Instructions

Vital Signs Monitoring and Nurse Call Alert Services

1 Project Overview

1.1 Background and Purpose

The State of Delaware (State), Department of Health and Social Services (Department or DHSS) wishes to sign a contract for professional services with a primary contractor (Contractor).

Activity Schedule Public Notice 3/16/2026

Deadline for Questions 4/6/2026 @ 4:30 PM EDT

Mandatory Bidder's Meeting 4/20/2026 @ 1:00 PM EDT

Response to Questions Post By: 5/4/2026

Deadline for Receipt of Proposals 5/18/2026 @ 1:00 PM EDT

Estimated Notification of Award 7/31/2026

Estimated Project Start Date 10/1/2026

2 DHSS Program and System Overview

2.1 DHSS

The mission of DHSS is to improve the quality of life for Delaware's citizens by promoting health and well-being, fostering self-sufficiency, and protecting vulnerable populations.

DHSS is comprised of eleven divisions as follows:

• Office of the Secretary

• Division of Substance Abuse and Mental Health

• Division of Child Support Services

• Division of Health Care Quality

• Division of Developmental Disabilities Services (DDDS)

• Division of Public Health

• Division of Services for Aging and Adults with Physical Disabilities

• Division of Social Services

• Division of Medicaid and Medical Assistance

• Division of State Service Centers

• Division for the Visually Impaired

2.2 The Division

DDDS supports individuals with intellectual and developmental disabilities to live their good lives by accessing services they need to thrive in their community. DDDS works to identify and support the unique needs of eligible service recipients by offering access to an extensive network of providers including: employment and pre-vocational services;

support coordination and community navigation; assistive technologies; respite; a variety of day and residential programs; and, options for supported living.

Stockley Center, located in Southern Delaware, is a Medicaid certified Intermediate Care Facility for individuals with Intellectual and Developmental Disabilities. The 50 - bed facility provides both intermediate and skilled nursing care for individuals requiring a variety of complex supports and medical needs. Each residential suite is staffed by registered nurses and certified nursing assistants among other ancillary staff members assisting residents to meet their physical, mental, personal and social goals, wishes, and desires.

Stockley Center supports a philosophy that all individuals we serve are exceptional people who deserve to live in a supportive and enriching environment that will foster and fulfill their needs, wishes and desires.

2.3 Support/Technical Environment

The three groups responsible for the development and operation of the automated systems that support the Division are described below. These three groups will be responsible for review and approval of all project deliverables, invoices and milestone payments. IRM will serve as the liaison with DTI (see below). The selected contractor will coordinate efforts for this project with the Project Director, other project contractors, State of Delaware participants, and stakeholders.

2.3.1 Information Resource Management (IRM)

The Project Director will oversee the project budget in coordination with the Department of Technology and Information (DTI), State Office of Management and Budget (OMB), and the division. The IRM unit is responsible for providing DHSS divisions with direct programming support of automated systems, as well as consulting support and management of automated systems software, contractors and development projects.

IRM consists of an Applications Development, Technology Planning, Base Technology, Telecommunications, Security, and Help Desk support group all who participate in all phases of the project lifecycle as appropriate.

IRM will appoint a Project Director with broad oversight authority for all project activities.

A Technical Manager will be appointed and report to the Project Director for project-related activities. The Contractor on this project will report to the Project Director. The Project Director will report to the Director of Information Resource Management and have a dotted line to DTI’s Director of Major Projects.

2.3.2 Department of Technology and Information (DTI)

DTI is a separate cabinet level agency responsible for running the majority of other State agencies’ computer operations, the wide area data network, and setting and enforcing Statewide IT policy and standards. DTI as a separate State agency does not fall under the authority of DHSS. However, the Project Director has a dotted line to DTI’s Director of Major Projects and is required to work with DTI groups throughout all phases of the project lifecycle, review project deliverables, and oversee the project budget. DTI is responsible for supplying Wide Area Network (WAN) systems support to DHSS as well as other State agencies. DTI also provides State agencies with technical consultant services.

2.3.3 Division Business Analyst Group

This group serves as the division liaison between IRM and Contractor technical staff with program staff. They typically translate business needs into IT requirements and vice versa. This is a critical function that ensures that division business requirements are properly communicated to technical staff and that division program staff understand IT policies and standards as they relate to the project. This group works closely with IRM and Contractor staff on all technical aspects of the project to ensure close communication with program staff on all phases of the project life cycle including RFP, business case process, contractor negotiations, deliverable review and signoff, through testing, implementation, and post-implementation support. For this project, a Functional Manager will be appointed. This position will report to the Project Director for project-related activities

3 DHSS Responsibilities

The following are DHSS responsibilities under this RFP. Outlined in the following subsections are such areas as project staffing, project management, available resources, and system testing and implementation (if applicable). DHSS staff expectations for this initiative beyond what is stated here must be clearly spelled out by the Contractor.

3.1 Staffing Roles

As stated above, the Division will appoint a Project Director. The Project Director will serve to manage project staff including Contractor staff during this project. All project deliverables will be approved by signature of the Project Director, Technical Manager and the Functional Manager. The Project Director will serve as the overall project lead with input from the Technical Manager and the Functional Manager

The Project Director will serve as primary coordinator to ensure that Joint Application Design (JAD) sessions take place with the appropriate subject matter experts (SME), that project documents and deliverables are thoroughly reviewed, and that approval takes place within agreed upon timeframes. This individual is also responsible for scheduling and coordinating User Acceptance Testing (UAT), when appropriate. The Project Director will coordinate with other divisions and State agencies for their input as needed. These staff will serve primarily as subject matter experts on relevant Division applications and related systems and will participate in meetings and deliverable review as necessary.

The Technical Manager and the Functional Manager will serve as primary technical liaisons to ensure that contractor and DHSS and DTI technical staff work together effectively to identify current and future technology considerations and make key technology decisions. The Technical Manager will serve as the primary liaison with DTI staff to gather State level input as needed.

The Project Director will report to a Project Steering Committee made up of representative managers from the Division, IRM and DTI. This Committee will meet monthly to review project status, progress and issues. The Project Steering Committee will report to an Executive Sponsors group. The Executive Sponsors group will be made up of representatives from DHSS, DTI, OMB and the Division. They will meet quarterly to discuss overall project status, progress and issues, project management, funding, staffing, sponsor issues, stakeholder participation and tasks planned for the upcoming quarter.

3.1.1 Project Organization Chart

The following sample organization chart outlines the proposed management structure for this project. Proposals must include the respondents proposed organizational chart for this project.

Project Director DTI PMO

Project Steering Committee

Executive Sponsors

PMO

Technical Lead

(IRM)

Functional Lead

(Division) QA/IV&V

System Architect

Telecomm

Base Tech

Applications Org Change Management

Testing

Project Coord/ Scheduler

Business Analyst/ Risk Lead

Prime Vendor

Ancillary Vendors

Functional Area

Functional Area

Functional Area

Functional Area n

3.2 DHSS Staff Participation

The Project Director will be assigned to work on this project full time. Additional DHSS staff participation is as assigned and is in addition to their primary responsibilities. DHSS staff normally work 7.5 hour days from 8:00 AM – 4:30 PM, although some staff flex their schedules. No DHSS staff will be available for data cleanup or meta-data definition.

However, divisional SME’s can serve to advise contractor on these topics. No DHSS technical staff will be assigned to this project to assist in the coding of the system. DHSS technical staff will attend JAD sessions as assigned. It is important to note that documentation on the existing systems may be missing, incomplete, out of date or in error.

Division staff will be responsible for user acceptance testing. The Division will be responsible for assigning a primary and backup division liaison and knowledgeable subject matter experts for the duration of JAD sessions related to their areas of expertise. These assignments will be sent to the Project Director prior to the start of the JAD sessions.

Attendance at these sessions is mandatory for assigned staff. These same subject matter experts along with other staff will be assigned to participate during UAT for their areas of expertise. Adequate divisional staff participation is critical.

3.3 Resource Availability

IRM applications, telecommunications and HelpDesk staff are on site from 8:00 AM to 4:30 PM on State business days. The State network is very stable and unscheduled downtime is minimal. Given that the network is an essential State resource, any reported problems have a very high priority and are dealt with immediately. Biggs Data Center power is conditioned and outside supply fluctuations can trigger a switch to automatic local power generation capability. DHSS has audio and video-conferencing capabilities as well in specific on-site locations for remote meeting participation. Remote connectivity through SSL-VPN is available for offsite work for contracted staff that must access, update or maintain servers and/or applications in the DMZ. Please refer to Exhibit C for more information on the DHSS IT environment.

3.4 Change Control

Scope control is critical to the success of any IT project. If the project is to remain on time and within budget, scope must be tightly managed. In this vein, the project will establish a Change Control Board (CCB) to review all changes requested beyond the scope established in the contract. This entity will be made of representatives from DHSS (Business and IRM) and the project contractor(s) to review Change Requests (CRs) and vet them as to whether they are critical for inclusion in the implemented solution. Non-critical requests will be prioritized for consideration in the M&O phase. CRs may be swapped for CRs of similar level of effort in order to contain scope. At a certain point, however, design must be locked down at which point no other CRs will be considered for inclusion at implementation. This design lock down date must be documented in the baselined project plan deliverable. The change control process will be documented in the Communications Plan deliverable.

3.5 Deliverable Review

It is the responsibility of DHSS to perform deliverable review including User Acceptance Testing on all functional aspects of the project. DTI may participate in the review process for certain deliverables. It is the responsibility of DHSS to review all project deliverables in the agreed upon timeframe. DHSS will notify the Contractor of any changes to the review schedule. Milestone invoicing and payment is contingent upon formal DHSS approval.

Likewise, production implementation of each module is contingent upon formal DHSS approval.

3.6 Implementation

Production implementation is normally an IRM responsibility. Depending on the solution selected, IRM may require participation of contractor staff. DHSS will be primarily responsible for post implementation administration if the system resides at the Biggs Data Center. If a hosted solution is selected, the Contractor has primary administration responsibilities.

4 Contractor Responsibilities/Project Requirements

The following are contractor responsibilities and project requirements under this RFP.

Please note that specific roles, responsibilities and expectations for DHSS staff under this initiative should be delineated in Section 3.

The contractor is expected to provide most of the expertise and provide for the full range of services during the project. Contractors must discuss each of these subsection requirements in detail in their proposals to acknowledge their responsibilities under this

RFP.

Contractors must have demonstrated experience and depth in the following areas:

• Successful implementation of the proposed solution in two or more sites similar to the solution being proposed for DHSS.

• Compliance with IDD Federal and Delaware State Rules and Regulations associated with proposed system(s).

• Ensuring interoperability between proposed system and existing State health care solutions, devices, peripherals and any other supporting hardware, software and equipment according to HL7 standards, CMS interoperability requirements, and HITECH and ARRA act provisions.

• Industry standard project management practices applied to the implementation of the proposed system(s).

This experience is critical in ensuring project success in terms of the future direction of the Division’s information technology development, as well as maintaining an open partnership with project partners.

4.1 Staffing

Contractor will propose and supply resumes for the following key positions including:

• Project Manager

• Business Analysts

• Network Engineer

• Product Technician

• Senior Developers

• Technical Analysts (i.e. DBA, SE, etc.)

• Technical Writer

• Testing Manager

• Trainer

The resumes will be for specific named individuals and will be in the format specified in Exhibit D. Other positions may be proposed at the contractor’s discretion. One person may be proposed to fill more than one role. The contractor project manager and other key staff like the Business Analyst(s) may be required to be on site at the discretion of the DHSS project director.

4.1.1 On-Site Staffing Requirement

The following key contractor staff may be required to be on-site at the Biggs Data Center in New Castle, Delaware, as specified by the Project Director:

• Contractor Project Manager

• Business Analyst

• Product Technician

• Network Engineer

• Testing Manager

• Trainer

DHSS and the key contractor staff will work very closely together on this project. This may require an on-site presence. DHSS will provide office space including furniture, phones and network connectivity for all on-site project staff. Contractor will be responsible for all other office necessities including workstation and required software. It is vital for the contractor project manager and key staff to play an active on-site role in the project and be visible and accessible.

4.1.2 Project Director Requirement

The Contractor Project Director is the individual who has direct authority over the Contractor Project Manager and will be the responsible party if issues arise that cannot be resolved with the Contractor Project Manager. The Contractor Project Director does not need to be on-site except for designated meetings or as requested. It is critical that a named Contractor Project Director with appropriate experience be proposed.

4.1.3 Project Manager Requirement

The contractor project manager is normally on-site and manages the project from the contractor perspective and is the chief liaison for the DHSS Project Director. The Project Manager has authority to make the day-to-day project decisions from the contractor firm perspective. This contractor project manager is expected to host meetings with Division Subject Matter Experts (SME) to review Division business organization and functions along with the organization, functions and data of existing information systems relevant to this project. The contractor project manager is expected to host other important meetings and to assign contractor staff to those meetings as appropriate and provide an agenda for each meeting. Weekly on-site status meetings are required, as are monthly milestone meetings. Meeting minutes will be recorded by the contractor and distributed by noon the day prior to the next meeting. Key decisions along with Closed, Active and Pending issues will be included in this document as well. In their proposals, Contractors must include a confirmation that their project manager will schedule status review meetings as described above. It is critical that a named Contractor Project Manager with prior project management experience be proposed.

In their proposals, Contractors must include a confirmation that their Project Manager will schedule status review meetings as required above and that their Project Manager will provide written minutes of these meetings to the DHSS Project Director by noon the business day prior to the next meeting.

4.1.4 Project Help Desk Staff Requirement

Contractor Help Desk expertise is critical to the success of the system. Staff proposed for this function do not need to be dedicated exclusively to this role. They may serve a primary role in addition to providing Help Desk coverage. Secondary Help Desk support must be identified in the resume of the staff member primarily bid for another function. Contractor must supply at least a primary and a backup Help Desk function during the UAT, production Implementation and the warranty timeframe. These staff will provide second-level support during DHSS business hours to callers with system issues. The DHSS Help Desk will provide first-level support. This generally includes resolution of issues such as network connectivity, application log in problems and general PC advice. The contractor will provide second level support. This will be more system-specific and require application expertise. Specific system issues may be referred to third-level divisional support for SME expertise.

4.2 Project Management

The contractor must be the prime contractor to develop all the deliverables required by this RFP. The prime contractor will be directly responsible for all project work and performance of any subsidiary, subcontractor or by any other third party. The prime contractor will ensure that all ancillary contractors understand and are responsible for the requirements of this project. If the prime contractor will be utilizing the services of an ancillary contractor under this project, please give an example of language to be used in the sub-contractual agreement to satisfy this requirement.

The contractor must recommend a core team to work with DHSS over the course of the project and must identify other resources needed. A high-level draft baseline project plan must be created and included as part of this proposal.

For custom development, the contractor is expected to employ a rapid application design methodology to speed customization/development. An iterative model of testing is required which will require early prototypes and subsequent demonstrations of working modules to ensure that the product meets user specifications in terms of user interface and functionality. It will be the contractor’s responsibility to provide complete and accurate documentation for all entities in the system. The contractor is expected to release prototypes/drafts of project deliverables and components for early DHSS consideration and comment in order to expedite the final review process.

4.3 Requirement to Comply with HIPAA Regulations and Standards The selected Contractor must certify compliance with Health Insurance Portability and Accountability Act (HIPAA) regulations and requirements as described in Department of Health and Human Services, Office of the Secretary, 45 CFR Parts 160, 162 and 164 along with the updated ARRA and HITECH act provisions, as well as all HIPAA requirements related to privacy, security, transaction code sets (where applicable) and medical provider enumeration. The proposed solution must meet these cited requirements

HIPAA requirements also apply to entities with which DHSS data is shared. If this data is covered by HIPAA, then the State Business Associate Agreement (BAA) must be signed by both parties to ensure that this data is adequately secured according to State policies and standards (See Section 4.4 for more information on this requirement). This agreement/contract must be in force prior to testing or production implementation of this data exchange. The signed BAA will be attached to the contract.

If the Contractor signs the State BAA, subcontractors will not be required to sign the State

BAA.

If the Contractor is a Covered Entity, they will not be required to sign the State BAA.

However, in this case, subcontractors will be required to sign a BAA with the Contractor and this document will be attached to the contract. Additionally, if the Contractor does not sign the State BAA, the following language must be added to the contract:

Contractor shall perform for Delaware the services specified in the Appendices to this Agreement, attached hereto and made a part hereof. The parties will perform services that involve the use or disclosure of Protected Health Information (“PHI”) that is subject to the final federal Privacy, Security, Breach Notification and Enforcement Rules (collectively the “HIPAA Rules”) issued pursuant to the Health Insurance Portability and Accountability Act of 1996 (the Act including the HIPAA Rules shall be referred to as “HIPAA”) and the Health Information Technology for Economic and Clinical Health Act of 2009 (“HITECH”), as each is amended from time to time. As such, each party represents that it shall comply with HIPAA in performance of the services.

In the proposal, contractor will explain their understanding of the HIPAA regulations and their impact on this project especially in the area of security.

4.4 Security Requirements

4.4.1 Authorizations

All Contractor staff working under this contract will be subject to a Criminal Background Check (CBC). The contractor will be solely responsible for the cost of the CBC. DHSS will review the CBC results. DHSS at their sole discretion may request that a Contractor staff member be replaced if their CBC result is unsatisfactory. See Exhibit K for instructions on this process.

Contractor staff will be required to fill out DTI’s Acceptable Use Policy, Biggs Data Center User Authorization Form, and the Biggs Data Center Non-Disclosure Agreement for necessary authorizations before starting work under the contract. Staff working at a secured DHSS site will be issued a security access card by DHSS.

4.4.2 Architecture Requirements

Securing and protecting data is critical to DHSS. This protection is required for data whether hosted onsite or offsite. As such it is required that the Contractor include in the response to this section proposed architectural diagram(s) in Visio format demonstrating how DHSS data is being secured.

The diagram must include any interfaces between the solution and other solutions. The diagram needs to be clearly documented (ports, protocols, direction of communication). It does not need to contain the inner workings of the solution or proprietary information.

Technical documentation will be required to be produced as part of the contract negotiations process. These will be submitted to DHSS for attachment to a DTI business case. The business case must be in “Recommended” status prior to contract signature or have a clear indication that the contract can be signed subject to conditions listed in the business case. The project business case is a DHSS responsibility. Technical documentation includes a final architecture diagram for each system environment (Prod, UAT, etc.), non-proprietary data dictionary and a high-level process flow diagram. This documentation shall be produced at no cost to DHSS prior to contract signature.

Architecture changes can be highly risky if not planned and tested correctly and therefore must go through the change control process. The architecture diagram may have to be updated along with other documents for prior approval. Architecture changes must be staged in lower environments.at least at the SIT level for integration testing. Formal UAT approval is required for scheduling production implementation.

4.4.3 DHSS Hosting Requirements

This section is only applicable if the solution is being hosted within the State network.

4.4.3.1 Requirement to Comply with State Policies and Procedures The proposed solution must be fully compatible with the DHSS technical environment.

Proposed solutions that are not fully compliant with State standards may be disallowed.

The Information Technology Publications web page (The link to this document is in Exhibit C.) has links to DHSS and DTI policies and standards and other documentation.

See the “Supportive Documentation for Bidding on Proposals” section.

• Please review the MCI and IAS documents referenced on this page. MCI is the Master Client Index which is required for all systems identifying DHSS clients. IAS is the Integrated Authorization System which is a DHSS mechanism for tracking authorized systems users. Contractors will comply specifically with these requirements.

The DTI Systems Architecture Standard contains information confidential to the State and is not published on the internet. However, DTI has set up an email address which will automatically send a response with this document attached. The email address is sysarch@lists.state.de.us.

The application will have at least 3 tiers with the tiers configured and secured as in the sample diagram included in the DHSS Information Technology Environment Standards.

Please see State of Delaware Systems Architecture Standard (The link to this document is in Exhibit C.) and DHSS Information Technology Environment Standards (The link to this document is in Exhibit C.) for more information.

All components of the proposed solution, including third party software and hardware, are required to adhere to the policies and standards described above, as modified from time to time during the term of the contract resulting from this RFP, including any links or documents found at the above referenced web sites.

4.4.3.2 Standard Practices

The contractor(s) shall be responsible for the professional quality, technical accuracy, timely completion, and coordination of all services furnished to DHSS. The contractor(s) shall follow practices consistent with generally accepted professional and technical policies and standards. The contractor(s) shall be responsible for ensuring that all services, products and deliverables furnished to DHSS are consistent with practices mailto:sysarch@lists.state.de.us utilized by, or policies and standards promulgated by, the Department of Technology and Information (DTI). The link to the Enterprise Standards and Policies is in Exhibit C. If any service, product or deliverable furnished by a contractor(s) does not conform to State policies, standards or general practices, the contractor(s) shall, at its expense and option either (1) replace it with a conforming equivalent or (2) modify it to conform to State policies, standards or practices.

4.4.3.3 Confidentiality and Data Integrity

The Department of Technology and Information is responsible for safeguarding the confidentiality and integrity of data in State computer files regardless of the source of those data or medium on which they are stored; e.g., electronic data, computer output microfilm (COM), tape, or disk. Computer programs developed to process State Agency data will not be modified without the knowledge and written authorization of the Department of Technology and Information. All data generated from the original source data, shall be the property of the State of Delaware. The control of the disclosure of this data shall be retained by the State of Delaware and the Department of Technology and Information.

4.4.3.4 Security Controls

As computer, network, and information security are of paramount concern, the State wants to ensure that computer/network hardware and software do not compromise the security of its IT infrastructure. Therefore, the Contractor is guaranteeing that any systems or software meets or exceeds Critical Security Controls. The link to this document is in Exhibit C.

4.4.3.5 Cyber Security Liability

It shall be the duty of the Contractor to assure that all products of its effort do not cause, directly or indirectly, any unauthorized acquisition of data that compromises the security, confidentiality, or integrity of information maintained by the State of Delaware. Contractor’s agreement shall not limit or modify liability for information security breaches, and Contractor shall indemnify and hold harmless the State, its agents and employees, from any and all liability, suits, actions or claims, together with all reasonable costs and expenses (including attorneys' fees) arising out of such breaches. In addition to all rights and remedies available to it in law or in equity, the State shall subtract from any payment made to Contractor all damages, costs and expenses caused by such information security breaches that have not been previously paid to Contractor.

4.4.3.6 Information Security

Multifunction peripherals must be hardened when used or connected to the network. They should be configured to harden the network protocols used, management services, processing services (print, copy, fax, and scan), logging, and physical security. Care shall be taken to ensure that any State non-public data is removed from memory before service calls and/or equipment disposal. Electronic information storage devices (hard drives, tapes, diskettes, compact disks, USB, multifunction peripherals, etc.) shall be disposed of in a manner corresponding to the classification of the stored information, up to and including physical destruction.

4.4.3.7 Mandatory Inclusions

4.4.3.7.1 Network Diagram

The Contractor must include a network diagram of the user’s interaction with the solution and any interfaces between the solution and DHSS must be clearly documented (ports, protocols, direction of communication). The network diagram does not need to contain the inner workings of the solution or proprietary information.

4.4.3.7.2 List of Software

The contractor must include a list of software (operating system, web servers, databases, etc.) that the State needs to utilize the solution. For example, a certain web browser (IE) or web service technology for an interface. The contractor will include a list of browsers and versions that are officially supported for web applications. Please use the following format:

Product Name Version Contractor Name

Required for Development?

Required for M&O?

4.4.3.7.3 3rd Party Authentication The contractor must include a list of any 3rd party authentication solutions or protocols that they support.

4.4.3.7.4 Password Hashing

The contractor must describe the method used by the solution for hashing user passwords. Include items like hash algorithm, salt generation and storage and number of iterations.

4.4.3.7.5 Data Encryption

The contractor must describe the solution’s ability to encrypt non-public State data in transit and at rest. Include encryption algorithm(s) and the approach to key management.

4.4.3.7.6 Securing DHSS Data

The contractor must describe how DHSS data will be protected and secured.

4.4.4 Mandatory Inclusions for Cloud/Remote Hosting

This section is only applicable if the data and/or service is not being hosted within the State network.

4.4.4.1 Network Diagram

The Contractor must include a network diagram of the user’s interaction with the solution and any interfaces between the solution and the State needs to be clearly documented (ports, protocols, direction of communication). The network diagram does not need to contain the inner workings of the solution or proprietary information.

4.4.4.2 List of Software

The contractor must include a list of software (operating system, web servers, databases, etc.) that the State needs to utilize the solution. For example, a certain web browser (IE) or web service technology for an interface. The contractor will include a list of browsers and versions that are officially supported for web applications. The software list will be formatted as follows:

Product Name Version Contractor Name

Required for Development?

Required for M&O?

4.4.5 DTI’s Terms and Conditions Agreement

DTI’s Terms and Conditions Governing Cloud Services and Data Usage Agreement (“T&Cs Agreement”) must be signed for provision of XaaS and accessing/storing State data outside of the State network. This document has columns identifying which provisions are mandatory depending on whether the data is Public or Non-Public.

The data classification for this procurement is Non-Public.

The mandatory clauses are identified by the checkmark in the appropriate Public/Non- Public column in the T&Cs Agreement. Contractor is instructed to review this document and sign and scan as applicable and include with your response.

Paragraph 5 specifies that State PII and/confidential information must be encrypted at rest. If the Contractor is proposing a solution that will comply with this requirement, please include the following statement in your response to this section:

• “[Contractor Name] is proposing a solution encrypting State PII at rest.”

In section 4.4.8.1 of this RFP, Contractor must specifically describe how the data will be encrypted at rest.

Cyber Liability Insurance If the Contractor cannot comply with the requirement to encrypt State PII and confidential data at rest, then Contractor must purchase adequate Cyber Liability Insurance as specified in paragraph 11 of the Agreement. Please include the following statement in your response to this section:

• “[Contractor Name] is proposing a solution that will not encrypt State PII and confidential data at rest and intends to purchase Cyber Liability Insurance at the proper level and provide a valid certificate prior to contract signature.”

The selected Contractor will present a valid certificate of Cyber Liability Insurance for attachment to the contract prior to contract signature.

4.4.5.1 Agreement Exceptions

If Contractor can only accept a clause with conditions (Accept Conditionally) or does not agree with (Reject) a clause as written, then please fill out the following DTI T&Cs Agreement Exceptions table as part of your response to this section. Please include a Comment for each exception stating why you Accept Conditionally or Reject. If you Accept Conditionally, state what controls are or can be put into place to provide for the same or similar level of compliance.

DTI T&Cs Agreement Exceptions (Example)

Paragraph Response Comment

5 Accept Conditionally

We cannot encrypt data at rest. However, we intend to substantially comply with the Cyber Liability Insurance requirement.

7 Accept Conditionally

We will provide the results of our internal Criminal Background Checks in lieu of the stated requirement.

Any exceptions specified will be vetted by DTI prior to contract signature. Individual clauses may be negotiated and updated by DTI. In this case, DTI’s written approval of the negotiated Agreement version will be attached to the final contract.

If the Contractor accepts all clauses as originally specified, Contractor will respond to this subsection with “We accept all clauses in the T&Cs Agreement”. Do not include the Template Exceptions table in this situation.

4.4.6 Subcontractor Requirements

Subcontractors are not required to sign the T&Cs Agreement; however, the Contractor is expected to hold them responsible to the same or more stringent security requirements to ensure that State data is adequately secured.

The Subcontractor Information Form is included as Attachment 6 in the RFP and must be filled out by the Contractor and signed and dated by both the Contractor and Subcontractor. This form will be required for a change in or addition of subcontractors and attached to a contract amendment after contract signature.

4.4.7 Standard Practices

The contractor(s) shall be responsible for the professional quality, technical accuracy, timely completion, and coordination of all services furnished to DHSS. The contractor(s) shall follow practices consistent with generally accepted professional and technical policies and standards.

4.4.8 Additional Security Requirements

4.4.8.1 Encryption of Data at Rest

If Contractor intends to encrypt State PII/confidential data at rest, please describe the method(s) for encrypting this data.

4.4.8.2 Encryption of Data in Transit

All State data in transit must be encrypted whether transmitted over a public or private network. Contractor will describe the encryption method(s) proposed.

4.4.8.3 DHSS Data Rights

All State data (Public and Non-Public) related to services provided under this contract will remain the sole property of the State. De-identified or derived/aggregated State data is not exempted from this requirement. This provision shall survive the life of the contract.

Contractor does not acquire any right, title or interest in State data under this contract.

Except as otherwise required by law or authorized by the State in writing, no State data shall be retained by the Contractor for more than 90 days following the date of contract termination. After the 90 day timeframe the following provisions will remain in effect:

contractor will immediately delete or destroy this data in accordance with NIST standards and provide written confirmation to the State; contractor is expressly prohibited from retaining, transferring, repurposing or reselling State data except as otherwise authorized by the State in writing; contractor retains no ongoing rights to this data except as expressly agreed to by the State in the contract.

4.4.9 UAT and Training Environments

The UAT and Training environments must be secured at a level equivalent to the security in place for the production environment. It must be sized and architected such that production-sized files can be copied over into UAT. The architecture must be equivalently configured so that performance and load testing will essentially produce the same results and expectations as testing in the production environment. Depending on the type of data (i.e. top secret/highly confidential, behavioral health) and specific security requirements around this data, there may or may not be an expectation to mask field values in the UAT and Training environments. Copying production data into lower environments may be prohibited especially for role-based training. Lower environments with production data that are secured in the same manner may be exempt from masking requirements as well however this may be subject to DHSS or Federal policies and regulations that override this potential exemption or explicitly disallow production data being copied into lower environments. The division DAG will be consulted on what is allowed/disallowed in non-production environments.

4.4.10 Masking of Production Data in Lower Environments

While securing of production data is of critical importance, migration of that data to lower environments presents its own set of challenges as lower environments typically are not as secure as the production environment. Masking of production data in lower environments usually involves deletion or obfuscation of actual PII-related field values such that they have no meaning as plain text and there is no identifiable method of translation back to the original values. If there are plans to copy production data to a less secure environment, Contractor will describe in detail their proposed masking strategy. If there is no expectation that production data will be copied into less secure environments, Contractor will describe their proposed test data generation plans and state clearly in this section that masking of production data is not required under this proposal.

4.4.11 Offsite Project Work

DHSS will permit project work to be done offsite, within the United States and its territories.

For offsite work, DHSS requires strong management of the resources and assigned tasks;

adequate, timely and accurate communications and completion of assigned work by specified deadlines. This is important to any offsite relationship. If Contractor is proposing offsite project work, Contractor must specifically address each of the bulleted items below in this section of the proposal. Otherwise, Contractor will respond to this section as follows:

“No offsite project work proposed.”

Note: For the purposes of this section, the Contractor staff organization includes subsidiary contractors.

• Provide a detailed description of work to be completed offsite along with a breakdown of the type of work to be provided on-site. Quantify this by estimating for each of the deliverables identified in this Section, the percentage of work to be done offsite.

• Provide an organization chart with job titles of offsite staff and their relationship to the Contractor.

• Provide a description of what tasks each job title is responsible for performing.

• Clearly identify if offsite work is to be performed by Contractor staff or subcontractors.

• For offsite subcontractor or Contractor staff, please include the names and resumes of key staff, highlighting prior participation on similar projects. Also provide named or sample resumes for lower-level staff.

• Provide a detailed plan for managing offsite work including communication strategy to accommodate time differences if any. Include contingency plan for completing work should offsite relationship be terminated.

• Propose a meeting schedule for project status discussions with offsite management staff.

• Identify the offsite single point of contact who will serve as the project manager of offsite resources. Describe how this project manager and the on-site project manager will interact. DHSS prefers that the offsite project manager be a Contractor employee. Please refer to RFP Section 4.1 for normal Contractor staffing requirements.

• Provide a contingency plan for substituting on-site staff if offsite relationship becomes problematic as determined by DHSS.

• Provide a description of prior Contractor organization experience with use of offsite Contractor staff or subcontractors and provide U.S. client references for that work.

• Provide a detailed description of proposed project manager's experience in directing offsite staff and/or subcontractors.

• Describe your understanding that DHSS will only provide management of this project and Contractor resources through the on-site project manager. All management/relationships with offsite resources, whether Contractor staff or subcontractors, will be handled by the respective bidding organization.

• Describe how the system components will be tested and staged during customization/development. For DHSS-hosted solutions, DHSS requires that all UAT, production and related environments be located at the Biggs Data Center. All system components of these environments including all system libraries and databases will be located in the data center as well. DHSS staff must approve the results of system testing before systems components are migrated into UAT. It is critical that system components are proven to operate in the Biggs Data Center UAT environment prior to promoting the code to production. Remote developers and testing staff may access these environments through VPN. The UAT environment must be the technical equivalent of the production environment to minimize issues with promoted code and/or database changes in production. Contractors may propose additional environments as necessary or recommended for their solution.

4.4.12 Offshore Prohibitions

See Offshore IT Staffing Policy in Exhibit C.

Offshore is defined as not being within the United States or its territories. Offshore storage and transmission of DHSS data is prohibited. Onshore project data and project artifacts including backup and recovery files in any form shall not be accessed by offshore staff and shall not be copied, processed, transmitted or moved offshore. Contractor is permitted to engage offshore resources including sub-contractors for development and lower level (unit & integration) testing only. Contractor is prohibited from using State data in any form even if masked or obfuscated for offshore testing. All aspects of User Acceptance Testing and production operations will take place onshore.

The provisions in this section…