We are living through an interesting moment in HIFIS right now. There’s a perfect storm of several things happening all at the same time, and it’s making the journey towards good data pretty rough for many communities. What am I talking about, exactly? Let’s call it the activity problem.
For starters, let’s talk about the different ingredients that are coming together to make this problem a thing.
1. Communities have to use the COR right now
Since around April 2025, Reaching Home funded communities have been required to use the COR report to count homelessness in their community. Furthermore, the CAEH has been administering the HRIF funding program, and one of the things that HICC is requiring as a condition of that funding is for them to use the COR to measure homelessness (and thereby the success of the project).
However, since the requirement to use the COR is relatively new, we have communities that:
-
Used to use an Excel spreadsheet or other non-HIFIS source to report on homelessness
-
Used the old CAEH Monthly Inflow/Outflow Report to count homelessness
-
Used HIFIS, but had their own custom reporting tool that followed different rules
All three of these categories of communities are now seeing different numbers on their official COR report than what they were previously reporting.
Now to be clear: this is not the COR’s fault. I wrote the report (to HICC’s specs) and while it doesn’t do everything the way you might want it to do, it works as intended. It is not buggy or faulty or seriously flawed. There are some areas that the COR handles sub-optimally, but it’s a solid report that’s been through a lot of testing. Mostly, the differences between your previous numbers and the COR numbers come down to definitions; how it is programmed to handle certain things.
2. The CAEH is asking everyone to use the Health Check
Because most communities are getting different numbers when they use the COR to report than what they were previously reporting, the CAEH, as responsible administrators of the HRIF fund (and also for other reasons too), are interested in making sure the numbers they’re seeing on the COR are accurate. Enter the HIFIS Health Check, which is a report that was developed to assess data quality for the metrics that are specifically impacting coordinated access. Things like your prioritization list or the COR report.
Now you may have other data quality gaps, but the common one everyone is dealing with right now is a higher than expected number of active clients. Sometimes thousands higher than it should be. Of course, this looks really bad, doesn’t it?
3. There was a changing definition of activity
In 4.0.60.4, how HIFIS handled activity and inactivity changed quite significantly. Let’s take Case Management specifically. It used to be that opening a Case or adding a Session would count as activity, so the client’s date of last activity in a case file was the last time they had a session.
As of 4.0.60.4, simply having a Case file open kept the client active. So if a case file is open, the client’s date of last activity is today. This logic also applied to Housing Placements and Housing Loss Prevention records, and Admission records (but that wasn’t new), so basically open service records now keep the client active until they are closed.
Now for Case Management, this arguably makes sense. Caseworkers should be closing their Case file when they are no longer supporting the client. If the client disappears and they haven’t seen them in, say, three months, the client should be removed from their caseload, which means closing the Case in HIFIS.
For Housing Placements and Housing Loss Prevention, the logic is unfortunately a bit trickier. You see, in these modules, the service is considered still open until after you stop following up with the client, and many funders require you to follow up with your clients post move-in for 12 months or more. So, hypothetically, you could have moved a client in a year ago and they’re stably housed and not on your caseload anymore, but you still need to keep the service record open because of how HIFIS handles follow-ups. (That’s why we have a future HIFIS Improvement Project planned to address follow-ups!)
4. HIFIS doesn’t handle Case Management that well, anyway
On the surface, there shouldn’t be a problem related to Case Management. As we pointed out, caseworkers should be closing their Case file when they are no longer supporting the client. Which is true, except for the fact that HIFIS doesn’t really handle Case Management very well.
Why does that matter? Well, to answer that question we have to look at some specific impacts:
-
HIFIS doesn’t (or at least didn’t until 4.0.61.1) have an easy way for you to see your own Cases (you’d pretty much see all of the Cases at your service provider, or all the Cases for a given client). There was no immediate feedback being provided to Caseworkers telling them they had 40 open Cases when they knew they should have 25. The older Cases would show up on page 3 or 7 of the list and it would take effort for Caseworkers to seek out and close their old Case files. So even well-intentioned Caseworkers could easily forget to close their old files.
-
There was a bug that when closing cases, the End Date field was not mandatory. This bug was present for several years, which means that Caseworkers could have been diligently changing the Case Status field from Open to Closed, but not realizing that they needed to manually enter the current date in the End Date field. It’s now fixed, but old data isn’t corrected. Many communities could have a multitude of closed Cases with no End Date, which is read by HIFIS as being still open, which means the client is still active.
-
Because HIFIS doesn’t handle things like case planning or even note taking very well (see our list of ideas for improving the Case Management module), many service providers have expressed a preference to use a different software for their case management activities. In many communities, this has resulted in a negotiation where the HIFIS Lead established what was the minimum requirement for case management programs to enter into HIFIS, and in many cases that was “open a Case file to show you are working with the client, and close the Case file when you aren’t anymore.” Sounds simple enough, right? But if you’re not required to be in HIFIS regularly, it can be easy to forget to record updates. It’s way easier to remember to go into HIFIS once a month and add new case files for the people you started working with. But for the clients you haven’t seen in a while, it’s hard to remember to go in and indicate that you haven’t seen them in a while (which is why the whole inactivity policy in HIFIS was such a necessary addition).
Also, we should point out that until this current storm, there wasn’t really a pressing reason to keep your Case files in good order. It was acceptable to just do what was “good enough for now” while the community worked on other data quality issues.
5. The problem is hard to fix
So regardless of how we got here, the problem in a nutshell is that many communities have hundreds or thousands of open service records that should be closed. They might be willing to put in the manual data entry work of correcting it all, but… there’s another stumbling block: consent expiry and attestation.
If your community’s consent expires automatically, like after a year, then it’s likely that most of these problematic old services (say, ones that have been open for more than a year) belong to clients whose consent has already expired. If you have the Enforce Consent setting turned on (because let’s face it, you should), HIFIS won’t let you make any modifications to client files when their consent has expired, and that includes ending ongoing services. So you want to close a Case file, but the client’s Consent has expired, so you can’t.
(Note that I’m not advocating that you turn off consent expiry. If your consent doesn’t expire, those higher numbers of active clients are going to have a bigger impact on your system, as we’ll explore below. So if consent expires, harder to close case files. If consent doesn’t expire, bigger impact of open case files. There’s no win, so just do what your privacy people tell you to do about consent.)
It’s also hard to tell what services, specifically, need to be closed. You could go through module by module, service provider by service provider, and filter your records by whether they’re open, but that could take an age.
6. Did we mention the bugs?
Even if communities are doing everything right, HIFIS is unfortunately plagued with several bugs related to activity status right now. The short version is that you could be doing everything right and still have clients with the wrong activity status. Here are a few bugs we’re monitoring:
So what’s the cumulative impact?
This is actually a really good question and there isn’t a single clear answer. Is it inaccurate to have all these open Case Files, Housing Placements, and Housing Loss Prevention records when the client isn’t receiving services anymore? Yes. Is it bad data quality to have all these clients listed as active when we haven’t seen them in years? Absolutely. Is it going to completely mess up your COR report and your prioritization list? Well… maybe? But maybe not.
Let’s start with the COR report. When you run the report, the COR will only count clients who are Active, with a status of Homeless, and with active Consent all at the same time. If any of those is not true - consent has expired, for example, or the housing status is Unknown - then the client won’t be captured. We’ve already addressed that your active numbers are higher than they should be, but how many of these problematic active-but-not-really-active clients are active, homeless, AND consenting?
Your COR report will most likely only be giving you false positives in the following circumstances:
-
Your consent does not automatically expire or it has a longer expiry period, AND
-
You’re doing a great job of recording Housing History records for people who are currently homeless and not in shelters (and not end-dating them, because they’re ongoing), AND
-
You’re opening up Case files, Housing Placements, or Housing Loss Prevention records for these people, and not closing them.
Here’s an example: a client is couch surfing (Housing History record with no end date), and visits a drop-in centre enough times for someone to open a Case file for them. They have regular sessions for three months before disappearing. Pre-4.0.60.4 they would go Inactive at 6 months (90 days after the last session) but in 4.0.60.4+ they stay Active. However, their consent expires after 12 months, at which point they no longer show up on the COR. So they show up on the COR report 6 months longer than they should.
Is this a problem? Yes. But it’s actually not going to impact a big portion of your system. I could see some outreach teams being affected, and a few other day programs, but other case managment programs will be less impacted:
-
A housing-based case management program successfully houses someone and leaves the Housing Placement and Case files open. Sure they should close them, but the client is Housed which means they don’t show up on the COR.
-
A shelter opens a Case file for a client in shelter. After the client exits shelter, the case manager forgets to close the file. But the client’s housing status is now Unknown, so they’re no longer being picked up on the COR report.
What about your prioritization report? A lot of the same discussion applies, except that your prioritization report could very well be including clients who are Unknown, so you don’t accidentally filter someone out after they just left shelter this morning. So clients only need to be active and consenting and just not Housed to show up on your list. You could filter out the Unknowns while you’re prioritizing people, or at least have a policy to look at them more closely. Even if they were previously homeless, if a lot of time has passed, they might have once been chronically homeless and are no longer chronically homeless, causing them to become a lower priority. And if they are listed as “Homeless” and being counted as chronic due to an ongoing, open Housing History record, they’ll likely be at the top of the list continuously, and your coordinated access team will frequently be reminded to correct the data for the clients showing up at the top of the list.
Many communities also include a column on their prioritization list to identify if a client has been assigned to a caseworker (e.g. has an open Case file or Housing Placement), and they filter out people who have been assigned a resource. Communities might also have a column about assessment score, but it’s filtered to only show assessments within the last 6 months or year.
So are all these active files going to be impacting your prioritization list? Maybe a little bit, but only to a manageable degree. Remember, you don’t want to be using your prioritization list to count homelessness, so it kind of doesn’t matter how many people are near the bottom of your list.
In summary, your COR report and prioritization lists are likely going to be impacted by all these open files, but the impact is unlikely to be as bad as you think.
Unless of course your data is very messy. But if your data is very messy, you won’t be able to find any report that gives you good numbers. What do I mean by very messy? Well, how’s this for a mess: you have eviction prevention programs that open Housing Loss Prevention records and then never close them (they stay active forever). Some of those clients might end up in shelters. Your shelter staff open a Housing History record AND ALSO book them in using the Admissions module, because they were told at some point that this was the way to make shelter stays stay up on the Housing History screen, or maybe to make sure the gaps between shelters count towards chronicity. At the shelter, they also open a Case file (which they never close) and a Housing Placement record to indicate they’ve begun doing a housing search, but since they’re shelter-based caseworkers, they never visit clients after they’ve been housed so the concept of doing “Follow-Ups” for Housing Placements is foreign, they weren’t trained on it, and maybe even don’t have the user rights to add Follow-Ups, so all Housing Placements stay open forever. Some of these clients end up at day programs or food banks, and the staff there see at a glance that the client has a Housing Status of “Homeless” so they don’t need to do anything (they’re busy anyway, and someone must have recorded some housing data. It’s not like it says “Unknown!”) They open another Case file for the client… If you’re counting, these clients have 4 different things keeping them active forever, and an ongoing Housing History record with no End Date saying they’re Homeless (that shouldn’t even have been added to begin with). The only thing keeping these clients from being on your prioritization list or COR report forever and ever is whether or not your consent form expires, which… does it expire?
How do I fix my data?
So, you have a data qualtiy problem. But how do you go about fixing it?
First, identify the open services that need to be addressed. The time-consuming option is to go through service provider by service provider, module by module, until your HIFIS Health Check results are within acceptable parameters. But it’s faster to use a report. You could use this free report commissioned by the City of Hamilton to look at their open cases, or our Audit Boot Camp report: Stalled Open Files. Or, if you’re techy, you can run a version of this query:
SELECT cs.* FROM vw_ClientsServices cs
INNER JOIN HIFIS_Clients c ON cs.ClientID = c.ClientID
WHERE c.ClientStateTypeID = 1 AND cs.DateEnd IS NULL
Looking for a way to identify suspicious open files?
Check out our Audit Boot Camp report: Stalled Open Files!
Next, we recommend that you turn Attestation off, temporarily at least. Having Attestation turned on at this current time is going to make your job more difficult, due to how it interacts with consent expiry.
Finally, go through each service, one at a time, and take the following steps:
-
Open up the client file (not the service record) and check the current consent status. If it’s active (like, if it does not say “Inactive”), skip to step 5. Otherwise, go to step 2.
-
Navigate to Client Information > Consent
-
Locate the most recent Explicit Consent record, or Coordinated Access + Explicit, and click the Edit button.
-
Copy the Expiry Date to the Comments box, and then clear the Expiry Date field. Click Save. The client’s Consent status will now become active.
-
Locate the problematic services for this client, and add appropriate end dates. Note that whatever End Date you add is essentially going to be their date of last activity. So if you add today’s date, today will be the date of last activity. (You probably want to backdate this significantly.)
-
For Case Management, edit the Case file, change the Case Status, then add an End Date.
-
For Housing Placements, if they have not yet moved in to housing, add an Attempt, and set it to “Final Attempt”
-
For Housing Placements, if they have moved in to housing, add a Follow-Up, and set it to “Final Follow-Up”
-
For Housing Loss Prevention, add a Follow-Up, and set it to “Final Follow-Up”
-
-
Repeat step 5 for each problematic service.
-
Theoretically, the Client Status should become Inactive. It’s possible that it won’t, for legitimate reasons
-
If you changed the Consent, go back to Client Information > Consent, re-edit the Consent record, and return it to its original state. The client’s Consent status will now return to Inactive.
Note: do not add a new consent. Some communities are tempted by this option, so we’re mentioning it here, but don’t do this! This is introducing fake data - creating a new data quality problem - to correct a different data quality problem. You’re shooting yourself in the foot here. It’s not possible to delete your new fake Consent record, AND adding a new Consent record counts as activity, so you’re setting their date of last activity to today, which is literally what you’re trying to correct. (Does it look like you’re being required to add a new consent record? You missed the first instruction, which was to turn off Attestation!)
Comments