HIFIS 4

Issue related to the word limit or maximum string length in the Comments field. Specifically, the Comments field under the Consent. Has been submitted as an enhancement ticket to INFC. Currently, the length of the comments field cannot be changed.

I would like to see a specific button on the consent screen that just says “Withdraw consent” or “Expire” or “end” or “close” I don’t know what it should be called but all it lets you do is add an end date. In an ideal world, the user can choose the end date and add an optional note about it. (That note can just be the existing Comments field) This should be governed by a separate, new right. Separate from Edit. Why? We probably want most staff to be able to end a consent, but not edit the other fields. Furthermore, there’s an issue since consents are “owned by” a SP. If I consent at SP A and then I go to SP B and say that I withdraw my consent, the staff at SP B cannot end the consent created by SP A. So the ability to end a consent overrules who owns the consent record. I’ve noticed that some consent date fields are un-editable. It’s a bit weird. Like, if I added a CA + Explicit consent, it creates two records, and I can edit the Start Date for Explicit but not for CA. Now I’m assuming that this probably has to do with an accountability trail. We can let people add comments to a consent when they edit it, but they can’t change the start date. However, this does have problems like what if they signed the consent form yesterday but I only added the record today? I think adding the close consent button, which is separate from editing the consent, would be helpful. Then those un-editable fields can be editable again, but only by people with the right permission, which would probably be just admins at this point.

Currently, can't make the attachments field in Consent module mandatory or disabled.

Either forced or through Service Provider Mandatory settings.

In Admissions, you can book in multiple clients at the same time but they're considered distinct Stays; they're not tied together in the database in any way other than they were booked in at the same time. But you can book in unrelated people so simply being booked in at the same time does not indicate that you're in a family. You can look up whether a person is part of a family at the time of the book-in, or at some time during the stay, but the rules for this are pretty fuzzy. Is a stay a "family stay" if they were in a family at the time of the book in? What about if they got put into a family 10 minutes later, since a staff entered it in incorrectly? What if I'm a pregnant mom and a week after I book in I have a baby and now it's a new family? What if it was a family stay, but somebody left halfway through? The point is that every single report out there needs to reinvent the wheel when it comes to counting how many family stays there were In contrast, in modules like Case Management or Housing Placements or Turnaways, there's a primary client and then you can additionally add family members and they're kind of like secondary clients, I guess. So if you want to ask me the exact same questions about Housing Placements, I can easily tell you the family composition of the people we served in Housing Placements, because they all have the same ServiceID and HousePlacementID. So basically we need a way to be able to link household stays, on book in.

In my opinion, it should work like the Service Restrictions All | Current filter, where records show as Current if the End Date and Time are in the future. However, the way the Storage List works right now is that records only show as Current if the End Date and Time is left blank. If End Date and Time is filled in, even with a future date, a record won’t show with the filter toggled to Current.

Add a new mandatory field to Housing Subsidy called Subsidy Type. It would be a look-up table like any other. Here are some suggested default values: Rent supplement First & last month's rent Damage deposit Arrears payment Moving assistance Housing start-up The problem we're fixing: Right now, people can add a Housing Subsidy but there's no real way to break it down. Sure, you can use the mandatory Program for this purpose, but increasingly communities are using the Program field for things like funding source. So the program might be "Reaching Home" or it might be Ontario's "HPP - Housing Assistance" program. Then there's the Reason for Service field, which I've seen some communities trying to hack. They say the "Reason for Service" is "First & Last Month's rent" but since that field is shared with other modules, it's not an excellent solution. Besides, Reason for Service is also useful. We want to know how many people are getting evicted by their landlord so we're paying their arrears versus how many got the power cut off, etc. What I'm trying to say is there's really a third dimension. So either we're getting staff not using the module, or setting up their programs in weird ways to accommodate this, setting up their reason for service drop-down for this, or trying to require staff to add it as a comment in the free-text field, which doesn't lend itself to any analysis.

I am hoping for a pop up to occur when someone's consent is about to expire in X number of days. And in Administration of the installation there should be setting for how many days in advance of the expiry, the pop up should occur. Kind of similar to how HIFIS allows you to set an inactivity threshold, we would like there to be a setting for 'consent is about to expire pop-up threshold.'

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.

Although obviously people shouldn’t be collecting information for non-consenting clients, there is a big sticking point and that’s shelter use. Shelters need to report on bed nights and occupancy, and if they give a bed to a client who didn’t consent to information collection, they’re put in a difficult position. What to do? The options are: Book in the client Anonymous, Anonymous. But this client is still bound by the concurrent stays rules, so cannot be in two beds at the same time. If there are two non-consenting clients occupying any two shelter beds at the same time, this is a problem. Don’t record it in HIFIS at all. But then the HIFIS data is unreliable, and you can’t run a year-end report, or do a data export to INFC, that is actually true. And people might think the bed is available because HIFIS says so, so make inappropriate referrals. Create a series of fake clients, like Anon 1 and Anon 2, so they can be booked in concurrently. This is the option a lot of communities take, but it then causes a proliferation of clients named “Anonymous” or “Anon,” which makes the database messy and actually discourages users from getting real consent. Since this is really only a big problem in Admissions (concurrent book-ins), I propose a solution like in Turnaways: Add Anonymous Book-In. Same as the way Turnaways handle anonymous clients, but for the Admissions module.