RFP IT & InfoSec Questionnaire (6).xlsx
XLSX spreadsheet 30 KB Posted
- Attached to
- Continuous Patient Monitoring System
- Solicitation number
- 2139514
- Issued by
- Erie County, New York
About this file
This is an RFP IT & InfoSec Questionnaire related to Roswell Park Comprehensive Cancer Center's procurement of a comprehensive telemetry and patient monitoring solution in New York. The solicitation seeks an integrated or modular platform combining bedside physiological monitoring, telemetry monitoring, centralized surveillance capabilities, and mobile alarm notification systems that integrate with the facility's existing EHR (Altera Sunrise Clinical Manager) and clinical communication platforms. The project encompasses 140 monitored beds across nine inpatient nursing units, with bedside monitors capable of continuous monitoring including Masimo SET SpO2, respiration rate, noninvasive blood pressure, temperature, and 5-lead ECG, along with telemetry monitoring capabilities for up to 32 patients. The solution must support centralized monitoring stations for each nursing unit with full-disclosure waveform review, alarm management, and mobile alarm notification functionality for clinical staff.
The questionnaire document serves as an IT and information security assessment tool for vendor evaluation, requiring respondents to provide detailed information regarding their proposed solution's technical specifications, security posture, and compliance with healthcare IT standards. Specific details regarding response deadlines, site visits, bidder conferences, pricing terms, set-asides, contract term, and renewal options are not detailed within the questionnaire file itself, as this document functions as a technical and security evaluation instrument rather than containing comprehensive RFP administrative details.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Appendix B - Roswell Park Terms and Conditions (1).docx | DOCX document | |
| Appendix A-1 EEO Requirements.docx | DOCX document | |
| RFP 26-165 EEO Staffing Plan.docx | DOCX document | |
| Roswell Park_Business Asscociate Agreement.docx | DOCX document | |
| RFP 26-165 Non-Collusion Affidavit.docx | DOCX document | |
| RFP 26-165 Price Sheet.xlsx | XLSX spreadsheet | |
| Appendix A Roswell Park Required Clauses.docx | DOCX document | |
| RFP #26-165 Continuous Bedside Patient Monitoring.pdf | ||
| RFP 26-165 Bid Proposal Form (1).doc | DOC document | |
| RFP 26-165 Disclosure Form.docx | DOCX document | |
| Appendix C (Information & System Security).docx | DOCX document | |
| RFP 26-165 EEO Policy Statement.docx | DOCX document |
Show all 12
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Sheet1 Please provide an answer to each question in the "Answer" cell.
Question Answer
| Infrastructure |
| If hosted locally, describe any power, storage, hardware, and operating system requirements for this system. |
| Standard VM Features: Compatible with VMware DRS (Distributed Resource Scheduling) and VMware Snapshots, meaning the application can tolerate VM migrations and snapshot-based backups without issue. This includes supporting Veeam backup operations and snapshot-based backups for recovery. |
| Enterprise Backup Integration: Supports Veeam for regular backups and restores of on premises systems. Application data and servers should be compatible with Roswell’s standard backup processes to ensure reliable recovery from failures. |
| Disaster Recovery Compatibility: Able to integrate with Roswell’s Zerto continuous replication for disaster recovery to a secondary data center. This is strongly desired for systems that require minimal downtime and low Recovery Point Objectives in a disaster. Alternatively, describe your systems DR capabilites. |
| Power over Ethernet (PoE) if required for device operation (e.g. for certain medical devices). |
| Operating System Compatibility: All server components support current, vendor-supported OS versions (e.g. Windows Server 2022/2025 or latest Linux distributions from RedHat or Ubuntu). The system must not rely on end-of-life or unsupported operating systems. |
| Virtualization Support: Solution can run on virtual machines in Roswell’s VMware vSphere environment; dedicated physical hardware is not required unless unavoidable. Roswell strongly prefers solutions that are VM-capable over those needing proprietary on-site appliances. |
| Resource Requirements: Does not exceed typical virtual server capacity. For example, avoid requiring more than ~16 vCPUs or 64 GB RAM per VM, or special CPU clock speeds beyond ~3.0 GHz, as these are outside Roswell’s standard VM specifications. Any need for unusually high compute/storage must be justified. |
| Scalability & Performance: The solution can scale to meet growing usage (more users or data) by adding resources or nodes, without requiring a complete re-architecture. Any hardware-based licensing restrictions (e.g. USB dongles for licensing) or Raw Device Mapping (RDM) storage requirements should be avoided. |
| Vendor Documentation: Vendor must provide comprehensive system architecture documentation (including network topology diagrams, port requirements, etc.) for the proposed solution. This allows Roswell to evaluate how the system will fit into our environment and plan for proper integration. |
| Additional Dependencies: The vendor must disclose any additional hardware, software, or third-party tools required or recommended for the solution that are not part of the base purchase. Hidden or unexpected dependencies (e.g. required middleware or specific hardware) are to be identified early. |
| Vendor Hardware Reimaging: If a vendor appliance or device is provided, it should support being re-imaged with Roswell’s standard Windows 11 OS image whenever possible (to load our configuration). This allows the hardware to be managed as a normal Roswell endpoint. |
| Standard Roswell Endpoint Usage: If the solution includes end-user devices or workstations, the preferred approach is to use Roswell Park–procured standard hardware (e.g. Dell PCs) and deploy the vendor’s software on our standard Windows 11 image. This ensures full compatibility with our management and security tools. |
| High Availability (HA): If the system is high or medium critical (e.g. patient care impact), it must support a high-availability deployment. Preferably, the application has built-in clustering/HA features; otherwise, it should support external HA configurations (e.g. multiple servers behind an F5 load balancer, use of SQL Always On clustering for databases). This ensures seamless failover between data centers or redundant servers. |
| Domain Join & Management Agents: Any Windows-based server or device must support Active Directory domain join and installation of Roswell’s standard endpoint agents – including CrowdStrike Falcon (EDR), Netskope, BeyondTrust privilege management, Rapid7 vulnerability scanner, SCCM/Intune for software management, BitLocker encryption, LAPS (Local Admin Password Solution), and standard Group Policy settings. This “Roswellization” is required for security and maintenance unless an explicit InfoSec exemption is granted. |
| Network Isolation: In rare cases where a vendor’s device cannot be re-imaged or have Roswell agents installed, it will need to be isolated on the network via Cisco ISE (network access control) with minimal access. Such cases (e.g. domain-join only for authentication without our agents) are considered only as a last resort and require formal security exception approval (not desirable due to added complexity and risk). If you application does not support the above reuirement, are there any imcompatibilites with segmentation via Cisco ISE? |
| CIS Baselines: Any Windows-based server or device must support Active Directory domain join and be compatible with all standard CIS Security Baselines. Deviation from these baselines should be minimal and would require approval for any exceptions. |
| Virtual Desktop (VDI) Compatibility: The application must function in a non-persistent VDI environment (VMware Horizon View) if it will be accessed via our virtual desktop infrastructure. This includes support for being delivered as a published application in VMware App Volumes or Citrix Virtual Apps environments. VDI support is a standard requirement for enterprise apps at Roswell. |
| Thin Client Support: The solution’s client components and any attached peripheral devices must work with Roswell’s IGEL Linux-based thin clients (which are used on ~1400 VDI endpoints). This means no dependency on installing drivers or software on the local thin client (since IGEL OS is read-only). Instead, devices should interface via standard protocols that our VDI environment supports. |
| Peripheral/USB Device Compatibility: If the medical technology includes USB or other peripheral devices, it must support VMware Horizon USB redirection (including isochronous USB transfer modes for continuous data streams) and work over the Blast Extreme display protocol. The device’s USB classification should be identified (e.g. HID, serial, etc.) – note that devices recognized as USB storage class will be blocked by security policies and require a formal exception. |
| Session Resilience: The system (and any connected devices) must tolerate a roaming user environment as clinicians may use it via VDI across multiple stations. It should handle VDI session disconnects, network interruptions, and device hot-plug/replug events without needing a system reboot or becoming inoperable. The device/application should not permanently bind to a single workstation or user session. |
| Local Storage Requirements: The solution should not require storing data on local endpoints (e.g. writing cache/files to a PC’s hard drive) especially if those endpoints are non-persistent VDI desktops or read-only IGEL thin clients. Any data generated should be stored in central systems or servers so that users can log in from any station without loss of information. |
| Client Platform Support: The solution client interface should ideally be web-based (accessible via modern browsers. Edge is the Roswell Standard, Chrome/Firefox second choice). If a desktop application is required, it must be compatible with Windows 11 (Roswell’s standard desktop OS) and not require unsupported OS versions. macOS support for client software is desirable if Mac endpoints are in scope, and any mobile app components should support current iOS/Android versions managed through Microsoft Intune (Optional). |
| Standard User Operation: End-user software must run under standard (non-admin) user accounts on Windows PCs. The application cannot require local administrator privileges for day-to-day use, since Roswell’s policy is not to grant admin rights to end users on workstations. |
| Wireless networking, the device must support 5 GHz Wi-Fi (802.11ac/ax) for compatibility with Roswell’s wireless infrastructure. Must support DFS (UNII-1, UNII-2, UNII-2-Ext, UNII-3) |
| Network Authentication (802.1X): All network-enabled devices must support 802.1x EAP-TLS authentication for network access. The solution should allow certificate-based authentication that can be centrally managed by Roswell (for example, the device or system should support installing Roswell-issued certs for network access control). |
| Virtual LAN and Segmentation: The system should operate under Roswell’s network segmentation policies. It must work when placed in restricted VLANs with only necessary ports opened and be compatible with micro-segmentation (Illumio) controls on server communications. (In practice, this means the vendor must document all network ports/protocols so appropriate firewall rules/micro-segmentation can be applied.) TCP is preferred over UDP. |
| Device supports DHCP. |
| Device functionality is not dependent on Multicast traffic. |
| Driver and Peripheral Software: If the solution includes client-side drivers or peripheral software, they should use standard drivers that support user-mode installation and carry WHQL certification for Windows compatibility. This ensures they can be installed on Roswell’s managed endpoints without compromising stability or requiring kernel-level changes. |
| No Proprietary VPN Requirement: The application should not require a dedicated VPN or custom point-to-point connectivity for routine use. All remote access should occur over standard secure channels (SSL/TLS over the internet or existing site-to-site VPNs) rather than vendor-specific VPN appliances, unless unavoidable. |
| Does your application require expressroute, direct connect, or dark fiber connection? |
| Network Interface Standards: If the system uses wired network connections, it must support at least 1 Gbps Ethernet connectivity (standard in the hospital) |
| Network Authentication (802.1X): All network-enabled devices must support 802.1x EAP-TLS authentication for network access. The solution should allow certificate-based authentication that can be centrally managed by Roswell (for example, the device or system should support installing Roswell-issued certs for network access control). |
| Describe the method for managing Enterprise PKI certificates for any hardware pheripherals that connect to the network. |
| Bandwidth and Latency Tolerance: The vendor should specify any unusual network bandwidth requirements or latency sensitivities. Solutions that operate reliably over typical hospital network conditions (which may include moderate latency and shared bandwidth) are Preferred, especially for real-time data or imaging. (e.g., no excessive bandwidth demand that could strain hospital networks). |
| Provide all system architecture documentation (including full network diagrams for the complete solution) as an attachment to this submission. |
| Does your application support High Availability across multiple data centers? If so, please include architectural diagrams and supporting documentation.Describe any additional licensing costs for HA or DR. |
| Describe the licensing model - (Ex: annual, per module, named users, concurrent, per CPU, etc.). |
| Describe any other associated hardware/software/3rd party tools that are required or recommended that may not be included in this purchase. |
| Access Control & SSO: The solution must provide robust user management and access controls, including role-based access and account lockout mechanisms. Integration with Roswell’s Single Sign-On is highly desired – e.g., support for SAML 2.0 / Azure AD for authentication and user provisioning – to leverage our existing identity management and MFA. |
| Application |
| Modern Browser Compatibility: Web-based components should support current, mainstream web browsers (Edge preferred, Chrome/Firefox second choice) without reliance on legacy technologies (no Internet Explorer-only functionality, ActiveX controls, or deprecated plugins). Any necessary browser plugins or client runtimes (Java, .NET, etc.) must be explicitly identified and kept updated to supported versions. |
| Is there a native mobile application? If so, what platforms are supported? |
| Are OS admin rights required to use any client-side part the application? (Our standard is to not have users as local Admins on workstations.) |
| Can the application be customized or enhanced by the customer through scripting? If so, which scripting languages can be used? (e.g., python, java, javascript, proprietary language, etc.) |
| Does this product require oracle branded Java to run? |
| Minimal Legacy Dependencies: The solution should not depend on obsolete software or OS features. For example, avoid requirements for outdated Java versions, Flash, or Windows features that are end-of-life. If older components (e.g., Internet Explorer compatibility modes or ActiveX controls) are needed for certain functions, this must be disclosed, and such designs are strongly discouraged in favor of modern alternatives. |
| Does this product require an oracle branded database to run? |
| Integration & Interoperability: The system should provide APIs or integration capabilities to interface with other systems (e.g., RESTful APIs, HL7/FHIR for health data exchange, or other standard interfaces). Availability of a software development kit (SDK) or configurable interfaces (e.g., support for HL7) is Preferred, to facilitate integration with Roswell’s electronic health records and data warehouse. |
| Database & Data Access: If the application uses a relational database, it should support modern database engines and versions (e.g., Microsoft SQL Server 2019+ or Oracle 19c+). Roswell prefers solutions that can integrate with our enterprise database clusters (e.g., compatibility with Microsoft SQL Always On failover clusters). Direct read access to the database for reporting (with a provided data dictionary) is Preferred, and any user-created tables or custom reporting capabilities should be supported. |
| If there is an on premise database need, can it run on our enterprise MS SQL cluster vs. needing a dedicated database host? |
| Security Patching, Driver Updates & Dependencies: The solution must support regular OS and application security patching as well as Driver updates. It should run on fully patched operating systems and allow installation of updates (e.g., monthly Windows Updates and VMware Tools upgrades) without breaking support. If the application requires third-party components (e.g., specific Java versions, browser plugins), it must remain compatible with their security updates as well. No hard requirement to skip or delay critical patches is acceptable. |
| Describe application logging capabilities. |
| Configurability vs. Vendor Reliance: The solution should allow Roswell’s IT administrators to manage configuration and user administration without dependence on the vendor for routine changes. Any features or configurations that can only be modified by the vendor (not by local admin users) should be clearly identified (as this may affect autonomy and response time for changes) – such limitations are not desirable. |
| Describe application administration process used within the system. |
| Will you need remote access to any on premise systems? If so, confirm that you can use Securelink for such access. |
| Reporting & Analytics: It is preferred that the application includes built-in dashboard and reporting tools for operational and clinical metrics. This should include application performance analytics to help monitor for a consistent user experience; the vendor should clarify what reporting capabilities exist and if custom report generation or data export is supported (to enable data-driven decision making). |
| Confirm and describe the cost and availability of separate development, testing or training environments. Discuss the process to migrate changes from environment to environment; and include information environment refresh requests, etc. |
| Training/Support |
| Training & Documentation: Availability of training programs or certification for Roswell’s IT support staff and end-users is highly desirable. The vendor should provide thorough user manuals and technical documentation. While not strictly required, comprehensive training options (on-site or online) are Preferred to facilitate smooth adoption. |
| Vendor Support Model: The vendor must provide a clear customer support and service model for the product. This includes support hours (24×7 support is expected for mission-critical clinical systems), methods for contacting support (e.g., phone, email, portal), incident escalation processes, and expected response/resolution times. A robust support and escalation plan is Mandatory for clinical technologies. |
| Feature Request Process: The vendor’s process for receiving and incorporating product enhancement requests or new features from customers should be described. While not a deal-breaker, a transparent and responsive enhancement request process (e.g., regular updates or user group input) is considered a Preferred attribute, indicating the solution will evolve with user needs. |
| Implementation |
| Implementation Assistance: The vendor should outline the expected implementation process and what will be required from Roswell Park (e.g., staff participation, time commitments, onsite requirements). A well-defined implementation methodology with typical timelines is Preferred. Additionally, it should be clear whether the vendor provides implementation services or certified third-party integrators to assist; having vendor involvement or vetted partners is preferable for complex systems. |
| Briefly describe the implementation process/methodology and typical timelines. |
| Briefly describe the implementation training and support you provide or require. |
| Can implementation be handled by the vendor or 3rd party partners? If 3rd party, please list some approved providers. |
| Post-Go-Live Maintenance: The vendor must describe the ongoing maintenance and support responsibilities after go-live. Roswell favors solutions that do not require overly burdensome effort by internal IT staff for regular maintenance. Any tasks expected of Roswell (e.g., server updates, user management, backups, etc.) should be clearly identified. |
| Business Continuity |
| Data Retention & Archiving: The system must support data retention policies, including configurable data archival and purging mechanisms in line with Roswell’s record-keeping requirements. This is crucial for managing long-term healthcare data (e.g., patient records) and compliance. |
| Cloud Service Continuity: For cloud/SaaS solutions, the vendor must have a documented Business Continuity Plan (BCP) and disaster recovery strategy for their hosted environment. This includes regular testing of failover procedures, data geo-redundancy, and communication plans for outages. The vendor should also guarantee that in a worst-case scenario (e.g. contract termination), Roswell’s data can be exported or returned in a usable format for transition. |
| Describe the process for data extraction upon termination of contract. |
| Security for Roswell / On-Prem Hosted |
| Endpoint Security (On-Premises): The system must be compatible with Roswell Park’s security software on any on-premises servers or clients. This includes CrowdStrike Falcon Protect for endpoint threat detection (no components of the solution should interfere with or require disabling our EDR agent). Likewise, the software must not conflict with Microsoft BitLocker drive encryption (full-disk data-at-rest encryption is standard on Roswell systems). |
| Describe the operating environment of any bedside or on‑prem components, including whether they run a general‑purpose OS, embedded OS, or proprietary firmware, and any security limitations inherent to that model. |
| Describe how security updates, patches, or firmware updates are managed for bedside devices and on‑prem components, including update responsibility and any clinical or operational constraints. |
| Describe how patient data is protected at rest and in transit across bedside devices, on‑prem systems, and integrations, noting any components where encryption is not supported and why. |
| Describe authentication and access controls for: |
Clinical users Administrative or maintenance access Vendor remote support (if applicable)
| Describe audit logging and monitoring capabilities, including whether logs capture user activity and system changes and whether logs can be exported to a centralized logging or SIEM solution. |
| Describe how changes to patient data or system configuration are tracked, including whether audit history is retained or overwritten. |
| Describe how vulnerabilities affecting bedside devices or on‑prem components are identified, assessed, and remediated, including how customers are notified of security issues. |
| Security for Vendor / Cloud Hosted/Integrations |
| In using this platform, is protected health information (PHI) ever exchanged between Roswell Park and you, your affiliates, or your platforms? If information is deidentified, describe how information is deidentified. |
| Do you perform annual risk assessments? |
| Do you have a SOC2 type II, HITRUST, or equivalent independent certification of your security controls within the past 12 months? If yes, please provide. |
| Will Roswell Park data be stored exclusively in the US? |
| Will Roswell Park data be encrypted at rest with FIPS 140-3 compliant methods for servers, workstations, mobile devices, and removable media? |
| Are all transmissions of Roswell Park data encrypted using FIPS 140-3 compliant methods? |
| Does your organization have a CISO or someone designated and qualified with protecting the data and infrastructure as their primary duty? |
| Is your company compliant with all applicable laws and regulations governing security, accuracy, and privacy of data (e.g., 21 CFR Part 11, HIPAA, PCI, NY SHIELD, GDPR)? Please list applicable laws and regulations you are subject to. |
| Do you perform regular (at least annual) penetration testing of your applications and environment? Frequency? |
| Do you have a vulnerability management program? How frequently is your internal network scanned? How frequently is your external network scanned? How often do you deploy patches? |
| Do you have a third-party risk management program? |
| Do you employ endpoint protection software for AV, IPS/IDS, and firewall on all your workstations and servers? |
| Do you perform background checks on employees? |
| Do you employ multifactor authentication for external access to sensitive resources? |
| Can IP restrictions be placed on the application to limit access to the Roswell Park network? |
| Do you have a security awareness training program? |
| Do you have an incident response policy/program? |
| Do you have a 24x7 Security Operations Center monitoring your environment? |
| Does your system support Roswell Park’s SAML/Entra Authentication? |
| Interface Integration |
| Specify out-of-the-box support for interoperability standards (e.g., HL7 v2.x, X12, DICOM, FHIR, REST APIs), with mapping guides and sample messages. |
| Detail all supported HL7 v2 message types (ADT, ORM, ORU, SIU, DFT, MDM, etc.), indicate whether each type is both produced and consumed, and provide samples of each. |
| Explain which system events trigger outbound messages or API calls, whether triggers are configurable at module or field level, and include workflow diagrams showing integration touchpoints. |
| Identify typical partner applications (EMR/EHR, LIS, RIS/PACS, HIE) and any master data feed requirements (e.g., providers) for integration. |
| Describe whether message structures, segments, or payloads can be customized to meet customer needs, and provide details about self-service mapping tools or vendor-managed customization processes. |
| If batch workflows are used, explain file formats (CSV, XML, etc.), transfer mechanisms (SFTP, API), and scheduling for incoming and outgoing data. |
| Indicate how integration errors are surfaced and handled – include logging, monitoring dashboards, retry logic, and customer-facing tools for tracking integration status. |
| Outline available non-production environments (DEV, TEST, UAT, STAGING, etc.) for integration development and testing, including data refresh procedures. |
| Provide a recommended testing methodology for integration validation (auditing, tracing, workflow inspection) and clarify expected vendor involvement during testing, certification, and go-live validation. |
| Specify the system’s capacity for incoming throughput (message volume, concurrent API calls) and describe any rate limits or throttling rules. |
| Specify outgoing throughput capabilities (message volume, API push frequency) and delivery guarantees such as FIFO ordering, retries, or message persistence. |
| Identify any middleware or non-standard components needed to support integrations, with architecture diagrams showing all components. |
| Define change management and versioning policies for message formats, API versions, or workflows – including notification processes, backward compatibility expectations, and support lifecycles. |
Firm:
Contact:
Address:
Phone:
Mobile:
Email:
File details come from the government source that posted it. Updated .