Reporting on Households in ART! Oh My!

Share on:

Navigating the homeless services landscape as a family can be very stressful and often leads to sometimes heartbreaking changes in household configurations, before, during, and after program stays. Capturing this kind of data can be especially tricky since not only are the situations complex, but the data objects themselves are sometimes confusing, and deciding on how to show your data can be very difficult, as the level of detail you could actually get to is excruciatingly granular. Let's start with the major players:

Client ID: a single unique Client ID per client record. Generally one Client ID per actual client, but this is not guaranteed in the case of closed systems where users are duplicating entries. Neither is it guaranteed in the case of users in open systems simply making mistakes, duplicating clients. This post will assume your system is not closed and your users never create duplicate clients. :)

Client Unique ID: a deduplicating mechanism that uses client name, DOB, SSN, and other factors to cobble together an ID number. Even though it is called the "Client Unique ID", it is not necessarily unique, especially when there are duplicate clients (or twins!). So you can just remember that the Client Unique ID is not unique and the Client ID is unique. :) Something else to realize about this Client Unique ID is that it is dynamic and will change as the data (such as SSN or DOB) on a client changes.

Household ID: a unique ID generated for each household created. This ID is not reliant on there being a program stay or a service, it simply belongs to the client record. Household IDs are, however, attached in the software to Entry Exits, ROIs, Services, Referrals, etc. One client can have more than one Household ID if they have been a member of more than one Household. Households (at least for our implementation) are modified if something changes during a program stay. New households are created if something changes between program stays. It is not necessary for users to create a household for single clients, however in our implementation, we do.

Household Relationship: each client in a household gets assigned a Relationship, like sibling, spouse, etc. If the client is the Head of Household, the relationship should be "Self". It is possible in the software to not answer this question. This field is not used anywhere in any HUD reports but users generally do a good job filling this field in correctly.

Head of Household (HoH): a yes/no field. There should only be one HoH per household, however the software allows you to select none or more than one, as of this writing.

Household Type: a pick list that describes household types like Single parent, Couple no children, etc. This field is not used in any HUD reporting.

Group ID: a unique ID generated for each Entry Exit record, only populated if the Entry Exit has more than one person attached to it. All clients included in an Entry Exit would share the same Group ID, and for singles, this field is null.

Group UID: like the Group ID, but for Singles, it returns the Entry Exit ID so that there are no nulls. Perfect for counting Households served.

Entry Exit ID: a unique ID generated for each client associated to an Entry Exit. It's like the Group ID, except it increments per client. So all the clients included in a single Entry Exit will all have different Entry Exit IDs.

Entry Subgroup ID: a unique ID that combines the Group ID, a dash, and then an assigned number that is the same for everyone who entered the Entry Exit together.

Exit Subgroup ID: a unique ID that combines the Group ID, a dash, and then an assigned number (different from the Entry Subgroup ID) that is the same for everyone who exited the Entry Exit together.

So if a household entered a program with 5 people, then one left on their own, and then the other four left together, they would all share the same Entry Subgroup ID, and then the one separate household member would have a different Exit Subgroup ID from the other four who exited together later.

To count household members involved in an Entry Exit, you would use the Client ID ForEach (Group UID).

To show how many households had changed composition during a program stay, you could use a combination of Client ID, Group ID, Entry Subgroup ID, and Exit Subgroup ID. For instance you could compare the count of clients per Entry Subgroup ID to the count of clients per Exit Subgroup ID to find this.

To show how many clients were served in multiple households during a reporting period, you could use the Household ID, Group UID, and Client ID to find how many clients were served more than once, and then of those, how many had more than one Household ID during that time period.

To count how many two-parent families vs single women parents vs single men parents, is actually more tricky. If your implementation has those specific Household Types, and the data quality on those answers is good, then it would be easy enough to use Household Type and Household ID and Entry Exit ID to figure that out. However, if your Household Type choices do not distinguish between women single parents and men single parents, then you would need to use Gender also to figure it out.

Displaying data about households is tricky because there are so many nuances to consider. As if the data objects weren't difficult enough to decipher, the everyday realities of trying to capture complex human relationships in a database create a tricky landscape to navigate. There is no way to detail all the ways to use HMIS data to paint a picture of family homelessness, but hopefully it helps to understand the data objects that are available to us and how they work!

Also please note you can refer to the Universe Guides in ART to learn more about Households (and many other things!) They are located in the Bowman Systems Resources > Bowman Systems Published Documents > Universe Guides. Highly recommended reading!