HIFIS 4 Implementation Masterclass | Term 4: Launch

You now know exactly what your HIFIS 4 software is going to look like and you're ready to focus on the actual implementation. It can be tempting to plunge forward, but it's a good idea to put some plans in place before you press the big red button. Over the next four weeks, we'll be covering everything you need to know about planning for your successful HIFIS 4 launch and beyond. This week, we'll be covering the launch itself. You'll learn everything you need to in order to plan for a launch date, and to think about what to do with your current (soon-to-be-old) data. Reference Materials HIFIS 4 Implementation Guide, Sections 2.2, 3.1, 3.2, and 4

So you're ready to launch HIFIS 4 in your community. Congratulations! But there's still one question remaining.  How, exactly, are you going to flip the switch? Look at a single individual staff. One day, they're going to be doing things the old way (whether that’s entering things into HIFIS 3 or taking notes with pen and paper), and then the next, they'll be expected to start using HIFIS 4. This can be a little intimidating, not to mention confusing for staff. That’s why it’s important to have what’s called a changeover strategy. In other words, having a strategy or a plan in place that ensures a smooth changeover or transition from doing things the old way to doing things the new way. There are multiple ways that a changeover could work, in practice, but a key component of a good changeover strategy is communication. Everyone involved – and that includes all the administrators, supervisors, and those on the front lines – need to know what to expect and when to expect it. Otherwise, things could get messy. There are four main changeover strategies that you have to select from. Which one you pick depends on what your needs are, since they all have some pros and cons. They are: Plunge Parallel Phased Pilot There are multiple different ways you can think about your launch plan, and there really is no one correct answer. Each option offers various positives and negatives. However, there are a few common best practices. You need to have a strategy that includes solid timelines and a communication plan. If you check those boxes, then you’ll be prepared to deal with whatever issues arise. But wait, didn't you tell us ages ago to do our project in phases? Why tell us about these other three options? Yes. Much, much earlier in the course we talked about project stages (see Term 1: Week 2). We actually assume that your default scenario is to have multiple stages of implementation. Technically speaking, we're referring to something slightly different here, so for clarity of communication, your project has Stages and your changeover could possibly have Phases. You could, for example, say that, in terms of project planning, you are launching all of your shelters in January. They're part of Stage 1 of your implementation plan. But right now, we're in the nitty gritty. You could do changeover phases within your project stages, and say that you are launching all of your shelters in January, but it's going to be one shelter per week for four weeks. Or you could do a parallel changeover for your case management stage. Or do a pilot changeover for your diversion stage. So just because you may have multiple stages to your HIFIS 4 project, that doesn't necessarily mean that you are committed to doing a phased changeover.

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 4, but it's a good reference for the overall project. In Term 4: Launch, look at the task lists in this resource entitled Deploy HIFIS: Launch Decisions and Support HIFIS Sustainability: Post-Deployment Decisions.

The resources required for your launch should be part of your roll-out plan, but we would be remiss if we didn't talk specifically about the resources you'll need to think about. Make sure you carefully read the Launch Checklist. Even if you give it a quick skim, you'll see that there are lots of boxes to check. IT Support Your IT Support will need to play a role in your launch. They need to make sure that the software is installed and configured and ready to go for your launch. Usually, they do the server set-up well in advance (i.e. a month before your launch), so this piece is not necessarily part of your crunch time. However, it's very important to work closely with your IT Support regarding the launch itself. If you're planning for 100 new users to just start using the software all at the same time, they should be prepared for that and for the possibility that something might go wrong. At a minimum, your IT Support should be on standby on your launch day itself. Note that you may also need your IT Support to be involved in the creation and support of a training environment that you'll be using prior to launch. Configuration Usually configuration is done by just one person, to reduce confusion on who is doing which parts, and usually that person is your Subject Matter Expert, but this isn't always the case. The job could be divided up, or done by IT Support, or by your partner agencies' super users. Regardless of who is doing it, configuration - or at least, the vast majority of it - needs to be completed prior to launch. Depending on how adept the users are who will be doing the configuration, and how complex your system is, this could take several full days. In most cases, this should be completed at least a week prior to your launch date (this is due in part to the fact that it could take longer than you planned). You'll need to make sure you're allocating resources to get this configuration piece done. Trainers A lot of users are going to need training (covered Term 4: Week 2), so you're going to need to have at least one person delivering the training. A lot of resources are going to need to go into training all of your staff before your launch, although depending on the training mode you opt for (more on that later), this might be in the days leading up to the launch or can be done in advance. User Accounts A component of configuration that we like to highlight separately is setting up and activating user accounts. HIFIS isn't super efficient when it comes to setting up user accounts. You'll either want to set them all up in advance, then spend some time on launch day activating them, or you'll want to set them all up on launch day. In any case, you need to allocate resources to make sure that user accounts are ready when staff need them.

Once HIFIS 4 is launched, your Legal Support no longer needs to play a significant role. Their main responsibilities included getting appropriate legal documents in place, and they should now be in place. However, that isn't to say that there is nothing for them to do. It's a good idea to ensure that you can access Legal Support in the future, but this is generally something that will happen rarely, and then in response to particular inquiries or events. Post-launch, your Legal Support may be called on for: Responding to a request for information, either by a client or a third party Responding to a PIPEDA compliance challenge, or similar Advising when there is a change in the data you want to collect (i.e. you expand and want to begin collecting photos of your clients, or their health information) Assisting when a new partner agency is onboarded, or an existing partner agency's contract is terminated Advising what steps to take when there is a data breach

One major topic left to cover before your changeover day: how to train all those staff? And how to make sure their user accounts are set up and ready to go? Training staff is a huge component of any new system, be it technological or not. You wouldn't expect to start a new Housing First program tomorrow and expect it to go well without making sure your staff know what they're doing first! Reference Materials HIFIS 4 Implementation Guide, Sections 3.3 and 5.4 HIFIS 4 Configuration Guide, pages 25-27

The training itself can take a number of different forms. In a pre-pandemic world, everyone mostly assumed that training would be conducted in person, but as a reminder, there are a variety of different approaches for training. In Person Students gather in a room with a teacher, who guides them through the material. This mode of training is preferred by some adult learners as it feels more personal, and can be preferred by management because it has a formal feel to it.  However, even while not in a pandemic, logistics can be difficult. This mode can cause lag, since people could require training almost any day, but it's impractical to offer on-demand in-person training.  In person training is the easiest way to monitor students and make sure they are actually being trained. Remote Remote training would be offered online through a screen-share and voice conference, such as over Zoom. This is preferred by some adult learners due in no small part to the fact that it's easy for them to not pay attention. But, some trainers also prefer this method since they don't need to travel to different sites, and it is easier on the logistics front. It's easier to make remote training more immediate; it could be offered remotely every week, for example.  However, keep in mind that for software training, users need to be able to see the presented material, while also accessing the software themselves, so without two monitors, this could be a bit challenging for some learners. Pre-Recorded You can offer in-person or remote training and record it, saving the recording for future use. Or you could simply record yourself or a trainer presenting to the camera. Then, once you have a video file, make it available to your staff that require training.  From a user's experience, this is somewhat similar to remote training, but it has the added advantage for students that they can pause the recording, take a break, and come back. From a logistics point of view, it can be difficult to record (which may require specialized equipment or software) and make available (may require payment for server space of some kind, or it could be posted on a public venue like YouTube which creates its own challenges). However, once it has been recorded and posted, managing it going forward is easy! You just need to give someone the URL and they click the play button. Keep in mind though that if a part of the software changes, you may need to rerecord the entire training session just for one 5-minute change. Asking a staff member to watch a video for several hours and then assuming they absorbed the material is not, however, a recipe for success. While some learners may thrive with this mode, others may struggle. To counter the possibility of learners not paying attention, it can be helpful to include a test at the end, so students can demonstrate that they did in fact learn. Learning Management System A Learning Management System (LMS) is the type of software you're currently using to take the Masterclass. It's an online course, where every user's individual progress is saved, and it can include whatever content you want - videos or text or quizzes. An LMS can be difficult to implement and develop. There's questions about the cost of the software and hosting, and once you find a platform you are happy with, someone needs to develop the content (which can be the same as in the pre-recorded mode). Hey, did you know we offer training for front-line staff through ACRE Consulting Academy? Because an LMS breaks things down into individual lessons, it's easy to update content if some small part of your process or the software changes. There's the same drawback as having a student watch pre-recorded training, and that is that they might just hit the play button and walk away. LMS software has the advantage of allowing you to build in quizzes to ensure that users have learned the content. Most software also issues certificates once content has been completed, so that's a great way to automate training. Once the content is ready, you hardly need to administer anything, just tell your student to go learn and come back when they have a certificate. Written Materials Finally, we shouldn't overlook written materials. Most software has user manuals available, for the types of learners who benefit from that sort of thing. Some students learn better by reading something than hearing it. However, having a completely written version of all of your training may be logistically impractical. While HIFIS does have user guides available, they are unlikely to provide guidance on how specifically you would like your users to be entering data and when, so you would need a lot of customization. Abbreviated guides, such as one-pagers and quick tip sheets can be helpful as an aid, but should probably not replace training. These materials can help provide someone who has been trained with a reference that they can go to for commonly asked questions without having to contact a support person.

You've spent a lot of time so far making careful decisions about how you will be using your software. I'm sorry to have to be the one to tell you this, but here it is: you didn't design HIFIS perfectly. There. I've said it. No matter how much time you've spent, and how great you think it is, there's something you overlooked. Maybe there's something that sounded great in theory but once you get to the real world, it's no longer great. Or maybe everything is in fact perfect, until the next software update comes out which causes you to rethink some of your earlier decisions. Or everything's working well until a change in funding requirements, or until a new program begins... That's normal. After implementation, you are going to be continually testing and tweaking your software to make it just right. The good news is it's going to be way easier to do so now that you're familiar with your whole system and what HIFIS can and can't do. This week's topic is managing changes, issues and bugs, and software updates.  

This week, we're going to talk about when users are unhappy with the software. Usually, when a user finds something wrong, they call it a bug. But as we will see, that's not always an accurate description. We are going to generally refer to these sorts of things as issues, not bugs.   There are a lot of different types of issues that can be found in a given software, and not all of them are bugs. The reason that we're making this distinction between bugs and non-bugs is in how you deal with them. Bugs are things that cannot be fixed by you, whereas a lot of issues can be resolved. Let's go through the various types: Bugs Everyone has heard the term bugs before. Specifically, a bug refers to a technical glitch in which the software does not work as the developers intended. When something should work but doesn't, that's a bug. When a bug is present, the only thing you can do is report the bug to the HIFIS Client Support Centre. Bugs tend to get resolved more quickly than other requests, but they would be fixed in a future update to the software, so at a minimum you must wait until the next software version. Some (made up) examples of bugs are: When a user selects a particular option in the "Reason for Turnaway" field, the user can't save the Turnaway record (this is made up, don't worry) When a user has the Display right for Health Issues, they can't actually Display the Health Issue unless they also have the Edit right for Health Issues (this is made up, but there have been similar real issues) When a user clicks the Reset Password button, the whole server crashes (also made up, don't worry) Non-Issues Next, let's talk about non-issues. A non-issue is when a user complains about something and there is no issue because what they're complaining about is by design. In this case, there's nothing to fix other than to explain to the user why things are the way that they are. Some examples of non-issues are: A user complains that when a client is booked in at another shelter, they can't book them in at the shelter they work at. It might look like a bug to them, but the cause of this would actually be because of the Concurrent Book-Ins setting. Many communities intentionally prohibit a client being booked in to multiple beds at the same time. So the user is complaining about something that is intentional. A user complains that when they create a Bulletin, users at other shelters can't read it. It might look like a bug, but the cause of this is because Bulletins, like many other things, are owned by the Service Provider that created it. Either this is a non-issue (that's how Bulletins are supposed to work) or a configuration issue (can be addressed through user rights). User Error A particular type of non-issue is user error. This sort of issue occurs when a user reports that something is broken or not working because they are doing something wrong. It might look like a bug to them, and you might be scratching your head trying to figure out why they have a bug and nobody else does, but when you look into it, you discover they are doing something quite incorrectly. We're highlighting this as slightly distinct from other non-issues because you can identify this as being fixable by more training, or maybe you'd just discovered a usability issue (see below). Some examples of user error are: A user complains that they can't book a client into a shelter bed, but they have the correct rights to be able to do so. When asked to show it not working, you realize that the client they are trying to book in has an active service restriction, and the user is getting a pop-up notification that they are ignoring. A user complains that any time they add a service restriction, it's not creating an alert for that client. You investigate and discover that all of that user's service restrictions have a start date and time equal to the end date and time, so the user had been successfully restricting the client for 0 minutes, and had done this several times because she thought it wasn't working. Configuration Issues Configuration issues are quite common. What this means is that someone set up some part of the software imperfectly and a user is discovering that they would prefer for it to be configured differently. In this case, it's almost always within your power to address. Some examples of configuration issues are: A user complains that there isn't an option that they need in a particular drop-down menu. The cause of this is someone not adding that option to the drop-down menu, which can be easily fixed. A user complains that they can't run a particular report. At first, that sounds alarming (maybe it's a bug?), but then you try to run the report and it works fine. After some investigation, you find out that a front-line staff is trying to run a report for administrators, and you've used Report Categories to configure who had access to the report. A user complains that they can't see a client's income records. The cause of this is because they don't have the user rights to do so; either this was a mistake (configuration issue) or intentional (a non-issue). Usability Issues Usability issues are not bugs, but are sometimes similar to non-issues. A usability issue is when the software is difficult to use, but nothing is actually broken. A note here is that a usability issue is often subjective. One user might find a usability issue with some aspect that another user has no problem with. There is nothing you can do about a usability issue except to request to the HIFIS Client Support Centre that they improve the software. However, since usability issues are often subjective and technically, nothing's broken, they are often considered to be a very low priority by the HIFIS Development Team and are addressed slowly. Some examples of usability issues are: A user finds it annoying that they can only select one goal per case. They're working on multiple goals with a client and they don't want to have multiple case files open. This is how the software is supposed to work, so nothing is broken, but the user would prefer that the software worked differently, so it's a usability issue. A user complains that they can't delete a Housing Placement they created in error. This sounds like it might be a bug (should work but doesn't) or a configuration issue (incorrect user rights) or even a non-issue (you've decided that they shouldn't have permission to delete Housing Placements). However, the way that a user can delete Housing Placements is via the Administration menu through Client Service Delete, so they might have permission to do so but they don't know how. This isn't intuitive, so it could be seen as a usability issue. Performance Issues Performance issues have to do with the technical performance of the software and the server that's running it. Time-outs, lagginess, and frequent downtime are all indicators of poor performance. Sometimes, performance issues can be resolved by your IT Support - perhaps the server that's hosting HIFIS 4 doesn't have enough memory or bandwidth. Sometimes, however, a performance issue is caused by some inefficiency in the software, and so it needs to be reported to the HIFIS Client Support Centre and addressed by them. Some examples of performance issues are: A user complains that it takes forever for reports to load, or a particular report when they run it for a long date range or for many clients. Users complain that they can't login to HIFIS 4 at 10:00 at night, when they are at their busiest. This suggests that too many people are trying to login at the same time and the server isn't equipped to handle it.

Almost there! Soon, your HIFIS implementation is going to be a thing of the past. You will no longer have to worry about onboarding your partners and will be able to enjoy the fruits of your labour. One of those fruits is having usable and high-quality data that you can begin to use to make data-driven decisions. Won't that be nice? The last topic we want to officially cover is how to make sure your data quality is high. It's one thing to tell everyone to use a new piece of software, but it's another thing to make sure they're using it well and that everyone is benefitting. Once you've launched, your ongoing focus is going to be on making sure your users are using HIFIS well. This week, we will leave you with some tips on how to manage this into the future.

In the United States, the Department of Housing and Urban Development (HUD) oversees homelessness programs nation-wide, and requires that every community (they call it a Continuum of Care or CoC) have a data quality plan. This is not required in Canada, but it is a good practice to be in. A data quality plan allows you to discuss as a community what everyone's expectations are for data quality, including benchmarks and monitoring. Your homework is to develop a data quality plan, but you don't need to submit it here. This is probably something you will be able to turn your attention to after your implementation is complete, so after you're done with this Masterclass. Download these resources and put this on your to-do list for later.

Shameless self-promotion time! There aren't a ton of good tools in HIFIS 4 for ensuring that you have top-quality data, so we at ACRE Consulting have put together a program called the Audit Boot Camp. We're publishing a series of premium reports that are designed to help you with your data quality, including: ABC Duplicate Clients helps improve your data's uniqueness by identifying duplicate client files, even when the names are misspelled or one has Declined - Anonymous consent. ABC Client Information Completeness helps to answer questions like "are my staff actually entering clients' sources of income, like they are supposed to?" ABC VI-SPDAT Timeliness helps you measure whether your staff are completing VI-SPDATS at the right stage in the client's experience of homelessness. ABC Rights Templates Usage helps you keep track of how many of your staff have access to which service providers and what rights they have where. And many more, with new reports published frequently!

Most communities implementing HIFIS 4 are not starting from scratch. The truth is, in a pre-HIFIS 4 world, communities did something to get data for reporting. What the something is, however, will have an impact on how you are going to approach the idea of data conversion. We're going to call this your current state. Your current state may look like any of the following (or even none of them): Some or all of your partner agencies are using HIFIS 3 Some or all of your partner agencies are using another data system, like WISH or YARDI or SAMS or COTS or ETO or Bowman Some or all of your partner agencies are doing their own data management, and might even have paper files or case notes stored in Word documents on various computers You have good data about a subsection of your homeless population - for example, those on the social housing waiting list, or those receiving social assistance - but are missing data for lots of other subsections You don't know how your partner agencies are currently managing their data You have a By-Name List that is stored in Excel or Google Sheets and a process by which people can make edits to the BNL As you can see, there's a lot of different current states that a community could be in prior to HIFIS 4 implementation. When considering whether you want to convert data from your old system to your new system, there's a few things you'll want to look at: Is the data valuable? Partner agencies could have prior data that is not particularly valuable or relevant. For example, they might have complete data for all the per diem billing a client had accumulated, which is important for an accountant but not as valuable for a Coordinated Access System. Is the data of high quality? A partner agency could have years and years of data of low quality. For example, they could record a nickname and an aggregated number of bed nights for each month (i.e. "Mickey" stayed for 17 nights in January 2015). If you're not able to get to identifiable clients and specific dates, the data might not be high quality. If the data is not valuable or not high quality, it might not be worth the effort to convert. How is the data currently being stored? If it's being stored on paper right now, then data conversion will look a lot different than if it's being stored digitally. If it's being stored digitally, how can it be exported? What are the resources we are willing to dedicate to data conversion? It's unrealistic to expect that you can just click a button and convert all your data perfectly, so you would need to manage the conversion. Do you have staff that can spend time on quality control? Do you have money available in the budget to contract an IT expert to facilitate the conversion? Do you have IT resources in house that will supervise this process? If your data isn't currently being stored nicely, and/or if you don't have resources available, it might be too difficult to convert your data.

If you are considering converting data from any previous source to HIFIS 4, there are several key considerations you should take into account. Consent Most legislation surrounding the collection, use, and disclosure of personal information states that when a client consents to have their information collected, it can be used and disclosed only for specific purposes. When converting from a non-shared data system to a shared data system, most communities therefore need to develop and implement new consent forms that include a clause stating that the client’s information can be shared with other agencies. Let’s assume, then, that your community is developing a new consent form for use with HIFIS 4. If you have a new consent form that states that information can be shared, and you begin using it as you move to HIFIS 4, that means all your previous clients have been signing consent forms that do not allow their data to be shared. Let’s further assume that you’ve been using your previous data system for some period of time, like 5 years. In that time, you’ve worked with a number of clients – hundreds, or even thousands – who have since been housed and are no longer interacting with your homeless-serving system. Or who have moved on to another city. Or who are currently spending time in an institution. It is nearly impossible for your community to ensure that you have valid consent to share personal information for all your past clients, if you weren’t initially collecting consent to do so from the start. What this means is you’re going to have some sub-section of clients in your current database whose data cannot be converted while still satisfying the terms of the consent they’ve provided. Similarly, you may have previously been collecting consent that was valid for a period of time, like one year, and could have a large number of past clients who have expired consent. So for them, you have no permission to do anything at all with their data. If you want to proceed with data conversion, you’ll need a way to ensure that you’re adhering to the legislation that allows you to collect personal information. This may mean converting only a select group of clients (those with appropriate consent), or it may mean converting all data but blocking access to the data for those who did not previously have permission to access it. Tip: It’s strongly recommended you consult with your Legal Support if you’re considering converting your previous data. Data Clean-Up A second topic to consider is the issue of data clean-up. At its simplest form, you may be considering taking one database and converting it from one format to another. This alone carries some risks of certain fields not transferring properly or data getting corrupted in the transfer. You are going to need to do at least one test conversion, and then perform a number of tests to see whether the conversion worked properly or not, identify what data pieces did not convert adequately, and address those issues. This is an iterative process, and there’s no telling how long this step will take. Resources – in particular IT support – will need to be assigned to this task. The problem is further compounded if you are considering taking two or more existing databases and merging them into one HIFIS 4 database. This is a likely scenario, considering that many communities might have two or more shelters, and the most common arrangement is for each shelter to be using an isolated HIFIS 3 installation. If you’re considering merging multiple databases, you’re going to have the added challenge of addressing duplicate clients. Even at its very best, software (in general) can only successfully identify duplicate people some of the time. Unfortunately, HIFIS 4 is not the best software at identifying and addressing duplicate records. There are several challenges with locating duplicate records. You might collect minimal information on clients and only have their name and age, or even approximate age. With limited information on each client, it’s hard to tell whether there’s an actual duplicate or two distinct clients with the same name. There could easily be two 40-year-old James Smiths or two 30-year-old Emily Martins. In fact, among my own social circle I know two different Daniel MacDonalds who live in the same city, have the same hobbies, and are the same age! Even if you collect more than just the bare minimum, there’s still a challenge. For example, two clients with a date of birth of 1980-03-06 and 1980-06-03 might look to a computer like two different clients, but one of the files might have been a data entry error from a staff who doesn’t remember if date of birth should be entered as YYYY-DD-MM or YYYY-MM-DD. Then there’s spelling errors and nicknames. For example, is William Jonson the same as Will Johnson? What about David Thomas-Brown and Dave Brown (and David Thomas)? Then you also could very well have clients who have changed their names after a marriage, divorce, or gender transition.   The point is, after conversion your merged database is going to be messy. You can manually merge duplicate clients in HIFIS 4, but you can only do so one at a time, so it can take a while if you have a large database. Several communities that have successfully merged databases have done so with the assistance of many dedicated resources, such as assigning extra personnel to data clean-up after merge. Tip: It’s recommended that if you’re considering converting your database, you have a frank conversation with your project team and your IT Support and determine how many resources are available to this step. If you find yourself at or over your budgeted resources, it may be a good idea to abort the idea of data conversion and start HIFIS 4 from a clean, blank database.

If you want to convert your data, there are two main ways to proceed: If currently using HIFIS 3, there is a HIFIS 3 to 4 conversion tool made available by the HIFIS Development Team; or, You could pay a third-party software developer to convert your data for you Third-Party Software Developers In theory, any similar-ish database could be converted to HIFIS 4 if you have someone with the appropriate technical skills to create a software program that will convert it for you. Again, theoretically, it's possible (however unlikely) that you have such a person on your staff right now. Certainly, there are a few communities in Canada that have developed their own HMIS software in-house and therefore do have the technical expertise necessary for a task like this. Most likely, however, you would need to contract out for someone to develop this software for you. In general, paying a third-party software developer is likely to be very expensive and is not recommended for most communities. Normally, we don't name communities that we use as examples, but hiring a developer to convert data from different databases into HIFIS 4 is part of the story in London, Ontario. The HIFIS 3-4 Conversion Tool There is a tool put out by the HIFIS Development Team that allows you to convert your HIFIS 3 database to HIFIS 4. However, it does have some idiosyncrasies of its own. The first thing to understand is it’s not very commonly used. While a number of communities are using HIFIS 3 today, and a number of communities are using HIFIS 4 today, a very small number of communities (perhaps 0) are using the conversion tool today. As a result, more software development resources are allocated to fixing bugs and adding new features to HIFIS 4 than to the conversion tool. If you call the support desk today and ask for the conversion tool, they may need to update the conversion tool (since it hasn’t been updated in 6 months, and there are new features in HIFIS that it doesn’t accommodate) before you can use it. There also may be bugs in the software, or it may cause bugs in your HIFIS 4 database that wouldn’t be present if you were starting with a clean, blank database. Related, you’re going to need to work with the HIFIS Development Team to do the conversion. It’s quite likely you’ll try a test conversion and something won’t quite work as intended. You can expect to spend time talking to the support desk and working through these issues, getting a few different updates and iterations of the conversion tool, and trying again. (Note that you can also expect the same thing if you have a custom conversion tool developed by a third party.) Third, it’s going to convert all of your clients, including the past ones. Their consent status should transfer over, but for better or worse, you’ll be converting your entire past history of clients, including ones you haven’t seen in ten years. This could potentially make your database very large, and if you’re server’s not built for that amount of data, slow down the software significantly. Finally, you have limited choice about what data gets converted and what doesn’t. You can select some options in the tool, but there are some pieces you’re stuck with. For example, it’ll convert all your Housing Units (which some communities have stated results in a lot of duplication) and all your People (which could be cause for some concerns regarding privacy). Tip: There are 3 municipalities in Canada that we know of who have used the HIFIS 3-4 conversion tool and then proceeded to launch with HIFIS 4. If you are considering this route, we strongly recommend you contact them (we can connect you) and learn from their experiences.

Assuming that you want to convert your client files, the question remains: how much of the content within them do you want to/need to convert? You probably want to convert shelter stays, but what else? Do you need all the case notes, all the incident reports, and all the past phone numbers? Back to consent for a moment – it’s possible that you were previously collecting some information (like health-related information) that your Legal Support is now telling you you cannot be collecting and storing in a shared database. So there might be some pieces of information that you’re not allowed to convert, even if the rest of the conversion project has been green-lighted by Legal Support. You’ll therefore need to decide what pieces of data you’ll be converting and what you’ll decide to leave behind. If you’re hiring a third-party software developer to build a conversion tool for you, this is an important decision. In general, the more information you want to convert, the more complicated the process and the longer it will take and the more it will cost. Even without the factor of a third-party developer, more data being converted means an increased risk that something will not transfer properly. If embarking on a data conversion project, it’s recommended that you consider carefully what your data requirements (see Term 3: Week 2) are before you proceed. It’s easy enough to say that you’ll just convert the whole database, but you may be inadvertently costing resources in order to convert a piece of data that’s ultimately not going to be important to anyone.