23-E0013_RFI_(SEHRS)_Project_-_State_Response_to_Questions.xlsx
XLSX spreadsheet 34 KB Posted
- Solicitation number
- 0000033391
- Issued by
- Sacramento County, Sacramento City, West Sacramento City, California
About this file
This is a Question and Answer document for RFI #23-E0013 from the Office of Environmental Health Hazard Assessment (OEHHA) regarding the State Environmental Heat Risk Score (SEHRS) Project. The project involves transforming a static website into a dynamic platform and developing a cross-platform mobile application called CalHeatScore. The system will ingest and process weather data every 24 hours for 1,800 ZIP codes, providing heat risk information through both a Drupal 10-based website and a downloadable mobile app that will be available in English and Spanish initially, with potential for additional languages.
The current environment includes existing contracts with Capio Group for Project Management and Business Solution Analysis, Infinite Solutions for Independent Validation & Verification Services, UCLA Regents for Research/Development Heat Ranking, and Sunstone IT for ESRI services. The project will follow an Agile methodology and includes community engagement through 2025. The website must conform to CA.gov templates, and while the website and mobile app are separate products, they will not handle PHI or PII data. The system will utilize REST API connections to manage datasets, with the scientific team managing the data and the IT vendor handling the technical implementation.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 24-E0013_OEHHA_RFI_SEHRS_Project.pdf | ||
| Attachment_G_-_Excel_Sheet_-_RFI_Business_Requirements.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
Q&A
| Q # | Section/Document(s) | Page # | Question | Final State Response |
| 1 | Section II, B. Current Environment | 10 | According to the RFI, “This is a maiden project so no current environment exists.” Can you confirm this means that there are not any previous related contracts for this project? | Current contracts and purchase orders include the following: |
23-E0008 Capio Group (Project Manager) 23-E0014 Capio Group (Business Solution Analyst) 23-E0020 Infinite Solutions, Inc. (Independent Validation &Verification Services) 23-E0034 The Regents of UCLA (Research/Dev. Heat Ranking) PO 1823 (Sunstone IT), ESRI Advantage Program
| 2 | Section I, A. Purpose of this RFI | 4 | System Performance and Capacity: What are the computational and network capacity requirements to handle the data processing operations and data submission rates? | Every 24 hours, the system ingests weather data and it runs against pre-set calculations set by the OEHHA team for every ZIP code (1,800). | |
| 3 | Section II, A. Background | 10 | Goal 6: In reference to this text : Transform a website from static to dynamic and develop a cross-platform browser agnostic mobile phone application, both named CalHeatScore, for the system. | ||
| This suggests that the mobile tool could be a responsive web page that works well on mobile, but other requirements suggest a downloadable mobile app (from the iStore and Google Play Store that supports offline functionality. Can you confirm that the mobile solution is a downloadable app? | Yes, the mobile solution will be a downloadable app. | ||||
| 4 | Section II, C. Proposed Environment | 16 | In reference to this text 13. Driving directions to nearest hospitals, urban tree canopies, cooling locations also known as cooling stations, cooling centers, cool zones – is the expectation to embed driving directions in the app, or connect addresses to 3rd party mobile app, such as Google Maps, Apple Maps, or Waze? | It would be okay to connect addresses to a 3rd party mobile app. | |
| 5 | Section II, C. Proposed Environment | 16 | From the requirements section 15. Availability of a second language at the time of deployment and the future ability to expand on the number of languages | ||
| Recognizing that Spanish is listed as required, do you have a list of all expected languages that need to be supported? | We don't have a list of all expected languages that need to be supported. Currently English and Spanish. We plan to solicit input from the community. OEHHA will translate material and provide it to the vendor as a file to be used in the mobile application. | ||||
| 6 | Section II, B. Current Environment | 11 | In reference to this text : In a parallel project, geospatial information related to CalHeatScore has been developed by a third- party vendor. Do you expect the new system to manage these data sets, or connect to these datasets via REST API (ESRI, or Opensource)? | The scientific team will manage the datasets, and the IT vendor will help connect to these datasets via REST API or other method. | |
| 7 | Attachment G, Sheet 1 | FR3.1.13 | Are there specific feeds required – or specific web site components different to the standard public-facing web site, or does this ask that the data is made available to stakeholders such as emergency services? | No specific feeds at this time but ability to provide data. Website might need a weather type widget or module that works with Drupal 10. | |
| 8 | Attachment G, Sheet 1 | FR6.1.31 | We recognize that elements of the web site will be dynamic using latest available data; this question is related to the information (images, text) adjacent to the dynamic content. This question could suggest the solution should be built on a CMS (Content Management System) to allow OEHHA to make updates to web site material. Is this correct and is there a particular CMS vendor of interest? | That is correct the solution should be built on our current CMS which is Drupal 10. The static site is already available at: calheatscore.calepa.ca.gov | |
| 9 | Attachment G, Sheet 1 | FR6.1.34 | Does this question refer to the system having access to public forecast data (from the sources discussed in the RFI) to support information and alerts, or actual development of numerical solutions to create custom weather forecasts? | Both are true. The system should pull from existing forecast data, but CalHeatScore is based on custom numerical solutions. | |
| 10 | Attachment G, Sheet 1 | FR7.1.61 | Does this refer to the admin tool to be used by OEHHA, or the public-facing website/app? | Creation for mobile application and not the public facing website. | |
| 11 | Attachment G, Sheet 1 | FR10.1.78 | Other than this functionality, is there any expectation that public users will enter data into the web site or mobile app? (other than entering address search etc.). | Users may answer surveys on the tool. Users may also have the ability to provide suggestions for tool improvements and suggest datasets for inclusion. | |
| 12 | General | The RFI states that the new website will be "dynamic." Can the Office provide a definition of dynamic? Is the Office expecting the vendor to recommend features that are dynamic? | The main definition of "dynamic" is that CalHeatScore is a live tool that is updated every 24 hours, mostly based on weather forecast information. | ||
| 13 | Section I, A. Purpose of this RFI | 4 | The RFI states that it needs "technical resources needed to transform and maintain a static website to a dynamic website as well as design, develop, deploy, and maintain a mobile application." Are there separate requirements for a website vs. a mobile application, or is there an opportunity to leverage a single platform that can be accessed through a website and mobile interface? | I believe they are two separate products. The website is based on an improved-upon OEHHA site. The mobile application is a standalone product. | |
| 14 | General | Has any user research been conducted to define the needs of the end user or their journey through or between the website and mobile application? | OEHHA is conducting this research now and will be through 2025. | ||
| 15 | General | How will this project define success? Are there clear metrics? | Project success is defined in our PAL Stage 1. 7.1 https://projecttracking.technology.ca.gov/DownloadProposal?documentid=3a612115-1792-414a-9ecb-085ab467e157&projectid=3980-004 | ||
| 16 | General | Besides the general public, who else is considered the audience or end user? | State and local government, community based organizations, non-profits, medical institutions, and other groups. | ||
| 17 | General | Will this be an Agile project? Will it have sponsorship support and a Product Owner? | Agile project and has sponsorship support and a Product Owner | ||
| 18 | General | Beyond the technical requirements outlined in the RFI, what are the business requirements? | This is defined in our PAL Stage 1. 7.1 https://projecttracking.technology.ca.gov/DownloadProposal?documentid=3a612115-1792-414a-9ecb-085ab467e157&projectid=3980-004 | ||
| 19 | General | What are the dependencies within OEHHA and CalEPA that should be considered and that may impact project scope and approval milestones? | The scope may be increased or decreased based on OEHHA's workshops, stakeholder engagement, and other feedback processes. | ||
| 20 | General | Is there a chance any PHI, PII, or other secure information will be exchanged or exposed? | No, CalHeatScore will not exchange this information. All PII will be treated with appropriate procedures. The information will not be made available within the system. | ||
| 21 | General | Does the Office have a rollout strategy that can scale statewide? Will onboarding be done in phases or all at once? Is the Office looking for the vendor to contribute to the onboarding process? | OEHHA will conduct rollout throughout CA in 2025. OEHHA will lead this but is open to ideas from the vendor. | ||
| 22 | General | What kind of training will be needed internally, external? What format of training will be needed (e.g., in-person, webinars, microlearning, video, self-led, learning platform, certification tracking)? | OEHHA staff will require training to modify and upgrade the system, website, and app over time. OEHHA is flexible to different learning styles. OEHHA will be developing training materials to share externally on using the CalHeatScore tool. | ||
| 23 | Section I, A. Purpose of this RFI | 4 | The RFI states the applications must "remain in compliance with state and local regulations and guidelines." Are there metrics identified to confirm compliance, or is the Office asking the vendor to identify? Will stakeholder support be available on all requirements? | The vendor will comply with state and local regulations as identified by CDT and OEHHA. Vendor won't have to identify metrics for compliance. | |
| 24 | General | Are user experience discovery and design tasks throughout the project considered in the project requirements, or is the Office looking for recommendations from the vendor? | OEHHA is open to UX tasks recommended by the vendor. | ||
| 25 | General | Does the website need to conform to the CA.gov website template? | Yes, the website will need to conform to the CA.gov template. https://template.webstandards.ca.gov/ | ||
| 26 | General | How will the Office include the outputs from community engagement? | Community input will help drive our future research and tool improvement. | ||
| 27 | Section II, A. Background | 9 | Under Section II Project Description, Goal 1b, the RFI mentions the need to summarize work in "other communication materials." Is the vendor responsible for print materials? | We need printed or electronic materials on the maintained and operations and training the system functionality. | |
| 28 | Section II, A. Background | 10 | Under Section II Project Description, Goal 5a, the RFI mentions the Office will contribute to multiple communication plans. Is the vendor expected to produce content for the communication plan or the plan deliverable? | The vendor will not need to draft a Communication Plan; however, standard project management practices for communications such as dashboards, reports, updates, summaries, status, and presentations as of such etc., would be expected. Planning of deliverables may be expected of a vendor if a Primary or Secondary Request for Proposal is used. | |
| 29 | General | Depending upon the platform, is the Office prepared for system upgrades and avoiding risk if the platform is built on an out-of-the-box solution? Are there a minimum number of licenses needed for any platform solution? Is it going to be scalable depending on the growing number of administrators? | We don't anticipate having a growing number of administrators (<7). Up to 10 licenses are needed for the COTS solution. | ||
| 30 | General | What mobile platforms need to be supported? (e.g., Android, iOS, Windows, macOS) | Android and iOS and downloadable from official application stores. | ||
| 31 | General | Is there an existing data system that has data on California's cooling locations? | The data is disparate and differs in availability per county. OEHHA is interested in developing this data over time. | ||
| 32 | General | Is there an existing data system that has data on California's urban tree canopies (UTCs)? | This data differs in availability and quality across the state. | ||
| 33 | General | Do estimates exist for the expected volume of data needing to be stored, and what is the data's rate of growth? | OEHHA anticipates storing daily data to AWS from CalHeatScore. | ||
| 34 | General | Do estimates exist for the size of the potential user base of the system? | Estimates do not exist. We plan to roll out CalHeatScore statewide and test its usability across different sectors and groups. | ||
| 35 | General | Will any of the data being collected or warehoused contain PII or PHI? If so, what are the security and encryption requirements? | OEHHA collects and stores PII according to statewide protocol. This data will not be collected or stored by the vendor. | ||
| 36 | Section I, A. Purpose of this RFI | 5 | Would you please expand on item six from the high-level technical details list on page 5? What is meant by, "to facilitate the compilation of numerous raw data submittals into a cohesive and meaningful output product"? Does this refer to mass data ingestion via means other than the web application? | OEHHA will be collecting and analyzing multiple datasets to produce the CalHeatScore output. The vendor is responsible for rendering data outputs from CalHeatScore on an interactive data and mapping platform. | |
| 37 | Section II, B. Current Environment | 11 | Would you please expand on the requirements for the annual publication of the datasets from HCAI described on page 11? Is this an automated process the chosen solution will need to perform automatically? Is it already known what datasets will be required and in what format the data needs to be presented? Will it require the generation of a supporting report document with contextual and explanatory information? | OEHHA collects and stores HCAI data according to statewide protocol. This data will not be collected or stored by the vendor. | |
| 38 | General | For a proposed custom solution, will there be an expectation to host the web application on-premise or on a cloud platform? If the expectation is to host on a cloud platform, is there a preference between Azure, AWS, or Google? | The website is on AWS. The custom mobile application solution will likely be on a cloud platform. Preferred on AWS but open to others that are FedRAMP | ||
| 39 | General | Can a cloud platform be used to provide specialized services, such as a Notification Hub service for mobile notifications? | The notification must act like a native mobile application notification. | ||
| 40 | General | Has the static website already been developed and deployed publicly? If so, what is the URL to access the static website? | Yes the website is already up and running. Https://calheatscore.calepa.ca..gov | ||
| 41 | General | What are the two languages that will need to be supported at launch? | English and Spanish. | ||
| 42 | General | Can Google Translate be used to localize the web application? | No, Google translate will not be reliable enough to provide the level of confidence needed. | ||
| 43 | General | Would you please elaborate on the authentication requirements, specifically on whether the solution needs to have a custom authentication solution or if users will need to authenticate via existing Identity Providers (IDP) such as Microsoft Entra ID (formerly Azure Active Directory) or social providers like Google? | OEHHA is interested in finding a solution that allows CalHeatScore users to sign in and save profiles that contain relevant user-provided information, such as saved location, occupation, and other information. | ||
| 44 | Attachment G, Sheet 1 | FR5.1.29-5.1.30 | Would you please expand on mandatory functional requirement 5.1.29 (“The system shall provide batch/message processing interface functionality with external systems.”)? How does this differ or relate to requirement 5.1.30 (providing a REST API)? Is 5.1.29 about batching/processing messages coming into the REST API? | If existing systems don't interact with REST API, the vendor must find a solution. | |
| 45 | General | If a custom software solution is proposed, are there any limitations on the technology stack that can be used? | We are open to any technology stack, but we must feel comfortable maintaining it after the contract. | ||
| 46 | General | Are you open to a phased rollout of features, starting with an initial Minimum Viable Product release, and then smaller, future releases that build out the remaining features incrementally? | Yes. The scope may be increased or decreased based on OEHHA's workshops, stakeholder engagement, and other feedback processes. | ||
| 47 | General | How many years of post-launch maintenance will be awarded under the initial contract? | We would like at least 6 months for cross training and documentation and bug fixes | ||
| 48 | Attachment G, Sheet 1 | FR5.1.28 | How essential is requirement 5.1.28 ("The system shall allow authorized users to create and maintain API connections and interfaces")? | It is essential because we must feel comfortable maintaining it after the contract. | |
| 49 | Attachment G, Sheet 1 | FR7.1.61 | How essential is requirement 7.1.61 ("The system shall allow authorized users to create new objects such as tables, fields, pages, templates, and forms in the solution")? | We would like the users to create custom reports, based on current or historical data. | |
| 50 | General | Current Solutions: "Do you have any COTS solutions for Data Integration, Business Intelligence, or other data functions? If so, what are they?" | For the prototype, we're using Python and ArcGIS Online for data integration and display. | ||
| 51 | General | Data Update Frequency: "How frequently will data from various sources be updated, and what is the expected latency for data availability in the system?" | Weather forecast data will be updated into CalHeatScore every 24 hours. Other data, such as cooling center locations, will be updated in the system as needed. | ||
| 52 | General | User Roles and Access Rights: "Can you provide details on the specific user roles and access rights that need to be enforced within the system?" | CalHeatScore will have administrators, authentication is required. For user profiles, OEHHA is open to ideas for authentication, such as one-time access codes. | ||
| 53 | General | Data Processing: "For the four main data sources (NWS, NOAA, HCAI, OES), with UCLA responsible for algorithms/ETL activities against NOAA and HCAI, will further downstream processing be anticipated, or will the data be consumed as is?" | Further downstream processing may occur, and the OEHHA team will lead the analysis of this data and suggest methods for synthesis into the system. | ||
| 54 | General | Data Quality: "What is the current state of data quality? How much cleansing of raw data is expected prior to reporting?" | There are several data sources to be integrated into CalHeatScore, some of which needs to be cleaned in advance of posting. Live data, such as weather, will likely not be cleaned, but other datasets, such as locations of nearby cooling centers, may need to be cleaned and standardized. | ||
| 55 | General | Data Volume: "What is the current expected volume of data?" | CalHeatScore will use daily weather data and static health data to create estimates of heat impacts every 24 hours across all ZIPs (1,800) in CA. | ||
| 56 | General | Real-Time Data Editing: "Can you elaborate on the need for real-time data editing?" | OEHHA staff may edit the data in real time as necessary. | ||
| 57 | General | Preferred Technologies: "Are there any preferred technologies or frameworks for developing the dynamic website and mobile application?" | We are currently using Drupal 10 for the website. The prototype tool will be available as a web application via ESRI. | ||
| 58 | General | Long-Term Support: "Would the vendor executing a future RFP be expected to provide long-term support for the system proposed within the RFI?" | We would like to eventually do cross training and have the ability to maintain and operate the system. | ||
| 59 | General | User Quantity and Access Requirements: "What is the expected number of users for the database and dynamic website? Additionally, what are the access requirements and needs for different users?" | OEHHA does not have an estimate of number of users, but will roll out CalHeatScore across CA. CalHeatScore users will need the tool translated to various languages - OEHHA will be responsible for the translation. | ||
| 60 | General | To provide a technical approach that aligns with existing tool-set considerations or constraints, are there any existing technical products the department would like us to include as part of the final proposed solution? | The CalHeatScore prototype runs on the ESRI interactive mapping platform. OEHHA would like to maintain ESRI as a base mapping service for CalHeatScore. | ||
| 61 | General | Could the State please clarify if the scope of the Statewide Extreme Heat Ranking System (SEHRS) Project will include development of the heat ranking algorithm. The level of data science required will impact our recommended approach, as well as the type of resources required to successfully implement the project. | Development of the heat ranking algorithm will occur internally at OEHHA | ||
| 62 | Section II, B. Current Environment | 10 | Could the State please clarify if any project goals where “OEHHA to deliver” should be interpreted as the sole responsibility of the State and no vendor involvement will be required to achieve. | Yes, OEHHA to deliver should be interpreted as OEHHA being responsible for the project goal. | |
| 63 | General | Are there any project duration considerations vendors should be aware? If the State is required to deliver the project within a certain duration, this would impact the team capacity required to deliver the project within the given timeline. | OEHHA plans to iteratively update and improve upon CalHeatScore, although a timeline has not yet been set. | ||
| 64 | General | Data Storage and Management: What are the expected volumes of data, and how will the storage solutions be scaled to accommodate future growth? What measures will be taken to ensure data quality and validation? | CalHeatScore will use daily weather data and static health data to create estimates of heat impacts every 24 hours across all ZIPs (1,800) in CA. OEHHA plans to use a platform that can scale to accommodate future growth. OEHHA staff will validate data on an ongoing basis. | ||
| 65 | General | System Performance and Capacity: What are the computational and network capacity requirements to handle the data processing operations and data submission rates? | CalHeatScore will use daily weather data and static health data to create estimates of heat impacts every 24 hours across all ZIPs (1,800) in CA. | ||
| 66 | General | APIs and Interoperability: What APIs will be available for querying and exchanging information with other related systems? What are the different APIs to be built to other systems? | OEHHA will use APIs from external sources in order to create data uploaded to a data warehouse that might have APIs. The vendor will need to create new APIs in order to interact with the solution they build and interact with the data warehouse. | ||
| 67 | General | Existing Geospatial Functionality: Can the State please confirm the level and nature of existing geospatial software/tooling that could be made available to support this system development (i.e. ArcGIS Online, ArcGIS Enterprise etc.) | ArcGIS Pro, Python for ArcGIS, ArcGIS Online | ||
| 68 | General | Existing Software Licenses: What are the existing software licenses that OEHHA expects to use for the CalHeatScore app? | ArcGIS Pro, Spatial Analyst, Image Analyst, ArcGIS Online | ||
| 69 | General | Are we able to utilize subcontractors to complete this work? | Subcontractors are allowed to complete the work according to State of California procurement guidelines. If a procurement is released by OEHHA for this project, preference points and percentages shall be given for certified Small Business and Disabled Veteran Business Enterprise participation which could include subcontractors. See https://www.dgs.ca.gov/PD/About/Page-Content/PD-Branch-Intro-Accordion-List/OSDS/OSDS?search=Disabled%20Veteran%20Business%20Enterprise%20(DVBE)%20Program. | ||
| 70 | General | What specific data will be collected from end users via the web and mobile app? Can you clarify what HIPAA-restricted data will be collected? | HIPAA data will not be collected from end users. Health data will be collected by the OEHHA scientific team according to all state protocols. Some possible data that may be collected from users includes: 1)surveys or polls about tool usability, and 2) an optional feature allowing users to submit their own suggestions for tool improvement and/or sample datasets. | ||
| 71 | General | Do web and mobile applications in this solution require a login for all users or is that optional? | This is optional and not a requirement for users to have a login in order to use the mobile application. Having an account expands the profile of the user in order to allow them to get better information depending on their profile choices. | ||
| 72 | General | Can you clarify if the solution requires a native application, installed via the platform app store or is a mobile-responsive web application acceptable? | Can be a mixture of both but some functionality requires a native applications. | ||
| 73 | General | Is it expected that the selected vendor will need to sign up to a HIPAA Business Associate Agreement? | Since the vendor will not be accessing, analyzing or storing HIPAA data, no. | ||
| 74 | Attachment G, Sheet 2 | NF1.01.01, 1.01.1 | Can you identify the specific environmental regulations and guidelines that this solution must adhere to? Who will validate the solution is in compliance? | CA-SIMM. CA's oversight control agency will validate compliance. | |
| 75 | Attachment G, Sheet 2 | NF1.01.02, 1.01.2 | Can you identify the specific regulatory standards and best practices that the solution must adhere to? Who will validate the solution is in compliance? What HIPAA data will be collected? | CA's oversight control agency will validate compliance. The vendor will not collect HIPAA data. | |
| 76 | Attachment G, Sheet 2 | NF2.01.03, 2.01.1 | What is the metric for success for load testing? How many active concurrent users should this solution support (Typically and Maximum) | The vendor should actively conduct load testing during development. OEHHA is unsure on how many concurrent users the solution will need to support. | |
| 77 | Attachment G, Sheet 2 | NF3.01.05 – 3.01.06 | What are the largest data sets anticipated for ingestion into the system? | We're currently ingesting daily weather forecast data from NDFD at a 2.5km grid across CA. Future climate or geographic datasets may be ingested at a finer spatial resolution (100m - 1km). | |
| 78 | Attachment G, Sheet 2 | NF4.01.08, 4.01.1 | What percentage of uptime availability is expected for this solution? | Since CalHeatScore will update daily and be cached every 24 hours, the system must have available uptime to capture and display new data during the update period. | |
| 79 | Attachment G, Sheet 2 | NF5.01.11, 5.01.1 | Can you clarify why temperature readings are considered sensitive data? | Upon further review temperature readings are not sensitive data. | |
| 80 | Attachment G, Sheet 2 | NF5.01.13, 5.01.3 | Can you explain why Audit Logging would be a mandatory priority requirement? Is the client open to alternative types/levels of auditing outside of what is described in the RFQ? | The logging is for monitoring, auditing, and compliance purposes. This is mandatory in order to be compliant. Only willing to consider if it still complies with state policies. | |
| 81 | Attachment G, Sheet 1 | FR7.1.72, 7.1.72 | Can you clarify which languages this solution and applications need to support? Just English and Spanish, or others? Are there any right-to-left languages that need to be supported? Is there any stored data that will need to be translated or stored separately in a translated variant to support multiple languages? | The app needs to support multiple languages based on need. OEHHA will translate the language and then import it as a separate file into the existing application. Data should not need to be translated or stored separately. | |
| 82 | Attachment G, Sheet 1 | FR9.1.76, 9.1.1 | Is this a mandatory requirement or would a mobile web application without offline caching be acceptable? | This requirement is for the mobile application. The mobile application has to be able to provide live or cached information. | |
| 83 | Section I, A. Purpose of this RFI | 4 | Can you provide detailed specifications on the data formats, volumes, and update frequencies | ||
| for all data sources (e.g., NOAA, NWS, OES, HCAI)? | The NOAA NWS weather forecast is grib format and additional data to be added may be in grib, netcdf, csv, or shapefile format. The file sizes are not anticipated to exceed 500 Mb. In future versions, weather forecast data are not anticipated to be updated more than 2x a day, and other data sources will be updated as needed (~ once a quarter, etc.). | ||||
| 84 | Section I, A. Purpose of this RFI | 4 | What specific data processing and integration points will UCLA handle, and what outputs (e.g., | ||
| APIs, datasets) will be provided to the solution provider? | The OEHHA team will be leading the identification and mode of processing for input datasets. OEHHA will provide these data sources and associated script/code to the vendor for integration into the public-facing system. | ||||
| 85 | General | Are there predefined data security or compliance requirements (e.g., HIPAA, FedRAMP) that must | |||
| be met for cloud storage and data exchanges? | FedRAMP | ||||
| 86 | Section I, A. Purpose of this RFI | 5 | Could you confirm the expected user load for the website and mobile app, including concurrent | ||
| users and peak traffic patterns | CalHeatScore will use daily weather data and static health data to create estimates of heat impacts every 24 hours across all ZIPs (1,800) in CA. CalHeatScore will be rolled out across CA. Peak traffic expected in hotter months. | ||||
| 87 | Section I, A. Purpose of this RFI | 4 | Are there specific performance benchmarks for real-time data ingestion, processing, and | ||
| visualization (e.g., response times for analytics or geospatial queries)? | We do not have any specific performance benchmarks at this time. | ||||
| 88 | Section I, A. Purpose of this RFI | 5 | What level of geospatial functionality is required (e.g., heatmaps, live location tracking, advanced | ||
| routing), and are there preferred GIS tools or libraries? | CalHeatScore will contain live updates for heat rankings that users can browse. Users can access ZIP-specific data and interact with supplementary data layers, such as the locations of nearby cooling centers. The user should be able to use a geolocation feature, and also a tool to get directions to other nearby features on the map, like cooling centers. The prototype of CalHeatScore is running on ESRI. | ||||
| 89 | Section II, A. Background | 9 | Will UCLA algorithms require in-house deployment by the solution provider, or will they | ||
| be available via APIs hosted by UCLA? | The algorithms will be maintained by OEHHA and provided to the solutions provider. | ||||
| 90 | Section I, A. Purpose of this RFI | 6 | For multilingual support, what languages are mandatory at launch, and will the translations be | ||
| handled by OEHHA or the solution provider? | English and Spanish need to be available at launch and then more languages will be integrated based on need. OEHHA will provide the translations. | ||||
| 91 | Section I, A. Purpose of this RFI | 5 | Are there existing state systems or external APIs (e.g., GIS databases, emergency response | ||
| platforms) that need integration, and what standards govern these integrations? | The current prototype is not using existing state systems or external APIs, but these may be integrated in future versions of CalHeatScore. We are incorporating feature layers from ArcGIS online. Standards are governed by SIMM. | ||||
| 92 | Section I, A. Purpose of this RFI | 5 | Can you provide examples of the anticipated outputs for public-facing dashboards (e.g., | ||
| specific charts, map overlays, or datasets)? | OEHHA expects to develop different dashboards that are tailored to different user types. These dashboards will include charts showing meteorological and climate data, map overlays showing locations of nearby relevant resources, and functions for downloading a user-defined subset of the data and/or making it available as a PDF report. | ||||
| 93 | General | What disaster recovery measures and uptime guarantees are expected for both the website and | |||
| mobile app? | Website is maintained by OEHHA. The vendor will focus on the uptime and availability for the mobile application. The mobile application is expected to provide information as updates happen which is every 24 hours. | ||||
| 94 | General | For system scalability, what is the anticipated growth rate of data and user interactions over the | |||
| next five years? | After the CalHeatScore prototype is launched, we will roll out CalHeatScore across California using various engagement, advertising, and Public Relations efforts. | ||||
| 95 | General | What are the expectations for accessibility compliance (e.g., WCAG levels) for both the | |||
| website and mobile application? | We follow what the Federal government policy which is WCAG and any subsequent changes. Government websites and third-party services must comply with WCAG 2.1 Level AA standards by April 2026. | ||||
| 96 | Section I, A. Purpose of this RFI | 4 | What format and mechanism will be used to share processed data (e.g., APIs, flat files)? Also, | ||
| what is the update frequency for processed data from UCLA? | OEHHA anticipates using a combination of web services and flat files for sharing processed data. OEHHA will lead the work in processing and sharing this data, and will update CalHeatScore at minimum, bi-annually. |
Office of Environmental Health Hazard Assessment State's Response to Questions Request for Information No. 24-E0013
Release Date &D &P of &N
File details come from the government source that posted it. Updated .