Can't close case file in 188.8.131.52
When closing a case, get an error saying "The value '## Days' is not valid for TotalElapsedTime."
Reason left housing for Housing History
I had often thought that extra information about why a non-shelter housing history record ended would be helpful. For example, if a user adds an end date to “Rental at Market Price” a field could appear that said “Reason for Ending housing Record” or something like that. Then they could say things like “eviction”, “moved to other housing”, “signed an N11” or whatever.
Referred to is missing on Book Out
The Reason for Discharge field is missing on shelter Book-Out, if you have the Geographic Region Filter disabled. It shows if you have the Geographic Region Filter enabled.
Book-Out leads to Add Housing History
When a client does a book-out, the Reason for Discharge field is mandatory. If the user selects one of the housed options, like "Housed - Independent" for example, HIFIS should automatically be adding a Housing History record. Here's what I'd like to see: A user does a book-out and on the Book Out screen, selects a housed option in reason for discharge The user clicks save HIFIS detects that one of the "housed" options has been selected, and redirects the client to the Add Housing History screen The Add Housing History screen should automatically enter the start date = the date of the book-out The Add Housing History screen should automatically select the Housing Type (looked up from the Reason for Discharge) The user can then add the rest of the details and hit save. This would go a long way to ensuring that housing status and housing transitions are being calculated correctly, and make the CHR have better data, and result in less work for shelter staff.
Duplicate records in HIFIS_Client_Services for Diversion
Editing a Diversion record results in duplicated records in HIFIS_Client_Services. This is a bigger issue than it would seem due to https://acreconsulting.canny.io/hifis-4/p/save-diversion-attempt-returns-to-edit-screen and then subsequently https://acreconsulting.canny.io/hifis-4/p/canceling-the-edit-diversion-makes-it-abandoned
Client Bulletins List bug
The Client Management - Bulletins list does not work properly when a client has more than 10 bulletins. Attempting to view any bulletin after the 10th bulletin will open it in a new window that is missing the HIFIS Application interface. Steps to reproduce: Log onto demo.hifis.ca . Open the client profile for client Wendell Conrelius (ClientID 3004). Click Client Management and select Bulletins. On the Client - Bulletins List, click the Next button to move to Page 2. View the Bulletin on Page 2. This bug impacts HIFIS Version 184.108.40.206.1 and 220.127.116.11 HIFIS Support ticket number for this bug: 13139.
Blank service DateEnd for Diversions
When a Goods & Services record is attached to a Diversion record, HIFIS_Services.DateEnd is NULL.
Add Goods & Services in Diversion fails to save
When I try to add a Goods record OR a Services record while completing a Diversion - either the Diversion Workflow, or from the Edit Diversion screen, it fails to save if Programs are a mandatory field for Express Goods / Express Services.
Encampments mixes up two concepts
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.
History of chronic homelessness is missing
If a client was chronically homeless but isn't anymore, say if they were in shelters from Jan 1 2022 to July 1 2022, then the records relating to chronic homelessness disappear. I would expect there to be a record saying that they became chronically homeless on, say, July 1 2022 (ish), and then another record saying they stopped being chronically homeless on, say, January 1 2023 (ish). So I'd expect to see two records here. What I'm actually seeing is, if the client is still chronically homeless, there'll be a record saying that they became chronically homeless on July 1 2022. But if the client is no longer chronically homeless, that record gets deleted, so there is no record that they ever were chronically homeless.