60.4 Deceased Clients are inactive

in updating to 60.4 - all of our Clients that were previously deceased were marked as inactive. HICC is aware and is currently working on a solution 🤞

Activity status derived from audit log not service dates

There is an issue when determining when a client becomes active/inactive. It is derived from the audit log  but it should not be. So I just added a Goods & Services transaction. By all accounts, adding a Goods & Services transaction counts as activity. I added it to a currently inactive client, but I backdated the start date to a week ago. However, the client State Change History indicates that the client only became active today, and they should have become active last week.  I continue to suggest that activity should be determined from the HIFIS_Services table, not the HIFIS_AuditLog table for this reason.

Can't modify attestation text

On 60.2.1, go to Cluster Settings and modify Attestation text. Hit save. It should say green "Data saved." However, open the Cluster settings again and you will see that the change has not been applied.

Clients disappearing after consent expires

When a client that previously had Declined - Anonymous consent, but subsequently has an Explicit consent, and then the Explicit consent expired, the client will revert to being hidden from the previous Declined - Anonymous consent. The client can only be activated again by the original service provider. This seems to be related to a fix/new in 4.0.59.6 https://hifisfeedback.acreconsulting.ca/announcements/40596

Can not Edit or Delete a Subsidy

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

"Get New Reports" right causes unintended additional access

An admin staff I was working with was concerned that they could access reports that were "private" to only one service provider, while they were logged in somewhere else. So I tested it out and figured out the root issue. For context though, here's the steps to reproduce: Configure a CUSTOM report to only be visible at one Service Provider. In my screenshot above, the SP I have is "Region of Oz"Grant a user access to ONLY a service provider that is not the one selected above. Give them rights that include Log On, Display Reports, Generate Reports, and View Report Manager (but no other rights in the Report Manager category)Log in as that user. Go to the Report Manager and attempt to locate the report.Report should NOT appear, as expected (this is good)Now, modify the same user account and grant the right to "Get New Reports"Log in as that user. Go to the Report Manager and attempt to locate the report.The report WILL now appear, along with every other report that exists in HIFIS. I think that the Get New Reports right is probably intended to provide access to HIFIS Reports (not Custom Reports) that have not yet been deployed to the HIFIS instance. But I don't think it's supposed to grant access to Custom Reports that have been uploaded but are attached to other service providers a user doesn't have access to.

Reactivated Clients - 60.4

In 60.4 Clients are active way past the 90 day threshold (and are reactivated during the update) some of these clients have never had a service and are active despite being created years ago- causing the numbers of active clients to Spike. HICC is aware of this and is currently working on the issue

60.4 Deceased Clients are inactive

in updating to 60.4 - all of our Clients that were previously deceased were marked as inactive. HICC is aware and is currently working on a solution 🤞

Being booked at a shelter no longer refreshes activity daily - 60.4

Clients currently in shelter appear to not have their activity status reset every day if they are actively booked into shelter. So instead of 0 days, all clients who have been booked in shelter are showing last activity day as the day of the update instead of 0 days.

Editing Client Vitals sets Chronically Homeless Status to 'No'

When editing a client’s vitals in HIFIS 4.0.60.3 and 60.4, the HIFIS application sets the client’s Chronically Homeless status to ‘No’, regardless of the client's current Chronically Homeless status. This may cause the Chronically Homeless status of some clients to be reported incorrectly by the application. Ticket 14971.

Updating to 60.3 or 60.4 is slow

Updating to 60.2 is slow because 60.2 introduces a new script that calculates chronicity for all clients, and takes ages. But we would expect that updating from 60.2 --> 60.3 or 60.3 --> 60.4 should run more quickly, right? Turns out that the update scripts to 60.3 and 60.4 will re-run the chronicity script introduced in 4.0.60.2 causing unnecessary slowness during update.

Financial Profile records duplicating

In testing 60.3 we have found an issue with records duplicating under the Financial Profile area. This appears to be affecting all 4 tabs within the Financial Profile section. Whenever you add a record under Income, Expenses, Assets or Debts when there is already a record, the new record is added multiple times. For example, I added a “Employment - Casual" record under Incomes on client # 5624 on the demo site. Adding the first record seems to work properly.I then added a new income record for “OW” and two were createdI then added another new record for “Panhandling” which was created 3 times.Adding a fourth record for “Disability Benefits” resulted in 4 records being created

Case Management > View All Session Details Blank

In testing 60.3 we have found an issue with the “View All Session Details” button in the Case Management area. To see this, create a new case management record, or open a client that already has an open case management record, either from Front Desk > Case Management, or from Client Management > Case Management. Then Click on the Display button to view the details. What we expect to see here is a summary of all sessions attached to the case management record. In our production environment (v4.0.59.7.1) we see a summary of all sessions attached to the case management record.

Housing Status: Incorrectly displaying as "Unknown"

Known bug that happens a LOT! Clients show up as “Unknown” housing status even when there is data that should give them a different status! More detail in the comments.

Chronic Homelessness mismatch

We updated our production environment to build 60.3 on Wednesday and have noticed some inconsistencies between the “Chronic Homelessness Y/N” field from the CA module and what is reported under the new “Chronically Homeless” Yes/No field available on the client profile. We use the CA module in order to run our local prioritization, so it’s important that we understand how it’s working and why the Y/N fields aren’t matching with what HIFIS is saying for the client on their profile. This example client shows “Yes” for the new Chronically Homeless field on the client profile. Please see the relevant housing history for this client below as well. From the CA Module, looking for this same client, he is reporting “N” under Chronic Homelessness Y/N. Here is a query demonstrating the relevant fields: SELECT CA.ClientID ,CA.HomelessIn365Days ,CA.HomelessIn1095Days ,CA.ChronicallyHomelessYN FROM vw_CoordinatedAccess as CA WHERE ClientID = 125 I am attempting to troubleshoot to trace the issue back to the source, but I thought I would start by reporting it and provide a sample query to the devs to demonstrate the issue. SELECT CA.ClientID ,CA.HomelessIn365Days ,CA.HomelessIn1095Days ,CA.ChronicallyHomelessYN as CAChronicallyHomelessYN ,HIFIS_Clients.IsChronicallyHomelessYN as ClientProfileChronicallyHomelessYN FROM vw_CoordinatedAccess as CA INNER JOIN HIFIS_Clients on CA.ClientID = HIFIS_Clients.clientID WHERE CA.ChronicallyHomelessYN <> HIFIS_Clients.IsChronicallyHomelessYN The following query is currently giving us 126 results (with 1376 total results from vw_CoordinatedAccess). 69 of the 126 are showing Y for Chronic in the CA Module, and N for Chronic on the client profile. The remaining 57 are showing N for Chronic in the CA Module, and Y for Chronic on the client profile.

Duplicated Unknown housing status on client created date

I have a total of 36 clients. I found the issue for 7 clients including Anonymous, Anonymous, that's around 20% of clients affected. I tested the demo site and the issue is present for over 1200 clients. Here are some examples of affected clients: all clients between 2,881 and 2,895 inclusive; 2,723; 800; 259.... there's lots.It's always duplicated Unknown status. Every time. I haven't found a duplicated status that wasn't Unknown.It's always the same client becoming unknown a bunch of times at the exact same timestamp.The timestamp is the same timestamp as the client created date.There are always 77 copies of the duplicated unknown status. The number 77 probably has to do with something in my database. I tested on demo.hifis.ca and the number was 615. I don't know what I have 77 of and demo.hifis.ca has 615 of, but there's probably something. In 4.0.60.2.1

Rights to Client Vitals

When we assign rights to a user, either via individual rights or a Template, sometimes the rights related to client vitals don't apply properly. So in the section Client Details > Vitals, there are 4 rights. I commonly want to assign Add Vitals, Edit Vitals, and Display Vitals, but not Ability to Hide Clients. If I individually check off the rights, then the user won't actually have access to the Vitals tab. However, if I hit the "select all" parent right, and then remove Ability to Hide Clients, the rights the user has end up being exactly the same, but it works properly in that case. So there's something misconfigured, but I don't know what exactly. Here's a video: https://www.loom.com/share/405270bb37db481ebe414982f14f4c7e?sid=38ccf871-6bca-41c0-9216-819d63fc84de

Client Search not working as expected

The Client Search is really different than in our current production version (4.0.59.4). Is it working the way you expect it to? For example, to get to my client John William Test (Alias 1 Jonathan Silly Pants), it no longer works to search jo te or wi pa. john test doesn't work either, you have to type in test, john. But jonathan silly works. Is that by design? Absurdly, han sil works.

Diversion does not count as activity

Adding a Diversion record does not make a client active or keep a client active

Housed Safely Last Night missing from workflow

On the Diversion Attempt screen (one-page version) there is a field called "Housed Safely Last Night" However, I'm noticing that the same field is not present anywhere in the Diversion Workflow, not on any page. I believe it should be on page 3, which is about Last Night's Housing.

Group Activities not in Audit Log

This is a duplication of https://hifisfeedback.acreconsulting.ca/b/6vrrdwev/feature-ideas/actions-missing-in-audit-log but it’s important enough to merit its own post. When a client is added as an attendee in a Group Activity, there is no corresponding record generated in the Audit Log. However, adding the client to the Group Activity does count as activity, so the client’s date of recent activity is updated and if they were inactive, they become active once more.

Parent Service Provider only shows service providers in current cluster

On the Add/Edit Service Provider screens, the Parent Service Provider drop-down menu only shows service providers in the current cluster.

Display issue on HIFIS header on login screen

I noticed when I resized my browser, my v60 instance is no longer displaying aligned. My browser width at the time was about 980px.

Reset Password Link broken

In 4.0.60, when users are sent a password reset link, the host (first) portion of the URL is missing. For example, it will say: "Please click the following link to reset your password: /Account/ResetPassword/123456" Instead of the necessary: "https://acre.hifis.site/Account/ResetPassword/123456"

Editing Client Vitals sets Chronically Homeless Status to 'No'

When editing a client’s vitals in HIFIS 4.0.60.3 and 60.4, the HIFIS application sets the client’s Chronically Homeless status to ‘No’, regardless of the client's current Chronically Homeless status. This may cause the Chronically Homeless status of some clients to be reported incorrectly by the application. Ticket 14971.

Financial Profile records duplicating

In testing 60.3 we have found an issue with records duplicating under the Financial Profile area. This appears to be affecting all 4 tabs within the Financial Profile section. Whenever you add a record under Income, Expenses, Assets or Debts when there is already a record, the new record is added multiple times. For example, I added a “Employment - Casual" record under Incomes on client # 5624 on the demo site. Adding the first record seems to work properly.I then added a new income record for “OW” and two were createdI then added another new record for “Panhandling” which was created 3 times.Adding a fourth record for “Disability Benefits” resulted in 4 records being created

Case Management > View All Session Details Blank

In testing 60.3 we have found an issue with the “View All Session Details” button in the Case Management area. To see this, create a new case management record, or open a client that already has an open case management record, either from Front Desk > Case Management, or from Client Management > Case Management. Then Click on the Display button to view the details. What we expect to see here is a summary of all sessions attached to the case management record. In our production environment (v4.0.59.7.1) we see a summary of all sessions attached to the case management record.

Updating to 60.3 or 60.4 is slow

Updating to 60.2 is slow because 60.2 introduces a new script that calculates chronicity for all clients, and takes ages. But we would expect that updating from 60.2 --> 60.3 or 60.3 --> 60.4 should run more quickly, right? Turns out that the update scripts to 60.3 and 60.4 will re-run the chronicity script introduced in 4.0.60.2 causing unnecessary slowness during update.

Housing Status: Incorrectly displaying as "Unknown"

Known bug that happens a LOT! Clients show up as “Unknown” housing status even when there is data that should give them a different status! More detail in the comments.

Chronic Homelessness mismatch

We updated our production environment to build 60.3 on Wednesday and have noticed some inconsistencies between the “Chronic Homelessness Y/N” field from the CA module and what is reported under the new “Chronically Homeless” Yes/No field available on the client profile. We use the CA module in order to run our local prioritization, so it’s important that we understand how it’s working and why the Y/N fields aren’t matching with what HIFIS is saying for the client on their profile. This example client shows “Yes” for the new Chronically Homeless field on the client profile. Please see the relevant housing history for this client below as well. From the CA Module, looking for this same client, he is reporting “N” under Chronic Homelessness Y/N. Here is a query demonstrating the relevant fields: SELECT CA.ClientID ,CA.HomelessIn365Days ,CA.HomelessIn1095Days ,CA.ChronicallyHomelessYN FROM vw_CoordinatedAccess as CA WHERE ClientID = 125 I am attempting to troubleshoot to trace the issue back to the source, but I thought I would start by reporting it and provide a sample query to the devs to demonstrate the issue. SELECT CA.ClientID ,CA.HomelessIn365Days ,CA.HomelessIn1095Days ,CA.ChronicallyHomelessYN as CAChronicallyHomelessYN ,HIFIS_Clients.IsChronicallyHomelessYN as ClientProfileChronicallyHomelessYN FROM vw_CoordinatedAccess as CA INNER JOIN HIFIS_Clients on CA.ClientID = HIFIS_Clients.clientID WHERE CA.ChronicallyHomelessYN <> HIFIS_Clients.IsChronicallyHomelessYN The following query is currently giving us 126 results (with 1376 total results from vw_CoordinatedAccess). 69 of the 126 are showing Y for Chronic in the CA Module, and N for Chronic on the client profile. The remaining 57 are showing N for Chronic in the CA Module, and Y for Chronic on the client profile.

Pagination missing on Client Search

When you use the Client Search, results show but the ability to navigate to another page is missing, so if your search result returns more than X clients, they cannot be found.

Users are not able to delete diversion records from the Client Service Delete module.

Can't merge clients in 60

An error related to merging clients has been brought to my attention in v60. It looks like merging any two clients throws an error. Notably though, there seems to be multiple errors thrown, and it seems somewhat random which error message you get. I've seen at least 3 different ones.

Can't close case file in 4.0.60.1

When closing a case, get an error saying "The value '## Days' is not valid for TotalElapsedTime."

Date of Death

In 4.0.60.1, the Date of Death field is now, inexplicably, a drop-down menu that contains no values.

Edit Diversion shows different screen for workflow vs form

I'm not clear on, once you do a Diversion Workflow versus a Diversion Form, why the software remembers whether it was a Workflow or Form, and shows a different Edit form accordingly. First of all, this is unnecessary - the Workflow is only useful in the moment, and not helpful if you have to edit it for some reason. For example, maybe you want to change the Referred From field, because the client didn't disclose it initially. If you edit the "Diversion Workflow, it'll take you back to editing page 7 and you have to first remember what page the Referred From field is on and then navigate through all the pages back to it. That's cumbersome for the user. It also seems simpler from a development standpoint to store the data equally and not care how it was entered, much like how it doesn't matter if you do an "Express Goods" transaction or a "Goods & Services Transaction," the data is stored exactly the same and it looks the same after you've recorded it. So, in conclusion, there should be one consistent Edit Diversion screen that you get to when you hit the Edit button, regardless of which way the Diversion was recorded, and it should take you to a one-page form that has all of the fields on one screen.

Blank service DateEnd for Diversions

When a Goods & Services record is attached to a Diversion record, HIFIS_Services.DateEnd is NULL.

Follow-up on Diversion should not be mandatory

In the Diversion module, the "Scheduled Follow-up" field should be optional, not mandatory. For context, here's why it needs to be optional and not mandatory: First and foremost, because there is no option to actually do a follow-up in the Diversion module! This means that every single Diversion has either an "upcoming" follow-up or a "past due" follow-up, and they are flagged as requiring attention, but there's no way to dismiss the alert saying they require attention. Second, because not every Diversion requires follow-up. Sometimes a person is diverted by buying them a bus ticket back to their home community, in which case it might be difficult to follow up. And in other cases, it might simply be so clear that you're successful that a follow-up is not needed. Or, if you end up booking them into shelter, then you're going to be working with them in the context of them being a shelter guest and you probably wouldn't want to go back and update the Diversion record. Third, because neither the Housing Placement module nor the Housing Loss Prevention module, which seem to be being replicated here, actually require scheduled follow-ups, so it's inconsistent.

Canceling the Edit Diversion makes it Abandoned

If you Edit a Diversion sort of by accident, and then hit "Cancel" to say, oops I don't mean to actually change anything, it says it will set the status to "Abandoned" which seems counter-intuitive. The user has already created a Diversion attempt and saved it with a status other than "Abandoned," so the Diversion attempt was actually not Abandoned. But, in attempting to avoid overwriting data, the user could unintentionally overwrite the actual status of the Diversion, which seems backwards to me.

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.

Outreach List shows all Goods & Services/Group Activities

It has come to my attention that all Goods & Services and Group Activities are being now listed on the Outreach List, regardless of if they have a location or anything like that. This strikes me as problematic. There are plenty of times you would provide a Goods & Services transaction that's not Outreach, and same goes for Group Activities. It just seems a bit weird to have every single one of these transactions show up on the Outreach List, when many of them. As a very simple fix, I'd suggest perhaps that only Goods & Services and/or Group Activities with a captured Service Location should show up on this list.

Map view on outreach shows services for other providers

In /Outreach/ServicesList there should only be outreach services for the current service provider visible. On the Standard View (i.e. list) the correct services show up. On the Map View, it shows services for other service providers.

Chronic homelessness not working properly

In 4.0.60.1, clients are becoming chronically homeless multiple times, and also becoming chronically homeless at the wrong time.

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.

"Diversion workflow steps" shows to users without right

A user with rights to everything in the Diversion module (HIFIS Modules > Diversion) but without rights to anything in Administration (including Administration > Diversion Workflow Steps). The Administration menu appears for this user with the option Diversion Workflow Steps. When the user clicks on it, they get a "you don't have rights" error message. The bug is that the option should not appear in the Administration menu at all.

v3 VI-SPDAT rights are a mess

There's a new category for the latest versions, instead of putting them under the matching category as before Several rights are inconsistently named. VI-F-SPDAT vs F-VI-SPDAT and TAY-VI-SPDAT vs Y-VI-SPDAT Doubled up on Y-VI-SPDAT v2 rights and no VI-SPDAT v3 rights

Pagination missing on Client Search

When you use the Client Search, results show but the ability to navigate to another page is missing, so if your search result returns more than X clients, they cannot be found.

Client Search not working as expected

The Client Search is really different than in our current production version (4.0.59.4). Is it working the way you expect it to? For example, to get to my client John William Test (Alias 1 Jonathan Silly Pants), it no longer works to search jo te or wi pa. john test doesn't work either, you have to type in test, john. But jonathan silly works. Is that by design? Absurdly, han sil works.

New Diversion Module

New Diversion module, similar to that described in ACRE Consulting's report. https://www.acreconsulting.ca/feature-recommendations

Client Reservation List Add button

On the Client > Admissions List, when you click on Add Reservation, it actually takes you to the Edit Reservation screen in which you can adjust the Reservation Status, which you cannot do if you add a Reservation through the Front Desk.

Manage rooms and beds shows date twice

When a user hovers over a bed that is currently being used, the date and time field displays the date the client was booked into the bed twice and does not reveal the time of the book in.

Add VI-SPDAT v3 series

Document date

The date of documents associated to a client's consent or their barcode always reflects the actual date. Not the date the document was added to the file.

Issue deploying reports

I was doing some work for a community and noticed they had a bunch of reports that needed to be deployed. So I downloaded one of them and it promptly disappeared from my screen. I panicked a little, thinking I had somehow lost their report, then I figured it out. The problem is that when you download a report for the first time, it has all of the mandatory fields blank: no service providers can run it. It's not in any report categories. So no user can actually access it except for the root admin. However, it's not necessarily true that the root admin will be the one taking the action of deploying new reports. I've seen some communities where they reserve root access for just a DBA, and grant their actual HIFIS administrators their own named accounts (i.e. like "Aryder" instead of "Admin") and they might have all of the rights, so they really SHOULD be able to do everything. My proposed fix is this: Have a separate right that grants the ability to download and deploy new reports from the marketplace When somebody with that right clicks the appropriate button, instead of just fetching the report, they are also prompted to define the report categories and service providers for the report on the same popup screen That way, the same person who downloads the report has the ability to also add a description and define who can use it.

Incorrect behaviour adding consent post expiry

I'm not sure which things are intentional and which things are unintended, so that's why I'm writing out this list: A client who previously had CA + Explicit consent, after they expire, can add consent records. The options are Explicit (that's fine), Inherited (that's not logical). There is  no option to add CA + Explicit. A client who has only Explicit consent can add consent records. The options are Explicit (redundant, but okay), Inherited (that's not logical), and CA consent. A client who has Declined - Anon consent can add consent records. The options are Explicit (again, fine), Declined - Anonymous (again, fine), and Inherited.  No option to add CA + Explicit A client who has Inherited consent can add consent records. The options are Explicit (okay), Inherited (okay), and Coordinated Access (wait, what?), but there's  no option to add CA + Explicit. Philosophical question here. If a client is incapable of providing Explicit consent, since they're a minor and with their parents, should they be capable of providing CA consent? I thought that Explicit consent was a prerequisite for CA consent. I wanted to check because I was pretty sure there was an option to add bundled CA + Explicit consent after client creation, but then I haven't been able to find it. So, is it supposed to exist? Or just my imagination? If you want my opinion, it should exist, because for communities that have automatic consent expiry, they would then have to re-obtain both forms of consent at the same time since both expire at the same time.

Declined - Anonymous consent expiring

It's come to my attention that HIFIS behaves in a problematic way when Declined - Anonymous consent records are set to automatically expire. In general, Declined - Anonymous works fine so long as it remains active. When Declined - Anonymous consent expires then the protection offered by the Declined - Anonymous, i.e. not visible to other service providers, goes away. Except that in some communities, they have indicated that consent records expire automatically after X number of days. And generally speaking, when consent expires it's often because you haven't seen a client in a while and are unable to re-obtain consent, which is probably more likely for people who declined consent to begin with. Anyways, it seems to be an oversight that Declined - Anonymous consent offers privacy for clients that might automatically end, while the whole concept of automatically expiring consent is designed to protect clients into the future. My easy fix suggestion is when you have a consent expiry set, that should not apply to Declined - Anonymous clients. So even though your Explicit consents might expire after 365 days, when a user is adding a Declined - Anonymous consent, the End Date field should be blank to begin with. There could be a fancier solution figured out later, but that'll put a bandaid on the immediate problem.

Duplicate clients in CA module (Income)

If a client has two different incomes with exactly the same monthly amount, and both of those amounts are tied for the highest, the client will show up twice. Workaround : change one of the monthly amounts by adding a penny Related to: https://hifisfeedback.acreconsulting.ca/b/6vrrdwev/feature-ideas/duplicate-clients-in-ca-module-consent https://hifisfeedback.acreconsulting.ca/b/6vrrdwev/feature-ideas/bug-in-ca-module-first-episode https://hifisfeedback.acreconsulting.ca/b/6vrrdwev/feature-ideas/duplicate-clients-in-ca-module-first-episode https://hifisfeedback.acreconsulting.ca/b/6vrrdwev/feature-ideas/duplicate-clients-in-ca-module-families

Duplicate Clients in CA module (Families)

There's a bug in the Coordinated Access view causing clients to appear more than once, having to do with families. Related to: https://hifisfeedback.acreconsulting.ca/b/6vrrdwev/feature-ideas/duplicate-clients-in-ca-module-consent https://hifisfeedback.acreconsulting.ca/b/6vrrdwev/feature-ideas/duplicate-clients-in-ca-module-income https://hifisfeedback.acreconsulting.ca/b/6vrrdwev/feature-ideas/bug-in-ca-module-first-episode https://hifisfeedback.acreconsulting.ca/b/6vrrdwev/feature-ideas/duplicate-clients-in-ca-module-first-episode

Deleting services is problematic

Currently, when most records exist (for example, Turn Aways, Appointments, Incidents, SPDAT, VAT, Waiting List, client in a Waiting List, Income, Education, Contributing Factor, etc.), a user can navigate to the List page for that kind of record and click the Delete button in the Action column. However, this is not the case for many types of services. Several types of services, including Case Management, Goods and Services, Housing Placements, Housing Loss Prevention, and Food Bank, cannot be deleted from the List page or the Client List page. In order to delete them, one has to go to the Client Service Delete page. This is confusing because there's a user right to, for example, Delete Food Bank Record, and one to Delete Housing Loss Prevention, and one to Delete Housing Placement. A user might assume that granting the "Delete Housing Placement" right will allow a user to delete Housing Placements, but that is not the case. Instead, the user needs the Administrative right to Client Service Delete, and then if they have that right they can delete ALL services at ALL service providers. It makes much more sense to simply implement a consistent behaviour across the software: add the Delete button in the Action column to all types of records. But that's not the only deleting weirdness: Group Activities cannot be deleted at all. Calls and Visits Logs can be deleted from the Client - Call and Visit List, but not from the Call and Visit List. Storage can be deleted from the Client - Storage List but not the Storage List. Conflicts can be deleted from the Client - Conflicts List but not the Conflicts List. Service Restrictions can be deleted from the Client - Service Restrictions List but not the Service Restrictions List.

Declined - Anonymous consent expiring

It's come to my attention that HIFIS behaves in a problematic way when Declined - Anonymous consent records are set to automatically expire. In general, Declined - Anonymous works fine so long as it remains active. When Declined - Anonymous consent expires then the protection offered by the Declined - Anonymous, i.e. not visible to other service providers, goes away. Except that in some communities, they have indicated that consent records expire automatically after X number of days. And generally speaking, when consent expires it's often because you haven't seen a client in a while and are unable to re-obtain consent, which is probably more likely for people who declined consent to begin with. Anyways, it seems to be an oversight that Declined - Anonymous consent offers privacy for clients that might automatically end, while the whole concept of automatically expiring consent is designed to protect clients into the future. My easy fix suggestion is when you have a consent expiry set, that should not apply to Declined - Anonymous clients. So even though your Explicit consents might expire after 365 days, when a user is adding a Declined - Anonymous consent, the End Date field should be blank to begin with. There could be a fancier solution figured out later, but that'll put a bandaid on the immediate problem.

Custom "Case Status" bug

When using custom values in the "Case Status" field, HIFIS does not allow the user to enter an end date for the case, so case files remain open. Related: sometimes in this version, you can save a closed case file and add an end date, but it doesn't save properly.

User Templates

Create a user template that includes Service Providers and Rights, to speed up user creation. The Problem User have a set of rights at each Service Provider (this is not the problem) Each user account needs to be configured individually, even when it should be identical to that of a co-worker. A user could have 10 different sets of rights at 10 Service Providers It’s time-consuming and confusing to set up user accounts and mistakes often happen For the following two example users, an administrator would need to manually go through and define rights at Shelter A, then define rights at Shelter B, then define rights at Shelter C, etc. Example User: Secondary Rights Steve Let’s imagine Steve works at Shelter A. He logs in at Shelter A but also needs some access to data belonging to Shelters B and C. In order to achieve that, he needs to be granted access to 3 Service Providers and be configured with different rights at each. Shelter A: General shelter staff rights Shelter B: No ability to log on, but can read case files and VI-SPDATs belonging to this agency Shelter C: No ability to log on, but can read VI-SPDATs completed here Example User: Manager Madeline Let’s imagine Madeline is a manager at Shelter A. Because the shelters in her community work together very closely, all shelters have agreed that managers can ban staff from the other shelters in exceptional circumstances, and communicate important notices with each other. Shelter A: General shelter manager rights Shelter B, C, and D: Can create Service Restrictions and Bulletins The Proposed Solution Allow administrators to define a user template, which is a combination of Service Providers and the Rights for each Service Provider, and/or Give administrators the ability to clone an existing user (copy Roles, Service Providers, and Rights) The Advantages of this Solution User accounts are set up without error (less troubleshooting) Increased user acceptance by new users (no more “I can’t do X that my co-worker can”) Reduced administrative burden to administrators (faster to set up accounts) Because it would be easier, communities may be more willing to customize data sharing to suit their needs instead of coming up with workarounds (i.e. through reporting)