4.0.59.6
Highlights
- Code refactoring to improve the performance of the Coordinated Access and Admissions modules.
- Validation rules added to improve data accuracy.
What's Different
Admissions
- Code refactoring performed in the Admissions module.
Appointments
- Fixed clients from other clusters appearing in the "With" field.
Application Settings
- Removed dependency between the Application Settings module and HIFIS.ca This will allow users to continue using the Application Settings module even if communication with HIFIS.ca cannot be established.
Case Management
- Multiple attachments can be added to a record at once.
Clients
- Added a validation rule to the Veteran Status field. Only clients who are 16 years of age or older can have a relevant Veteran status. Clients 15 and younger are automatically recorded as "Not a Veteran".
- Users who add new clients are asked to confirm the clients age if they are 85 years of age or older.
- The client list page shows active clients by default when producing initial results. Client List Columns on the client list page can be sorted.
- Clients remain active while they are booked into a shelter.
- Fixed the Client Vitals History log not recording changes from the Veteran module.
Client Service Delete
- Users can now delete a housing loss prevention record.
Consent
- Multiple attachments can be added to a record at once.
- Coordinated Access + Explicit consent type is now available as a bundle in the Consent module.
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.
1
- Fixed clients appearing across the cluster once their declined-anonymous consent expired.
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.
1
Coordinated Access
- Code refactoring performed in the Coordinated Access module.
- Fixed clients appearing multiple times on the Unique Identifier List if they have duplicate income amounts across multiple records.
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. Related to /Duplicate Clients in CA module (Families) /Duplicate Clients in CA module (First Episode) /Duplicate Clients in CA module (Consent) Workaround : change one of the monthly amounts by adding a penny
1
- Fixed clients appearing multiple times on the Unique Identifier List due to housing placement, service restriction and household records.
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 /Duplicate Clients in CA module (Consent) /Duplicate clients in CA module (Income) /Duplicate Clients in CA module (First Episode)
1
Documents
- Multiple attachments can be added to a record at once.
Family
- Clients associated to another service provider with declined consent now appear as “Hidden Client” in the Family module.
Financial Profile
- Added a validation rule to the following income type: Aboriginal Band Council. Only clients who identify as Indigenous can be tagged with this income type.
- Added a validation rule to the following income type: Canada Pension Plan (CPP) and Old Age Security. Only clients 60 years of age or older can be tagged with these income types.
Food Bank
- Fixed the form to allow the creation of new food bank records when accessing it via the Front Desk.
Help
- Fixed grey "Get Help" icon that produced an error message.
Housing History, Housing Placement, Housing Loss Prevention
- "Landlord" field added to the housing history form Users can now add, remove or change the landlord for housing records.
- Fixed the "Next Follow up" date field not remaining mandatory when trying to edit a housing loss prevention record.
- Fixed housing loss prevention records not updating the move in date when editing the information under housing history.
Housing Unit
- Fixed user rights for housing units. Users no longer see the buttons for actions they do not have the rights to for other service providers.
Incident
- Fixed incident records allowing clients to be both involved and a witness to an incident.
Look Up Table
- Removed "HPS" (Homelessness Partnering Strategy) in the "Program" look up table and replaced it with the current program name RH (Reaching Home).
- Added a new look up value in the Income table: English: Other Canada Pension Plan Benefits, French: Autres prestations du régime de pensions du Canada
Mandatories
- The "Treaty Number" and "Home Reserve" fields can now be disabled or tagged as mandatory.
Pit Count
- Fixed COH questions not deactivating properly when removing question from the PiT Count survey.
- Fixed PiT Count export list not loading when an old export exists.
Questionnaire
- Fixed and added missing "Delete" action. Users can now delete questions from a questionnaire. Note: Only questions that have not answered can be deleted.
Reports
- Removed dependency between the Reports module and HIFIS.ca This will allow users to continue using the reports module even if communication with HIFIS.ca cannot be established.
Rights
- Fixed "List Stay Records" right, users without the appropriate right can no longer see stays from other service providers.
- Replaced "HIFIS" with "SISA" in the rights tree when using HIFIS in French.
Rooms and Beds
- Fixed the form to add new beds; leaving the "Additional Beds to add" field empty does not prevent the creation of a single bed.
Service Provider
- Added validation to prevent duplicate service provider names on the same HIFIS site.
Service Restriction
- Fixed the missing delete action on the service restriction list on the front desk.
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.
4
System
- Refactoring JavaScript to be more general and robust for future development.
- Added security directives to web config template to tighten up security according to best practice.
- Fixed the elmah log displaying password inputs.
Users
- Added a proper error message when attempting to clone a user with an existing username.