Heat Check-In

Call Sheet page
Landing page

Inspiration

Extreme heat poses serious health risks for New Yorkers living with serious mental illness or substance use disorders. A meta-analysis found that the odds of substance use disorder–related emergency department visits were approximately 11% higher during periods of extreme heat.

NYC guidance for service providers recommends identifying vulnerable clients, planning outreach, and documenting cooling needs and check-ins. Yet when a heat advisory arrives, social workers still have to piece together whom to contact first, which information is outdated, and whether earlier requests for support were resolved. Our team, Mind the Gap, wanted to support conversations between social workers and clients—and help those conversations lead to action.

What it does

Heat Check-In is designed for social workers on NYC behavioral health care teams supporting New Yorkers with serious mental illness or substance use disorders. It creates a call sheet showing whom to contact first and why, using heat advisories alongside recorded location, cooling plans, previous outreach, and unresolved support needs. It also shows when information was last confirmed and flags missing or outdated details for follow-up.

Before calling, a social worker checks the client’s contact consent and preferred method. The call card separates what the team already knows from what it needs to ask. If the conversation reveals a broken air conditioner or a transportation barrier, the team assigns a next action and an owner. Heat Check-In tracks the contact attempt, the request for support, and confirmation that support was received as distinct steps. Unreached clients remain on the list for another attempt, while new information and support outcomes inform the next heat response.

How we built it

Mind the Gap brings together policy, data, design, and engineering. Giovanna Braganza is a Senior Policy and Analytics Manager at a New York State nonprofit. Ellen Wei brings data science expertise; Hyejin Jeon, UX/UI design; Seren Kim, software and design engineering; and Jill Andriotty, climate-tech development. We began with the decisions a social worker faces during a heat advisory: whom to contact, what to check, and how to know whether support reached the client.

Data pipeline. We used two real public sources: NYC’s Heat Vulnerability Index and its heat-related emergency department visits paired with daily maximum temperature. The Index provides neighborhood context on the call card, while the emergency department data shows what happened on past hot days. For the demo, we created 12 client profiles with dated sources, missing answers, and restricted information; 10 are used in the prioritization engine. We simulated a heat advisory using National Weather Service criteria for NYC. No real patient data was used.

Prioritization and explanation. A separate scoring engine uses weights informed by Bouchama (2007), Martin-Latry (2007), Chen (2025), and CDC heat-and-medication guidance to produce a risk range and confidence indicator. Contact order follows workflow rules informed by NYC guidance for service providers and the CDC CHILL’D-Out questionnaire. Each client is placed in Contact first for an open support task, no working cooling, a transportation or cost concern, or a clinical question; Needs verification when a key answer is missing or more than 30 days old, consent is unconfirmed, or the last contact failed; or Plan confirmed. The call sheet explains why this client needs attention now, what still needs checking, and when the underlying information was last confirmed.

From check-in to follow-up. Missing answers or answers older than 30 days expand into questions on the call card; recently verified answers remain collapsed with their dates. An editable decision table suggests housing staff for cooling problems, a resource partner for transportation, a care navigator for cost concerns, and a clinician for clinical questions. In the demo, browser storage records whether a client was reached, could not be reached, or declined the check-in. It also tracks whether a follow-up task is open, accepted, in progress, blocked, or confirmed to have delivered the needed support. Confirmed answers and dates remain available for the next heat event.

Implementation. We built the web experience with HTML, CSS, and vanilla JavaScript, using Leaflet with OpenStreetMap tiles for geographic context. Python scripts prepared the datasets and fetched NOAA temperature observations. JSON files supplied application data, browser localStorage saved dated check-ins and follow-up tasks, and a Python HTTP server served the local demo. A freshness rule identifies missing or outdated information; the Claude Haiku 4.5 API uses that context to generate check-in questions and draft a text message with relevant resources and guidance for the client. Transparent rules determine contact priority and suggest next actions. During development, we used OpenAI Codex, Claude Code, and Hermes for workflow design, coding, data preparation, and testing.

Challenges we ran into

The main challenge was distinguishing neighborhood-level climate data from a client’s actual circumstances. NYC’s Heat Vulnerability Index provides place-based context, but it cannot tell us whether a client has working cooling at home. Client records may also be outdated, missing, or restricted. We left those gaps visible as questions for the social worker to verify. The studies we consulted measured different outcomes, including deaths, emergency department visits, and hospitalizations. We distinguished values drawn from research from weights set by our team and kept the risk score separate from the workflow rules that determine contact order. We also recorded a completed call separately from confirmation that the needed support was delivered.

Accomplishments that we're proud of

We built a demo that carries a heat advisory through to an outreach order, check-in questions, and follow-up tracking. A social worker can see why a client needs attention now and revisit only information that is missing or outdated. When a check-in reveals a need, the workflow suggests an action and owner and keeps the task visible until support is verified. We are especially proud of separating the risk score from the contact order. The score helps surface relevant factors, while the outreach rules focus the team on unresolved tasks and answers that need checking. We applied the engine to 10 of our 12 demo client profiles, including cases with missing or outdated information, so those gaps remain visible in the call sheet.

What we learned

We learned that showing what each piece of data can and cannot tell us matters more than simply collecting more data. Neighborhood heat vulnerability offers context, but a conversation with the client is needed to confirm their cooling situation. Showing where information came from and when it was last confirmed helps social workers assess and correct the reasons behind the call list. We also learned that outreach is only the start of a response. Once a client identifies a need, the team must know who owns the next step and whether support actually arrived. Bringing policy, data, design, and engineering perspectives together helped us make that connection central to the product.

What's next for Heat Check-In

We want to improve the outreach, documentation, and follow-up processes care teams already use, rather than add another separate workflow. Our next step is to review the contact order, call-card questions, and task assignments with NYC behavioral health care teams. Their feedback would guide how Heat Check-In could work within existing electronic health record or care-management systems. Our intended impact is to reach clients who need help sooner during extreme heat and ensure that identified needs lead to delivered support. We would evaluate this through time to first contact, unmet needs identified, support completion, retries after unsuccessful contact, and social workers’ time spent on outreach. Before deployment, we would need consent-aware access, role-based permissions, and clinical review of the prioritization rules. After testing with one care team, we could adapt the workflow for other programs and locations, using maintainable rules and AI only where it adds value to manage long-term costs and energy use.