You’re embarking on a big journey. Implementing a new data system for all of your homelessness services is no small feat! But there’s good news: you’re not alone. Not only are there other communities that are embarking on the same journey as you (maybe even some in this course!), but you will also be working with other people within your own community to make this thing happen. This week, your task is to put together a HIFIS 4 Implementation Project Team. These will be the people you’ll be working with most closely over the coming months to make this HIFIS project a reality. You’ll need some people with specialized skills… like a superhero team! So get ready... Avengers Assemble!  Reference Materials HIFIS 4 Implementation Guide, Sections 1.1 & 1.2

Your HIFIS 4 Project Team is going to be the core group of people who meet most frequently and make decisions about HIFIS 4 implementation. You will also probably have a wider group of people that you will need to consult with (like your stakeholders) but we’re going to look at them next week. Before we actually get into your project team composition, please watch the video entitled RACI Explained, if you’re not already familiar with a RACI Model.

This resource was released by Infrastructure Canada relatively recently (2022) to assist communities with HIFIS implementation. Not every step in it is relevant for Term 1, but it's a good reference for the overall project. In Term 1: Planning, look at the first task list in this resource under Governance: Support Informed Decision-Making.

It’s considered a best practice in the IT world to have more than one copy of important software that you’re developing. For example, ACRE Consulting has a website (you’re on it right now!). If I wanted to make a change to it, the best practice would me for me to have a testing site where I could muck around and change things without worrying about what would happen to folks like you who are currently taking an online course using my website! In fact, for software like HIFIS, most IT folks would recommend a three environment configuration. An environment is like a copy of the software that is used for a specific purpose. From Atlassian Production Environment The first environment is usually referred to by techie folks as the production environment but for non-techies, you might think of it as the live site. It’s where your real live staff are entering real information about real clients in real time (hopefully). At this point, you don’t have it set up yet, but it will be the version of HIFIS that your staff see. Because it’s used by all your staff, your IT Support will want to make sure there’s a lot of support surrounding it. They’ll want to make sure things like firewalls are in place so the data can’t get hacked, and they’ll want to make sure that there’s enough bandwidth so that it won’t slow down or crash if too many people are trying to use it at the same time. Development Environment At the other end of the spectrum is the development environment. You might also hear this called the testing environment or even the sandbox. The idea here is that you can use this environment to try out new things. For example, when there’s a new update to HIFIS, you might want to install it here first and see what’s in it. Or, if you’re trying to add in a new program area, you could use this environment to experiment with modules you aren’t normally using. It’s a safe place for you to make whatever huge changes you need to try out, with no fear of getting in someone else’s way, or impacting day-to-day HIFIS use. Note that demo.hifis.ca is a development environment, so you don't need your own, strictly speaking. Staging Environment In between, you have a third environment that is often called the staging environment but might be called something entirely different, like a pre-production environment or a training site. The idea of a staging environment is that it is a copy of the production environment that is not used on a day-to-day basis with real clients and real data. It’s a simulated environment that should feel as much like the production environment as possible. The most frequent use for a staging environment is to deliver training. If you can train staff and give them the freedom to add in fake clients and dummy data while they’re still learning, but still have all of the configuration look the same (same rights, same shelters, same programs), they’ll be able to easily apply what they learned in training to doing their actual job in the production site. Another important use for the staging environment is it’s a bit of a testing ground for the production environment. Let’s imagine you want to make a change in the software. You test it out in the development environment and it seems like a good idea. Next, you can test it out in the staging environment and what kind of an impact it would have on your real staff, real clients, and real data… without actually impacting them. Putting it all Together Your IT Support may disagree with this approach, and that’s okay. They’re the IT experts in your community, and you should listen to them! However, the most common configuration goes like this: You have three environments, as listed above. When there’s a new version of the software, or you want to make a change, first we test out the change (like installing the update) in the development environment. If everything goes well, we apply the same change in the staging environment, and test it again. If it still looks good, we apply the same change in the production environment and do a quick test. Theoretically, it should be fine because we already tested it in the staging environment. Then, after the change is applied, we take a backup or copy or clone of the production database and copy it over to the staging environment, because – and this is important – we always want the staging environment to look like the production environment. That way, it’s going to be ready for the next test. We’ll also probably want to copy the production environment to the development environment, although we don’t need to do that as often. When we want to make a change, like modify some user rights, add a new service provider or setup a new program, we make that change in the staging environment, and test to see what the impacts are. If the impacts are what we're looking for, then we make the same change to our production environment. If our change doesn't turn out the way we want, we haven't caused any damage, and we can either revert the changes (by restoring a backup version of our staging database, or simply re-copying the production database to staging) or ignore them and try something new. Finally, when training is being delivered, you set up some training logins in the staging site, and deliver training in the staging environment. When the staff have completed the training, new user accounts are created for them in the production environment. From Wordpress At Scale

Our collection of legal and privacy resources has moved to a location where they can be accessible to everyone, not just HIFIS 4 Implementation Masterclass participants! Go get them! 

Photo courtesy of Built for Zero Canada Last week, you assembled your core HIFIS 4 Implementation Project Team. But this team is not going to be operating in a vacuum. There are lots of other interested parties with a vested interest in the HIFIS 4 implementation. This week is all about identifying stakeholders. We’re going to put together a list of our Partner Agencies and gather some information about them that we’re going to use next week. We’re also going to put together a HIFIS Advisory Group consisting of representatives from many of these Partner Agencies. Before we make a list of our agencies, though, we really want to make sure we have a good idea about the project scope. What are the boundaries of our geographic area? Which Partner Agencies will or won't be part of our initial project launch? Will we need multiple launch dates? Reference Materials HIFIS 4 Implementation Guide, Section 1.1 & Appendix A

[External Content] The following video is not owned by ACRE Consulting. It's a short video that describes how to conduct stakeholder analysis. Source: https://www.mindtools.com/pages/article/newPPM_07.htm

A common practice in communities is to form a larger HIFIS 4 Advisory Group, that includes not only the HIFIS Project Team, but also representatives from the Partner Agencies that will be included in consultations. Sample Governance Diagram  To form a HIFIS 4 Advisory Group, identify a list of your stakeholders that, as part of your Stakeholder Engagement Plan, should be consulted on a regular basis.  Next, you'll need to define their responsibilities. It's a good idea to be clear on what's expected. You could run into a problem if some of the HIFIS 4 Advisory Group members think they have authority to make decisions, if their role is simply to advise. Likewise, you could run into difficulties if you are trying to obtain feedback from them but they think they're simply being informed of what's going on. This can be accomplished through defining the group's Terms of Reference or Governance Charter. Finally, what are your expectations regarding meetings and attendance? It's a good idea to let your HIFIS 4 Advisory Group members know how much of their time you will be demanding. For example, many communities have a regular meeting once per month, while others may simply schedule meetings as needed. Or the group may convene for a one or two day workshop, and then communicate via email after that. From HIFIS 4 Implementation Guide Appendix A: Sample Terms of Reference Purpose The HIFIS Working Group will direct the HIFIS project to conclusion through governance related deliberation and decision-making. Responsibilities Through collaboration, the committee will: Serve as the decision-making authority on project issues, risk mitigation and scope; Act as the approving body for project deliverables; Advise and provide strategic project and program oversight and direction; Provide effective, timely, and consistent communications to the project team and stakeholders; Ensure alignment with government, community and funding organizations and initiatives; Serve as the primary advocate for the project. Chair The HIFIS Working Group meetings will be chaired by the HIFIS Lead. Membership of the HIFIS Governance HIFIS Lead or Project Manager Coordinated Access Lead Director, Service Provider A Director, Service Provider B Community/Governmental Representatives End User Representatives (Shelter/Outreach Managers) Funding Representatives HIFIS Business Analyst Reporting Structure Escalations and communications to executives will leverage the existing reporting structure: Community Entity Representative Vice President, Homeless Services Executive Director, Service Provider A Executive Director, Service Provider B Reporting out of the working group to the project will be conducted through the subworking groups for each of the project work streams. Reporting to the stakeholder community will follow the protocols set forth in the Communications Plan. Decision-Making Process Decisions will be made by consensus and recorded in the HIFIS Working Group minutes that each member has acknowledged agreement to that decision. In order to reach consensus, a quorum is required. For the purposes of the working group, a quorum requires a minimum of four members where service provider, funders and community members are represented. If the working group cannot reach consensus on a decision, it will be escalated to the executives identified in the ‘Reporting Structure’ section above. Should a decision be required prior to the next scheduled meeting, an out-of-band meeting will be set up. If a meeting cannot be coordinated, an email requesting decision support will be sent out to the committee members. HIFIS Working Group members shall not provide votes by proxy. Approval of Deliverables Project deliverables will be sent via email to committee members when they are ready to enter the review and approval process. As a guide, committee members will have five business days to review and provide feedback or approval on project deliverables. Confidentiality All confidential information that comes into the possession of the committee members is for the sole purpose of enabling the committee to seek solutions to issues requiring strategic counsel. Committee members will not share any confidential information; use confidential information only as required to enable the member to perform his or her duties on the committee and not use the confidential information for any other purpose. Frequency of Meetings The HIFIS Working Group will meet on the first Tuesday of each month. As required, additional meetings may be held at the call of the Chair. A teleconference will be set up for members that cannot attend in person. Meeting minutes will be distributed to the members within two weeks after a meeting. The agenda and presentation will be distributed a minimum of 3 business days prior to a scheduled meeting. Evaluation The terms of reference will be reviewed annually.

Last week, you identified the Partner Agencies in your community, and put together a lot of information about the services they offer and the sites they operate out of. Now, we're going to start putting you to work! This week is all about the building blocks of HIFIS 4 configuration, and we're going to cover two important concepts: Service Providers and Clusters. We're going to talk about translating Partner Agencies into their HIFIS 4 equivalents: Service Providers. It's not a direct translation, unfortunately, so there are some nuances that are important to learn. We're also going to group the Service Providers into Clusters, and begin to discuss who can share their data with everyone else. Reference Materials HIFIS 4 Implementation Guide, Section 2.5.1 HIFIS 4 Configuration Guide, pages 16-24

Infrastructure Canada has released a video describing Service Providers, and how they relate to Clusters and Programs. Here's INFC's description of the video: This video describes Service Providers and Programs in HIFIS, and it is an excellent resource for those seeking to learn more about these features. It begins by explaining what Service Providers and Programs are in HIFIS, and it then provides several considerations to account for when configuring both features. The video then provides instructions on how to define Service Providers in HIFIS, as well as a fictional example of how a community could configure its Service Providers and Programs in HIFIS. This video is recommended for communities implementing or expanding their use of HIFIS. While this video is overall quite helpful, please be aware that we have noticed more than one error in the video, where the video states something that is simply not true. In the event that you notice something that conflicts with the Masterclass, it's most likely the case that the Masterclass is correct. If you have any questions, please contact the instructor.

A Cluster is a HIFIS 4 term that can be defined as a sub-grouping within the HIFIS 4 database. Each Cluster is a group of Service Providers with a shared pool of Clients. Each Cluster contains one or more Service Providers. This Cluster of Service Providers has a shared pool of Clients.  Service Providers belonging to this Cluster can see and interact with Clients in this shared pool. However, Service Providers belonging to a Cluster are not even aware of the existence of Clients in other Clusters.  That also means that Service Providers within a Cluster cannot detect the activities of Service Providers within other Clusters. There is no crossover between Clusters. In general, the state of Clustering within a HIFIS 4 installation can be described in one of three ways: A fully integrated system comprises of only one Cluster. A partially integrated system comprises of at least two Clusters, and at least one of those Clusters contains at least two Service Providers. A fully isolated system comprises of multiple Clusters, each containing only one Service Provider. 

There are two main approaches to protecting client information in a shared database like HIFIS 4. The first approach is by controlling what information gets collected.  The second approach is by controlling who has access to that information. This week, we're going to be talking about the first approach (we'll cover the second approach next week). With regards to HIFIS 4, that can be divided into two parts: making sure that we have informed consent from our service participants, especially consent to collect their information, and, controlling what information exactly we're collecting We'll cover what information we're collecting later on in the course, but this week we're going to be focusing on consent. This is the real fundamental building block to protecting our clients' privacy: do we enter a client into HIFIS at all? Have they given us permission to collect any information about them? Reference Materials HIFIS 4 Implementation Guide, Section 1.2

This is a great training video that the Region of Waterloo created and uses to explain privacy and consent related to HIFIS. What we like about it is its simplicity and clarity. Consent is a tricky topic. But it's important to find a way to clearly communicate the important ideas to all staff, so they can communicate them to all clients.

As we mentioned last week, there are two main approaches to protecting data in HIFIS 4. The first approach is by controlling what goes in to our database. We started to talk about this with regards to consent last week. This week, we're focusing on controlling who has access to that information. Again, we can divide this into two chunks: controlling who has access to a given client file at all, and, controlling who has access to exactly what pieces of information are within the client file. Term 2 is going to focus a lot on what information will be in a client file and who will need access to which information in order to do their job. This week, however, we're still going to be focusing on the real fundamentals. When a client exists in HIFIS, who can access the file at all? Reference Materials HIFIS 4 Implementation Guide, Section 2.4

Now that we've covered: whether clients can get added to HIFIS at all, and who can access a client file at all, It's time for us to start talking about what information we will be collecting. Remember back to our conversations about controlling what information gets collected. One of the principles that was covered in PIPEDA was that of limiting collection. Well, it's time for us to start talking about exactly what information we're collecting. This week, we're going to cover personal information, which is the sort of information we might be asking our clients for on an intake form. Reference Materials HIFIS 4 User Guide, pages 14-34

In general, personal information that is entered into HIFIS is shared between all the agencies and programs that are serving the client. This makes sense because one of the advantages of a shared data system is to reduce need for clients to provide information over and over.  For example, if a client provides an intake site with her gender and date of birth, then the intake site refers her to a shelter, that information will still be true when the client arrives at the shelter. It saves time when a staff can locate an existing client file and use the information that’s already been provided by the client instead of asking them again. Another reason this makes sense is it helps staff to be able to work together and update each other's work. For example, a street outreach worker meets a client who is sleeping under a bridge and records a Housing History entry that describes the client's living situation. A Housing History has a start date and and end date, so the street outreach worker leaves the end date blank, indicating that it's a current living situation. A few weeks later, the client enters shelter, and a different staff at a different Service Provider now notes that the client is no longer living under the bridge. They will need to edit the existing Housing History record and add an end date. They're able to edit the record even though it was entered by another user at another Service Provider because this Housing History record is not "owned" by any Service Provider. Similarly, if a client is staying in a shelter and the shelter worker records their source of income as receiving social assistance, but later the client begins working with a Housing First caseworker who helps them apply for and receive disability support, it makes sense that the Housing First caseworker can edit the shelter worker's financial records. Or, if one staff records a client's phone number and then the client loses their phone and gets a new one, it makes sense for any staff to be able to delete the old phone number and add a new record, even if they didn't make the original Contact Information record. Sharing personal information also helps to reduce the amount of data entry required. Imagine that you have 100 total clients in your community, and 4 partner agencies. If you weren't sharing personal information, then each partner agency would have their own file for each client they're serving. Each agency might have 50 different files, which is a total of 200 files - on average, each client has 2 files, which means that staff, collectively, were doing twice as much data collection as was necessary. However, just because we're sharing personal information between Service Providers doesn't mean that all information is shared all the time. Personal information is generally available to staff who need access to that information, and not shared with staff who don’t need it. For example, shelter workers might need access to clients’ food allergies, while staff working to prevent evictions don’t need that piece of information. What an individual staff member can access is dependent on their user rights. Exceptions In general, personal information is shared as described previously. However, there are a few exceptions to those rules: Assessments, such as the VI-SPDAT, SPDAT, and VAT, are all considered service-related information. As a result, they are not shared as freely between service providers. For this type of information, the total score is shared, but not the individual details of the assessment. Health Information including a client’s health issues and what medications they are taking can be made private. There are some settings that can be configured that give individual users the ability to decide whether a particular piece of health information is private or shared. Financial Information including a client’s income, expenses, assets, and debts can also be made private. The same settings can give individual users the ability to decide whether a particular piece of financial information is private or shared. Client Notes can also be made private. If settings permit, users can also choose whether a note is private or shared. Sharing Service-Related Information in HIFIS 4 This week, the focus is on personal information, so we're not going to cover service-related information in too much detail, except to state that service-related information is "owned" 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. Service-related information is covered extensively in Term 2.

One of the components of HIFIS that you'll most likely be wanting to customize is the Geographic Regions. There's a drop-down menu containing a list of Geographic Regions, which is used whenever you add a Service Provider (what Geographic Regions does this Service Provider serve?) or a Housing Unit (what Geographic Region is this housing in?), and some other parts of the software too. The Geographic Region field is used in addition to other location data such as address, postal code, city, and province, so keep that in mind. You can say that a Service Provider is in Oshawa (the City) and also in Durham (the Geographic Region). The default options in the drop-down menu are: This Community This Region / County This Province / Territory Other Province Other Territory Outside Canada It’s probably best to think of these values as placeholders that you can modify in your community. So, instead of just leaving it as saying "This Community," you would replace that value with the actual name of the community that you're in. For example, I live in Kingston, Ontario.  I might replace “This Community” with “Kingston” and “This Region / County” with “Frontenac County” and “This Province / Territory” with “Ontario.” Some HIFIS 4 installations are quite large, however. For example, the province of New Brunswick is using HIFIS 4 province-wide (so is British Columbia)! It didn't really make sense for them to simply have the list say "New Brunswick," "Other Province," "Other Territory," and "Outside Canada." Instead, they subdivided their catchment area into regions like "Moncton Area" and "Fredericton Area" and "Saint John Area."  You can sub-divide your service area even further, if that makes sense to you locally. For example, if you have a local encampment area (a tent city) you may want to define that as its own Geographic Region.  Or, if your city is large, you could differentiate between the west end, east end, downtown, north, and south. Whatever makes sense for you locally.  It is up to you to decide locally what Geographic Regions you want to define, but the good news is that you probably already have a good idea of what regions you already have defined or would like to define. For example, if you were in Vancouver you may want to use the already defined Municipalities, Electoral Areas, and Treaty First Nations that are already well-known. You may also want to define some other Geographic Regions that are out of your catchment area but you frequently receive referrals from or send referrals to, or you get a lot of people experiencing homelessness coming from or going to. To use Kingston as an example a second time, there are several population centres near the city: Ganonoque, Brockville, Belleville, and Napanee, to name a few. We may want to include those as Geographic Regions - maybe even the Greater Toronto Area and Ottawa too - so that we can have a better understanding of the migration patterns locally. However you want to define them, your Geographic Regions can help you to obtain geographic data on the services you're providing and the clients you're serving. It provides you with a customizable extra field to track locations in addition to writing out addresses, cities and provinces.

Now that you've started to think about your Geographic Regions, you have a decision to make locally. You can turn on a setting called the Geographic Region Filter which changes how certain parts of the software behave. Tip: If you have a large service area, you should enable the Geographic Region Filter. If you have a small service area, you do not need to enable the Geographic Region Filter. As a general, rough rule of thumb, the Geographic Region Filter is useful for large service areas. If you have a large service area, you should enable the Geographic Region Filter. If you have a small service area, the Geographic Region Filter is less useful for you, and you may not want to or need to enable it. Geographic Region Filter Functionality So what does this mysterious setting do? To explain in a short sentence, it adds a field which you can use to filter location-based records. For example: You're a staff at a shelter and someone presents themselves seeking a shelter bed, but you are out of space. You are going to send them to another shelter, but which one? The first thing a staff might do is check on the bed availability at other shelters. Without the Geographic Region Filter, staff will see a list of all shelters.  Depending on how big your service area is, this might be a lot of shelters! By default, only the first 10 alphabetically are displayed on the first page, so staff may have to navigate to page 2 or 3 to find the shelter they're looking for. Bed Availability Tab without the Geographic Region Filter enabled   With the Geographic Region Filter enabled, staff will only see shelters in the same Geographic Region as the Service Provider they're currently logged in at (in other words, for the Geographic Region they're currently in). This cuts down on the clutter and should only show the relevant options. However, if staff need to look up availability in another Geographic Region, they can select a different Geographic Region from the drop-down menu and see shelters in that area. Bed Availability Tab with the Geographic Region Filter enabled   The second thing a staff might do is record a turnaway with a note that there was a referral made to another shelter. The referral field is also a drop-down menu that has a list of all your partner agencies, which again might be quite long. With the Geographic Region Filter enabled, it only shows local partner agencies by default, but again you could look up agencies in other Geographic Regions. A staff might also reference an area of HIFIS called the Directory of Services. This contains a list of all the Service Providers and other places you've added to HIFIS, and is sometimes used as a look-up for staff. Have a client that wants to know where the closest food bank is? Check the Directory of Services for them. Need to know if a particular partner agency offers a needle exchange program? Check the Directory of Services. The Directory of Services similarly has a filter which allows the user to only show places within a particular Geographic Region. As another scenario, perhaps you are managing a Housing First program (or similar). You could indicate that each available Housing Unit is located in a particular Geographic Region. When a caseworker and their client are looking up available Housing Units, they'll only see a list of Housing Units within the current Geographic Region (again with a filter to also show Housing Units in other regions) if the Geographic Region Filter is enabled. If the Geographic Region Filter is not enabled, it simply displays all of the Housing Units regardless of location.