Response Template - RFI for an Incident Prevention Monitoring System IPMS Procurement.xlsx
XLSX spreadsheet 17 KB Posted
- Attached to
- 27EHSPMDDSIPMSRFI: RFI for an Incident Prevention Monitoring System (IPMS) Procurement Preview
- Solicitation number
- BD-27-1039-EHS01-ASHWA-133015
- Issued by
- Suffolk County, Massachusetts
About this file
Summary
This is a response template for a Request for Information (RFI) issued by the Executive Office of Health and Human Services on behalf of the Commonwealth of Massachusetts Department of Developmental Services (DDS) regarding the procurement of an Artificial Intelligence-driven Incident Prevention Monitoring System (IPMS) for deployment at the DDS Hogan Regional Center. The RFI seeks vendor input on AI-driven safety and incident prevention monitoring solutions, with a specific focus on a 60-camera existing infrastructure. Vendors are required to provide detailed written responses addressing eight primary categories: solution capabilities, deployment model, data privacy and security, fairness and responsible AI considerations, cost structure, training and support, accessibility and usability, and additional technical questions. The template requests company information, contact details, and comprehensive documentation of product capabilities, including core functionality for detecting violent or high-risk incidents without identity tracking, configurable alert routing, scalability, dashboard functionality, and extensive reporting and search capabilities.
The RFI emphasizes strict data privacy and security requirements, including compliance with HIPAA, state privacy law, and federal security standards, with particular attention to privacy-preserving video analytics that prohibit facial recognition or biometric identification unless explicitly authorized. Vendors must address security certifications, encryption protocols, role-based access controls, and comprehensive responsible AI governance including bias monitoring, performance validation, and human-in-the-loop review processes. Cost structure responses should detail licensing models, one-time versus recurring costs, and estimated cost ranges for the described scope. Additional optional attachments requested include conceptual solution architecture, product capability matrices, camera compatibility summaries, detection performance evidence, a five-year total cost of ownership estimate, and implementation plans. The RFI specifically requests information regarding prior deployment in human services settings, effectiveness with individuals with intellectual disabilities and autism spectrum disorder, and the ability to confine solutions to customer-owned cloud environments with exclusive data ownership retention by the Commonwealth.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Questions and Answers - RFI for an Incident Prevention Monitoring System (IPMS).docx | DOCX document | |
| RFI for an Incident Prevention Monitoring System IPMS Procurement.docx | DOCX document |
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
| Response Template - RFI for an Incident Prevention Monitoring System (IPMS) Procurement |
| Document Number: 27EHSPMDDSIPMSRFI |
| Company Information |
| Company Name (list parent company as well): |
| Company Address: |
| Company Website: |
| Contact Name and Information (e-mail address required): |
| Respondents are asked to provide detailed written information to the following | Response | |
| 1 | Solution Capabilities | |
| 1.1 | Core functionality of the AI system | |
| 1.2 | Ability to detect violent or high‑risk incidents without identity tracking | |
| 1.3 | Configurable alert routing to designated staff, security personnel, or operational stakeholders. Alerting methods and response times | |
| 1.4 | Scalability and environmental adaptability | |
| 1.5 | Prioritization of alerts based on event type, severity, location, or operational criteria. | |
| 1.6 | Alert review functionality providing sufficient event context for decision-making. | |
| 1.7 | Ability to document alert review, disposition, and follow-up actions. | |
| 1.8 | Support for history, search, and retrieval of incidents, alerts and trends. | |
| 1.9 | Dashboard or console views for active alerts, incidents, and monitored activity. | |
| 1.10 | Event summaries, status indicators, and operational reporting. | |
| 1.11 | Search and filtering capabilities by date, location, event type, status, or other configurable criteria. | |
| 1.12 | Reporting that supports operational oversight, safety management, and quality improvement initiatives. | |
| 2 | Deployment Model | |
| 2.1 | On‑premise or cloud hardware/software requirements | |
| 2.2 | Estimated implementation timeline and support needs | |
| 2.3 | Minimized transfer of video data outside Commonwealth-controlled environments. | |
| 2.4 | Clear disclosure of any SaaS, cloud, remote access, third-party, or external processing dependencies. | |
| 2.5 | Ability to support future expansion without requiring replacement of core infrastructure. | |
| 2.6 | What standard support exists for camera and video-stream integration methods. What would be the integration approach for existing camera infrastructure of 60 cameras. | |
| 2.7 | Integration with authorized notification, reporting, operational, and security systems where applicable. | |
| 2.8 | API or interface capabilities supporting authorized data exchange. | |
| 2.9 | Compliance with applicable Commonwealth cloud, security, privacy, accessibility, and Responsible AI requirements. | |
| 3 | Data Privacy & Security | |
| 3.1 | Compliance with HIPAA, state privacy law, and federal security standards | |
| 3.2 | Whether the solution stores, transmits, or retains any video or alert data. Are there processing and storage controls that keep sensitive data within authorized environments. | |
| 3.3 | Privacy-preserving video analytics without facial recognition, identity tracking, or biometric identification unless expressly authorized by DDS and the Commonwealth | |
| 3.4 | HIPAA compliance approach, including administrative, technical, and physical safeguards. | |
| 3.5 | Compliance with CMS regulations, federal and Commonwealth privacy laws, and 42 CFR Part 2 where applicable. | |
| 3.6 | Security certifications held (e.g., SOC 2 Type II, FedRAMP, HITRUST). | |
| 3.7 | Role-based access controls, audit logging, and information barrier capabilities. Detail controls preventing unauthorized retention, memorization, or use of sensitive video-derived information. | |
| 3.8 | Data encryption (at rest and in transit), vulnerability management, and penetration testing practices. | |
| 3.9 | Least-privilege access controls across applications, APIs, infrastructure, and administrative functions. | |
| 3.10 | Approach to data ownership, portability, and exit strategy should the Commonwealth transition to a different system. | |
| 4 | Fairness, Responsible AI and Detection Quality | |
| 4.1 | Monitoring of model performance and detection quality. | |
| 4.2 | Processes to identify, assess, and mitigate bias or disparate error rates. | |
| 4.3 | Human-in-the-loop review for sensitive detections and operational decision-making. | |
| 4.4 | Explainability information such as confidence scores, event context, or other review-supporting information. | |
| 4.5 | Controls designed to reduce false positives, false negatives, and unreliable alerts. | |
| 4.6 | Support for initial calibration, testing, and validation activities prior to operational deployment. | |
| 4.7 | Ability to adjust confidence thresholds and detection settings to align with operational requirements. | |
| 4.8 | Human oversight capabilities that ensure authorized personnel remain responsible for operational decisions and incident response actions. | |
| 4.9 | Version management and tracking of deployed AI models. | |
| 4.10 | Validation, testing, and approval processes for model updates. | |
| 4.11 | Ability to disable, suspend, or roll back AI capabilities when required by DDS or Commonwealth policy. | |
| 4.12 | Monitoring for model drift, performance degradation, governance exceptions, and operational impacts. | |
| 4.13 | Support for ongoing Responsible AI governance activities. | |
| 5 | Cost Structure | |
| 5.1 | Licensing model (per camera, per facility, etc.) | |
| 5.2 | One‑time vs. recurring costs | |
| 5.3 | Estimated cost range for the scope described | |
| 6 | Training & Support | |
| 6.1 | Staff training approach | |
| 6.2 | User guides, administrator guides, operational procedures, and training materials. | |
| 6.3 | Support for system configuration, calibration, testing, and go-live readiness activities. | |
| 6.4 | Ongoing technical support and consultation. | |
| 6.5 | Advisory support to assist DDS in maximizing operational value and adoption of the solution. | |
| 6.6 | Post‑deployment support and maintenance options | |
| 7 | Accessibility and Usability | |
| 7.1 | Accessible user interfaces supporting Commonwealth accessibility expectations. | |
| 7.2 | Clear alert presentation and intuitive operational workflows. | |
| 7.3 | Usability features that reduce unnecessary complexity and training burden. | |
| 7.4 | Documentation and training materials available in accessible formats. | |
| 7.5 | Vendor disclosure of accessibility conformance and known limitations. | |
| 8 | Additional Questions | |
| 8.1 | If your organization offers a solution that provides this capability, how is the model trained? What is the origin of the training data? | |
| 8.2 | Would your model be able to effectively augment its training to include historical video footage from a client facility? If so, how much historical footage would be required? | |
| 8.3 | Can your model be deployed in a test environment to demonstrate effectiveness as a proof of concept, prior to full go-live implementation? | |
| 8.4 | Has your model been used in human services settings in other states? If so, please describe any such uses and settings in as much detail as possible, including whether or not any such use has involved subjects with intellectual disabilities and/or co-occurring autism spectrum disorder. | |
| 8.5 | Has the tool been evaluated for the risk of bias? If so, describe that methodology and the results. | |
| 8.6 | How can you ensure that your tool would appropriately factor in the behavior of subjects with intellectual disabilities and/or co-occurring autism spectrum disorder, so as to minimize the risk of bias and false positive alerts? | |
| 8.7 | Describe the typical architectural deployment of your solution. Where would this tool and associated data reside? Could the tool be confined to a customer-owned cloud environment? | |
| 8.8 | Would ownership of the data recorded by the tool be exclusively retained by the customer? | |
| 8.9 | Please describe innovative capabilities or emerging technologies that your solution offers or has on its product roadmap: | |
| • Artificial intelligence and machine learning applications (e.g., AI-assisted documentation, predictive analytics, natural language processing for assessments or notes). | ||
| • Real-time data validation, error capture, and proactive data quality management. | ||
| • Describe your product roadmap and approach to continuous innovation and feature development. | ||
| • Any other AI-assisted features. | ||
| Optional Attachments to Include | ||
| 9 | If the following are available for your product, please consider including them in your response | |
| 9.1 | Conceptual solution architecture. | |
| 9.2 | End-to-end system flow diagram. | |
| 9.3 | Product capability matrix. | |
| 9.4 | Camera and infrastructure compatibility summary. | |
| 9.5 | Detection performance and validation evidence. | |
| 9.6 | Recommended pilot and acceptance approach they would take. | |
| 9.7 | Five-year total cost of ownership estimate. | |
| 9.8 | Responsible AI and model governance documentation. | |
| 9.9 | Security and compliance documentation. | |
| 9.9 | Generic implementation plan and responsibility matrix. | |
| 9.10 | Sample operational reports and dashboards, if available; and | |
| 9.11 | Sample service-level and support model. |
File details come from the government source that posted it. Updated .