should i make a custom table for that?

if hifis doesn’t have a spot for you to easily record what you want to record, there’s an obvious solution: add a custom table! but is that the right solution? maybe. or maybe not.

what is a custom table?

a custom table is a series of custom fields, that looks like a form, that you can design yourself. it’s then attached to another record, so you can think of it as a way to expand another module. this is most usefully explained with an example.

let's imagine you want to use the case management module. you know you'll be doing so, but one thing that is missing from it is a way to capture a case plan. you can create a custom table called "case plan" and attach it to the case management module. it adds extra fields that are effectively attached to the case file.

case_management_custom_tables

case management custom tables

in the image above, the case file actually has four different custom tables attached to it: a housing support coordination plan, a housing support plan, a crisis plan, and a safety audit. these could all be thought of as extra data that is or can be attached to an existing case file.

but case management is not the only place that custom tables can be added. you can add a custom table to nearly any module, including incidents, admissions, goods & services, housing units, service providers, and client details.

when is it a good idea to add a custom table?

it’s generally a good idea to add a custom table when all of the following are true:

you’re trying to collect a piece of data that there literally isn’t a place in hifis to collect. for example, whether they have pets; landlord engagement; children in care; or sexual orientation.
the module you want to extent with a custom table displays the custom table conveniently. (not sure what i mean by that? case management and client details are good. go add custom table to turnaways or goods & services and then try to add data to it.) not all modules that can host a custom table are good at hosting a custom table.
your overall data quality is pretty good. your staff are collecting data reliably and entering what they’re supposed to, and you can generally rely on your hifis data to answer your questions about homelessness in the community.
you are able to take ownership and support users as you begin to use hifis off-script. you’ll need to train them on something that there isn’t training available for, it’ll be harder for you to find existing reports that meet your needs, and there could be unforeseen future complications resulting from new hifis software updates that didn’t take into account your specific custom table.

when is it a bad idea to add a custom table?

it’s probably less of a good idea to add a custom tables if any of the following are true:

you’re going to be requiring people to double-enter something. for example, if you’re requiring staff to update the housing history of clients (which you should be doing, all the time, for every program), don’t also have a custom table asking how long someone’s been homeless for. or, if you’re requiring staff to complete the vi-spdat, don’t add a custom table that asks about tri-morbidity.
- why not? making staff double-enter data is never a good idea. it takes twice as long to do that, and so think about what is being sacrificed here. do you want staff to spend less time with clients, so that they can do redundant data entry? if you expect them to maintain the same number of hours with clients, then they’re still going to have the same amount of time for data entry, and they won’t be able to record everything you want. the data will be spotty and incomplete. the sacrificed data quality might not be specifically related to the custom table, though - it might mean sparser case notes or a delay in booking clients into and out of shelters or forgetting to attach documentation.
hifis already has a spot for you to collect the data, but you just don’t like that spot. for example, don’t create a custom table to collect income-related information since hifis already has an income module.
- why not? you’re sort of painting yourself into a corner. existing reports (and hypothetical future reports) will assume you entered the data in the built-in spot, and they’ll show a big fat zero for your data. if the module is so bad that you’d rather use a custom table, tell the hifis client support centre. chances are someone else thinks the same thing, and your concern can be addressed in a newer version of hifis. there could even be future updates to hifis that reference the module you are eschewing (for example, the diversion workflow includes data from the income module) that you’ll miss out on because all your data is in the wrong place.
you’re just at the beginning of your hifis implementation journey.
- why not? you should probably get a handle on how hifis is supposed to work before you start going off script. if you’re just at the beginning, you probably don’t know yet what the impacts of your potential configuration decisions might be, and so it’s good to start with using hifis as expected. this is the lowest risk approach.
you’re adding a custom table just to convince some cranky service provider to finally start using hifis.
- why not? allowing exceptions to standardized data entry for some providers is generally a recipe to have bad data. you start with a one-time thing here or there, and the exceptions start to grow and grow, and then you have multiple similar programs with wildly different methods for hifis use. in a few years, you’ll likely regret the decision and then struggle with how to fix it, because all their historical data is stored in a custom table you don’t want them using anymore. it also gives the impression that if they don’t like your data entry requirements, they don’t have to follow them.
you haven’t really tested the custom table, or you just thought of the idea today.
- why not? trust us when we say, test it first. add the custom table to your test site first (or to demo.hifis.ca) and then pretend you’re an end user and try actually adding data the way you’ll be asking them to do so. sometimes it might sound like a great idea on paper, but when you try it out, it’s super clunky. sometimes you have a custom table designed, but some of your fields are the wrong format (e.g. single-select versus multi-select. boolean versus datestamp. one record versus multiple records.). go through a few iterations of testing and see what works best.
you haven’t set aside resources for custom reporting.
- why not? asking staff to put information into hifis and then not allowing them to have access to the data is not a recipe for success. they’ll call hifis a black box that they put data into but never get anything out of, and your data quality will fall.

what else should i know about custom tables?

the most important things that you should know about using custom tables are the following.

first, you’re not going to be able to pull data out of your custom table (in terms of reporting) without a custom report. if your table was just to provide information for a caseworker, like in how to record a client's support network in hifis 4, you may not need a report for that. but if you wanted to add a custom table for, say, use in a prioritization report, you’ll need a custom report that pulls data from the right source. (as someone who writes these reports, let me tell you that reports referencing custom tables usually take two or three times as much time to troubleshoot as ones that do not.)

second, you could potentially be impacting your data quality in other areas. adding a custom table in one place is probably going to discourage people from going somewhere else and entering data there. sometimes, that’s a good thing. other times, not so much. consider carefully questions like: how long will it take for staff to use the custom table? is this going to make the software easier or harder to use? what could go wrong with this approach?

finally, try to think in the long term. introducing a custom table to fix a short-term problem might sound like a good idea at the time, but when the short-term problem is addressed, what will be the plan to decommission the custom table? how will staff retain access to the data they entered, without encouraging them to keep entering data in the custom table forever? if you are fine with using the custom table forever, okay. but if you’re not, you need to have an exit strategy in mind.

in general, adding a custom table isn’t a decision to be made lightly. if you think through the pros and cons and decide it’s a good idea, by all means, proceed. just don’t rush into it.

HIFIS Masterclass: Advanced HIFIS Use

Course Introduction

Mandatory & Disabled Fields

Look-Up Tables

Geographic Regions

Service Inventories

People

Advanced Program Use

Questionnaires & Surveys

Custom Tables

Housing Resources

Miscellaneous Configuration Bits