Emergency Housing Spells

adam.kado
26 June 2025

Module Output

SQL:[IDI_Community].[hsg_emergency_housing_spells].[emergency_housing_spells_YYYYMM]
SAS: libname cmeh dsn=IDI_community_srvprd schema=hsg_emergency_housing_spells; run ;
How to access a code module in the Data Lab:Read here
All workshop recordings : Find here

Purpose

The purpose of this module is to construct spells of Emergency Housing Special Needs Grant (EH SNG) received by a primary applicant. These spells can be used to produce estimated counts of people who are receiving EH SNG as a primary applicant at a given point in time. The module can be used to produce data for research into the extent of provision of EH SNG and those who have accessed it.

Key Concepts

Emergency Housing eligibility/criteria (current as at April 2025)

Emergency housing (EH) is short-term accommodation and individuals must meet certain criteria:

Emergency housing may also be available for those escaping family violence or leaving prison when they meet the above criteria of having nowhere to stay.

Residency

If a person is getting a main benefit (e.g. Jobseeker Support), NZ Super or Veteran’s Pension from MSD , they meet the residency criteria.
If they don’t get one of the above benefits, they need to be considered ordinarily resident in New Zealand and meet one of these residency criteria:

Housing need circumstances

Income and assets

Generally, applicant households need to have income and/or assets under specified amounts the current values as at April 2025 are as followed:

References

  1. Work and income - Emergency Housing: www.workandincome.govt.nz/housing/nowhere-to-stay/emergency-housing/who-can-get-it.html
  2. Monthly MSD EH report on numbers/grants: www.msd.govt.nz/about-msd-and-our-work/publications-resources/statistics/housing/monthly-housing-reporting.html

Development Team

Domain Agency Person
Lead SME, module coder HUD Saera Chun (HUD)
SME, business rules MSD Caitlin Buchanan (MSD)
Code support, peer review HUD Adam Kado (HUD)
Peer review of code MSD Yan Chen (MSD)
Policy/Operational Experts HUD/MSD Saera Chun (HUD)
Policy/Operational Experts HUD/MSD Caitlin Buchanan (MSD)
Data Supply MSD

Module Business Rules

  1. If the primary applicant has multiple EH grants, the grants are ordered chronologically.
    If the days between two grants (based on the MSD decision date for a grant) for a client is longer than 28 days, it is treated as a new spell.
    Where the MSD decision date between grants is 28 days or less, they are considered to form a single spell.
  2. For each unique snz_uid (person) the spells are ordered chronologically and numbered with a spell_nbr of 1 indicating the earliest emergency housing spell.
  3. The spell start date is determined by the earliest grant decision date in a spell.
  4. The spell end date is determined by looking at the latest/final grant date [MSD decision date] and adding +21 days to this date.
  5. The spell duration is the number of days between the spell start date and the spell end date (end date business rule detailed above)

Spell nbr

Spell start

Spell end

Payment amount

Open Issues/Comments

  1. External data matching issue: This analysis uses the EH code module which builds from existing MSD data, using MSD business rules to calculate spells in EH.
    Limitations in the current data provision mean housing spells cannot be exactly replicated within the IDI and exits from EH may be undercounted.
    This issue will be resolved once the new provision goes into the IDI during the October refresh.
  2. Note on duplicates:
    A client may have multiple grants on the same day. However, MSD advises to consider them all legitimate
    as these occur due to the frontline practices and to match publicly published figures as close as possible.
    Count all records of grants in each spell.

Parameters

The following parameters should be supplied to this module to run it in the database:

  1. {targetdb}: The SQL database on which the spell datasets are to be created.
  2. {idicleanversion}: The refresh version of IDI Clean that the spell datasets need to be based on.
  3. {targetschema}: The project schema under the target database into which the spell datasets are to be created.

Dependencies

{idicleanversion}.[msd_clean].[msd_third_tier_expenditure]

Outputs

{outputs}{targetdb}.{targetschema}.[eh_emergency_spells]

Variable Descriptions

Aspect Variables Description
Entity snz_uid The unique STATSNZ person identifier for the person.
snz_msd_uid A unique MSD identifier that links to other MSD datasets.
spell_nbr The spell number for a person that identifies that spell’s chronological place where a person has multiple spells, for example the earliest EH spell for a person will have a spell_nbr of 1.
Source data_source msd_clean.
Period spell_start_date The start date for an emergency housing spell derived from the grant decision date sourced from msd_clean.msd_third_tier_expenditure.
spell_end_date The end date for an emergency housing spell derived from the grant decision date sourced from msd_clean.msd_third_tier_expenditure.
Event information spell_duration The total length of the spell in days.
spell_nbr The spell number.
payment_amount The total sum of all payments made during the spell event, derived from payment amounts sourced from msd_clean.msd_third_tier_expenditure.
recoverable_ind Whether the grant is required to be repaid or not sourced from msd_clean.msd_third_tier_expenditure.
benefit_code A numerical code for the type of benefit the primary applicant receives sourced from msd_clean.msd_third_tier_expenditure.
msd_district_code A numerical code for the MSD district office that administered the EH grant.

Module Version & Change History

Date Version Comments
2024/2025 Initial Version based on specifications from Commissioning document.
20 February 2025 Update Updated to deal with duplicates.
27 May 2025 Headers Update to header

Code

:setvar idicleanversion "{idicleanversion}" 
:setvar targetdb "{targetdb}"
:setvar targetschema "{targetschema}"

/* Assign the target database to which all the components need to be created in. */
USE $(targetdb);
GO

/* Delete the database object if it already exists */
DROP
VIEW IF EXISTS [$(targetschema)].[eh_emergency_spells];
GO

CREATE
VIEW [$(targetschema)].[eh_emergency_spells] AS 

/* 1. Note on duplicates; 
   A client may have multiple grants on the same day. However, MSD advises to consider them all legitimate 
   as these occur due to the frontline practices and to match publicly published figures as close as possible. 
   Count all records of grants in each spell. */
WITH base_data AS(
    SELECT [snz_uid]
        , [snz_msd_uid]
        , [snz_swn_nbr]
        , [msd_tte_tt_pmt_nbr]
        , [msd_tte_decision_date] AS [spell_start_date]
        , [msd_tte_parent_svc_code]
        , [msd_tte_lump_sum_svc_code]
        , [msd_tte_pmt_rsn_type_code]
        , [msd_tte_pmt_amt] AS [payment_amount]
        , [msd_tte_recoverable_ind]
        , [msd_tte_rcmd_dist_code]
    FROM [$(idicleanversion)].[msd_clean].[msd_third_tier_expenditure]
    WHERE [msd_tte_pmt_rsn_type_code] = '855'
)
    , 
/* 2. Identify Spells;
   If the days between two grants for a client is longer than 28 days, treat it as a new spell. */
identify_spells AS(
    SELECT *
        , CASE 
            WHEN DATEDIFF(DAY, LAG([spell_start_date]) OVER (PARTITION BY [snz_uid], [snz_msd_uid] 
															 ORDER BY [spell_start_date]), [spell_start_date]) > 28 
            OR LAG([spell_start_date]) OVER (PARTITION BY [snz_uid], [snz_msd_uid] 
											 ORDER BY [spell_start_date]) IS NULL 
            THEN 1 ELSE 0 
        END AS [new_spell]
    FROM base_data
)
    , 
/* 2a. Add a spell number for each client */
spell_nbr AS(
    SELECT *
        , SUM([new_spell]) OVER (PARTITION BY [snz_uid], [snz_msd_uid] 
							   ORDER BY [spell_start_date] ROWS UNBOUNDED PRECEDING) AS [spell_nbr]
    FROM identify_spells
)
    , 
/* 3. Clean up the attributes of each spell;
   The earliest spell start date is the spell start date
   The sum of all payments is the total payment amount for each spell
   Use the information from the latest payment_nbr within the spell for its attributes */
spell_maxpaymentnbr AS(
    SELECT [snz_uid]
        , [snz_msd_uid]
        , [spell_nbr]
        , MIN([spell_start_date]) AS [spell_start_date]
        , MAX([spell_start_date]) AS [max_spell_start_date]
        , COUNT(*) AS [spell_grants_count]
        , SUM([payment_amount]) AS [payment_amount]
        , MAX([msd_tte_tt_pmt_nbr]) AS [max_payment_nbr]
    FROM spell_nbr
    GROUP BY [snz_uid]
        , [snz_msd_uid]
        , [spell_nbr]
)
    , spell_info AS(
    SELECT a.[snz_uid]
        , a.[snz_msd_uid]
        , a.[spell_nbr]
        , a.[spell_start_date]
        , a.[max_spell_start_date]
        , a.[spell_grants_count]
        , a.[payment_amount]
        , b.[msd_tte_parent_svc_code] AS [benefit_code]
        , b.[msd_tte_recoverable_ind] AS [recoverable_ind]
        , b.[msd_tte_rcmd_dist_code] AS [msd_district_code]
    FROM spell_maxpaymentnbr a
    LEFT JOIN spell_nbr b
    ON a.[snz_uid] = b.[snz_uid]
    AND a.[snz_msd_uid] = b.[snz_msd_uid]
    AND a.[max_payment_nbr] = b.[msd_tte_tt_pmt_nbr]
)
/* 4. Finalise the table with the spell end date and spell duration
   spell end date is 21 days from the max spell date within the spell*/

SELECT [snz_uid]
    , [snz_msd_uid]
    , [spell_nbr]
    , [spell_start_date]
    , DATEADD(DAY, 21, [max_spell_start_date]) AS [spell_end_date]
    , DATEDIFF(DAY, [spell_start_date], DATEADD(DAY, 21, [max_spell_start_date])) AS [spell_duration]
    , [spell_grants_count]
    , [payment_amount]
    , [recoverable_ind]
    , [benefit_code]
    , [msd_district_code]
FROM spell_info

;
GO