HIFIS 4

Adding a person to an Encampment does not keep the client active

I have noticed that while the housing history determines a client's housing status based on the housing type, there is no such determination made when the client has a stay. In particular, some shelters might be transitional, which should have the client's housing status be listed as transitional, not homeless. When the client's most recent record is a stay, it should look up the service provider type to determine what the housing status should be. Some of the service provider types are things like "supportive housing" and so if they were using the admissions module for their housing, for some reason, the client should be listed as housed, not homeless or transitional.

In Version 4.0.59.7 and 4.0. 60.1 users are no longer able to manually select the actual bed/room that clients. The decision making process that HIFIS now uses is resulting in the wrong bed/room/ location being chosen which is not accurate and is impacting our statistics and the shelters understanding of where specific clients have been over the course of weeks/months. Support Desk as informed us that: "Removing the bed name from the historical stays was a strategic move on the developers side. The Change was made because it was causing other issues for users being unable to create historical stays if a client was already booked in, causing them to have to be booked out in order to create a historical stay. HIFIS will choose a bed based on the following criteria: 1. Does the SP have active beds over the stay's entire date range? if no, return error stating no beds exist 2. if beds exist for the whole historical stay period... Does Client have other stays? Pick the bed they used closest to these dates, if available If no recent stays or recent bed is unavailable... Get list of available beds for the date range chosen if no beds were available over date range... Get list of all beds that existed for date range, even if already booked Force double booking.

What is an encampment? It's a group of tents together in an area that I can see when I walk down the street (or through the woods, or wherever). But an important aspect of encampments is that they change over time. Today, there might be 10 tents, next week there might be 15, and in the spring, there might be only 5 remaining. The point is that there are kind of two key data points here: where the encampment is and when. Now the Encampments module does contain both of these elements, but here's the problem: it's not possible for someone to pull the data in such a way that allows them to track a single encampment over time. Let's dive into this a little deeper: There's an encampment in Kingston called Belle Park. It's in the news, everybody knows about it. So I'm an outreach worker. I go to Belle Park and then load up HIFIS. I can create a new Encampment in HIFIS, name it Belle Park, and say there are 10 people there. And today is November 13. That's fine. But what happens next week? I come back again, and now there are 12 people. So I have two choices: I can edit the existing Encampment record, and replace the count of there being 10 people last week with a record that there are now 12 people. The single "Encampment" record can only store one population count. Or, I can create a new Encampment. I choose the latter. So now I've created a second Encampment record, it's also called Belle Park, and it has 12 people. But now what am I supposed to do about the dates? For the first Encampment record, am I supposed to add an End Date? Because there are still people in the Encampment. What am I supposed to do for the Start and End Date for the second Encampment? It's really not clear what you'd use the dates for, so I can foresee that you'd have like 20 copies of "Belle Park" that are all "Active" and have random dates associated with them that don't make sense. And the important thing is I can't roll them up, I can't categorize them so that I can track trends over time, because the Encampment field is a free text instead of a drop-down. So if I spell Belle Park with lower case versus upper case those count as different things, and maybe there might be other terms people might use like "Belle Park Encampment" or "Belle Island" or "Belle Tent Park" that once again are not the same. So the Encampments module is conflating two important but related concepts: The first is a physical location. The physical location of the Encampment. I would call this record in HIFIS an Encampment. Belle Park is the encampment, not Belle Park on November 13. The second is a population count on a date-stamp. This is somewhat like a PIT count. On Nov 13, we found 23 people. On Nov 15, we found 25 people. So you need a bunch of sub-records of counts, connected to the parent record. The parent record being the Encampment. I would call the sub-records Encampment Counts or just Counts or Enumerations.  You could conceptualize it like a Case file that has multiple Sessions within it; a Housing Placement has multiple follow-ups; etc.

When a client is booked in, you can enter a Housing History for the same date, allowing for multiple open records. However, you cannot create an additional Housing History Record when one is open, not related to shelter stay. This creates multiple open Housing History records. I booked the client into a shelter location. I then was able to create a Housing History record for the same timeframe. However, I was not able to create an additional Housing History entry, so I believe the Admissions module and the Housing History module are not communicating and allowing a duplicate entry.

Citizenship & Country of Birth. If you select Canadian Citizen - Born in Canada, then Country of Birth should automatically select Canada and you shouldn't be able to change it. If you select pretty much anything else, you shouldn't be able to select Canada as Country of Birth. Consents. You can have multiple active consents, including consents of different types. So for example, you can create a Declined - Anonymous consent, and then later create an Explicit consent, but that leaves the Declined - Anonymous one open. Reservations + Admissions. You can have a reservation for Client A and then when Client A arrives, you could book them in normally, ignoring the reservation, and then the same client has both a current bed and a reservation for one. Income. You can have more than one Primary source of income. Veterans. You can have a child veteran. Or you can have a veteran - canandian armed forces who is a refugee. Indigenous. Should ALL people identifying indigenous status be Canadian Citizen - Born In Canada? Or what happens if you have, say, an American with indigenous identity? Should they be non-indigenous? So maybe what should happen is you ask about citizenship first and then if they say born in canada, then the indigenous status question appears (like some other areas of the software where a field is hidden unless you do X). if they don't say born in canada, the value captured is automatically "not indigenous"? Overlapping Housing History records are possible. Overlapping Housing History and Stay records are also possible.

There's a logical error on the Group Activities List. You can create a Group Activity and replicate it for tomorrow, but the Group Activities list only shows by default current and past events. The only way to get it to show future events is to set the date filter to "All" because if you set it to something like "1 Week" it's actually showing the PAST week, rather than records WITHIN 1 week. I don't really care how this gets fixed but it's a common annoyance that often results in people believing that the replicate function isn't working and them replicating events like 2 or 3 times, and Group Activities cannot be deleted.

I'm having some difficulty with the Transitional housing status as it appears in HIFIS, in particular whether it counts as homeless or counts as housed. First of all, the transitional category is too broad, since it incorporates institutional situations (i.e. hospital, jail) as well as actual transitional housing, and communities might want some of these things to count as homeless and other ones to count as housed. However, the bigger issue I'm having is now that I've looked at it more, I'm realizing that it doesn't even matter whether transitional counts as homeless or counts as housed. So why have that setting at all? Especially since it's causing headaches for communities. First, let's ask the question, where does a client's housing status come up? Well, on the client profile, it lists their status as one of 5: housed, homeless, chronically homeless, transitional, or unknown. So in this case, it doesn't matter what setting the community uses. Where else? On the Coordinated Access module and related functions. But the CA module includes clients who are housed, chronic, and unknown. It specifically excludes those who are housed. So all this module is doing is checking to see, if the setting says that transitional counts as housed, then exclude it. But it seems to me that it would be simpler to just have a filter - there's lots of filters in the CA module already - and have the user generating the CA list to indicate whether they want to include or exclude those with transitional housing status at the time of generation. For that matter, I would suggest making it a multiple select field, and basically just say: show only clients with the following housing statuses. And then the user could use that one single field to indicate whether they want to show only chronic, or chronic + homeless, or chronic + homeless + unknown, or chronic + homeless + transitional, etc. Finally, and here's the big kicker. Days spent transitionally homeless do not count towards a client's number of days homeless in the past year/3 years, so they don't result in the client becoming chronically homeless. I know that there's debate as to whether it should or shouldn't. But my logic is: if a community says, yes, in my community transitional definitely counts as homeless then shouldn't the days they spend being transitional actually count as homelessness? I don't have a specific action that I want taken as a result of this email. I just know that you guys are currently reviewing things like transitional housing, the category for Reaching Home and the RROL report (and hopefully reviewing my other comments about chronic homelessness status and unknown housing status!), and so I thought I'd add this to the pile while you consider.