Undesirable data is any information in HMIS that undermines accuracy, completeness, timeliness, consistency, privacy, or compliance. It affects clients, agencies, funders, and community-level reporting. As the system transitions to Global Visibility (go-forward only), any data you can see for an unlocked client may appear in your reports even if another agency entered it. This article defines undesirable data, shows how to find it in Community Services, outlines the exact steps to fix it, and provides preventative steps so your projects stay clean, compliant, and report-ready.
What Counts as Undesirable Data?
1. Missing Required Fields
Leaving required fields blank creates gaps in reporting and eligibility checks. Missing data prevents accurate APR validation and can cause federal report rejections. These fields are essential for compliance and performance measurement.
Examples include:
- Missing Date of Birth (DOB), which prevents age validation and household logic.
- Blank Social Security Number (SSN) or missing SSN data-quality flag.
- No Race/Ethnicity, Sex, or Veteran Status recorded.
- Missing Prior Living Situation at entry or Exit Destination at exit.
-
Income or Disability sub-assessments are missing or blank
2. Invalid or Placeholder Values
Placeholder or fake values undermine data integrity and create duplicates. They fail validation checks and distort client counts.
Examples include:
- Names like “Sample” are entered as legal names.
- SSNs such as 999999999 or sequential patterns like 123456789.
- Impossible dates, such as DOB after project start or exit date before entry.
3. Logical Contradictions
Contradictions occur when fields conflict with program rules or other data in the record. These inconsistencies trigger errors in data quality and reporting.
Examples include:
- Veteran Status = Yes for a minor.
- Disabling Condition = No while disability sub-assessments indicate “Yes.”
- Enrolled in PATH but missing Date of Engagement or Status Determined.
4. Overuse of “Client Doesn’t Know,” “Client Refused,” or “Data Not Collected”
These picklist values should only be used when truly applicable. Overuse hides real client information and skews program metrics.
Examples include:
- All income fields are marked as “Client Refused” without any attempt to collect data.
- Housing status is marked as “Data Not Collected” for every assessment.
- Annual assessments completed entirely with “Refused” responses.
5. Duplicates and Overlapping Enrollments
Duplicate profiles and overlapping enrollments inflate counts and cause confusion. They distort utilization and length-of-stay calculations.
Examples include:
- Two profiles for the same person with slightly different spellings of their name.
- A client enrolled in two emergency shelter projects at the same time.
- Overlapping dates in the same project when only one enrollment should be active.
How to Detect Undesirable Data
-
Run Data Quality Reports: The APR and the Data Quality Business Object reports are designed to identify data errors within your project. Running these reports on a consistent frequency will help catch errors before they pile up.
-
APR Documentation - https://hmis.allchicago.org/hc/en-us/articles/360000404183-Running-and-Understanding-the-APR-and-QPR-Report
-
Data Quality Report Documentation - https://hmis.allchicago.org/hc/en-us/articles/360040178351-Running-and-Interpreting-the-Data-Quality-Report
-
- Assessment History: Check the history of the assessment values to determine if an error was entered by mistake. The history bar will show you the effective dates, source provider, and user creating the value.
- EVA: EVA is the best tool to identify any data errors and ensure your project meets HUD requirements.
- Search Before Creating: Always search multiple ways to avoid duplicates. If you encounter a duplicate client, please submit a merge request.