At this point leading up to your HIFIS 4 implementation, you should have a reasonably good understanding of which Partner Agencies and programs will be using HIFIS 4 for your initial launch. You should also understand which of their staff will be putting data into HIFIS, and have a general idea of what data will be recorded. For example, it’s pretty easy to conclude that case managers would be using the Case Management module to record their case notes. One thing that you may not have considered, and we haven't covered specifically (if you've been with us since Term 1) is supervision. Are there things that supervisors should be able to do that entry-level staff should not? What are going to be the roles and responsibilities of supervisors and managers, when it comes to HIFIS 4? This week, we're going to talk about supervisory staff roles and what they'll be doing in HIFIS 4. We're also going to cover communications in HIFIS - that is, the ability for HIFIS 4 users to communicate with each other through the software. This isn't directly related to supervision, but it's certainly a task that your supervisors will want to think about. And heck, who knows, maybe your other staff will want to communicate with each other, too? Reference Materials HIFIS 4 Implementation Guide, Section 2.6

The main focus of this term is to dive deep into our HIFIS 4 configuration. We’re going to be looking at things like which fields we want to make mandatory and which options we want in each drop-down menu. This whole portion of the project, however, is really tempting to skip. It’s easy to assume that HIFIS will work for you right out of the box and your staff will put data in and it will work fine. The fact is that this may be true! You may not need to analyze every option in every drop-down menu! That could take you a really long time and take you down some rabbit holes you don’t need to explore. However. We’ve worked with enough communities on their HIFIS 4 launches that we know that communities that skip this important planning phase are creating difficulties for themselves down the line. Maybe not today, or tomorrow, or next week or even next month, but certainly by the end of the year someone is going to complain that they need to report on some target and they aren’t able to obtain the data that they need. This week, we're focusing on identifying what data you need and we're going to be spending most of the rest of this Term making sure you're capturing it. Reference Materials HIFIS 4 Configuration Guide, pages 28-30

There are a few different elements that you need to configure before users can simply run reports. It's easy to miss one or two steps, so here is a simple checklist for you to follow, to make reports work for you: Modify the Report Categories look-up table. Define your report categories and add those custom values to the look-up table. (If you're not sure how to do that, wait until Week 4.) For each report, edit it and and assign one or more Report Categories. This includes not only your own custom reports, but the HIFIS Reports that come with the software. For each report, edit it and also choose which Service Providers can run it. You can do this at the same time as you are assigning Report Categories. For each rights template, choose which Report Categories users with that rights template can access. Once you do all the above steps, users will have access to reports based on their Report Category and the Service Provider(s) they have access to.

Last week, you laid out your data requirements. You probably identified some data holes and noticed some gaps you now need to fill. One of the ways that we can fill those holes is through the use of the HIFIS concept: Programs. Note that a HIFIS 4 Program most likely means something quite different from what you assume, so be sure to pay attention to this week's lessons so you can make informed choices while setting up your Programs. In a nutshell, Programs are a way for you to sort and categorize similar services. For example, you have two case files and one is a "Rapid Re-Housing" case file and the other is a "Housing First" case file. You would use the Programs field to differentiate between the two. Reference Materials HIFIS 4 Configuration Guide, pages 22-24

There are three main categories or types of Programs that you could use HIFIS to keep track of. Not every community chooses to use all of them, so use what makes sense locally. You could use Programs to reflect: Funding sources System-level sectors of service Agency specific You can also use a combination of the above methods. You could use Programs to track funding streams, system-level sectors of service, and agency specific programs if it makes sense to record all three in your community. Funding Programs Most homeless programs obtain funding through one of four different sources: Federal funding, such as Reaching Home, Provincial funding, such as the Community Homelessness Partnering Initiative (CHPI) in Ontario, Municipal funding, and Private donations or fundraising The overwhelming majority of funders expect funded agencies to report back on how the money was spent and what the impact was. For example, communities may be required to report how many clients they served, or what services they provided. If you use Programs to identify which services were funded by which funder, at the end of the funding cycle you can run a report to count outcomes for each funder separately. One way to think about Programs in HIFIS is as funding programs. This is the classic way to approach Programs in HIFIS, and it works well with little to no explanation required. You would create a new program for each funding source and call it something like “Reaching Home Funded.” Most likely, you can take it a step further to select default Programs for each Service Provider, so this can operate as a “set it and forget it” approach. Case Study One community in Ontario set up Programs in this way. They were primarily HPP-funded (provincial funding source), but a few HPP-funded agencies had other programs that they offered in-house that were non-HPP-funded. They created two Programs: “HPP” and “Non-HPP,” and made the Program field mandatory for all services. For some Service Providers that were exclusively HPP-funded, they made the HPP Program default, so staff didn’t need to select it when they created a service, but they didn’t set a default for Service Providers that had both funding sources using HIFIS 4. This made HPP reporting at the end of the year much easier, since administrators could just run a report and select the HPP Program to fulfill their reporting requirements. System Programs Communities that have a holistic systems approach to their homelessness services may appreciate using Programs in a different way. If you take a birds-eye view of your system, you may see it as a series of interlocking parts. For example, you may say that your system can be divided into four parts: Homelessness Prevention Outreach Emergency Shelters Housing Programs You may, at the end of the year, want to answer questions from a systemic level, such as: How many clients accessed Homelessness Prevention services and then did not enter Emergency Shelters? How many clients moved from an Emergency Shelter to a Housing Program? How many clients did we provide Outreach to, and of those, how many are we now supporting in our Housing Programs? You could set up Programs in HIFIS to reflect all the different components of your homeless-serving system and monitor Program participation to identify bottlenecks in service delivery and work out the kinks. There would be a smaller number of Programs, most likely delivered by multiple Service Providers. Case Study One Ontario community used this approach after going through an extensive system planning exercise. They had recently overhauled all of their funding and contracts and were really interested in thinking as a system. They set up five key Programs in HIFIS 4, and all services that were offered fit into one of them: Emergency Shelter Overflow Shelter Brief Intervention (i.e. prevention and diversion) Rapid Re-Housing Housing First Agency Programs When asked what programs they offer, many agencies are quick to reply with a list, for example: “Youth Services” or “Anger Management” or “Dress for Success” or the “Baby Box” program. In many cases, these are not what HIFIS considers Programs.  For example, a program that helps homeless people find appropriate clothing for job interviews (“Dress for Success”) is, in HIFIS language, an Express Goods transaction in which the client was provided with Clothing. However, if desired, an agency could create a Program called “Dress for Success” and, when a staff provides a Clothing Express Good, they could indicate that it was part of the “Dress for Success” Program. Then, at the end of the year, that agency would be able to report on how many clients were provided with clothing as part of the “Dress for Success” Program. In this mode, each Service Provider could be responsible for defining their own programs and then setting up Programs in HIFIS to capture data that they need. These Programs, being agency-specific, are most likely not shared between multiple Service Providers. This approach would be useful for agencies that need to report on distinct segments of the services they provide. Case Study A rural Ontario community offers a funding program to help clients renovate their homes. (For example: a client lives in a home that’s been in their family for generations, but it’s in such poor repair and the utilities bills are so high that they can’t live there anymore, even though they own their own home.) This is offered through a variety of different funding sources, and it’s only one of the different programs this Service Provider offers, and periodically they need to be able to report on how much money was issued through this program, so they set it up as its own Program in HIFIS 4. Using Multiple Program Categories HIFIS allows staff to select one or more Programs when they provide a Service. That means when you provide a Service, you can select as many Programs as are relevant. In other words, you can use Programs in multiple ways. You are not limited to only using one of the above methods.

A few weeks ago, we talked about your data requirements and identified some data holes and noticed some gaps you now need to fill. Then, we talked about things like customizing drop-down menus and making fields mandatory in order to plug those holes. Well, this is the week that we're following up on those topics. This is part of a broader concept we'll be introducing you to: your data dictionary. Technically speaking, a software developer would think of a data dictionary slightly differently from the way we will be, but the general idea is the same. You have a large database with lots of pieces of data stored within it. There's lots of moving parts and lots of people involved, and it's really important to make sure you have consistency in your data practices. That's where a data dictionary comes in handy - it lets you define all the different fields, and all the different options in each field. That way, you avoid situations where someone is looking at data that another person had entered and wondering "what did they mean by this?" Reference Materials HIFIS 4 Implementation Guide, Sections 2.5.3, 2.5.4, & 2.5.6 HIFIS 4 Configuration Guide, pages 32-33

To customize, or not to customize? That is the question. Sometimes, communities in the early stages of HIFIS 4 implementation might want to customize everything so that it’s completely perfect and matches their system exactly. Other communities might hesitate to modify anything for fear of making something suddenly stop working. From experience, its probably best for communities to be somewhere in the middle of that spectrum. First of all, if you want to customize everything, that’s a lot of customization! There are over 100 Look-up tables in HIFIS 4, and you’re probably not going to use them all. It would take a huge amount of resources to go through them all and thoughtfully consider each value. To add to the challenge, sometimes what sounds like a good idea at the time might not work out in practice. Case Study One community wanted to get everything perfect before they launched HIFIS 4 system-wide. This was an admirable goal, but they ran into some challenges. First, they started asking partner agencies for feedback on each and every look-up table, but partner agencies became reluctant to participate after they realized the scope of is request. It's one thing to thoughtfully discuss one look-up table at one meeting, but when it is dozens or hundreds of tables over the course of many, many meetings, stakeholders felt that they had more important things to do with their time. So, partner agencies directed the HIFIS 4 Project Team to come up with a proposal that they would then approve. The Project Team spent hours going through every option in every table with a fine-toothed comb, and had valid reasons for the decisions they made. And they sought approval from the stakeholders, which was provided (at this point, the partner agencies were eager to launch). After launch, however, the Project Team started to receive feedback that they hadn't considered some situation or circumstance and they really needed X or Y option in Z look-up table. Ironically, many of these were requests to re-enable default values that had been disabled! By spending too much time trying to customize everything, the Project Team in this case failed to prioritize the most important areas - the ones front-line staff would be dealing with on a day-to-day basis - and didn't get meaningful feedback. On the other hand, however, if you don’t customize anything at all, you and all your users will have to put up with a system that doesn’t reflect your local realities. Case Study One community wanted to launch as quickly as possible, with the basic assumption that HIFIS 4 had been tested and used enough that it would mostly handle common needs. They didn't spend any time looking at look-up tables and instead promised to modify them after launch, should the need arise. Overall, this approach was more-or-less successful, but they did get many requests from front-line staff immediately after launch which could have been resolved by spending a little bit of time looking for obvious flaws. For example, the "Income Type" look-up table includes a value for "Provincial Social Assistance" and a value for "Public / Social Assistance" but doesn't include the names of any specific social assistance programs, like "Ontario Works (OW)" or "Saskatchewan Assistance Program (SAP)." This led to a lot of questions about when to select one option or the other, and why the specific provincial program wasn't listed. We suggest that you customize a few key tables prior to HIFIS 4 launch. Then, if after you’ve been using HIFIS for a while, you want to further refine things, that’s a great course of action. Prioritize first the ones that you think your staff will be dealing with most frequently, and you'll get greater buy-in from your front-line staff! Some tables you might want to customize in advance include: Geographic Region Reason for Service Reason for Discharge Reason for Turnaway Reason for Restriction Services Types (if using Goods & Services) Goods Types (if using Goods & Services) Group Activities Types (if using Group Activities)

You have the ability to make certain fields mandatory in your HIFIS 4 installation. However, we want to make it abundantly clear from the start that just because a field is mandatory does not necessarily mean you'll have data from that field for all clients. What do we mean by that? Let's use an example. Hypothetically, you might want your client's Contributing Factors to be mandatory. You want to know each client's current Contributing Factors and also some notes about it. So you go through the steps you learn this week and make various fields in the Contributing Factors module mandatory. However, there's generally nothing forcing a user to add a new record. So while you could say something like "when a user adds a Contributing Factor record, they must include some Comments about it," but you can't say something like "when a user adds a new Client, they must also add at least one Contributing Factor." In other words, you can't make a module mandatory, but you can make fields within a module mandatory. Tip: Generally speaking, communities will work around this limitation in the following ways: creating clear policies and documents telling staff what is expected of them; and disabling a lot of unnecessary fields and modules to reduce clutter and confusion. One more note about mandatory fields: there may be times when the actual answer should be blank. For example, you can make the Emergency Services field mandatory on the Incidents module. That means that you have to specify which emergency services responded to the incident. But what if the answer is legitimately that none of them were involved - say, someone cut themselves and got a band-aid from the first aid kit? Consider these situations when thinking about what fields to make mandatory. One solution is to first customize the Look-Up Table and add a "None" option before making the field mandatory.

This is our last week talking about data requirements and gaps. Many Partner Agencies - and service managers too - will sometimes require that data be collected that simply isn't normally collected by HIFIS 4. This can be all sorts of different kinds of data, including: Satisfaction surveys completed by clients, perhaps on program discharge Assessments that are not already in HIFIS, such as a Danger Assessment or the YAP tool Single or additional data points about clients, like their sexual orientation, or what motel they stayed at Locally-used forms and templates for things like case planning Luckily, we have the option to add custom forms to HIFIS 4 that allow your staff to collect these data points. There are actually two different tools that we can use: questionnaires and custom tables. We'll be covering both of these features this week. Reference Materials HIFIS 4 Implementation Guide, Sections 2.5.7 HIFIS 4 User Guide, pages 91-92

You are almost done what you need to know about configuring HIFIS 4! While it might take you a little bit of time to actually do the configuration, you are almost there. The light at the end of the tunnel should be getting pretty bright! This week, we will be discussing our last topic: inventories in HIFIS 4. It's not the best term, but we're talking about things like: A list of rooms and beds for each of your shelters A list of landlords, parole officers, child services caseworkers, or other people you might want to keep track of A list of housing units that are part of your Coordinated Access System A list of zones and hotspots, service locations, and other places that your staff might reference A list of types of services that each of your partner agencies provides Honestly, this week's content isn't particularly difficult, but it is a little tedious. We're sorry it's not going to be more interesting, but on the other hand, it might be a nice break to do something straightforward for a change! Reference Materials HIFIS 4 Configuration Guide, pages 30-31, 33-35 HIFIS 4 User Guide, pages 70-71, 75-76, 86-87, 94-95, 98

According to the Built for Zero Canada Campaign: A By-Name List is a real-time list of all people experiencing homelessness in your community.  It includes a robust set of data points that support coordinated access and prioritization at a household level and an understanding of homeless inflow and outflow at a system level.  This real-time actionable data supports triage to services, system performance evaluation and advocacy (for the policies and resources necessary to end homelessness). By this definition, HIFIS 4 is arguably already a By-Name List (BNL), particularly if you're using it as intended. In other words, if you have integrated clusters set up, and your partner agencies are sharing data system-wide, then you already have a BNL! How's that? Well, if a BNL is a list of all people experiencing homelessness, and all of your partner agencies that serve homeless people are putting their client's information into HIFIS 4, and you're collecting the names and additional information for all the clients you're serving, then... yeah... HIFIS 4 is your community's By-Name List. Of course there is a catch. It's not quite that easy. There are a few differences between HIFIS 4 and your BNL. Housed vs. Homeless HIFIS 4 is going to include not only clients who are currently homeless but also clients who are currently housed. This could be intentional - some of your partner agencies serve people who are at risk of homelessness but haven't become homeless (yet). Or it could be a by-product of your services - some of your partner agencies help house clients and follow up with them after they're housed. In order to translate your Client List in HIFIS 4 to a By-Name List, you'll need to include only those clients who are currently homeless, or at least exclude those who are currently housed. Active vs. Inactive HIFIS 4 is also going to include not only clients who are currently relevant, but also clients who you haven't seen in a while. For example, if you've been using HIFIS 4 for three years, you may have had a client stay in shelters three years ago then disappear. You don't know conclusively that they're housed - they could be in a different community, or in jail, or deceased - but you do know that you haven't seen them in years. For your By-Name List, you shouldn't be including those who are not actively homeless. In order to translate your Client List in HIFIS 4 to a By-Name List, you'll also need to include only those clients who have been active recently, however that may be defined in your community. Perhaps clients who have received any services within the past three months? Non-Consenting Clients This is the trickiest aspect to account for. HIFIS 4 only includes clients who have consented to data collection and sharing, which means that clients that you know about (known homelessness) but who have not consented for you to collect their information should not be in HIFIS, but that makes it difficult to say that HIFIS 4 contains a complete list of all clients who are known to be homeless. However, a lot of communities have a similar requirement that clients must consent to join the By-Name List, so it could be that consent forms would cover both addition to the By-Name List and to HIFIS 4. One thing to consider is what might be done with the known-but-anonymous clients! Check out our free Guide to BNLs in HIFIS!

HIFIS version 4.0.59 was released in December 2020 and included new functionality surrounding By-Name Lists and Coordinated Access. Attached to this lesson are the Reference Guide and the FAQ for this release, which are a good place to start when understanding the Coordinated Access module.