2020 HMIS Data Standards

2020 HMIS Data Standards: Final Reminders and Pro Tips

 

Hello System Administrators,

As you know, the FY 2020 HMIS Data Standards went live in the system on October 1, 2019. All necessary updates to your system should now be implemented in alignment with the 2020 HUD HMIS Data Standards.

New Minimal Profile Screen:

  • A new System Client Profile screen ‘[2020] Minimum Intake’ option is now available. This profile screen, if preferred, can be used by agencies who do not need to collect the Data Standards Element V1 “Veterans Information” data within their programs. Please note that this screen will still contain UDE “3.07 Veteran Status.”

SSVF and VA Funded Programs:

  • The SSVF Services Provided and Financial Assistance Service Updates Guidance have been updated to reflect that the new SSVF Service Items required for SSVF-funded programs are for Rapid Re-housing and Homeless Prevention program types. The new SSVF Rapid Resolution program type does not require SSVF services to be configured as per the HUD HMIS Data Dictionary.
    • Please note: The SSVF Rapid Resolution program type does require data element ‘4.20 Coordinated Entry Event.’ Therefore, please be sure to configure ‘Coordinated Entry Event’ and its associated service items to the Rapid Resolution programs. Please refer to Coordinated Entry Data Elements for more details related to configuring ‘Coordinated Entry Event’, and the VA Programs HMIS Manual and the FY 2020 VA Data Guide regarding SSVF Rapid Resolution data collection requirements.
  • In addition to configuring the new SSVF service items for SSVF-funded program types Rapid Re-housing and Homeless Prevention, ‘V2 Services Provided - SSVF’ service collection is optional for GPD and HCHV-funded programs, as per the VA Programs HMIS Manual. Therefore, if collecting SSVF services for these programs, the new SSVF service items should be configured to these programs, as appropriate.  

PATH-Funded Programs:

Important reminder: When working with PATH projects, the PATH Status field is collected at ‘Occurence Point,’ and there is only one Occurence Point per project stay. Therefore, it should only be entered once. It can be entered on either the Entry, Status, or Exit Screen. Once entered, it should not be updated or changed, aside from fixing data entry errors.  

The PATH Program Manual, states: ‘The date of PATH enrollment should be entered into the HMIS at the point that the client has become enrolled. It may be on or after the project start date or engagement date and prior to project exit. If the client exits the project without becoming enrolled, the PATH Status element still needs to be completed, indicating that the client was not enrolled and the reason the client was not enrolled.’  

There should only be one unique PATH Status Date response, and unique ‘Client Became Enrolled in PATH/Reason Not Enrolled’ response per Client Program Enrollment. The ‘PATH Status’ fields on the ‘Exit’ screen are required, as clients should not be exited from PATH programs without the client’s PATH Status entered.   

Therefore, when entering a client’s ‘Date of Status Determination’ and ‘Client Became Enrolled in PATH’: It should be reflective of the date the client’s eligible PATH Status was first determined. Whether it is on the Enrollment, Status, or Exit screen, it should be reflective of the date the Client’s PATH Status was determined, and the same ‘Client Became Enrolled in PATH’ field response.  

Changing the date of PATH enrollment/PATH Status on subsequent screens after it is originally entered will affect if/when a client is considered ‘Enrolled in PATH’ which could subsequently impact PATH reporting. Enabling Program Set Up features such as ‘Enrollment Data Cascade,’ as well as training users, will help eliminate occurrences of conflicting dates and status being entered.    

RHY BCP Programs:

Important reminder: When working with RHY BCP projects, the RHY BCP Status field is collected at ‘Occurence Point,’ and there is only one Occurence Point per project stay. Therefore, it should only be entered once. It can be entered on either the Entry, Status, or Exit Screen. Once entered, it should not be updated or changed, aside from fixing data entry errors.  

The ‘RHY-BCP Status’ fields for RHY BCP programs are collected on the Enrollment/Status/Exit screens, as the RHY Program Manual states: “The RHY-BCP Status occurs on the date when eligibility for RHY Services has been determined. The RHY-BCP date of status determination may be on or after the project start date.” There should be only one unique ‘Date of Status Determination’ response and unique ‘RHY BCP Status’ response per client enrollment. The ‘RHY BCP Status’ fields on the ‘Exit’ screen are required, as clients should not be exited from the program without the client’s ‘RHY BCP Status’ entered.  

Therefore, when entering a client’s ‘RHY BCP Status’ information, regardless of if it is on the Enrollment/Status/Exit screen, it should be reflective of the date the client’s RHY BCP Status was first determined, and the RHY BCP Status at that time of status determination.  

Changing the RHY BCP Status Determination Date and Status on subsequent screens can potentially affect how the client is reported. Enabling Program Set Up features such as ‘Enrollment Data Cascade,’ as well as training users, may help with these occurrences of conflicting dates and status being entered.

If you have any questions about implementing these updates, please reach out to our friendly Technical Support staff at support@bitfocus.com, and they will be happy to assist you.

 

Thank you,

Your Data Standards Update Team