How HEAT answers map to the FY2026 HMIS data standards
Written for an HMIS lead who is asked to record a HEAT result in HMIS, or to fill HEAT in from HMIS, and needs to know which data element and which value code each answer belongs to.
Public beta in development. Not for production decision making.
The scope line, first, because it is the one a plan gets wrong. A field mapping does not make integration free. This page says which questions the two systems ask in common and where the answers correspond; it does not say that a HEAT result can be reconstructed from an HMIS record, and it does not say that pre-filling HEAT from HMIS is a configuration task. The overlap is small, well defined, and enough to enroll from and report from. Outside it, HEAT asks things HMIS does not ask and HMIS records things HEAT deliberately never asks. Building anything on top of this costs real work, and a community that budgets a field map has budgeted the easy half.
Value codes were read directly from the FY 2026 HMIS Data Dictionary, released October 2025 for reporting beginning 1 October 2025. Nothing below is a guess. Where a mapping is uncertain, the uncertainty is in the mapping and is stated, not hidden in a code. This is HEAT's reading, not a HUD determination and not an approval.
How to read a mapping
The direction is always HEAT answer to HMIS value: it tells you what to write in HMIS when a person gave a particular HEAT answer. The reverse direction is not symmetric and is not claimed, because several HMIS elements carry distinctions HEAT never asked about.
The five ratings
EXACT: The two questions ask the same thing and the answer sets correspond one to one. Safe in both directions
CLOSE: The same idea, with a wording or scope difference that matters at the edges. Safe to write with a note; check before filling HEAT in from it
LOSSY: HEAT's answer does not settle a single HMIS value, or the HMIS answer does not settle a single HEAT value. Something has to be asked again
NONE: No HMIS data element asks this. The answer has no coded home and belongs in a locally defined field or a case note
DO NOT MAP: A mapping is technically available and would be wrong. The reason is stated in every case
The three absence codes, which are the same in both systems
Why it is the cleanest correspondence in the document: HEAT records a decline, a do-not-know and a not-asked as three different things and never collapses them into a no. HMIS carries the same three, as data not collected, participant refused, and participant does not know. So the one thing HEAT most needs to survive a write into HMIS survives it
Coverage, stated as a summary rather than argued
The instrument against FY2026
HEAT items: 37 (24 core, 13 across 8 modules) at the version this document was pinned to
CLOSE mapping to an FY2026 element: 5
LOSSY mapping: 9
No HMIS counterpart at all: 18
DO NOT MAP: 5
HEAT determinations with a direct HMIS element: 0. Not one of the six determinations HEAT produces has a field of its own in HMIS
EXACT: No HEAT item is EXACT end to end, because even the closest ones carry a wording or scope difference. Four individual option values are: unsheltered to 116, safe haven to 118, transitional housing to 302, and the three absence codes
Where the two systems actually overlap
The region: Living situation, the three chronic homelessness history fields, the disabling condition, veteran status, whether any income comes in, the domestic violence element, and the institutional stay dependencies
What that is enough for: Enrolling from, and reporting from
What it is not enough for: Reconstructing a HEAT result from an HMIS record. This page does not claim otherwise
One field an HMIS lead must not set from a HEAT result
Field 7, prioritization status, on the coordinated entry assessment record: HEAT produces no score, no rank and no queue position, so it has nothing to put there. A community sets that field from its own adopted written standards, applied by the people the standards name. Writing it from a HEAT output would invent a prioritization decision HEAT did not make and is not entitled to make
What HEAT deliberately does not collect
None of the following is an oversight and none of it is on a roadmap to be added. Several are excluded by a test that fails the build if they reappear.
Identity
Name, Social Security Number, date of birth: The public beta is memory-only: HEAT creates no record and transmits no answer. Every age rule reads a band rather than a date, and a date is more than any rule needs. CPD-17-01 III.C directs that a tool gather only necessary information
What follows, and an HMIS lead should hear it plainly: A completed HEAT cannot be used to create a record for a person. It holds no name, no date of birth and no Social Security Number, so it cannot be matched or de-duplicated. It is an assessment a worker attaches to a record that already exists
Protected characteristics
Race and ethnicity, sex, gender, sexual orientation: Permanently excluded from every item and from every determination, enforced by a property test. Two of these are FY2026 changes and neither changes HEAT's position: gender was retired and sex is a new element, and sexual orientation was retired
The cost, published rather than buried: HEAT cannot monitor its own disparities, because the characteristics that would be needed to measure them are not in it. That monitoring belongs to the community's HMIS data, where the demographics actually live
Specific diagnoses and the six disability elements: HEAT asks the yes-or-no disabling condition question the chronic homelessness definition requires, and tells the person they need not say what the condition is. It asks about events, never about disorders (CPD-17-01 II.B.12(f))
Program facts that belong to an enrolment, not an assessment
Income sources and amounts: HEAT asks only whether any money comes in each month. Income and employment are excluded from the support need determination entirely: they are program-fit facts rather than vulnerability, and they carry differential disclosure bias
CoC code, project start, exit, destination, move-in date: HEAT is an assessment, not an enrolment. It has no project, and it is location-agnostic so that it never narrows coverage
Verification of the living situation: HEAT is self-report throughout and verifies nothing. Verification is the worker's act
Where to check this
What HEAT said when it was run over real HMIS records, and where it disagreed with HUD's own derivation, is published at the HMIS study. Every question and the reason it exists are on Questions and the Evidence Register. How HEAT reads the HUD coordinated entry rules is at HUD alignment. Found a value code you would map differently? Use the Feedback button, bottom left.