Information Technology Requirements_AED Mgmt and Maint.xlsx
XLSX spreadsheet 40 KB Posted
- Attached to
- RFQ - AUTOMATED EXTERNAL DEFIBRILLATORS (AED) PROGRAM MANAGEMENT AND MAINTENANCE SERVICES
- Solicitation number
- BPM013307
- Issued by
- California
About this file
This document is an Information Technology Requirements attachment for Request for Proposal/Bid/Quote (RFQ) 13307 issued by the Department of San Diego County Emergency Medical Services Office for Automated External Defibrillators (AED) Program Management and Maintenance Services. The file contains two comprehensive sets of IT requirements—business critical requirements and detailed technical requirements—that vendors must address in their proposals. The requirements outline mandatory capabilities for a web-based application solution, including Single Sign On (SSO) integration with County identity providers via SAML 2.0, Open ID Connect, or WS-Federation; compliance with HIPAA and federal/state privacy regulations; domestic support and infrastructure within United States borders; and comprehensive data encryption standards for both in-transit and at-rest data. The document specifies that vendors must provide detailed responses indicating whether their solutions meet each requirement with a "Yes" or "No" answer, and if unable to comply, vendors must explain what work is necessary to achieve compliance and identify any associated costs.
The technical requirements address critical security, architecture, and performance standards that vendors must support or document exceptions to, understanding that material exceptions may result in proposal rejection. Key technical mandates include Endpoint Detection & Response (EDR) or anti-malware protection; FIPS 140-3 validated cryptographic modules; prohibition of deprecated protocols such as SSLv2/SSLv3, TLS 1.0/1.1, and SMBv1/v2; role-based access control (RBAC) with principle of least privilege; SOC 2 Type 2 audit compliance; comprehensive audit logging with seven-year HIPAA retention; high availability database support; mobile device support with Microsoft Intune deployment capability; and support for a minimum of 10 concurrent users with 24/7 response time performance targets. The document requires vendors to provide SOC 2 Type 2 reports and attestation letters from subcontractors regarding control compliance as part of their proposal submission.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| RFQ 13307.pdf | ||
| aed_locations_and_serial_numbers.xlsx | XLSX spreadsheet | |
| Data Security Checklist_AED Mgmt and Maint.xlsx | XLSX spreadsheet |
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
Version Log
| Version | Date | Description |
| 1 | 7/5/18 | Initial draft |
| 2 | 7/13/18 | Updates from team review; remove Pricing and Customer References tabs. |
| 2.1 | 7/15/18 | Minor editing: instructions, vendor profile, and questionnaire worksheets |
(1) IT Requirements - Attach. 1
Request for Proposal/Bid/Quote (RFQ) 13307
DEPARTMENT OF SAN DIEGO COUNTY EMERGENCY MEDICAL SERVICES OFFICE
AUTOMATED EXTERNAL DEFIBRILLATORS (AED) PROGRAM MANAGEMENT
AND MAINTENANCE SERVICES
Information Technology Requirements Business Critical
| Attachment 1 - Statement of Work | IT Review and Comments (Check / Complete as applicable) | |
| The following are business critical requirements that proposer must resond to. All Information Technology Requirements shall be incorporated as an Attachment to Exhibit A - Statement of Work. State Yes or No to indicate whether or not your solution will meet the requirement. If No, state what work is necessary to meet the requirement or how your solution will meet the requirements and the work necessary to meet the requirements - indicate costs if needed. Applicable product literature or technical documentation can be provided to support your response. |
The County will favor a response that substantially meets the Information Technology requirements outlined in this document. Should you take exception(s) to the requirements, you understand that the County may, as part of its evaluation process, conclude that exceptions are so material as to make the Offeror’s response to the solicitation unacceptable.
| Response # | Requirement Description | YES/NO | Vendor Response and Comments. | |
| Please describe how your product will comply with the requirement | Vendor response acceptable as stated | Vendor response acceptable as modified below (re-state) | Vendor No confirmation and comments can be reserved | |
| MR-1 | Solution shall support Single Sign On (SSO) integration with the County's external identity provider (IDP) via SAML 2.0, Open ID Connect (Oauth 2.0) or WS-Federation. County ID (ex: srwillam) is the standard claim attribute for SSO integration. County ID (ex: srwillam) is the standard claim attribute for SSO integration (CoSD ID will be used for the Claim ID, not email address). If using OAuth 2.0 vendor shall use Authorization Code flow, PKCE, and the State parameter. | |||
| MR-2 | The solution shall protect the privacy of customer personal identifiable information (PII) in accordance with Federal and State regulations. Please describe how the solution meets the requirements. | |||
| MR-3 | All support for the solution shall be provided from locations within the borders of the United States including customer service and non-client facing technology and infrastructure support personnel. | |||
| MR-4 | All data processed and stored by this solution shall only traverse networks contained within the borders of the United States. | |||
| MR-5 | Endpoint Detection & Response (EDR) or Anti-Malware protection software shall be installed on all systems supporting the solution. Please describe the specific software that the solution uses. | |||
| MR-6 | Solution shall support data in-transit encryption, including but not limited to: |
1. Client to server communications
2. Server to server communications
3. Database communications
4. API communications
5. List any unencrypted data-in-transit instances the solution requires MR-7 The solution shall support data encryption for all data at rest including:
1. Disk level encryption
2. Database/Storage/Share Encryption
3. File level encryption
| MR-8 | Contractor shall provide dedicated internet protocol addresses and URLs for the County implementation (not multi-tenant) to use County DNS (not re-direct to the contractor environment). This will enable the use of County DNS and security standards such as 24/365 DNS availability, Web Application Firewall, Geo-blocking, Security Monitor, Client Reputation, IP Allow/Deny lists, Bot Management, Dynamic Site Accelerator, DDOS defense, primary and secondary DNS services, and interface to internal DNS services. |
| MR-9 | Solution shall be a web browser based application on a browser version supported by the leading browser market share vendors (e.g. Google Chrome, Microsoft Edge, Apple Safari, etc). |
| MR-10 | The solution product development teams shall not have access to production infrastructure and/or production data. |
| MR-11 | The solution must prevent the following items from being stored/hardcoded within the source code: |
1. Passwords
2. API keys
3. Certificates
4. Tokens
5. Hashes
6. Anything considered secret
| MR-12 | Solution shall support role-based access (RBAC) incorporating the principle of least privilege. | |
| MR-13 | All cryptographic functions performed within the solution (e.g., data encryption, key management, hashing, digital signatures) shall utilize FIPS 140-3 validated cryptographic modules. Any cryptographic module employed for data-in-transit or data-at-rest encryption, as well as authentication protocols, shall meet or exceed the requirements as defined in NIST FIPS 140-3 (Security Requirements for Cryptographic Modules) and NIST SP 800-131Ar2 (Transitioning the Use of Cryptographic Algorithms and Key Lengths). | |
| MR-14 | All solutions, systems, and applications within the environment shall not use the following deprecated or legacy protocols and ciphers, due to known security vulnerabilities and/or insufficient cryptographic protection: | |
| • | SSLv2.0/SSLv3.0 | |
| • | TLS 1.0/TLS 1.1 | |
| • | SMBv1/SMBv2 | |
| • | LM/NTLMv1/NTLMv2 | |
| • | FTP without TLS | |
| • | SSHv1 |
(2) IT Requirements - Attach. 2
Request for Proposal/Bid/Quote (RFQ) 13307
DEPARTMENT OF SAN DIEGO COUNTY EMERGENCY MEDICAL SERVICES OFFICE
AUTOMATED EXTERNAL DEFIBRILLATORS (AED) PROGRAM MANAGEMENT
AND MAINTENANCE SERVICES
Information Technology Requirements Detailed Technical
| Attachment 2 - Statement of Work | IT Review and Comments (Check / Complete as applicable) | |
| The following are detailed technical requirements that proposer must respond to. All Information Technology Requirements shall be incorporated as an Attachment to Exhibit A - Statement of Work. State Yes or No to indicate whether or not your solution will meet the requirement. If No, state what work is necessary to meet the requirement or how your solution will meet the requirements and the work necessary to meet the requirements - indicate costs if needed. Applicable product literature or technical documentation can be provided to support your response. |
The County will favor a response that substantially meets the Information Technology requirements outlined in this document. Should you take exception(s) to the requirements, you understand that the County may, as part of its evaluation process, conclude that exceptions are so material as to make the Offeror’s response to the solicitation unacceptable.
| Response # | Requirement Description | YES/NO | Vendor Response and Comments. | |
| Please describe how your product complies with the requirement | Vendor response acceptable as stated | Vendor response acceptable as modified below (re-state) | Vendor No confirmation and comments can be reserved | |
| General Regulatory | ||||
| DR-1 | Contractor shall provide a SOC 2 report as requested by the County. Contractor will furnish the Department with a copy of Contractor’s annual independent service auditor’s report on Contractor’s controls relevant to security, availability, processing integrity, confidentiality, and privacy. The SOC audit report must be a type 2 report that includes management’s description of Contractor’s system and the suitability of the design controls set forth in AICPA Trust Services Criteria Section 100 (2017). This independent audit of the Contractor’s controls must be completed in accordance with the AICPA SSAE No. 18 (SOC 2, Type 2). The SSAE 18 (SOC 2, Type 2) annual audit will include all programs under the Contract and will be conducted at the Contractor’s expense. If the Contractor’s SSAE 18 (SOC 2, Type 2) audit covers less than twelve (12) months of a calendar year, the Contractor will provide a bridge letter to the Department, stating whether processes and controls have changed since the SSAE 18 (SOC 2, Type 2) audit. In addition, the Department requires Contractor to submit a letter of attestation indicating Contractor’s receipt of management’s assertion of control compliance from Contractor’s subcontractors. | |||
| DR-2 | Solution shall comply with the follow laws and standards: Health Insurance Portability and Accountability Act (HIPAA) of 1996. | |||
| Architecture | ||||
| DR-3 | Application shall be web browser based for internal and public facing users. | |||
| Security | ||||
| DR-4 | Solution shall support PKI infrastructure and allow for both Server and Client Authentication i.e. mutual authentication. | |||
| DR-5 | Solution shall support role-based (RBAC) access. Please describe the roles that are available in the product and how RBAC is satisfied. | |||
| DR-6 | Solution shall support the ability to define custom access roles and associated permission sets. | |||
| DR-7 | Solution shall have access permissions configurable at the application module, screen and function level. | |||
| DR-8 | Solution shall permit access roles to both users and groups. | |||
| DR-9 | Solution shall require service account(s) and allow for application of least privileged access for these accounts. Required permissions for these accounts shall be delivered in documentation. | |||
| DR-10 | Solution shall provide authorized CoSD Business/Operational Administrators the ability to assign authorized customers permissions. Describe how this completed in the system. | |||
| DR-11 | Solution shall use an encryption key management process. Please describe your process and solution | |||
| DR-12 | Encryption keys shall be rotated automatically on a periodic basis. Please describe how this is achieved. | |||
| DR-13 | The solution shall provide audit logging for (you will be asked to demonstrate each of these): 1. Successful user login and logoff |
2. Log on attempt and failed data access attempts
3. System and application file access
4. System change attempts
5. User and Service account changes, including
a. Account creation
b. Account role changes/modification
c. Deletion
6. Use of privileged user account
7. All changes to security configuration, including:
a. User access changes
b. Deletion of audit logs DR-14 The solution shall retain audit logs within the server or application as appropriate for data classification and special mandates imposed by state and federal laws:
- Health Insurance Portability and Accountability Act (HIPAA) retention minimum of six (7) years per California Cal. Code Regs. Title 22, 72543
| DR-15 | The solution shall provide logs for edits and additions made to business data to include the date / time stamp and editor identification. |
| DR-16 | The solution shall have all actions with the software application log for attribution to a specific user. |
| DR-17 | Solution shall allow for the collection and consumption of generated audit logs such as SIEM Connector, Syslog, WEF. Please indicate how this is performed. |
| DR-18 | Solution shall use secure Web APIs for all application interfaces using TLS/HTTPS to encrypt data in transit. In addition, the contractor shall use secure coding practices to avoid vulnerabilities and validate and sanitize all inputs to prevent injection attacks. |
| DR-19 | Solution shall use SFTP for file transfers if secure Web APIs are not available. |
| Solution Architecture | |
| DR-20 | Solution shall have a tool and documented process for data conversion and migration. Please describe your solution |
| DR-21 | Solution must provide high availability for the database/datastore. Please describe how high availability is accomplished. |
| DR-22 | Solution must use a responsive UX design pattern to render on a variety of devices and window or screen sizes from minimum to maximum display size to ensure usability and satisfaction. Please describe in detail how this is accomplished. |
| DR-23 | Please explain the solutions ability to scale to 10 concurrent users. ADD Requirement: Solution must support 10 concurrent users. |
| DR-24 | The solution must support the use of mobile devices. Please describe in which operation systems and versions are supported. |
| DR-25 | The solution must support the deployment of mobile software through the County's MDM solution (Microsoft Intune). |
| Service Level/Performance/Capacity Requirements | |
| DR-26 | The solution must need the following service level for response time: |
a. Performance Target = Response Time 24/7, <2 seconds
b. SL Performance (%) = Aggregate 99.0%
Please describe how this can be accomplished.
DR-27 The solution must meet the following service level for application availability:
a. Performance Target = Available 24/7
b. SL Performance (%) = 99.90%
Please describe how this can be accomplished.
DR-28 Solution must have a Recovery Time Objective (RTO) within 48 hours.
Please explain how this is accomplished.
| Infrastructure Requirements | |
| DR-29 | The solution shall be configured to support multiple system environments (development, test, and production) |
| DR-30 | The solution shall use a database that is currently supported and can receive feature and security patching. |
| DR-31 | Vendor shall provided service desk support during the hours from 0700 - 1800 Pacific Time Zone. |
| AI Requirements | |
| DR-32 | Solution shall comply with CoSD Artificial Intelligence Board Policy: https://codelibrary.amlegal.com/codes/san_diego/latest/sandiego_board/a_140__artificial__intelligence__board__policy |
| DR-33 | Solution shall maintain a complete AI Bill of Materials (AI BOM) including all AI models, datasets, embeddings, prompt templates, plugins, agents, and third-party components used within the solution. |
| DR-34 | Solution shall cryptographically sign and verify model artifacts, datasets, and plug ins prior to loading, deployment, or update. |
| DR-35 | Solution shall maintain an auditable change management process for all AI related components, including retraining events, fine tuning, guardrail modifications, and configuration changes. |
| DR-36 | Solution provider shall implement and document their layered defenses against direct and indirect prompt injection, including sanitizing, validating, filtering, and constraining all user and system inputs. |
| DR-37 | Solution provider shall implement and document anomaly detection for potential data poisoning including RAG embedding vectorization, out of distribution samples, or malicious data artifacts. |
| DR-38 | Solution shall maintain rollback capability to revert to previous model versions if poisoning or degraded behavior is detected. |
| DR-39 | Solution shall ensure all AI Model training sets utilized within the solution are archived. |
| DR-40 | Solution shall ensure County data submitted in prompts is not used for model training, tuning, or embedding creation unless explicitly authorized in writing. |
| DR-41 | Solution shall implement per user and per session rate limits, context size limits, and token budgets to prevent abuse or DoS like consumption of compute resources. |
| DR-42 | Solution shall prevent exposure of system prompts, embeddings, tuning data, or other high signal model internals through user accessible interfaces. |
| DR-43 | Solution shall block Server Side Request Forgery (SSRF) by prohibiting access to internal networks, metadata services, or unauthorized external destinations. |
| DR-44 | Solution shall enforce least privilege scopes for plug ins, agents, and function calls, limiting each tool to its intended purpose. |
| DR-45 | Solution shall use only rotated, short lived, or ephemeral credentials for all AI workflow operations. |
| DR-46 | Solution shall log all AI interactions, including prompts, tool use, retrieval queries, errors, safety filter events, and security relevant metadata (token counts, cost, etc.). |
| DR-47 | Solution shall generate alerts for indicators of compromise, such as prompt injection attempts, anomalous retrieval patterns, or excessive context expansion. |
| DR-48 | Solution shall maintain regression test suites covering safety, hallucination, privacy leakage, bias, and jailbreak resistance. |
| DR-49 | Solution shall define safety and security KPIs (e.g., hallucination rate, leakage rate, harmful content rate) and enforce minimum acceptance thresholds. |
| DR-50 | Solution shall re-evaluate safety metrics after each model update, fine tune, guardrail change, or major configuration modification. |
| DR-51 | Solution shall prevent outputs that may endanger life, property, or the environment, consistent with ISO/IEC 5723 safety principles. |
| DR-52 | Solution shall support Explainable AI (XAI) features to provide transparency into model reasoning, decision steps, or influential input factors. |
| DR-53 | Solution shall enforce access controls on all documents and data sources retrieved by AI, ensuring users cannot access information beyond their authorized permissions. |
| DR-54 | Solution shall prevent cross-user data leakage within RAG pipelines, embeddings, vector stores, or retrieval chains. |
| DR-55 | Solution shall enforce access controls on all documents and data sources retrieved by AI, ensuring users cannot access information beyond their authorized permissions. |
| DR-56 | Solution shall prevent cross-user data leakage within RAG pipelines, embeddings, vector stores, or retrieval chains. |
Project Req
| Requirement Number | Requirement Description | Supported | Comments |
| Project requirements | |||
| System Documentation Requirements | |||
| T-230 | Online help on system functionality is to be a component of the online system | ||
| T-231 | Online help can be searched based on screen, job function, process name, nouns so that user can find help by topic | ||
| T-232, P-165 | System documentation includes product user guides | ||
| T-233 | System documentation includes technical manuals | ||
| T-234 | System documentation includes data model, tables and attributes | ||
| T-235 | System documentation can be exported into a format that can be annotated electronically and then stored, i.e. product documentation does not need to be re-typed to create custom training material or custom business process documentation | ||
| T-236 | System documentation is available in electronic format that may be stored on county computers | ||
| T-238 | Custom documentation on business processes is developed as part of the project | ||
| T-239 | Custom documentation on configurations and customization made to base product are developed as part of the project | ||
| T-240 | Custom documentation on installation procedures for configurations, customization are developed as part of the project |
| System Training Requirements | |
| T-241 | Training materials need to be accessible online and indexed by job function or process name. |
| T-242, P-166 | Training materials include detail user steps to complete job functions. |
| T-243 | Training materials are provided in electronic format. |
| T-244 | Training class are defined, materials written, classes conducted for end user training, super user training and system application support staff are developed as part of the project |
| WW-189 | Training will be hands-on practical on the installed system, using helpful training documents. |
| Data Extraction, Data Conversion, Data Loading | ||
| T-245 | Data from existing EAM systems, custom Access databases, and excel spreadsheets is extracted, transformed and loaded into new EAM as part of the project | With error messaging on load problems |
| T-246 | Defining the data mapping from existing EAM data sources into the new EAM system is part of the project | |
| WW-190 | Data conversion services as required to transfer existing County data into the new EAM. |
&"Arial,Bold"&14&A
&"Times New Roman,Italic"&11Functional Requirements Page &P of &N &"Times New Roman,Italic"&11&D
&"Times New Roman,Italic"&11Functional Requirements Page &P of &N &"Times New Roman,Italic"&11&D
&"Times New Roman,Italic"&11Functional Requirements Page &P of &N &"Times New Roman,Italic"&11&D
File details come from the government source that posted it. Updated .