HIFIS 4 Implementation Masterclass | Term 2: Staff & Rights

This week, we are going to be talking a lot about staff. Specifically, the staff that work at your Partner Agencies, most of whom deliver services to the service recipients in your system. Even more specifically, we're going to talk about the staff that are going to need to login to HIFIS, who we're going to call users.

This week, we are going to be beginning to talk about what our different staff roles can do and see in HIFIS 4. This is governed by their user rights. Any time in HIFIS 4 when you can say something like "my staff need to be able to..." then you are actually talking about user rights! There are a lot of user rights that exist in HIFIS 4, and a lot of software modules. We're going to be covering lots of content this term, but this is our second week covering some building blocks. Last week we made sure you knew what staff you were talking about; this week, we're making sure you understand what we mean when we say "List Client Admissions" or "Display Contributing Factors." It's a little bit technical, but trust us when we say this knowledge is important! Try to take the time to go through this week's Lessons and make sure you understand them before moving on to an area that you might be more interested in, like Shelters or Housing First.  

In general, personal information that is entered into HIFIS is shared between all the agencies and programs that are serving the client. Who has access to it is governed by the rights that the user has, but it doesn't matter who first created the record. In contrast, service-related information is controlled by the Service Provider that created the record. That means things like case notes and incident reports are protected and are shared much less freely between Service Providers. Users can only see all of the details of service-related information if they have access to the Service Provider that controls the record in addition to having appropriate user rights. In other words, if there's a case file that is owned by Munchkinland Shelter, only other users that have access to Munchkinland Shelter can see all of the details of that case. "Seeing all of the details" is a little bit of a vague phrase, but the reason for that is because what is and what isn't shared is different for different types of information. Examples Throughout this term, we will be exploring the different parts of HIFIS 4 one at a time, and will clearly convey what fields are shared and which are not. But to give you a general example of what sorts of things are shared and what aren't: Module Shared with other Service Providers Not Shared with other Service Providers Case Management Caseworker, Goal, Target Date Comments, Sessions, Case Documents Admissions Dates, Reason for Service Referrals, Late Pass Time, Comments Service Restriction Dates, Reason for Restriction Comments

This week is part 1 of a 3-part series that cover specific types of agencies or program areas. In this section, we're going to learn about the modules most relevant for shelters and other similar programs such as transitional housing, residential detoxification programs, motel vouchers, and so on. In particular, we're going to look at Admissions, which is the main module for shelter operations. We're also going to touch briefly on the Chores and Medication Dispensing modules. These might seem a bit odd to be discussing now, but these modules can only be used in conjunction with clients that are booked in through the Admissions module, so it makes sense to talk about them now, even though they might not seem as important. We're going to have a specific focus on some of the things that shelter staff do. If you're planning to convene your HIFIS Advisory Group to discuss this section's lessons, the topics primarily concern shelter programs, so representatives from other agencies may not need to participate in the discussion. Using This Section First, read the Module Overview lessons for the chapters in this section (Admissions, Chores, & Medication). This will give you a grounded understanding of what the module is all about. You may dismiss some modules out of hand, thinking that you will never use that module, or at least that it's not relevant to your learning right now. Once you have a good idea of what the modules do, for the modules you are interested in learning more about, go ahead and read the Data Fields lesson, and sometimes there will be some extra lessons talking about specific features that are unique to the module you are learning about. For example, the Admissions module has a specific lesson about the Bed Availability feature. Next, we suggest you visit your development site and play around with the module. Click on some buttons, check out the drop-down menus, save some fake data, and see how the workflow behaves. Reading about a module is no substitute for first-hand experience. After that, come back to your lessons and read up about Data Sharing and User Rights. You can also come back to the Data Fields lesson to learn more about each field. These are pretty boring lessons, we know, so it's best to look at them when you are thinking about specific questions like "who will have access to the Reason for Service information?" and "how can I customize the list of case Goals?" You should also read the Tips & Tricks lesson that is provided for most modules - this often provides suggestions for things to think about and how to make the module work best for your community. Not all modules have Tips & Tricks, especially if they aren't commonly used. Finally, now that you have a good understanding of the modules, come back to this Chapter and take a look at the Group Activity. This has suggestions for how to manage a discussion with your partner agencies about this section's topic. You'll need to present the information you learned to your partner agencies and get some meaningful feedback, and ultimately decide which staff need what permissions in HIFIS 4. The very last thing you'll do, after your Group Activity, is to fill out the Homework, that will actually include the rights you've chosen for your staff roles. Reference Materials HIFIS 4 User Guide, pages 36-42, 47, 60

The Diversion module is new in HIFIS 4.0.60 (October 2023). As it is relatively new, we generally have less experience with putting it to use in communities. Also note that as it is so new, this section is more subject to change than other modules. According to the official documentation: Shelter diversion is a process intended to identify safe housing options for individuals or families experiencing homelessness seeking entry into emergency shelter. It is an important part of the Coordinated Access process, and its main objective is to prevent a shelter stay by finding a safe and appropriate alternative. The Diversion module added to this version of HIFIS enables users to record diversion attempts. The module offers both a standard form option and a workflow option. The workflow option provides HIFIS users with a script that can be read to clients explaining the diversion process. In addition, this script can be customized by HIFIS administrators according to the community’s needs. Generally speaking, the Diversion module is useful for when you're doing shelter diversion. It allows you to record: That a client presented for service What their presenting needs were What assistance was provided to the client What the outcome was There are two methods to create a Diversion record in HIFIS. The workflow method shows the user multiple steps, with a script, essentially walking them through the process of shelter diversion. For example, the first step is to record some high level information (who, when, where); the second step provides a script for staff to state the goal of diversion and ask why the staff are presenting for service; the third step asks about where they were staying last night; etc. This procedure is best for newer staff or if you're newly implementing diversion in your community and it's not being done consistently well. The one-page method has a simple one-page form, like other modules, where you simply record what happened after the fact. This method is best for when staff are having diversion conversations away from their computer, or the staff are very experienced and don't need a guide. You can choose to enable one method or the other, or both, or give some staff access to one while other staff have access to the other.

*Subject to Change* The Diversion module includes the following fields: Name Type Notes Service Provider Automatic Automatically filled with the Service Provider the user is currently logged in at Client Name Single-select drop-down Mandatory. Contains a list of searchable Clients Family Members Multiple-select drop-down   Reason for Service Single-select drop-down Mandatory. Values in drop-down menu can be modified in the Reason for Services look-up table. Date and Time Datetime Mandatory. Default value is current date and time. Program Multiple-select drop-down Optional. Contains a list of Programs that are delivered by this Service Provider and include Goods & Services as a Service Type. Housed Safely Last Night? Boolean Caseworker Single-select drop-down Mandatory. Contains a list of users at this Service Provider with the Role of Caseworker. Referred From Single-select drop-down Optional. Contains a list of Places that are Referable From. Referred To Single-select drop-down Optional. Contains a list of Places that are Referable To. Expended Minutes Number Optional. Financial Assistance Provided? Boolean   Expected Diversion Destination Single-select drop-down Mandatory. Values in drop-down menu can be modified in the Expected Diversion Destination look-up table. Next steps for Client or Worker Text area Optional. Scheduled Follow-Up Date Optional. Diversion Story Text area Optional. Comments Text area Optional. Diversion Result Single-select drop-down Optional. Values in drop-down menu can be modified in the Diversion Status Type look-up table.

Client Diversion List Screen  Information about a Diversion record is shared with other Service Providers, but is owned by the Service Provider that recorded the Diversion. When a user has permission to List Client Diversion Records, the shared data fields that they can see are: Service Provider Date and Time Reason for Service Expected Diversion Destination Caseworker Status Next Scheduled Follow-Up

User Rights related to Diversion are fairly straightforward: Right Behaviour Notes List Diversion Records Grants access to a list of Diversion records for the designated Service Provider List Client Diversion Records Grants access to a list of Diversion records for the Client, at all Service Providers   Display Diversion Records Allows user to see all fields in a Diversion record at the designated Service Provider Add Diversion Records Allows user to add a new Diversion record at the active Service Provider via the one-page method This grants access to the "Add Diversion" button which is the one-page version, not the workflow version Add Diversion Workflow Records Allows user to add a new Diversion record at the active Service Provider via the workflow method This grants access to the "Add Diversion Workflow" button which is the workflow version, not the one-page version Edit Diversion Records Allows user to edit a Diversion record at the designated Service Provider if it was created via the one-page method Unclear why there are two different Edit rights. This might change in the future. Edit Diversion Workflow Records Allows user to edit a Diversion record at the designated Service Provider if it was created via the workflow method Unclear why there are two different Edit rights. This might change in the future. Delete Diversion Records Allows user to delete a Diversion record at the designated Service Provider  

As the Diversion module is relatively new (4.0.60, October 2023), a consensus about the best usage of this module has yet to be developed. Therefore, you are a pioneer! Go experiment. Module Development The Diversion module was designed in large part by ACRE Consulting. A whole lot of communities across Canada were consulted and a proposal for a new Diversion module was developed in 2021. We are happy to say that most of our recommendations were implemented as we described, but there are certainly some areas where our vision was not completely captured. To the extent that the current module does not match our proposal, we are working on understanding the differences and exploring ways to narrow that gap. For example: We proposed that the Diversion module should automatically calculate whether the Diversion effort was successful or not, based on whether a client subsequently is admitted to a shelter within a particular timeframe. It's currently a manual selection, with confusing options. We also don't like the look of the Diversion one-pager. It's too cluttered. Our original proposal envisioned that that page be quick, clean, and easy-to-use, but the development team embedded a lot of information from other modules within it. It remains to be seen which approach makes more sense. Interested in reading our whole proposal? Here it is: HIFIS Improvement Project: Diversion Report Shelter Staff We suspect that it's best if you grant access to the Diversion module for all front line shelter staff, even if they aren't currently doing diversion. Why? First of all, it may help to normalize the concept that shelter staff should be attempting to divert clients away from shelter before admitting them. If you're just implementing a diversion program at shelters, or it isn't well established, we recommend granting staff access to the workflow method and not the one-page method, to teach good habits and also to ensure consistency while you're trying something new. Once you've got your deiversion program more established, you can explore the one-page version. Prevention & Diversion In many communities, they have something called a "Prevention & Diversion" program. In HIFIS, there's a Housing Loss Prevention Module which exists to record what sorts of financial assistance were issued to assist people remain in their current housing, and there's also the new Diversion module, which doesn't directly let you track financial assistance, nor is it attached to a client's current housing. We suspect that staff that deliver a combined prevention/diversion program may struggle with determining which module to use in which circumstances. For example, if you instruct staff to only do Housing Loss Prevention when the client is remaining at their current address, and do Diversion at other times, would result in messy data. Half of the time you're recording data one way and half the time you're recording data another way. It's inconsistent, and that should generally be avoided. This is an area where we are still working out what works best in practice. One option that you could consider: while doing a Diversion record, there's a link to the Housing Loss Prevention module. You could instruct staff to create a Diversion record every time, and in certain circumstances, also create a linked Housing Loss Prevention record.

This is section 2 of a series focusing on specific types of agencies. We already covered shelters, and next week we will cover light touch services. In this section, we're going to learn about the modules most relevant for Housing First, Rapid Re-Housing, and other similar program. In particular, we're going to look at Housing Placements, Case Management, and Assessments like the VI-SPDAT, SPDAT, and VAT. We're going to have a specific focus on some of the things that housing-based case management staff do. If you're planning to convene your HIFIS Advisory Group to discuss this section's lessons, the topics primarily concern housing programs, so representatives from other agencies may not need to participate in the discussion. A brief note: we're also going to be covering Housing Loss Prevention, which is a module that will be used by eviction prevention programs and similar. We know that this is most likely a different group than those that do Housing First and Rapid Re-Housing, but the Housing Loss Prevention module is very similar to the Housing Placement module, so it makes sense to learn about them both together. However, when you're meeting with your partner agencies, you might choose to meet with your eviction prevention programs separately from Housing First and Rapid Re-Housing. Using This Section First, read the Module Overview lessons for the chapters in this section (Assessments, Case Management, Housing Placements, Housing Loss Prevention). This will give you a grounded understanding of what the module is all about. You may dismiss some modules out of hand, thinking that you will never use that module, or at least that it's not relevant to your learning right now. Once you have a good idea of what the modules do, for the modules you are interested in learning more about, go ahead and read the Data Fields lesson, and sometimes there will be some extra lessons talking about specific features that are unique to the module you are learning about. For example, the Admissions module has a specific lesson about the Bed Availability feature. Next, we suggest you visit your development site and play around with the module. Click on some buttons, check out the drop-down menus, save some fake data, and see how the workflow behaves. Reading about a module is no substitute for first-hand experience. After that, come back to your lessons and read up about Data Sharing and User Rights. You can also come back to the Data Fields lesson to learn more about each field. These are pretty boring lessons, we know, so it's best to look at them when you are thinking about specific questions like "who will have access to the Reason for Service information?" and "how can I customize the list of case Goals?" You should also read the Tips & Tricks lesson that is provided for most modules - this often provides suggestions for things to think about and how to make the module work best for your community. Not all modules have Tips & Tricks, especially if they aren't commonly used. Finally, now that you have a good understanding of the modules, come back to this Chapter and take a look at the Group Activity. This has suggestions for how to manage a discussion with your partner agencies about this section's topic. You'll need to present the information you learned to your partner agencies and get some meaningful feedback, and ultimately decide which staff need what permissions in HIFIS 4. The very last thing you'll do, after your Group Activity, is to fill out the Worksheet, that will actually include the rights you've chosen for your staff roles. Reference Materials HIFIS 4 User Guide, pages 44-47, 53-59, 61-63, 65-67

This is section 3 of a series focusing on specific types of agencies. We already covered: Shelters, and Housing programs In this section, we're filling in the blanks between these major program areas. The modules we'll be talking about this week are things like providing tangible goods like bus passes and socks, brief services like referrals and tenancy education, group activities like meal programs and life skills classes, and food items like in a food bank. Typically, these types of services are delivered by your shelters, but also drop-in centres and resource centre programs, housing help programs, and maybe outreach teams also. We call this type of assistance Light Touch Services, meaning that they aren't intended to be overly in-depth or long-term. You should be able to bring this information back to your HIFIS Advisory Group and start talking to these sorts of agencies about the types of assistance they provide. Using This Section First, read the Module Overview lessons for the chapters in this section (Goods & Services, Group Activities, & Food Banks). This will give you a grounded understanding of what the module is all about. You may dismiss some modules out of hand, thinking that you will never use that module, or at least that it's not relevant to your learning right now. Once you have a good idea of what the modules do, for the modules you are interested in learning more about, go ahead and read the Data Fields lesson, and sometimes there will be some extra lessons talking about specific features that are unique to the module you are learning about. For example, the Goods & Services module has a specific lesson about the Express feature. Next, we suggest you visit your development site and play around with the module. Click on some buttons, check out the drop-down menus, save some fake data, and see how the workflow behaves. Reading about a module is no substitute for first-hand experience. After that, come back to your lessons and read up about Data Sharing and User Rights. You can also come back to the Data Fields lesson to learn more about each field. These are pretty boring lessons, we know, so it's best to look at them when you are thinking about specific questions like "who will have access to the Reason for Service information?" and "how can I customize the list of case Goals?" You should also read the Tips & Tricks lesson that is provided for most modules - this often provides suggestions for things to think about and how to make the module work best for your community. Not all modules have Tips & Tricks, especially if they aren't commonly used. Finally, now that you have a good understanding of the modules, come back to this Chapter and take a look at the Group Activity. This has suggestions for how to manage a discussion with your partner agencies about this section's topic. You'll need to present the information you learned to your partner agencies and get some meaningful feedback, and ultimately decide which staff need what permissions in HIFIS 4. The very last thing you'll do, after your Group Activity, is to fill out the Worksheet, that will actually include the rights you've chosen for your staff roles. Reference Materials HIFIS 4 User Guide, pages 48-53

By now, you should have met with all of your partner agencies and have completed mapping, or at least are well on your way to mapping, all of the services these agencies provide. That's not to say that you've covered all of the things they do, just the services they provide. During the next few weeks we will be filling in the blanks to talk about everything else they might need to do in HIFIS 4. This week, we're going to be reviewing service interruptions. A "service interruption" is not an official term you would see anywhere in HIFIS. However, it is being used this week to help provide context and information for some related ideas. There are four related concepts in HIFIS 4 discussed this week: Service Restrictions are created when a client is restricted from accessing a Service Provider. As there is a setting that allows Service Restrictions to be overridden, some agencies also use Service Restrictions to indicate when a client has a warning related to their service use. Turnaways are created when a client attempts to access a Service Provider and ultimately does not receive the service they are seeking. Note that an increasing number of communities are using the Turnaways module to record shelter diversion. Conflicts are recorded when a client has an ongoing dispute with another client or staff and an interaction between them would likely result in an incident of some variety. Incidents are created when there is a reportable incident such as a medical event, an accident, or an altercation involving one or more clients and/or staff.

We're wrapping up our whirlwind tour of the HIFIS 4 modules. We've covered the nuts and bolts, but by this time you might have one or two straggling needs that haven't been covered yet. This week, we're talking about some housekeeping functions. Things like tracking appointments and waiting lists. They're probably not going to be the core of the business at any partner agency, but sometimes an agency wants to be able to switch entirely from their old system(s) to HIFIS 4 and they say that they really can't do it if some specific need can't be met. We're also going to talk about what to do about the program areas you have and know about that don't neatly fit into one of the modules we've covered. Reference Materials HIFIS 4 User Guide, pages 42-43, 63, 67

This week is all about wrapping up with our rights templates. By the time you get to this week's lessons, you should have a pretty good idea what staff roles your users have, and what your users of a particular role will need to be able to access in HIFIS. There are two main things we are going to be covering this week: putting everything together into a rights template, and then allowing users to test out those rights. You're still early on in your implementation journey, so how we're going to let our users test the rights is by creating some dummy user accounts in a development environment, and then hosting an event called user acceptance testing to collect feedback. Reference Materials HIFIS 4 Configuration Guide, pages 25-27

[External Content] The following video is not owned by ACRE Consulting. It's a clip from a comedic television show called Silicon Valley that shows a humorous take about why it's important to conduct User Acceptance Testing. Source: https://www.youtube.com/watch?v=QYBcLMiR9b0

Your average users are not going to require access to the Point in Time Count moudle 99% of the time, but at some point, they likely will. We already offer free training for PIT counts in HIFIS. Instead of reproducing all of the content here, follow the links below to access this bonus content. Point-in-Time (PIT) Count Administration and Point-in-Time (PIT) Count Training