Over the past decade or so, conversation about homelessness data has focused a lot on the By-Name List (BNL). Let’s make sure all the people we know of who are experiencing homelessness are on the BNL. Is Bob on the BNL? What date did Sally get added to the BNL? How many people are on our BNL right now?
There’s absolutely nothing wrong with the idea of having a By-Name List, except for one thing: it’s very binary. Either a person is on the list, or they’re not.
But in the world of homelessness, there’s a lot of grey area. Like a lot. 50 shades of it, maybe. Consider:
Jessie has been homeless for years, but she’s recently been hospitalized. She’ll be homeless after being discharged, but no one can say when that will be.
John has really complex needs and is currently housed in interim housing to get him off the street, but it’s not a permanent solution. He’s not homeless, but he will be if he can’t access supportive housing soon.
Jen is living with her “boyfriend” with whom she engages in survival sex in exchange for a place to stay for her and her son. She doesn’t think of herself as homeless because she’s not on the street or in a shelter.
There’s that angry guy everyone knows is living under the overpass, but he refuses to engage in a civil conversation with anyone, so we don’t know his name. Definitely homeless, though.
Julia has stayed at the low-barrier shelter a few times, but she always shows up in the middle of the night and she’s never sober. We haven’t been able to complete an official intake for her or get informed consent from her. We see her about once a week, but nobody knows where she goes the rest of the time.
Our team housed James several months ago, but he’s had some unwanted houseguests that have decided to take over his apartment, and now he’s back to spending time in the shelter, even though we know he has an apartment.
Jeremy has been staying in the shelter for years, and thinks of it as his home. He’ll happily fill out any form you ask him to, and readily provides consent for you to collect his information, share it with other providers, and receive services. But any time anyone tries to help him find housing, he misses appointments, sabotages efforts, and has made it quite clear that he is not at all interested in moving out of the shelter.
So, you tell me. Out of the people above, how many of them would you consider to be “on your BNL”?
Yeah. Tricky question, I know.
The answer that makes the most sense here is “it depends.”
If you want to count absolute homelessness, you probably wouldn’t count John or Jen. You would count that angry guy, and Jeremy too. Jessie, Julia, and James could go either way. Maybe some communities would count them and some wouldn’t. A PIT Count would count Jessie as homeless. You’d probably count James, since he’s currently in a shelter, but maybe not.
If your definition of homelessness was broader and included hidden homelessness, you’d probably count Jen too.
If your goal is advocacy, to show that homelessness is a crisis, you’d probably include all of them, even though some of them aren’t technically homeless.
If you want to count the people you know by name, you’d probably take your previous count and remove the angry guy. But this probably isn’t a useful metric, even though that’s what is implied by having a BNL (one reason knowing them by name matters is in de-duplication) (but that’s not the only reason).
If you want to count the people who are homeless and have consented to you collecting information about them, you’d take your previous list and remove Julia.
If you want to count the people who want your help in accessing housing, you’d count Jessie, John, and James for sure. You’d probably count Jen too. However, several of these are not experiencing absolute homelessness, so they might not have been on your previous list.
If you had a housing unit available for someone from your BNL to move into tomorrow, and you wanted to generate a list of people who should be considered, you couldn’t consider Jessie, because she’s not available for housing tomorrow. You wouldn’t consider the overpass guy, because he won’t accept the help. You couldn’t consider Julia, because she hasn’t consented and you don’t know enough about her. You wouldn’t consider Jeremy, because you know he will refuse. That leaves John, James, and Jen, who are all somewhat housed, and might be excluded from this list for that reason, depending on how your community does things.
Hopefully, you should be able to see why just considering a client “on the BNL” or “not on the BNL” is a little bit problematic.
Concentric Circles
So, what’s a community to do? How do you make any decision about anything when the answer is just “it depends?”
A helpful concept you can borrow is the idea of concentric circles. The following image is borrowed from the Reaching Home Coordinated Access Guide, and illustrates this concept.
Instead of having just one list, one By-Name List, you are applying different filters to get to a narrower or broader definition, depending on your purpose.
Level -1: Universe
Yeah, so this one isn’t on the above image. The largest circle you could possibly have is the total universe of everyone experiencing homelessness. However, this is virtually impossible to actually quantify, manage, or do anything with, so it’s purely hypothetical. Imagine everyone in your service area that’s experiencing homelessness, including the people you don’t know about and the people who are never going to interact with your homelessness response system.
From our previous examples, the “angry guy who lives under the overpass” is someone who definitely exists in this circle, but not any other circles.
Level 1: Aggregate
The largest circle that you can possibly have data for is the aggregate level, which includes everyone experiencing homelessness that have connected with the housing and homelessness response system. If they haven’t connected with your system, you can’t know about them. If you don’t know about them, you can’t have data about them. If you don’t have data about them, you can’t count them. So this is the largest possible number you can get about homelessness in your community.
A great example of someone in this circle and not the smaller ones is Julia (at the low-barrier shelter), who has connected with your system but hasn’t consented to anything else. We know about her, and we know her first name, but we don’t know enough about her to know if she’s the same Julia that goes to the drop-in centre in the east end.
In HIFIS language, this list is almost equivalent to doing the following:
Take all clients in the database
Filter to only include clients that are active
Filter to only include clients that are homeless*
(* Because HIFIS has some idiosyncracies, you might also include clients who have unknown housing status. You might also include people in public institutions who are known to otherwise be homeless. And your community might consider clients currently in transitional programs to be homeless, or you might not. But moving forward, we will just use the term “homeless” to capture all these possibilities. It’s shorter.)
I say almost because there could be some other people, some non-consenting people who you can count during an anonymous PIT count event, but who refuse to have any personal data about them entering HIFIS. So, your data in HIFIS might be a small undercount of this level. That being said, we aren’t yet able to de-duplicate our clients, so we might be counting some people multiple times, resulting in an overcount of this level.
Level 2: By-Name List
Our next biggest circle is the by-name list level, which includes everyone from the aggregate level who have provided consent to be on the list. In other words, they’ve agreed for you to collect data about them, for you to refer them to other service providers as appopriate, and to receive services.
Jeremy (who lives at the shelter) is definitely in this circle and not in a smaller one. As you’ll see in a minute, the next layer has to do with interest, and Jeremy is definitely not interested in moving out of the shelter.
In HIFIS language, obtaining this list means:
Take all clients in the database
Filter to only include clients that are active
Filter to only include clients that are homeless*
Filter to only include clients with Explicit (or higher) consent
Since we’re now talking about people that have provided consent, you should have data about them in HIFIS. So, if you’re using HIFIS across all your service providers and your data quality is reasonably good, this is the biggest circle you can measure with a degree of certainty. In other words, you should be able to pull this from HIFIS relatively easily.
Having everyone listed by name means you can identify and remove duplicates, which is extremely important. It’s well known that some people experiencing homelessness move from service provider to service provider and could potentially be counted dozens of times if you ask each service provider individually how many people they know to be homeless. At this level, we can at least attempt to identify and remove clients who have multiple files.
Now, what’s the purpose of this list? Well, as I mentioned, it’s the most comprehensive list you can pull from HIFIS (or your equivalent HMIS), so this is often used to measure homelessness in your community. Does it include everyone? No! As we already covered, there are two larger circles that are basically uncountable. This is the biggest list we can generate that could be accurate, so it is most commonly used to get real-time data to understand how many people are homeless in your community.
When we measure things like inflow (how many people became homeless) and outflow (how many people exited homelessness), we’re usually talking about people being added to and removed from this circle. Are there reports that count inflow and outflow differently? Yes. But this is what makes the most sense. If you use this definition to count homelessness, it makes sense to count people who now fit this definition as inflow, and people who no longer fit this definition as outflow.
This is the level of data that the Community Outcomes Report (COR) looks at. It cares about activity, homelessness, and consent. So if you run the COR report and it tells you you have 200 clients, it’s telling you there are 200 clients in this circle. If you run the COR and it tells you there are 12 people new to homelessness this month, it’s telling you there are 12 people who are newly active, homeless, and consenting.
Level 3: Coordinated Access List
We are narrowing down our list here from the by-name list, and now we’re only including clients who are eligible and interested in housing resources. Unfortunately, that’s a lot to unpack.
Let’s talk about interested first. As we’ve previously established, Jeremy is definitely not interested in housing resources. If you had an apartment available for move-in, you would definitely want to offer it to someone who’s actually interested in having housing over someone who’s not. However, this is something that’s a bit hard to measure, particularly when you’re looking at a database. There isn’t a single field that we can look at that says “interested in housing yes/no.”
Here’s what some communities do in HIFIS. To gauge interest, they use consent types. It’s not exactly the same thing, but a lot of communities simply have one consent form covering data collection and participation in the coordinated access system. So the difference between Explicit consent and Coordinated Access consent in HIFIS is unimportant. Some communities use the Coordinated Access consent to denote whether the client is interested and engaged with the coordinated access system. And to be honest, it makes sense. If a client is not participating in undertaking a housing search when resources are provided to them, they’re not really holding up their end of the agreement. You can think of coordinated access consent as “I agree to participate in the coordinated access system.” Not engaging with their caseworker is not participating. It’s sort of the same thing as them not providing coordinated access consent.
So, in HIFIS language, we’re now at:
Take all clients in the database
Filter to only include clients that are active
Filter to only include clients that are homeless*
Filter to only include clients with Coordinated Access consent
So that’s the Coordinated Access module. Or, if you have a custom report, something that pulls data from the Coordinated Access module view.
What is the function of this list? Well, it’s kind of an intermediate step to get to the next level, so by itself it’s not actually that helpful. But it is helpful to look at all the people who are interested in housing, but not in one of the next circles. If you take this list and exclude those are on the priority list, you have a to-do list for your caseworkers. They need to help everyone that’s stuck on this list and figure out how to get them to the priority list.
Level 3.5: Eligibility
But just wait. Didn’t the Coordinated Access List say something about eligibility. Remember, a client has to be interested and eligible to be here.
I’m so glad you asked.
Although there are potentially some global eligibility requirements, like being a legal Canadian resident, usually eligibility can be thought of as housing-specific, like:
Age-based - you often have to be at least 18. But some housing might be specific for youth, or specific for seniors
Gender-based - some supportive and transitional housing buildings might only accept some genders
Indigenous housing might only accept clients with indigenous identity
Veteran housing might only accept clients with confirmed veteran status
Arrears - most housing providers won’t let you sign a new lease with them if you’re currently in arrears with them
Then on top of that, there are some things that cannot be quite defined as eligibility requirements but are more like housing requirements, such as:
Accessibility - some clients require an accessible unit, or a building with an elevator, or no stairs, or something like that
Unit size - if you have a family of 6, you’re going to need at least three bedrooms
Pets - some clients have a pet they refuse to part with, and some housing units don’t allow pets
Supports - a client may require a moderate or high level of support, and need a housing resource that can provide that
Although they’re not quite the same as eligibility, if you offered a one-bedroom apartment to a family of four, they might turn you down. If you offered a 3rd floor apartment with no elevator to someone in a wheelchair, they’d turn you down. If you tried to house someone with very high support needs independently, that probably won’t go well.
So eligibility can be seen as a contextual situation - someone might be eligible for one housing resource but not another. Which makes it hard to count how many people are on this list. In fact, counting this list at all isn’t going to give you a useful number, so I wouldn’t bother.
What makes the most sense is at this point to start making different lists for different types of resources. For example:
A youth list
A seniors list
A veterans list
A family list
Of course you could have an endless number of lists here since there’s thousands of different combinations of eligibility requirements. So here are some things that make the most sense:
Option 1: just keep one master Coordinated Access List that has a bunch of different columns you can use to filter based on eligibility. Like a column for veteran if you have some veteran-specific housing, for example.
Option 2: keep a different Coordinated Access List for each housing resource you have. Depending on the size of your community, this might be a manageable number. For example, you have a supportive housing building for seniors, build one list that shows the clients who are eligible for that building.
Option 3: help me improve HIFIS! My next project involves housing matching and housing eligibility and client needs and preferences. It hasn’t started yet, but you can subscribe to a mailing list and we’ll reach out once we start working on it. Basically the goal is to be able to integrate housing eligibility requirements to client attributes, and then client housing requirements and preferences to housing units, so you can easily see in HIFIS which clients are a match for a given unit.
Level 4: Priority List
The smallest circle includes everyone from the previous circle who is able to accept an offer of housing resources immediately. Sometimes, this is referred to as being move-in ready, document ready, or housing ready (although there are plenty of people that don’t like those terms).
The function of this list is if you have an apartment that’s available, or you have a rent supplement available, or you have a caseworker spot available, and you only have one spot, you need to have a list of people you can pick from. You don’t want to offer the resource to someone that won’t be able to accept it for whatever reason.
One of the people from our previous example who’s not in this circle is Jessie, who’s currently in the hospital. We definitely know she’s homeless, chronically homeless even. But she’s currently hospitalized indefinitely, and unfortunately that means she’s not able to proceed with a housing move in if it was tomorrow. (She’d stay on the Coordinated Access List, and once she gets out of hospital she’ll be back on the Priority List, though.)
Other reasons why people couldn’t accept a housing offer include:
Not having ID, whether it’s lost or stolen or just they didn’t have it to begin with
Not having a source of income (even social assistance), so being unable to pay any rent
In jail or prison
In hospital, rehab, detox, or other medical facility
Whereabouts unknown - if you can’t track down your client to offer them housing, it’s hard for them to move in tomorrow
Now, this concept of move-in readiness isn’t really something that’s easy to track in HIFIS, because there could be a multitude of reasons why someone cannot accept housing. It’s not like there’s one field that we filter by. It’s hard to narrow down your Coordinated Access List to a Priority List accurately, and you don’t want to accidentally filter someone out who is move-in ready. So what communities often do is take their Coordinated Access List and use that as a Priority List, along with some notes about each client. For example, you might have a note that a client is expected to be released from prison on Thursday, or a note about a different client indicating that there was a housing resource available for them as of last Monday but no one has been able to find that client. Then communities kind of go through their top 10 people on the list and manually filter out the people they know couldn’t accept a housing offer.
Once again, it doesn’t really matter how many people are on this list - not really. You only really care about looking at the top five, or ten, or twenty people who are the best match for the available housing resource. So you really wouldn’t use your Priority List to count homelessness in any meaningful way.
By-Name Data
So where am I going with all this? Well, if you remember nothing else from this whole post, remember this: having a client be on or off “the list” shouldn’t be a binary. There’s more than one list, and that’s a good thing, because you use them for different purposes.
The Canadian Alliance to End Homelessness has switched their jargon in the past year or so, and now they’re talking about the importance of having By-Name Data (as opposed to having a By-Name List). Why? Because of exactly what I’m talking about here. Referring to “the BNL” makes it sound like there is only one list, and that oversimplification can result in misunderstanding.
Some communities count their Coordinated Access List and use that to say how many people are experiencing homelessness. That’s going to result in an undercount of homelessness. The true number is definitely going to be higher.
Some communities remove people from their By-Name List if the client isn’t eligible for housing, like if they’re not a Canadian citizen or permanent resident. Or if the client isn’t document ready. True those people shouldn’t be considered for housing, but they should remain on the BNL. This is like having a spork, trying to get one tool to do the job of two tools. It kind of works, I guess, but wouldn’t it just be better to have a spoon and a fork?
Some communities have a giant, single list, that pulls in so much data it takes ages and ages to get anything out of it. (Runtime is one reason why you need TWO reports for Coordinated Access). You don’t need to know about someone’s housing preferences if you’re counting homelessness, and you don’t need to know about non-consenting clients when you’re considering who should be offered a housing resource.
Some communities count inflow and ouflow from their Aggregate list but they use their By-Name List to count total homelessness. You’re counting apples and oranges and aren’t going to get numbers that add up. For example, if your By-Name List says you have 200 people experiencing homeless, and then you find another person who has not yet consented, and you count them as inflow, your math would say 200 + 1 = 200.
So, in conclusion (because this post is already pretty long), it’s probably a pretty good idea to understand that there are multiple versions of a BNL that your community might have.
And it’s probably a good idea to have the right tool for the job - use one definition to count homelessness, and a different definition to prioritize for housing.
Also, anytime you ask whether a client is “on the list,” stop yourself and ask: which list?
Comments