HIFIS Feedback

Basically, for each client, you can block or authorize specific users - either you pick block all except user A, user B, or admit all except user A, user B​. Then there's also a setting about whether you hide the name if blocked or not. Seems to cover all the bases. Sure, some service providers could get into trouble with this feature, but they also don't have to use it if they want to avoid trouble. https://www.acreconsulting.ca/blog/108172-using-conflicts-to-track-prohibited-file See attached screenshot from WISH (DV shelter software)

The Calls and Visits Log can be used by organizations to track the number of visits and inquiries they receive. This data is useful for their monthly reporting. As this module functions on the assumption that clients are already in HIFIS, it can be difficult to log when an organization receives an inquiry or visit from someone outside of the system. The HIFIS User Guide describes this module as a way to record "contacts and communications a client makes and/or receives during their stay at the service provider". This module is useful for non-emergency shelter organizations. Information which should be logged in this module is being entered as a comment on the Client - Vitals page, which does not effect Client State.

I don't think the Edit Diversion form should have other modules embedded in it. I can see that whoever made the decision was trying to include a value add here, and while well-intentioned, and I appreciate the effort, I think there are a couple issues with it. First of all, I think most users would not edit a Diversion record in order to add a Contributing Factor. They would go to the Contributing Factors screen to add a Contributing Factor (for example. They also wouldn't do that in order to add a Goods & Services record, a Contact record, a Housing Loss Prevention record, etc.) . So I strongly believe that these will see minimal use. Given that there would be minimal utility for these embedded other modules, then they would mostly only serve to clutter up the page. If I want to edit a Diversion record, I want easy access to all of the Diversion-related fields, I don't want to have to scroll past stuff I can access from elsewhere.

When I add a Diversion Attempt (i.e. form version) and hit Save, it takes me to the "Edit Diversion" screen when the URL is /Diversion/New?returnurl=List and so it should return to the Diversion List.

One of the fields in the Diversion module, Diversion Result, was originally supposed to be a calculated field, much like how HIFIS can automatically calculate activity/inactivity and chronic status. The important reason for this is because a user might think they have successfully diverted a client, but the client goes down the street and is booked in at a second shelter. Only HIFIS has the system-level data to be able to assess "success." The "Diversion Destination" field was the field we would use to record what the staff thinks happened. I can tell that the Diversion Result field was based on my proposal, because I recognize the values in it. However, it was never intended to be a manually selected field. It is better to not have it at all, I think, than to have it be a user-selected field. Why? Because there are too many options for it to be user-selected, the options in the drop-down menu were strictly defined, and the average user will not understand the differences between them. So half the time someone might select "Not Diverted" when someone enters shelter but they might also select "Rapid Exit" or "Non-Rapid Exit" since these terms are actually not super well known. I foresee a lot of confusion about what these options mean, which will result in communities modifying the drop-down menu, which will cause future problems if you do intend to make it a calculated field. I would like to request that the "Diversion Result" field be temporarily hidden. It can be re-introduced if and when there is capacity to make it auto-calculated. For reference, here was the original information about the definitions and calculations: Defining Successful Diversion By the strictest definition, diversion is only successful when it results in the avoidance of shelter entry. However, this begs the question: for how long does the client need to remain out of shelter for the diversion to be considered successful? In addition, despite the fact that diversion and rapid exit are two distinct services, the fact remains that many communities combine the delivery of these two services: they would be delivered in the same way by the same staff. How, then, can one assess the success of a diversion service for a client who is already in shelter? There are two variables at play here which are relevant: X, defined as the minimum number of days, after the diversion service is provided, that a client must remain out of shelter for a diversion service to be considered successful. Communities should be able to define this value. For instance, they may use a value as low as 1 day, or a value as high as 180 days.Y, defined as the maximum number of days, after the diversion service is provided, that a client is permitted to be in shelter for a rapid exit service to be considered successful. OrgCode Consulting, Inc. suggests that the default value of Y should be 14 days, but that communities may modify this value to suit local circumstances. One participating community indicated that they would use a value of 3 days. Determining the success of a given diversion record should be calculated as follows: Is the client currently booked in to any shelter at the time of the Diversion date? If no, does the client have any book-ins at any shelter that start between the Diversion date and the Diversion date + X days? If no, the Status is "Diverted"If yes, is the client booked out within Y days from the Diversion date?--> If no, the Status is "Not Diverted"--> If yes, the Status is "Rapid Exit" If yes, is the client booked out within Y days from the Diversion date? If no, the Status is "Non-Rapid Exit"If yes, does the client have any book-ins at any shelter that start between the Diversion date and the Diversion date + X days?--> If no, the Status is "Rapid Exit"--> If yes, the Status is "Non-Rapid Exit"

Right now, the icon for recent diversion is the same as active service restriction. I suggest changing it to the attached.

The Turnaways module asks for Client Name and Family Members, then separately asks for the user to manually enter the number of Adults, which defaults to 1, and the number of Children, which defaults to 0. These fields should be automatically calculated based on the Client Name and Family Members fields. Moreover, on the Add Turnaway screen, these fields could even be hidden to reduce any confusion that may exist (these fields should still be present on the Add Anonymous Turnaway screen).

When a client who has an active Service Restriction is added to the Client field on the screen for a service type that the Service Restriction applies to (i.e. Book-In), there is a pop-up screen which uses the browser’s native pop-up function. This is incongruous with other pop-ups in HIFIS such as the Attestation pop-up or the Expired Consent pop-up, and because of its inconsistency some users misunderstand what it is communicating or miss the pop-up entirely. It is recommended that the Service Restriction pop-up be redesigned to be consistent with other pop-ups in HIFIS. Furthermore, the text in the pop-up can be improved at the same time. Currently, the text reads “[Client] [DOB] has an active service restriction.” This could be more helpfully changed to “[Client] is restricted for [Reason for Restriction] until [End Date].” Currently, the pop-up only includes one button with the text “OK.” If the user does not have permission to override service restrictions, they remain on the Book-In screen (or the screen of whatever service they are providing) with the client’s name removed, which can be confusing. Instead, two buttons should be present: “Display Restriction” and “Proceed with Book-In.”