What's up with the Geographic Region field on the Client Vitals screen?

Communities ask me all the time about the Geographic Region field on the Client Vitals screen.  All. The. Time. Not sure what I'm talking about?  There it is below, when you add a new Client.

There are really two questions I get asked:

1. Why does it say things like "This Community" and "This Region"?
2. What exactly are we supposed to select?

In summary, you're expected to modify the Geographic Region drop-down menu to include relevant regions for your local area. Then, when you add a client, select the Geographic Region that the client lives in.

Diving Deeper

This seems straightforward enough, on the surface. However, all sorts of additional questions get asked in practice. For example:

• Do I use the client's current residence or last permanent address?
• What if the client is just passing through?
• What if the client is in one region, and they receive services there, and then they move to a different region, and continue services?
• What if the client is in one region, but hopes to find housing in a different region?
• How big should regions be? For example, can I have different regions for "downtown" and the "west end"? If so, how does that impact what Geographic Region to put on a client's vitals page?

These are all perfectly valid questions. If you're asking these very same questions in your community, then congratulations! That means you're thinking critically about data quality.

To answer these questions, the first thing you'll need to do is ask another question: what data do we need? What do we need it for?

For example, you might want to know something like "are the people we're serving local, or are they coming from other nearby cities and towns?" Or, you might want to know something more like "which areas of my catchment area have lots of homeless people who are being under-served?"

Notice that these two different ways to frame a community's data needs result in two different perspectives. The first is concerned about where clients were previously, while the second is concerned about where clients are now. Therefore, two different communities with different data needs might come up with different ways to use the Geographic Region field.

Need for Standardization

Regardless of what your data needs are, it's really important that this particular field be filled out consistently by all staff.  If staff at one agency use the Geographic Region field to indicate where a client is right now, and staff at another agency use the same field to indicate where a client's last permanent address is, your data is going to be a mess, and nobody is going to know what it means when it says that a client's Geographic Region is "Kingston." Does it mean they're currently in Kingston? That's where their last known address was? Last permanent address? Is it where the client wants to find housing?  Where they were born? All that we know is the client has some connection to the region of Kingston.

Helping With the Data Problem

The situation is not all bleak and grim, however. There are two important additional sections in HIFIS that we can use to improve our data situation.

The first is Country of Birth. On the Client Vitals screen, we can also provide information about where a client was born. The Country of Birth alone is not terribly useful, but if we select "Canada" or "United States," additional fields will appear that will allow us to specify the Province/Territory/State, and also City of Birth.

The reason this is important is because there is much more clarity on what value should go in this field. There's no ambiguity as to whether it's a current or past value.  Each client can only have been born in a single location, so there is a correct value for each client. It's not open to interpretation.

A slight limitation with this approach, however, is that while you can make the Country of Birth field mandatory, you cannot make the Province/Territory/State or City fields mandatory.

Housing History

Another really important tool in your toolbox that helps towards understanding where clients are and have been is the Housing History module. If I haven't stated it enough times, this is one of the modules that every community should be filling out 100% of the time!

The really important aspect of the Housing History module is it attaches dates to clients' residential information. So regardless of what your data needs are, you can almost certainly solve them by keeping an accurate Housing History for each of your clients.

A Housing History record includes:

• A housing type (e.g. rental, group home, campsite, correctional facility, living with parents, etc.)
• A date range that the client was living there during
• Locational information (e.g. address, city, province/territory/state, country, postal code, geographic region)

Having a thorough Housing History for clients therefore lets you answer questions such as:

• What is the client's most recent permanent address? We would check for housing types that count as permanent housing, and look for the most recent date range.
• What was the most recent city or geographic region that the client was in before they entered our system? We would find the most recent date range before the client's intake, and look at the city or geographic region for that record.
• How long as the client been residing in our community? We can look at all of the Housing History records that have the city(s) or geographic region(s) we're interested in and calculate the number of days from when they first started living here and when they stopped (or today, if they're still living here).
  
• Is the client homeless, housed, or transitionally housed?
• If they're homeless, is the client chronically homeless or just homeless?
• What types of housing are we seeing prior to clients entering homelessness?
• Can we divert clients to previous housing arrangements?

Back to the Geographic Region Field

Between Country of Birth and the client's Housing History, we should be able to answer all of our geography-related data questions. So let's return to the original question at hand: what to do with the Geographic Region field on the Client Vitals screen?

Considering that we previously discussed how important it was to have consistency, that is part of the answer. In your community (or at least in your cluster), you need a community-wide definition of what should go in that field. In practice, here's what that might look like:

• We have an intake form that every service provider in our community uses when we are adding a new client to HIFIS
• This intake form tells staff what information they need to collect. For example, beyond the information on the Client Vitals screen, it might also ask for income and housing history information.
• This intake form has a single, specific question about geography. Staff are instructed to record the client's answer in the Geographic Region field. This question might be: 
  • "In what city or town did you spend the night last night?"
  • "Where was your last permanent address?"
  • "What community do you call home?"
  • "In what region are you seeking permanent housing?"
• We also have made the Geographic Region field on the Client Vitals screen mandatory, so we know staff are asking this question and putting data in to HIFIS.

You would then also need a policy on when the field is updated. For example, should the field get updated every time the client books in to shelter? Or only after a period of inactivity? Or never?

Why Bother, Then?

Of course, there is one more possible answer to the question "what do we do with the Geographic Region field" - nothing. You could decide, as a community, to disable the field. That way there's no confusion at all about what should be entered in it. Just be sure that you're able to answer your community's data needs through other methods.

However, there are a few reasons why the Geographic Region field is useful or valuable to keep:

• It's on the Client Vitals screen, which means most staff will see it first thing when they load up a client file
• Because it's on the Client Vitals screen, and it can be made mandatory, you could ensure that you have a value for 100% of your clients
• There is only one value, and it's easy to access and change, which means that things like reporting are easier. You could easily run a report that counts the number of clients in each Geographic Region - something that is a bit trickier when you're using a client's Housing History, and they might have moved around a lot.

Conclusion

Having standardized policies and definitions helps everyone in the community understand what it means when they see a value in a particular field. It also helps with data quality, so that your administrators can be confident about what they are reporting on, when they inevitably are asked a question related to the geography of clients.