The HMIS data standards do not always address the business needs on the ground. The Project Descriptor elements include the CoC code, geocode, and project street address, thereby associating a project with a region. However, sometimes projects have multiple addresses, or has multiple grantees., and span multiple regions. In these cases, data really needs to be tracked by services provided, the type of funding used, or the location of the service, rather than a CoC boundry. In order to meet the reporting requirements, some organizations set up fake projects, or have to divide reporting into separate programs. This is an administrative burden with implications for cost, data quality, project participation, and project outcomes.

HUD’s response as reflected in the 2017 Data Dictionary states that, “residential projects that operate in multiple CoCs that cross HMIS systems must be documented in each CoC’s HMIS, even in cases where all client data are entered into a single CoC’s HMIS.”

The issue with this guidance is that it is re-purposing the concept of a project. According to the standards “a project refers to a distinct unit of an organization”. As soon as a project is split into multiple projects the integrity of the project is inherently weakened as it is no longer a singular distinct unit. Clients that are served by both prevention and re-housing for example will now need two project enrollments. Each will have a distinct project entry date, income for each could be different, household compositions could be different, and the exit dates could be different. What is the most recent assessment for the project? Well, since there are two different project IDs now there might be two “most recent assessments” with one for each project. If the client was enrolled in the prevention project and left to enter into the rapid rehousing project then he/she could technically be counted as both a leaver and as a stayer.

As organizations are instructed to have a universal ID for each client then the questions, such as demographics, that are specific to a client (and not his or her enrollment(s) in a project) tend to not be duplicated even if a project has been split into multiple sub-projects. The questions related to project enrollments however will tend to be duplicated which causes validation errors when submitting data to eSnaps.

Here is an example: The image below is an example of how VA and HUD jurisdictional boundaries can be quite different. The image to the bottom left shows the four VA VISNs that comprise Illinois and the image to the bottom right shows how Illinois is divided into 21 HUD CoCs. An exact physical location can be attributed to both a VA region and a HUD region whereas any multi-site project, which lacks a distinct physical location, cannot be attributed to a particular region given that the operating locations can be across boundaries.

If CoCs take HUD’s encouragement to merge then with this approach of enrolling clients into a project at a physical location there is no massive data migration required. The operating locations are simply reassigned to the new region type. The assignment of regions can also be done automatically during report run-time through the usage of the Region Designation Web Service that was developed by Simtech Solutions and was licensed to HUD as part of the Point in Time Mobile App project. The approach of using a web service that can detect what region a physical location resides also alleviates the need for data element 3.16 “Client Location”. With this new element, a HUD CoC is to be assigned at project entry. The web service approach is preferable since this element ignores the region types of other Federal partners altogether, creates an extra data collection burden for the end user, and is something that an end user could potentially get wrong. Since the Client Location data is gathered at a point in time, and it is not generated at report run time, then it will becomes obsolete and irrelevant if the boundaries of a region are changed over time.

SOURCE: Sharing Data on Homeless Veterans, VA Homeless Management Information System – DRAFT, Sep 2012.