HIFIS 4

Reports can get archived when the version of the report itself gets updated, but can I put in a request for a way to manually archive/delete reports our community doesn't use anymore? For example, the Unique Identifier List is also irrelevant now that 59 exists, and multiple of the new reports have 59 and 60 versions.

This might be new in 60.3

In 60.2 you cannot edit or delete a subsidy. When trying to edit, you get a "Loading" message that never clears. When trying to delete you receive an error in the right corner that says item failed to delete. Tested for both Housing Placement and Housing Loss Prevention. Added and secured a unit. Moved in Went to the Subsidy tab within the Housing Placement record and added a new subsidy Once created I used the edit option (pencil) to try and edit and it kept loading I went back to the record and tried to delete the subsidy and received the item failed to delete. Ticket #13401

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.

There’s an accountability issue: either staff can globally Edit a thing, or they can’t Edit any of a thing. What is missing is the ability for a staff to only be able to Edit their own things, or only Edit things that have happened recently. For example, I add a case note. Then I notice a typo, so I want to fix it. I should be able to edit my own case note within 24/48/72 hours. But 6 months from now I have no reason that I would need to edit this case note. The only possible reason I might have for wanting to edit a case note months or years later is to protect my butt because I’m being subpoena’d. But that’s the time that I really should NOT be allowed to edit my own notes. Similarly, what reason might a caseworker have for wanting to edit someone else’s case notes? It’s hard to think of a legitimate reason. So 6 months down the line, if a staff is editing somebody else’s case note, it seems suspicious. Maybe they’re trying to make that person look bad for some other unethical reason. What needs to happen is an authenticate/lock function. There’s a few ways this should happen. First (recommended): a time-lock setting. After X amount of time has passed, certain records cannot be edited. This is automatic, and possibly with a bypass for an administrator, supervisor, or manager (like Override Service Restriction). Second: logging a reason for edit. Third: having a “lock” or “authenticate” button that the user can click to prevent further edits. This might not be necessary with the time-lock setting, but it might be easier to implement. Now what parts of the software should this occur in? Case Management VI-SPDATs SPDATs VATs Potentially others; poll the audience. (Comment below!)

Here’s a big pain point: when you have a client with expired consent, but they’re in the middle of receiving services. Like, they’re booked into a shelter, or they have an open case file. I get that with no consent, the principle of you can’t modify the client’s information is good and valid, but there’s a problem I think where HIFIS is conflating modifying information and ending a service. So for example to close a case file, you need permission to Edit the case file, and you have to click the Edit button, which also lets you, say, change the caseworker or otherwise modify information. I think globally it would be helpful to have a separate right and button to simply close services. Like there’s a separate right and button to close bulletins. In Admissions, Book-Out is already a separate right. But there should probably be a separate right for CM and other modules like storage, subsidies, HPs, and any other ongoing service. Not saying that you couldn’t close a case file by editing it (in this proposed future), but to have a separate button that JUST closes it. Like with bulletins. Obviously, since this describes lots of different modules and cases, I’m putting it as a longer-term fix. Anyways, we need the ability to close services for clients with expired consent. Right now people tell me they are doing workarounds like: disabling Enforce Consent for an hour and then turning it back on, or editing the Consent Expiry Date to tomorrow then changing it back, just so they can close these services. Option 1: grant the Admin a permanent exemption to the Enforce Consent rule. The Admin can do whatever they like to client files, regardless of whether the consent is valid or not. Forever. Option 2: create a Database Maintenance option that’s something like “bulk expire all services for clients with expired consent” Option 3: just add these close buttons throughout the software Option 4: create an automatic process of when consent expires, also automatically close all services (this could be problematic if, say, a client's consent expires for a few days before getting reactivated, thought) Option 5: have a button or something on a client file, that says, bulk expire all services for this client. Maybe this can be like the Client Service Delete option.

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

Either forced or through Service Provider Mandatory settings.

Allow custom tables on user accounts