In August 2020, the DWP issued Housing Benefit Circular A9 2020, which is a special bulletin to councils notifying them of a change to policy or process. This specific circular sets out the details of a Housing Benefit Award Accuracy (HBAA) Initiative and the funding LAs will receive to undertake activities to identify unreported changes of circumstances.
The funding, from the DWP, is designed to support LAs undertaking specific activities to proactively identify unreported changes and make sure that the right amount of benefit is paid to the right person at the right time.
This funding is awarded for councils carrying our Full Case Reviews (FCR).
A FCR requires a council to consider and look at all the current claim details and evidence associated with the claim, as well as any other fresher information or evidence they can source, in order for the weekly HB amount to be reviewed. The key elements are that:
- the Council reviews and validates whether the current information associated with the claim remains correct
- the Council seeks evidence from the claimant where it is possible to do so, in accordance with their review processes
All of this in order to identify any changes of circumstances and recalculate a claimant's HB award accordingly.
From October 2020, the DWP will provide details of cases (new monthly Caseload Risk Data) deemed to be high / medium risk cases that the council in turn should focus their efforts on ensuring a review takes place.
IEG4 | Research & Development 2
Council activity associated with FCRs undertaken will be monitored by DWP via SHBE. Specifically, the DWP will be extracting data from the Fraud and Error detection activities, Change and Error Records within the SHBE. A list of the actual SHBE fields DWP will be monitoring is included below:
F&E detection activities record
Field 171 Date Fraud activity initiated
Field 173 Code 1 = High risk score referral from HBMS
Field 174 Y’ Full review
Field 175 Date Fraud and Error detection activity completed
Field 176 Outcome
Change record:
Field 50 Weekly HB entitlement after the change.
Field 248 New weekly HB entitlement after the change
Field 251 Date LA first notified of change in claim details.
Field 253 Date change of details are effective from
Field 254 How was the change identified (=8 LA review)
Field 255 Date supersession decision was made on the HB claim
Field 320 Unique T-record identifier
Error record:
Field 320 Unique T-record identifier
Field 337 Total value of payment error
Field 338 Weekly benefit discrepancy at start of payment error
Field 339 Start date of payment error period
Field 340 End date of payment error period
Field 341 What was the cause of the overpayment
- Councils need a way to carry out a FCR
- They need to be proactive in ensuring that those high risk cases are reviewed and customers respond
- They need a way to distinguish this from a regular change in circumstances so that when the officer makes a decision in the back office they know to record it properly so that the monthly data extract (SHBE) reflects the work they've carried out.
To help with this IEG4 has completed a specification to illustrate how we could help councils with this.
First, we will create a duplicate of the eChanges form. But, to ensure the citizen proactively identifies areas that have NOT changed, we replace the current 'What has changed page' with a new Claim Review page. This will be presented when a person passes the authentication stage. I.e. currently when a person has found their claim it presents the screen on the left (below). When they press next it takes them to the page - What has changed? as shown on the right:
One could argue that simply replying ‘No’ to all of the questions (on the right) would achieve the same as a full case review but the user has not had to proactive view what’s currently held and state that no items have changed.
But because, the current eChanges form will not actually allow a person to submit the form without having reported at least one change, it cannot actually provide a review function per se. Only the means to say something HAS changed.
The suggested enhancement here is therefore to create a new version of eChanges form hat includes a new page called:
Review your Claim
This will use the existing ClaimDetail retrieved from Northgate, Capita, and Civica to present a personalised, user friendly and quick to complete review process.
When we ‘speak’ to the back office benefit system we are passed data in the national benefit schema ClaimDetailsResponse. This means we always know the structure of the data and so can design the page to mirror this but take into account the ease of use for the customer.
Claim Detail is structured like this in terms of what’s relevant to the claimant for review:
- Property
- Rent (this includes the rent and service costs)
- Household
- Household Members
- Statuses (e.g. Student)
- Earned Income (this includes earnings and self employed info)
- Unearned Income (this includes benefits / tax credits / pensions)
- Capital (this includes bank accounts/stocks/shares etc.)
- Expenses (this includes child care costs / private pensions)
The following illustrates the suggested design with different sections presented that represent the various sections of data. Note that the purpose of this page is for the customer to indicate if anything is different - not to report changes. The existing functionality of the eChanges form will be used for that.
Your Home (property/rent)
This will show details of their current address and rent amount (If they have Housing Benefit):
- If they have changed address we will automatically take them down the report a move journey of the form.
- If they have change in rent only, we will take them down the change in rent journey of the form
Your Household
This will list details of those currently held on the claim. The date of birth is to make it simpler to identify the correct person if two people (father/son) have the same name:
If they say the list is not the current list of people living with you we will ask:
- Has someone moved out?
- Has someone moved in?
Based upon the answers we will take them to the correct pages in the CIC form. Obviously they have to select one if they say the list is different.
Statuses
This will list details of any statuses.
Because there are statuses beyond the scope of what the CIC form does we should take them to the page to end student status if applicable and if a status is anything else take them to the other change page of the CIC form.
Household Income
This will list incomes a person has. If we have a description e.g. the Employer Name ASDA in the screenshot below we should provide this. For earned incomes, the number of hours worked matters and so this should also be present.
If the income has change then they will be taken to the Change in Income page of the CIC form.
If the income change includes a private pension change then they should be taken to the change of pension page too.
Savings
If the Capital type is provided e.g. Natwest we should provide it. If a description is provided we should add it to the table.
If there is a change the user will be taken to the CIC change in capital page.
Expenses
The following illustrates the expenses page. This purposefully has nothing present to illustrate that where there is not something we should still show the area to allow the user to indicate no change.
Where there are expenses details of these should be listed against the person with the amount paid and frequency like the incomes.
Where the user indicates a change they will be taken to the expenses page.
Summary
When a user gets to the end we should summarise the areas they’ve reported a change within.
If they’ve had no changes we should provide a message stating:
“You’ve indicated that there are no changes to your current circumstances”
So the clone of the form only will be called Claim Review and will not go to the WhatHasChanged page (unless this makes sense to do so from a code perspective).
Additional Automation and monitoring function
This would be as follows:
- High Risk Case file imported
- Northgate searched for email/mobile number for each claim identified
- Where an email/mobile is found an automated message is sent to them with a link to the online form via email/SMS using GOV.UK Notify
- Where no email/mobile is found a letter is generated and posted via GOV.UK Notify
- The process then tracks these claims for a set period of time the council specifies.
- If a form is not completed the claim is automatically suspended
- If a form is completed and there are no changes the process ends and the form is pushed into the EDMS with a document code reflective of this
- If a form is completed and there are changes this is pushed as a CIC to the back office application and the EDMS with a document code reflective of this for review (along with any supporting evidence)
- A log of whether there were changes/no changes is available for the council to see the outcomes