attachment-1-rfp-2027-nhh-02-patie.xlsx
XLSX spreadsheet 46 KB Posted
- Attached to
- Patient Identification Software System State and local contract opportunity
- Solicitation number
- RFP-2027-NHH-02-PATIE
- Issued by
- Merrimack County, New Hampshire
About this file
This is a technical requirements and pricing worksheet attachment to a Request for Proposal (RFP) issued by the State of New Hampshire Department of Health and Human Services for a Patient Identification Software System to be implemented at New Hampshire Hospital in Merrimack County. The RFP seeks a comprehensive web-based software solution capable of producing patient identification wristbands in multiple colors with tamper-proof clasps for approximately 800 patients annually, with integration capabilities to existing electronic health records systems and compatibility with handheld scanning devices. The system must be delivered with full staff training, software installation, and ongoing support services. Vendor proposals are due by October 21, 2025, at 12:00 PM Noon, with vendor inquiries accepted through September 16, 2025. The anticipated contract will be effective July 1, 2026, with an initial five-year term ending July 1, 2031, and extension options available for up to five additional years.
The worksheet contains 41 distinct deliverables organized across five primary categories: Planning and Project Management (20 deliverables), Installation (3 deliverables), Testing (8 deliverables), System Deployment (6 deliverables), and Operations (4 deliverables). Vendors must respond to mandatory, preferred, and optional technical requirements addressing general specifications, application security, testing protocols, hosting and cloud requirements, disaster recovery, service level agreements, support and maintenance, and project management. The evaluation process allocates 700 of 1,000 total scoring points to technical capabilities and 300 points to pricing. The RFP mandates extensive security compliance including HIPAA regulations, NIST Special Publication 800-171 and 800-53 standards, and requires vendors to provide comprehensive security documentation including Data Protection Impact Assessments, Systems Security Plans, and Disaster Recovery Plans. Vendors must maintain ANSI/TIA-942 Tier 3 data center standards with 99.982% uptime availability, implement 24/7 system availability except during scheduled maintenance, and provide specific response times for deficiency resolution ranging from two hours for critical issues to four hours for non-critical issues.
View the file
Other files for this state and local contract opportunity
| File | Type | Posted |
|---|---|---|
| attachment_3_RFP-2027-NHH-03-PATIE.xlsx | XLSX spreadsheet | |
| attachment_1_RFP-2027-NHH-02-PATIE.xlsx | XLSX spreadsheet | |
| attachment_2_RFP-2027-NHH-02-PATIE.pdf | ||
| RFP-2027-NHH-02-PATIE.pdf | ||
| addendum-2-rfp-2027-nhh-02-patie-0.pdf | ||
| addendum-3-rfp-2027-nhh-02-patie-0.pdf | ||
| attachment-4-rfp-2027-nhh-02-patie.pdf | ||
| attachment-2-rfp-2027-nhh-02-patie.pdf | ||
| attachment-3-rfp-2027-nhh-03-patie.xlsx | XLSX spreadsheet | |
| rfp-2027-nhh-02-patie.pdf | ||
| addendum-1-rfp-2027-nhh-02-patie.pdf |
Show all 11
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Instructions
| Vendor Instructions for Technical (TR) Requirements |
| Vendor Response Column: Place a “Yes” if the current release of the software can fully support ALL the functionality described in the row, without special customization. A “Yes” can only be used if the delivery method is Standard (see delivery method instructions below). Otherwise, enter an "No"; A "No" can only be used with delivery method Future, Custom, or Not Available/Not Proposing (see delivery method instructions below). |
Criticality Column:
(M) Indicates a requirement that is "Mandatory". The State considers it to be of such great importance that it must be met in order for the proposal to be accepted. If the proposer believes that there is something about their proposal that either obviates the need for this requirement or makes it of less importance this must be explained within the comments. The State retains the right to accept a proposal if the need of the requirement is reduced or eliminated by another feature of the proposal.
(P) Indicates a requirement which is "Preferred". This requirement is considered by the State to be of great usefulness but the lack of this feature is not considered serious enough to disqualify the proposal.
(O) Indicates a requirement which is "Optional". This requirement is considered by the State to be one which useful or potentially useful but not a central feature of the Project.
Delivery Method Column:
Complete the delivery method using a Standard, Future, Custom, or Not Available/Not Proposing (as defined below) that indicates how the requirement will be delivered.
Standard - Feature/Function is included in the proposed system and available in the current software release.
Future - Feature/Function will be available in a future release. (Provide anticipated delivery date, version, and service release in the comment area.)
Custom - Feature/Function can be provided with custom modifications. (Respondent must provide estimated hours and average billing rate or flat cost for the software modification in the comment area. These cost estimates should add up to the total cost for software modifications found in the cost summary table in Section X of the RFP).
Not Available/Not Proposing - Feature/Function has not been proposed by the Vendor. (Provide brief description of why this functionality was not proposed.)
Comments Column:
For all Delivery Method responses vendors must provide a brief explanation of how the requirement will be met. Free form text can be entered into this column.
| Vendor Instructions for Activity, Deliverable, and Milestone |
| Vendor shall complete the Activity Deliverable, and Milestone Table identifying estimated delivery date and price. |
Technical Requirements
APPLICATION REQUIREMENTS
tc={C962510D-A045-48AA-A2D2-C5A730FCF5FE}: [Threaded comment]
Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924
Comment:
Integration Requirements have not been added.
Noticed this was not redlined. Please ask the IT Lead to review and remove non-applicable or duplicative requirements and add IT integration requirements as applicable.
| State Requirements | Vendor | ||||
| Req # | Requirement Description | Criticality | Vendor Response | Delivery Method | Comments |
| GENERAL SPECIFICATIONS | |||||
| A1.1 | Ability to access data using open standards access protocol (please specify supported versions in the comments field). | ||||
| M | |||||
| A1.2 | Data is available in commonly used format over which no entity has exclusive control, with the exception of National or International standards. Data is not subject to any copyright, patent, trademark or other trade secret regulation. | ||||
| M | |||||
| A1.3 | Web-based compatible and in conformance with the following W3C standards: HTML5, CSS 2.1, XML 1.1 | ||||
| M | |||||
| APPLICATION SECURITY | |||||
| A2.1 | Verify the identity or authenticate all of the system client applications before allowing use of the system to prevent access to inappropriate or confidential data or services. | ||||
| M | |||||
| A2.2 | Verify the identity and authenticate all of the system’s human users before allowing them to use its capabilities to prevent access to inappropriate or confidential data or services. | ||||
| M | |||||
| A2.3 | Enforce unique user names. | ||||
| M | |||||
| A2.4 | Enforce complex passwords for Administrator Accounts in accordance with DoIT’s statewide User Account and Password Policy. | ||||
| M | |||||
| A2.5 | Enforce the use of complex passwords for general users using capital letters, numbers and special characters in accordance with DoIT's statewide User Account and Password Policy. | ||||
| M | |||||
| A2.6 | Encrypt passwords in transmission and at rest within the database. | ||||
| M | |||||
| A2.7 | Establish ability to expire passwords after a definite period of time in accordance with DoIT’s statewide User Account and Password Policy. | ||||
| M | |||||
| A2.8 | Provide the ability to limit the number of people that can grant or change authorizations. | ||||
| M | |||||
| A2.9 | Establish ability to enforce session timeouts during periods of inactivity. | ||||
| M | |||||
| A2.10 | The application shall not store authentication credentials or sensitive data in its code. | ||||
| M | |||||
| A2.11 | Log all attempted accesses that fail identification, authentication and authorization requirements. | ||||
| M | |||||
| A2.12 | The application shall log all activities to a central server to prevent parties to application transactions from denying that they have taken place. | ||||
| M | |||||
| A2.13 | All logs must be kept for six (6) years. | M | |||
| A2.14 | The application must allow a human user to explicitly terminate a session. No remnants of the prior session should then remain. | ||||
| M | |||||
| A2.15 | Do not use Software and System Services for anything other than they are designed for. | ||||
| M | |||||
| A2.16 | The application Data shall be protected from unauthorized use when at rest. | ||||
| M | |||||
| A2.17 | The application shall keep any sensitive Data or communications private from unauthorized individuals and programs. | M | |||
| A2.18 | Subsequent application enhancements or upgrades shall not remove or degrade security requirements. | ||||
| M | |||||
| A2.19 | Utilize change management documentation and procedures. | ||||
| M | |||||
| A2.20 | Web Services : The service provider shall use Web services exclusively to interface with the State’s data in near real time when possible. | ||||
| M | |||||
| A2.21 | Logs must be configured using "fail-safe" configuration. Audit logs must contain the following minimum information: |
1. User lDs (of all users who have access to the system)
2. Date and time stamps
3. Changes made to system configurations
4. Addition of new users
5. New users level of access
6. Files accessed (including users)
7. Access to systems, applications and data
8. Access trail to systems and applications (successful and unsuccessful attempts)
9. Security events
| M | |||||
| TESTING REQUIREMENTS | |||||
| State Requirements | Vendor | ||||
| Req # | Requirement Description | Criticality | Vendor Response | Delivery Method | Comments |
| APPLICATION SECURITY TESTING | |||||
| T1.1 | All components of the Software shall be reviewed and tested to ensure they protect the State’s web site and its related Data assets. | ||||
| M | |||||
| T1.2 | The Vendor shall be responsible for providing documentation of security testing, as appropriate. Tests shall focus on the technical, administrative and physical security controls that have been designed into the System architecture in order to provide the necessary confidentiality, integrity and availability. | ||||
| M | |||||
| T1.3 | Provide evidence that supports the fact that Identification and Authentication testing has been recently accomplished; supports obtaining information about those parties attempting to log onto a system or application for security purposes and the validation of users. | ||||
| M | |||||
| T1.4 | Test for Access Control; supports the management of permissions for logging onto a computer or network. | ||||
| M | |||||
| T1.5 | Test for encryption; supports the encoding of data for security purposes, and for the ability to access the data in a decrypted format from required tools. | ||||
| M | |||||
| T1.6 | Test the Intrusion Detection; supports the detection of illegal entrance into a computer system. | ||||
| M | |||||
| T1.7 | Test the Verification feature; supports the confirmation of authority to enter a computer system, application or network. | ||||
| M | |||||
| T1.8 | Test the User Management feature; supports the administration of computer, application and network accounts within an organization. | ||||
| M | |||||
| T1.9 | Test Role/Privilege Management; supports the granting of abilities to users or groups of users of a computer, application or network. | ||||
| M | |||||
| T1.10 | Test Audit Trail Capture and Analysis; supports the identification and monitoring of activities within an application or system. | ||||
| M | |||||
| T1.11 | Test Input Validation; ensures the application is protected from buffer overflow, cross-site scripting, SQL injection, and unauthorized access of files and/or directories on the server. | ||||
| M | |||||
| T.1.12 | For web applications, ensure the application has been tested and hardened to prevent critical application security flaws. ( At a minimum, the application shall be tested against all flaws outlined in the Open Web Application Security Project (OWASP) Top Ten (http://www.owasp.org/index.php/OWASP_Top_Ten_Project). | ||||
| M | |||||
| T1.13 | Provide the State with validation of 3rd party security reviews performed on the application and system environment. The review may include a combination of vulnerability scanning, penetration testing, static analysis of the source code, and expert code review (please specify proposed methodology in the comments field). | ||||
| M | |||||
| T1.14 | Prior to the System being moved into production, the Vendor shall provide results of all security testing to the Department of Information Technology for review and acceptance. | ||||
| M | |||||
| T1.15 | Vendor shall provide documented procedure for migrating application modifications from the User Acceptance Test Environment to the Production Environment. | ||||
| M | |||||
| STANDARD TESTING | |||||
| T2.1 | The Vendor must test the software and the system using an industry standard and State approved testing methodology. | ||||
| M | |||||
| T2.2 | The Vendor must perform application stress testing and tuning. | ||||
| M | |||||
| T2.3 | The Vendor must provide documented procedure for how to sync Production with a specific testing environment. | ||||
| M | |||||
| T2.4 | The vendor must define and test disaster recovery procedures. | ||||
| M | |||||
| HOSTING-CLOUD REQUIREMENTS | |||||
| State Requirements | Vendor | ||||
| Req # | Requirement Description | Criticality | Vendor Response | Delivery Method | Comments |
| OPERATIONS | |||||
| H1.1 | Vendor shall provide an ANSI/TIA-942 Tier 3 Data Center or equivalent. A tier 3 data center requires 1) Multiple independent distribution paths serving the IT equipment, 2) All IT equipment must be dual-powered and fully compatible with the topology of a site's architecture and 3)Concurrently maintainable site infrastructure with expected availability of 99.982%. | ||||
| M | |||||
| H1.2 | Vendor shall maintain a secure hosting environment providing all necessary hardware, software, and Internet bandwidth to manage the application and support users with permission based logins. | M | |||
| H1.3 | The Data Center must be physically secured – restricted access to the site to personnel with controls such as biometric, badge, and others security solutions. Policies for granting access must be in place and followed. Access shall only be granted to those with a need to perform tasks in the Data Center. | ||||
| M | |||||
| H1.4 | Vendor shall install and update all server patches, updates, and other utilities within 60 days of release from the manufacturer. | ||||
| M | |||||
| H1.5 | Vendor shall monitor System, security, and application logs. | ||||
| M | |||||
| H1.6 | Vendor shall manage the sharing of data resources. | ||||
| M | |||||
| H1.7 | Vendor shall manage daily backups, off-site data storage, and restore operations. | ||||
| M | |||||
| H1.8 | The Vendor shall monitor physical hardware. | ||||
| M | |||||
| H1.9 | Remote access shall be customized to the State’s business application. In instances where the State requires access to the application or server resources not in the DMZ, the Vendor shall provide remote desktop connection to the server through secure protocols such as a Virtual Private Network (VPN). | ||||
| M | |||||
| DISASTER RECOVERY | |||||
| H2.1 | Vendor shall have documented disaster recovery plans that address the recovery of lost State data as well as their own. Systems shall be architected to meet the defined recovery needs. | ||||
| M | |||||
| H2.2 | The disaster recovery plan shall identify appropriate methods for procuring additional hardware in the event of a component failure. In most instances, systems shall offer a level of redundancy so the loss of a drive or power supply will not be sufficient to terminate services however, these failed components will have to be replaced. | ||||
| M | |||||
| H2.3 | Vendor shall adhere to a defined and documented back-up schedule and procedure. | ||||
| M | |||||
| H2.4 | Back-up copies of data are made for the purpose of facilitating a restore of the data in the event of data loss or System failure. | ||||
| M | |||||
| H2.5 | Scheduled backups of all servers must be completed regularly. The minimum acceptable frequency is differential backup daily, and complete backup weekly. | ||||
| M | |||||
| H2.6 | Tapes or other back-up media tapes must be securely transferred from the site to another secure location to avoid complete data loss with the loss of a facility. | ||||
| M | |||||
| H2.7 | Data recovery – In the event that recovery back to the last backup is not sufficient to recover State Data, the Vendor shall employ the use of database logs in addition to backup media in the restoration of the database(s) to afford a much closer to real-time recovery. To do this, logs must be moved off the volume containing the database with a frequency to match the business needs. | M | |||
| HOSTING SECURITY | |||||
| H3.1 | If State data is hosted on multiple servers, data exchanges between and among servers must be encrypted. | ||||
| M | |||||
| H3.2 | All components of the infrastructure shall be reviewed and tested to ensure they protect the State’s hardware, software, and its related data assets. Tests shall focus on the technical, administrative and physical security controls that have been designed into the System architecture in order to provide confidentiality, integrity and availability. | ||||
| M | |||||
| H3.3 | All servers and devices must have event logging enabled. Logs must be protected with access limited to only authorized administrators. Logs shall include System, Application, Web and Database logs. | ||||
| M | |||||
| H3.4 | Operating Systems (OS) and Databases (DB) shall be built and hardened in accordance with guidelines set forth by CIS, NIST or NSA. | ||||
| M | |||||
| SERVICE LEVEL AGREEMENT | |||||
| H4.1 | The Vendor’s System support and maintenance shall commence upon the Effective Date and extend through the end of the Contract term, and any extensions thereof. | ||||
| M | |||||
| H4.2 | The vendor shall maintain the hardware and Software in accordance with the specifications, terms, and requirements of the Contract, including providing, upgrades and fixes as required. | M | |||
| H4.3 | The vendor shall repair or replace the hardware or software, or any portion thereof, so that the System operates in accordance with the Specifications, terms, and requirements of the Contract. | ||||
| M | |||||
| H4.4 | All hardware and software components of the Vendor hosting infrastructure shall be fully supported by their respective manufacturers at all times. All critical patches for operating systems, databases, web services, etc., shall be applied within sixty (60) days of release by their respective manufacturers. | ||||
| M | |||||
| H4.5 | The State shall have unlimited access, via phone or Email, to the Vendor technical support staff between the hours of 8:30am to 5:00pm- Monday through Friday EST. | ||||
| M | |||||
| H4.6 | The Vendor shall conform to the specific deficiency class as described: o Class A Deficiency - Software - Critical, does not allow System to operate, no work around, demands immediate action; Written Documentation - missing significant portions of information or unintelligible to State; Non Software - Services were inadequate and require re-performance of the Service. |
o Class B Deficiency - Software - important, does not stop operation and/or there is a work around and user can perform tasks; Written Documentation - portions of information are missing but not enough to make the document unintelligible; Non Software - Services were deficient, require reworking, but do not require re-performance of the Service.
o Class C Deficiency - Software - minimal, cosmetic in nature, minimal effect on System, low priority and/or user can use System; Written Documentation - minimal changes required and of minor editing nature; Non Software - Services require only minor reworking and do not require re-performance of the Service.
| M | |
| H4.7 | As part of the maintenance agreement, ongoing support issues shall be responded to according to the following: |
a. Class A Deficiencies - The Vendor shall have available to the State on-call telephone assistance, with issue tracking available to the State, eight (8) hours per day and five (5) days a week with an email / telephone response within two (2) hours of request; or the Vendor shall provide support on-site or with remote diagnostic Services, within four (4) business hours of a request;
b. Class B & C Deficiencies –The State shall notify the Vendor of such Deficiencies during regular business hours and the Vendor shall respond back within four (4) hours of notification of planned corrective action; The Vendor shall repair or replace Software, and provide maintenance of the Software in accordance with the Specifications, Terms and Requirements of the Contract.
| M | |
| H4.8 | The hosting server for the State shall be available twenty-four (24) hours a day, 7 days a week except for during scheduled maintenance. |
| M | |||||
| H4.9 | A regularly scheduled maintenance window shall be identified (such as weekly, monthly, or quarterly) at which time all relevant server patches and application upgrades shall be applied. | ||||
| M | |||||
| H4.10 | If The Vendor is unable to meet the uptime requirement, The Vendor shall credit State’s account in an amount based upon the following formula: (Total Contract Item Price/365) x Number of Days Contract Item Not Provided. The State must request this credit in writing. | ||||
| M | |||||
| H4.11 | The Vendor shall use a change management policy for notification and tracking of change requests as well as critical outages. | M | |||
| H4.12 | A critical outage will be designated when a business function cannot be met by a nonperforming application and there is no work around to the problem. | ||||
| M | |||||
| H4.13 | The Vendor shall maintain a record of the activities related to repair or maintenance activities performed for the State and shall report quarterly on the following: Server up-time; All change requests implemented, including operating system patches; All critical outages reported including actual issue and resolution; Number of deficiencies reported by class with initial response time as well as time to close. | ||||
| M | |||||
| H4.14 | The Vendor will give two-business days prior notification to the State Project Manager of all changes/updates and provide the State with training due to the upgrades and changes. | ||||
| M | |||||
| SUPPORT & MAINTENANCE REQUIREMENTS | |||||
| State Requirements | Vendor | ||||
| Req # | Requirement Description | Criticality | Vendor Response | Delivery Method | Comments |
| SUPPORT & MAINTENANCE REQUIREMENTS | |||||
| S1.1 | The Vendor’s System support and maintenance shall commence upon the Effective Date and extend through the end of the Contract term, and any extensions thereof. | ||||
| M | |||||
| S1.2 | Maintain the hardware and Software in accordance with the Specifications, terms, and requirements of the Contract, including providing, upgrades and fixes as required. | ||||
| M | |||||
| S1.3 | Repair Software, or any portion thereof, so that the System operates in accordance with the Specifications, terms, and requirements of the Contract. | ||||
| M | |||||
| S1.4 | The State shall have unlimited access, via phone or Email, to the Vendor technical support staff between the hours of 8:00am to 5:00pm- Monday through Friday ET. | ||||
| M | |||||
| S1.5 | The Vendor response time for support shall conform to the specific deficiency class as described below or as agreed to by the parties: |
o Class A Deficiency - Software - Critical, does not allow System to operate, no work around, demands immediate action; Written Documentation - missing significant portions of information or unintelligible to State; Non Software - Services were inadequate and require re-performance of the Service.
o Class B Deficiency - Software - important, does not stop operation and/or there is a work around and user can perform tasks; Written Documentation - portions of information are missing but not enough to make the document unintelligible; Non Software - Services were deficient, require reworking, but do not require re-performance of the Service.
| o Class C Deficiency - Software - minimal, cosmetic in nature, minimal effect on System, low priority and/or user can use System; Written Documentation - minimal changes required and of minor editing nature; Non Software - Services require only minor reworking and do not require re-performance of the Service. | M | ||
| S1.6 | The Vendor shall make available to the State the latest program updates, general maintenance releases, selected functionality releases, patches, and Documentation that are generally offered to its customers, at no additional cost. | ||
| M | |||
| S1.7 | For all maintenance Services calls, The Vendor shall ensure the following information will be collected and maintained: 1) nature of the Deficiency; 2) current status of the Deficiency; 3) action plans, dates, and times; 4) expected and actual completion time; 5) Deficiency resolution information, 6) Resolved by, 7) Identifying number i.e. work order number, 8) Issue identified by; | P | |
| S1.8 | The Vendor must work with the State to identify and troubleshoot potentially large-scale System failures or Deficiencies by collecting the following information: 1) mean time between reported Deficiencies with the Software; 2) diagnosis of the root cause of the problem; and 3) identification of repeat calls or repeat Software problems. | ||
| P | |||
| S1.9 | As part of the Software maintenance agreement, ongoing software maintenance and support issues, shall be responded to according to the following or as agreed to by the parties: |
a. Class A Deficiencies - The Vendor shall have available to the State on-call telephone assistance, with issue tracking available to the State, eight (8) hours per day and five (5) days a week with an email / telephone response within two (2) hours of request; or the Vendor shall provide support on-site or with remote diagnostic Services, within four (4) business hours of a request;
b. Class B & C Deficiencies –The State shall notify the Vendor of such Deficiencies during regular business hours and the Vendor shall respond back within four (4) hours of notification of planned corrective action; The Vendor shall repair or replace Software, and provide maintenance of the Software in accordance with the Specifications, Terms and Requirements of the Contract; or as agreed between the parties.
| M | |||||
| S1.10 | The Vendor shall use a change management policy for notification and tracking of change requests as well as critical outages. | ||||
| M | |||||
| S1.11 | A critical outage will be designated when a business function cannot be met by a nonperforming application and there is no work around to the problem. | ||||
| M | |||||
| S1.12 | The Vendor shall maintain a record of the activities related to repair or maintenance activities performed for the State and shall report quarterly on the following: All change requests implemented; All critical outages reported including actual issue and resolution; Number of deficiencies reported by class with initial response time as well as time to close. | ||||
| M | |||||
| S1.13 | A regularly scheduled maintenance window shall be identified (such as weekly, monthly, or quarterly) at which time all relevant server patches and application upgrades shall be applied. | ||||
| M | |||||
| S1.14 | The Vendor shall give two-business days prior notification to the State Project Manager of all changes/updates and provide the State with training due to the upgrades and changes. | ||||
| M | |||||
| S1.15 | The Venor shall agree to use a secure FTP site provided by the State for uploading and downloading files if applicable. | M | |||
| S1.16 | The State shall provide the Vendor with a personal secure FTP site to be used by the State for uploading and downloading files if applicable. | ||||
| M | |||||
| S1.17 | The hosting server for the State shall be available twenty-four (24) hours a day, 7 days a week except for during scheduled maintenance. | M | |||
| S1.18 | The Contractor will guide the State with possible solutions to resolve issues to maintain a fully functioning, hosted System. | M | |||
| PROJECT MANAGEMENT | |||||
| State Requirements | Vendor | ||||
| Req # | Requirement Description | Criticality | Vendor Response | Delivery Method | Comments |
| PROJECT MANAGEMENT | |||||
| P1.1 | Vendor shall participate in an initial kick-off meeting to initiate the Project. | ||||
| M | |||||
| P1.2 | Vendor shall provide Project Staff as specified in the RFP. | ||||
| M | |||||
| P1.3 | Vendor shall submit a finalized Work Plan within ten (10) days after Contract award and approval by Governor and Council. The Work Plan shall include, without limitation, a detailed description of the Schedule, tasks, Deliverables, milestones/critical events, task dependencies, vendors and state resources required and payment Schedule. The plan shall be updated no less than every two weeks. | ||||
| M | |||||
| P1.4 | Vendor shall provide detailed bi-weekly status reports on the progress of the Project, which will include expenses incurred year to date. | ||||
| M | |||||
| P1.5 | All user, technical, and System Documentation as well as Project Schedules, plans, status reports, and correspondence must be maintained as project documentation in an online library accessible by the Department, | ||||
| M | |||||
| P1.6 | Vendor shall provide a full time Project Manager assigned to the project. | M | |||
| P1.7 | The Vendor Project Manager, and relevant key staff, shall every three (3) months, beginning in the first month of the Contract, travel to Concord, NH to meet with project representatives from DHHS and the NHID to review past quarter performance and upcoming quarter Work Plan. Virtual meetings may be permitted if approved by DHHS. | M | |||
| P1.8 | The Vendor's project manager is also expected to host other important meetings, assign contractor staff to those meetings as appropriate and provide an agenda for each meeting. | M | |||
| P1.9 | Meeting minutes will be documented and maintained electronically by the contractor and distributed within 24 hours after the meeting. Key decisions along with Closed, Active and Pending issues will be included in this document as well. | M | |||
| P1.10 | The Project Manager must participate in all other State, provider, and stakeholder meetings as requested by the State. | M | |||
| P1.11 | For the first three (3) months of the Contract, the Vendor shall provide written progress reports, to be submitted to DHHS every two (2) weeks. The reports should be keyed to the implementation portion of the Work Plan and include, at a minimum, an assessment of progress made, difficulties encountered, recommendations for addressing the problems, and changes needed to the Work Plan. | M |
Integration Requirements have not been added.
Noticed this was not redlined. Please ask the IT Lead to review and remove non-applicable or duplicative requirements and add IT integration requirements as applicable.
Appendix G Attachment 1
Deliverable Activity Milestone
| DELIVERABLES / ACTIVITY / MILESTONES PRICING WORKSHEET | |||||
| DELIVERABLE, ACTIVITY, OR MILESTONE | DELIVERABLE TYPE | PROJECTED DELIVERY DATE | PRICE | ||
| PLANNING AND PROJECT MANAGEMENT | |||||
| 1 | Conduct Project Kickoff Meeting | Non-Software | |||
| 2 | Work Plan | Written | |||
| 3 | Attestation of background check | Written | |||
| 4 | Project Status Reports | Written | |||
| 5 | Infrastructure Plan, including Desktop and Network Configuration Requirements | Written | |||
| 6 | Information Security Plan (ISP) | Written | |||
| 7 | Communications and Change Management Plan | Written | |||
| 8 | Software Configuration Plan | Written | |||
| 9 | Systems Interface Plan and Design/Capability | Written | |||
| 10 | Testing Plan | Written | |||
| 11 | Data Conversion Plan and Design | Written | |||
| 12 | Deployment Plan | Written | |||
| 13 | Comprehensive Training Plan and Curriculum | Written | |||
| 14 | End User Support Plan | Written | |||
| 15 | Business Continuity Plan | Written | |||
| 16 | Documentation of Operational Procedures | Written | |||
| 17 | Bring Your Own Device (BYOD) Security Plan (if applicable) | Written | |||
| 18 | Data Protection Impact Assessment (DPIA) | Written | Mandatory security document. Consult DHHS DISO if you wish to remove as a requirement. | ||
| 19 | Systems Security Plan (SSP) | ||||
| (the SSP shall include security requirements of the system and describe the controls in place, or planned, for meeting those requirements. The SSP shall also delineates responsibilities and expected behavior of all individuals who access the system) | Written | Mandatory security document. Consult DHHS DISO if you wish to remove as a requirement. | |||
| 20 | Disaster Recovery Plan (DRP) | Written | Mandatory security document. Consult DHHS DISO if you wish to remove as a requirement. | ||
| INSTALLATION | |||||
| 21 | Provide Software Licenses if needed | Written | |||
| 22 | Provide Fully Tested Data Conversion Software | Software | |||
| 23 | Provide Software Installed, Configured, and Operational to Satisfy State Requirements | Software | |||
| TESTING |
tc={883DFB2B-C5C9-4A55-ADC5-E564B5581DAF}: [Threaded comment]
Your version of Excel allows you to read this threaded comment; however, any edits to it will get removed if the file is opened in a newer version of Excel. Learn more: https://go.microsoft.com/fwlink/?linkid=870924
Comment:
Integration requirements in the SOW testing have not been added to the deliverable table.
| 24 | Conduct Integration Testing | Non-Software |
| 25 | Conduct User Acceptance Testing | Non-Software |
| 26 | Perform Production Tests | Non-Software |
| 27 | Test In-Bound and Out-Bound Interfaces | Software |
| 28 | Conduct System Performance (Load/Stress) Testing | Non-Software |
| 29 | Certification of 3rd Party Pen Testing and Application Vulnerability Scanning. | Non-Software |
| 30 | Security Risk Assessment (SRA) Report |
o if PII is part of the Contract, the SRA shall include a Privacy Impact Assessment (PIA) o if BYOD (if personal devices have been approved by DHHS Information Security to use, then the SRA shall include a BYOD section)
| Written | Mandatory security document. Consult DHHS DISO if you wish to remove as a requirement. | ||
| 31 | Security Authorization Package | Written | |
| SYSTEM DEPLOYMENT | |||
| 32 | Converted Data Loaded into Production Environment | Software | |
| 33 | Provide Tools for Backup and Recovery of all Applications and Data | Software | |
| 34 | Conduct Training | Non-Software | |
| 35 | Cutover to New Software | Non-Software | |
| 36 | Provide Documentation | Written | |
| 37 | Execute System Security Plan | Non-Software | |
| OPERATIONS | |||
| 38 | Ongoing Hosting Support | Non-Software | |
| 39 | Ongoing Support & Maintenance | Software | |
| 40 | Conduct Project Exit Meeting | Non-Software | |
| 41 | Contract End of Life Transition | Non-Software | |
| TOTAL |
Integration requirements in the SOW testing have not been added to the deliverable table.
Attachment 1
File details come from the government source that posted it. Updated .