A Homeless Management Information System (HMIS) is the information system designated by a local Continuum of Care (CoC) to comply with the requirements of CoC Program interim rule 24 CFR 578. It is a locally implemented data system used to record and analyze client, service, and housing data for individuals and families who are homeless or at risk of homelessness.

HMIS is administered by the U.S. Department of Housing and Urban Development (HUD) through the Office of Special Needs Assistance Programs (SNAPS) as its comprehensive data response to the congressional mandate to report annually on national homelessness. It is used by all projects that target services to persons experiencing homelessness within SNAPS and the office of HIV-AIDS Housing. It is also used by other federal partners from the U.S. Department of Health and Human Services (HHS) and the U.S. Department of Veterans Affairs and their respective programs to measure project performance and participate in benchmarking of the national effort to end homelessness.

The HMIS Data Standards were first published by HUD in 2004 as the HMIS Data and Technical Standards. HUD, in collaboration with its Federal Partners, has continued to update the HMIS Data Standards regularly thereafter. Each updated document supersedes the previously released HMIS Data Standards. A complete historical archive of previous data standards can be found on the HUD Exchange Data Standards page.

An HMIS software must be able to collect all the data elements defined within these HMIS Data Standards, support the system logic identified, and ensure that the visibility of data elements is appropriate to the Project Type and Funding Sources for any given project.

Comparable databases are required for use by providers of services for victims of domestic violence, as described in the Violence Against Women Act (VAWA).

There are many software products on the market that communities across the county have chosen to use as their HMIS. Each product has unique features and was built to meet the different data collection needs of each community. Each software vendor should provide the guidance, support, and documentation necessary for the CoC to understand the system they are using.

Communities may elect to add data elements, add response categories, or maintain historical data element collection beyond what is specified in the Data Standards as long as it does not impact the ability of the CoC to accurately collect and report on the required data elements. In these cases, HMIS Leads should work directly with their HMIS software providers to meet their individual needs.


Related Documents

There are a variety of documents that comprise the suite of HMIS Data Standard resources. Each of the documents has a specific purpose and intended audience. The HMIS Lead should be familiar with all of the documents and collectively use them as their HMIS reference materials along with any supplemental instructional materials provided by the software vendor.

HMIS Federal Partner Program Manuals

These manuals contain specific and detailed information on project setup for each of the federal partners participating in HMIS including: HMIS project typing, the specific data elements required for collection by that federal partner, program-specific meanings and definitions, and key information that the federal partner has identified as required for their program. Each Manual was created jointly by HUD and the relevant federal partner, and approved by both entities prior to publishing.

Manual Name

Federal Partner

Program (s)

COC Program HMIS Manual

U.S. Department of Housing and Urban Development - Office of Special Needs Assistance Programs

CoC Program Information link

All Continuum of Care (CoC) Program component projects.

ESG Program HMIS Manual

U.S. Department of Housing and Urban Development - Office of Special Needs Assistance Programs

ESG Program Information link

All Emergency Solution Grant (ESG) Program component projects.

HOPWA Program HMIS Manual

U.S. Department of Housing and Urban Development - Office of HIV/AIDS Housing

HOPWA Program Information link

All Housing Opportunities for Persons with AIDS (HOPWA) program component projects.

PATH Program HMIS Manual

U.S. Department of Health and Human Services - Substance Abuse and Mental Health Services Administration   

PATH Program Information link

All Projects for Assistance in Transition from Homelessness (PATH) component projects.

RHY Program HMIS Manual

U.S. Department of Health and Human Services - Administration for Children and Families - Family and Youth Services Bureau

RHY Program Information Link

All Runaway and Homeless Youth program component projects.

VA Program HMIS Manual

Department of Veterans Affairs   

VA Program information link

Supportive Services for Veteran Families (SSVF), Grant-Per-Diem (GPD), and Healthcare for Homeless Veterans (HCHV) Veteran homeless programs.

VASH Program HMIS Manual

U.S. Department of Housing and Urban Development - VASH and Department of Veterans Affairs   

VASH Program link

Veterans Affairs Supportive Housing (VASH) program.



HMIS Data Standards Terms and Concepts

Continuum of Care (CoC) is used in multiple ways throughout the Data Standards:

HMIS User means the individual who uses or enters data in an HMIS or a comparable database approved by the CoC.

HMIS Lead means the entity designated by the Continuum of Care in accordance with the HMIS Proposed Rule (24 CFR Part 580) to operate the Continuum's HMIS on the Continuum's behalf. As of May 2021, the HMIS Rule is not in effect. When HUD publishes the final HMIS Rule communities will be given time to come into compliance with the rule.

HMIS System Administrator means the individual(s) whose job it is to manage the HMIS implementation at the local level: providing agency access to HMIS and managing appropriate use, supporting users through connection to, or direct provision of, user training, and overseeing system setup.

Project and Program are terms used to mean different things across the federal agencies. In this document, and for the purposes of data collection in HMIS, a program refers to the federal funding source (e.g., HUD CoC, HHS PATH, VA SSVF, etc.) whereas a project refers to a distinct unit of an organization as set up in the HMIS.


Data Element Structure

Every data element required by HUD and the Federal Partners to be stored within an HMIS is specified in this document. The following format is used to describe each data element:

Rationale: provides a basic explanation for data collection for the element and describes how the data are used in national or local reporting.

Data Collection Instruction: provides overall instructions for data collection and entry. Additional information regarding project setup and data collection instructions specific to an HMIS Federal Partner program can be found in the HMIS Federal Partner Program Manuals.

System Logic and Other System Issues: Describes logically required data collection or system structure information for HMIS software development purposes and information on rationale, conditions, constraints, etc. that may be applicable to a specific element and are important for HMIS software development purposes.

FY2022 Revision Summary: Documents the initial change(s) to the element from the 2020 Data Standard to the FY2022 Data Standard. Corrections made resulting in new FY 2022 Data Standard versions are tracked in Summary of Changes and by logical version numbering.

Data Element Number and Name:

Table Section

Information contained in the table

Field Number

The numbers assigned to the element fields.

Field Name

The names assigned to the element fields.


Dependent Fields and the Field/ Response category to which they are dependent.

The dependencies outlined are expected to be visible to users on-screen. The methods vendors use to make dependencies visible will vary by software provider/developer.

Response Category/ Data Type

All response options associated with the field, and their data type, if specified.

CLIENT REFUSED AND CLIENT DOESN’T KNOW RESPONSE OPTIONS: Most elements contain responses of “client doesn’t know” and “client refused.” It is not the intention of the Federal Partners that clients be denied assistance if they refuse or are unable to supply the information. However, some information may be required by projects or public or private funders to determine eligibility for housing or services, or to assess needed services.

The "Client doesn't know" or "Client refused" responses should not be used to indicate that the case manager or data entry person does not know the client's response. Nor are these responses to be assumed without first asking the client to provide the information. Some clients may decline to provide responses to some fields but case managers or data entry staff may not make that decision for them. At a national level, in every project type, a majority of clients are willing to provide identifying information. If a project is experiencing a high rate of client refusals as compared to similar projects, CoCs should consider implementing training around interviewing or trust-building techniques to support client engagement. A deeper engagement with clients may lead to more rapid movement off the street and placement in housing, consistent with meeting federal goals to end homelessness and improvement on HUD's System Performance Measures.

MISSING DATA RESPONSES: The HMIS Data Standards assume that fields for which data are not collected will be left blank (i.e., 'missing'). In situations where a system requires a response to all data fields before saving a record, the system must use a specific response category to indicate that data were not collected. In such cases, that response category must be treated as missing data for reporting purposes.

“Data not collected” continues to be identified as a response option in these HMIS Data Standards. It is not a response option necessary in every system or in every element. The element is required for use by any HMIS system which requires a response to an element before allowing the user to move forward in the system. Adding the response option of “data not collected” enables a user who did not collect or simply does not have the information to enter a response that does not present a false answer. HMIS systems which require entry of an element for the system to progress must implement the “data not collected” response for all elements that require a response. “Data not collected” must equate to missing data or null values as appropriate for transfer and reporting purposes.


General definitions and descriptions of fields and responses. Detailed, program- specific descriptions can be found in the HMIS Federal Partner Program Manuals, as applicable.  

Data Element Number and Name:

Table Section

Information contained in the table

Data Collected About

The universe of client(s) for whom an element response is required (e.g., all clients, heads of household, adults). Data may be collected about a wide group (e.g., all household members) but may be further limited in data reporting specifications.

Funder/Program Component

The federal department, the program, and the program component which requires the collection of the element. If a program component is not listed, it does not require collection of the element.

Project Type Applicability

The HMIS project type(s) required to collect and report the data element, as specified in element 2.02 Project Information.


The XML element in XML specifications where the data standard element is located.


The primary file in the CSV specifications where the data standard element is located.

Collection Point

The point(s) at which the data must be able to be collected in an HMIS. For data elements with multiple collection points, each record must be stored with the appropriate Data Collection Stage (as listed in metadata element 5.03). Data elements with only a single collection point need not be stored with any particular data collection stage, since their data collection point is inherent in their requirements.

Record creation – Indicates the element is required to be collected when the client record is created. Elements collected at record creation should have one and only one value for each client in an HMIS. Data are collected and entered into the HMIS, responses must be reviewed for accuracy at each project start and edited as necessary to make corrections or to improve data quality.

Project start (stored with Data Collection Stage of “Project Start” for elements with multiple collection points) – Indicates the element is required to be collected at every project start. Elements collected at project start must have an Information Date that matches the client’s Project Start Date.  Information must be accurate as of the Project Start Date. When a data element with multiple collection points is collected at project start, it must be stored with a Data Collection Stage of ‘project start.’ There should be one and only one record with a Data Collection Stage of ‘project start’ for each relevant data element for any given project start.  Data may be edited by users associated with the project to correct errors or omissions; such edits will not change the data collection stage associated with the record.

Occurrence Point/Update (stored with a Data Collection Stage appropriate to when they were collected) – Indicates the element may be collected and entered at any point during a project stay to track changes over time or document the occurrence of events (e.g. a service is provided). These types of records must be able to be entered at any point during the project stay.  Some data elements are collected once per project stay, but it may fall at any point during the project stay. For others, the system must be able to support a theoretically unlimited number of records per project stay, each with a distinct Information Date. The Information Date should reflect the date on which the information is collected and/or the date for which the information is relevant for reporting purposes. Information must be accurate as of the Information Date, regardless of when it is collected or entered into the HMIS. While data may be edited by users associated with the project to correct errors or omissions, accurate records should never be overwritten or discarded when update records are created. Corrections to existing records will change neither the data collection stage nor the information date unless it is explicitly altered by the user.

Annual assessment (stored with Data Collection Stage of “Annual Assessment”) – Data elements required for collection at annual assessment must be entered with an Information Date of no more than 30 days before or after the anniversary of the head of household’s Project Start Date, regardless of the date of the most recent ‘update’ or any other ‘annual assessment’. Information must be accurate as of the Information Date. The data collection stage may not be inferred from the Information Date, although the field must have an Information Date recorded with it. To be considered reportable to HUD as an annual assessment, data must be stored with a Data Collection Stage of ‘Annual Assessment’. The Annual Assessment must include updating both the head of household’s record and any other family members at the same time.

There should be one and only one record for each data element annually with a Data Collection Stage recorded as ‘annual assessment’ associated with any given client and Enrollment ID within the 60-day period surrounding the anniversary of the head of household’s Project Start Date. Regardless of whether the responses have changed since project start or the previous annual assessment, a new record must be created for each subsequent annual assessment such that it is possible to view a history, by date, of the values for each data element. Data may be edited by users associated with the project to correct errors or omissions; such edits will change neither the data collection stage nor the information date unless they are explicitly altered by the user.

Project exit (stored with Data Collection Stage of “Project Exit” for elements with multiple collection points) – Indicates the element is required to be collected at every project exit. Elements collected at project exit must have an Information Date that matches the client’s Project Exit Date.  Information must be accurate as of the Project Exit Date. When a data element with multiple collection points is collected at project exit, it must be stored with a Data Collection Stage of ‘project exit.’ There should be one and only one record with a Data Collection Stage of ‘project exit’ for each relevant data element for any given project exit. Data may be edited by users associated with the project to correct errors or omissions; such edits will not change the data collection stage or the information.

Post exit (stored with Data Collection Stage of “Post Exit” for elements with multiple collection points) – Indicates the element may be collected after project exit for a period of no longer than six months.

Relationship to Enrollment ID

Indicates cardinality of the element relative to an enrollment (Enrollment ID) and the client (Personal ID). This will often indicate "One or more" even though the element is only applicable to certain project types or funders which require the data element, and is further limited to clients described in the "Data Collected About" standard. "One or more” does not inherently imply the element should be collected on every client in HMIS. In general, elements recorded at least once per enrollment are required at project start. Elements recorded 0 or more times per enrollment might only be collected as needed or at exit, e.g. a referral.

Relationship to Personal ID




Project descriptor data elements (PDDE) are intended to identify the organization, specific project, and project details to which an individual client record is associated in an HMIS.

PDDEs enable the HMIS to:

  1. Associate client-level records with the various projects that the client will enroll in across continuum projects;

  2. Clearly define the type of project the client is associated with the entire time they received housing or services;

  3. Identify which federal partner programs are providing funding to the project; and

  4. Track bed and unit inventory and other information, by project, which is relevant for the Longitudinal Systems Analysis (LSA), Annual Homeless Assessment Report (AHAR), System Performance Measures (SPM), Housing Inventory Counts (HIC), Point In Time (PIT) counts, and utilization analysis.

This section describes the data to be recorded in HMIS for each project descriptor data element and its relation to each project for which data is being entered. Correct use of the 2.02 Project Information and 2.06 Funding Sources data elements will help assure that projects are identified for correct visibility and are able to generate reports required for each of the Federal Partners as reporting parameters will be based off of one or both of these elements.

Project descriptor data are generally entered and managed in an HMIS by the HMIS Lead, not a project end user. They are created at the initial project setup within the HMIS and should be reviewed at least once annually and as often as needed to ensure that reporting is accurate. The HMIS Lead, in consultation with the CoC, should develop a plan and timeline for routine review and updates to PDDEs. If any project descriptor data is entered or updated by project end users, the HMIS Lead Agency must have oversight and data entry/edit ability along with strong review procedures to assure timely, accurate and complete data.

At a minimum, HUD requires that the CoC (typically via the HMIS Lead Agency) collect project descriptor information in the HMIS for:

This is to facilitate AHAR participation.

If the HMIS database includes client and service data entered by non-continuum projects (e.g. food pantries or other services that might be used by people who are not experiencing homelessness), the continuum must identify them as such using the PDDEs to ensure that data are excluded from required reporting on continuum projects.

The following Project Descriptor Data Elements are required for project setup in HMIS:

2.01    Organization Information

2.02    Project Information

2.03    Continuum of Care Information

2.06    Funding Sources  

2.07    Bed and Unit Inventory Information



HMIS Project Setup Guidance

One of the most critical steps in accurate data collection and reporting is ensuring that a project is set up properly in an HMIS. If project setup is done incorrectly, this will jeopardize the ability to produce accurate, reliable reports.

Prior to creating a new project in the HMIS, the HMIS Lead should consult with both the organization administering the project and the CoC Lead Agency regarding appropriate responses for the PDDEs. Project Type and Funding Sources are particularly critical as they are the basis for setting up client-level data collection and for reporting. Project Types must be consistent with HIC and PIT guidance issued by HUD each year. Some HMIS applications automatically configure data collection based on Project Type and Funding Sources to ensure that minimum requirements are met. Where this is not the case, data collection for each project must be set up so that all data elements required based on Project Type and Funding Sources are available for data entry. The HMIS Project Setup Tool  identifies the required data elements for each funding source, project type, and funding source combinations.

For additional information on federal partner programs and related project setup guidance, refer to the applicable federal partner HMIS Program Manual.

Multiple Funding Sources

CoCs may have projects operating in their communities that receive funding from multiple Federal Partners for the same project to serve the same clients. There are a few factors he HMIS Lead will need to consider in these cases.

First, it is important that projects are set up in the system so all data elements needed for all required reports are “visible” to the end users. For example, a youth shelter may be funded through HUD's Emergency Solutions Grants Program (ESG) to support essential services and through HHS's Runaway and Homeless Youth (RHY) Program as a Basic Center Program. In this example, the project should be set up with a 'Project Type' (from data element 2.02 Project Information) of "Emergency Shelter" using the "Entry/Exit Date" 'Method for Tracking Shelter Utilization' (from data element 2.02 Project Information); it will show both "HUD:ESG Emergency Shelter" (operating and/or essential services) and "HHS:RHY Basic Center Program" as the 'Funder Program and Component' (from data element 2.06 Funding Sources). With the appropriate project type and correct identification of both funding sources, all elements required for both federal partner funding sources must be visible, and all data required for reporting to both funders can be collected. If the HMIS does not automatically configure data collection based on Project Information and Funding Sources, the HMIS Lead should reference the HMIS Data Standards to appropriately set the element visibility for the project.

Second, it is important to understand how projects are funded and what reports are required of each funding source because some projects receive funding from multiple funding sources for different eligible activities. For example, a project may receive a grant for residential operations/leasing costs and another grant for services. These two grants may be from the same federal program or two different federal programs. In these cases, HMIS Leads and project providers have two options:

  1. Create one project in the HMIS that both the housing provider and the service provider will jointly share and record data in, or

  2. Create two separate projects in the HMIS, one for the housing provider and another for the service provider.

Correct setup under either option is critically important to accurately record HIC/PIT information and to support correct system wide performance measures.

If a single project is created, the 'Project Type' (from data element 2.02 Project Information) will be the appropriate residential project type (e.g. Transitional Housing, Permanent Supportive Housing, etc.), and the 'Funder Program Component' (from data element 2.06 Funding Sources) will identify both funding sources/component types for the project.

If two separate projects are created, each project will be associated only with the specific federal funding source and component type appropriate to the grant.

Multiple Project Setup

There may be other circumstances within the HMIS implementation where a project that appears to be one project must be set up as two separate projects in an HMIS. Some common examples of this are:

  1. If one residential building has both emergency shelter beds and transitional housing beds, this must be set up as two separate projects, with the 'Project Type' (from data element 2.02 Project Information) 'Emergency Shelter' and 'Transitional Housing,' respectively. Clients moving from the shelter bed to the transitional housing bed, even if in the same building or funded by the same source, will require an exit from the shelter project and an entry into the transitional housing project. Similarly, a permanent housing facility may have both a permanent housing for persons with disabilities required for entry and other units without a disability requirement. Those must be set up as separate projects in HMIS.

  2. Projects that provide Homelessness Prevention and Rapid Re-Housing, whether funded by HUD or by the VA (i.e., under the Supportive Services for Veteran Families (SSVF) program) or another funding source, must be set up as two separate projects in the HMIS with the two distinct project types, even if they are funded under a single grant. In this case, the 'Grant Identifier' (from data element 2.06 Funding Sources) will be the same in both project setups.

  3. Permanent Housing projects are often created with a variety of rental subsidies. Unless the HMIS has the ability to identify the source and specific grant for a rental subsidy on a client-level basis, separate projects will have to be created in the HMIS in order to appropriately separate the client records for reporting purposes. A common example of this is the “pre-HEARTH” McKinney Vento Shelter Plus Care (S+C) program. Although operated as a unified project, different clients are served using rental subsidies from multiple S+C grants, each with a different operating year and grant number. In many systems, in order to accurately report which and how many clients are served under each separate grant, the grants are set up and maintained as separate projects in the HMIS unless or until the S+C grants are consolidated under the CoC Program.

  4. PATH projects may provide funding to one organization for both traditional street outreach services and supportive services such as case management to persons at-risk of homelessness. In such cases, PATH requires that two projects be set up in the HMIS, one with the 'Project Type' (from data element 2.02 Project Information) 'Street Outreach' and one with the 'Project Type' (from data element 2.02 Project Information) 'Services Only' to distinguish the projects' operations and reporting for PATH and to support system level performance measurement.

Projects that Operate in Multiple CoCs

In general, site-based projects funded by one CoC but located in another CoC have special setup requirements as described in this section. However, nothing about this instruction is intended to suggest that occasional client placement in another CoC via tenant-based voucher programs funded to serve a single CoC, for example, are required to set up projects and track clients at the Continuum level.

Some projects are funded to provide lodging and/or services to clients in only one continuum (e.g., CoC: Transitional Housing); others are funded to provide lodging and/or services across a geographic area that includes more than one continuum (e.g., some VA-funded SSVF projects). In these cases, funding recipients are expected by the Federal Partners to participate in the HMIS implementation of each CoC in which they operate projects. This expectation may be satisfied either by direct data entry into each HMIS or by entering data into a single HMIS and providing exports of client-level data to each HMIS, with appropriate agreements in place between the CoCs involved.

If the CoCs decide to enter data into a single HMIS and provide exports to the other HMIS implementations, it is critical to be able to track the clients by CoC to facilitate exporting the appropriate data. In order to do this, federally-funded projects that are funded to operate in multiple CoCs but are entering data into a single HMIS implementation must create a separate record for each 'Continuum Code' (from data element 2.03 Continuum of Care Information), consistent with the area served by the project according to their grant agreement with the federal funder. The associated 'Geocode,' 'Project ZIP code,' and 'Project Street Address' fields must reflect the location of the project's principal site in each CoC (or, for multiple site projects, the area in the CoC which most of the project's clients are housed). The ‘Continuum Codes’ selected in data element 2.03 would then be used to populate an option list of ‘CoC Codes for Client Location’ for data element 3.16 Client Location.

When deciding which CoC will directly enter data versus which CoC data will contribute via uploads, it is advisable to decide which CoC has the largest share of the funder’s clients. For example, a VA SSVF project providing services to clients in both a balance of state and an urban CoC must, after establishing appropriate agreements between the two CoCs, be associated with the 'Continuum Code' for both the balance of state AND the urban continuum. Note that if an SSVF project is expected to provide assistance to everyone in the catchment area then all of the CoC codes which cover the area must be selected. However, if the SSVF project only provides services to people in City X, and City X has a single CoC code, then select the code that applies to City X’s CoC only. If a project is funded to operate in multiple CoCs and is participating in the HMIS implementations of each separate CoC with a separate project created in each, only the CoC Code relevant to the HMIS implementation need be entered.



HMIS Universal Data Elements are elements required to be collected by all projects participating in HMIS, regardless of funding source. Projects funded by any one or more of the federal partners must collect the Universal Data Elements, as do projects that are not funded by any federal partner (e.g. missions) but have agreed to enter data as part of the Continuum of Care's HMIS implementation.

The Universal Data Elements are the basis for producing unduplicated estimates of the number of people experiencing homelessness, accessing services from homeless assistance projects, basic demographic characteristics of people experiencing homelessness, and patterns of service use, including information on shelter stays and homelessness over time.

The Universal Data Elements are the foundation on which the Longitudinal System Analysis (LSA) is developed. The LSA informs the AHAR, which provides Congress the national estimates of the current state of homelessness across the United States and the use of homeless assistance programs. The AHAR is a critical resource for informing the U.S. Interagency Council on Homelessness and other federal partners on the nature of homelessness in the United States and provides a unique longitudinal lens to inform homelessness policy nationwide. The LSA is also used locally via the Stella tool to inform communities on how their specific homeless information changes over time. Universal Data Elements also help local communities to better target resources and position programs to end homelessness.

Universal Identifier Elements (One and Only One per Client Record)

3.01 Name

3.02 Social Security Number

3.03 Date of Birth

3.04 Race

3.05 Ethnicity

3.06 Gender

3.07 Veteran Status

Universal Project Stay Elements (One or More Value(s) Per Client or Household Project Stay)

3.08 Disabling Condition

3.10 Project Start Date

3.11 Project Exit Date

3.12 Destination

3.15 Relationship to Head of Household

3.16 Client Location

3.20 Housing Move-In Date

3.917 Prior Living Situation


General Data Collection Guidance

Universal data elements are required to be collected by all projects participating in an HMIS, regardless of funding source. Data elements 3.01 through 3.07 are required to be collected once per client, regardless of how many project stays that client has in the system. If, upon Project Start in a new project, the data in these elements are observed to be incorrect or outdated, the data must be corrected in the client record. The remaining universal data elements are to be collected at least once per project stay. The timing of when the data are to be collected and about whom is noted in each data element.


Uses and Disclosures of Client Data

The Universal Data Elements in particular can lead to questions about what to enter in the HMIS if a client does not complete a "consent form" for the HMIS. When considering client consent in the context of HMIS, it is important to make a distinction between HMIS data entry and HMIS data sharing. At this time, there is no requirement that client consent be obtained to enter client information into HMIS. There is only a requirement that client consent be obtained in order to share information entered into HMIS with one or more other HMIS participating providers.

This means that it may not be necessary at all to obtain written consent from every client to simply enter the data into your HMIS. However, if your HMIS is configured in such a manner that information entered into HMIS is automatically shared with other HMIS participating projects, then client consent is necessary. Consult with your Continuum of Care and HMIS Lead Agency for more information. The privacy and security standards, as described in the 2004 Data and Technical Standards Notice, seek to protect the confidentiality of personal information while allowing for reasonable, responsible, and limited uses and disclosures of data. Additionally, the Coordinated Entry Management and Data Guide offers the most recent guidance on privacy in Chapter 2.



To meet the statutory and regulatory requirements of federally funded programs using HMIS, additional elements are required for different funding sources. The Program Specific Data Elements are elements that are required by at least one of the HMIS Federal Partner programs.

Some of the program specific data elements are collected across most Federal Partner programs. These are called “Common” Program Specific Data Elements.

The HMIS Federal Partners have cooperatively developed these elements. For each Program-Specific Data Element, multiple response categories are provided. Projects may choose to capture more detailed information (or finer response categories), but only if this information can be exactly mapped to the required response categories described in this section. For reporting purposes, an HMIS must be able to produce required reports using the response categories exactly as they are presented in this section.

Local CoCs may elect to require all continuum projects participating in HMIS to collect a subset of the data elements contained in this section to obtain consistent information across a range of projects that can be used to plan service delivery, monitor the provision of services, and identify client outcomes. CoCs and projects are encouraged to develop their own data collection protocols and assessment tools to fully assess client service needs.

Common Program Specific Data Elements

4.02 Income and Sources  

4.03 Non-Cash Benefits  

4.04 Health Insurance

4.05 Physical Disability  

4.06 Developmental Disability

4.07 Chronic Health Condition  

4.08 HIV/AIDS  

4.09 Mental Health Disorder

4.10 Substance Use Disorder  

4.11 Domestic Violence  

4.12 Current Living Situation  

4.13 Date of Engagement  

4.14 Bed-Night Date

4.19   Coordinated Entry Assessment

4.20   Coordinated Entry Event

Many additional elements have been developed by the Federal Partners, but are limited to one or two Federal Partner programs or a single component of one of the Federal Partner programs. More detailed guidance about how to use these Federal Partner-specific data elements can be found in the HMIS Federal Partner Program Manuals.

An HMIS must have the ability to enable and restrict visibility of elements for each project based on the reporting requirements of the Federal Partner program funding the project. An HMIS may do this in whatever manner the software provider chooses (hard coding, customization via system administrators, etc.). HMIS vendors should note that no Federal Partner expects that any project would have all elements visible to the user. The strong preference among the Federal Partners is that only the elements required for the programs that fund a specific project are visible to the users at that project.

Federal Partner Program Data Elements

Program specific guidance issued through HUD and the individual Federal Partner in the HMIS Federal Partner Program Manuals provides program setup and visibility information and definitions relevant for the partner. The Federal Partner Program Components are intended to help HMIS Lead Agencies and their federally funded partner programs to collect and report according to the HMIS Data Standards.


Continuum of Care (CoC)

C1 Well-being

C2 Moving On Assistance Provided

C3 Youth Education Status


W1 Services Provided - HOPWA

W2 Financial Assistance - HOPWA

W3 Medical Assistance

W4 T-cell (CD4) and Viral Load

W5 Housing Assessment at Exit

W6 Prescribed Anti-Retroviral



P1 Services Provided - PATH Funded

P2 Referrals Provided - PATH

P3 PATH Status

P4 Connection with SOAR



R1 Referral Source

R2 RHY-BCP Status

R3 Sexual Orientation

R4 Last Grade Completed

R5 School Status

R6 Employment Status

R7 General Health Status

R8 Dental Health Status

R9 Mental Health Status

R10 Pregnancy Status

R11 Formerly a Ward of Child Welfare/Foster Care Agency

R12 Formerly a Ward of Juvenile Justice System

R13 Family Critical Issues

R14 RHY Service Connections

R15 Commercial Sexual Exploitation/Trafficking

R16 Labor Exploitation/Trafficking

R17 Project Completion Status

R18 Counseling

R19 Safe and Appropriate Exit

R20 Aftercare Plans



U1 Worst Housing Situation



V1 Veteran's Information

V2 Services Provided - SSVF

V3 Financial Assistance - SSVF

V4 Percent of AMI (SSVF Eligibility)

V5 Last Permanent Address

V6 VAMC Station Number

V7 HP Targeting Criteria

V8 HUD-VASH Voucher Tracking

V9 HUD-VASH Exit Information



The term metadata is often defined as 'data about data.' Instead of capturing information about a project or a client, Metadata Elements capture information about the data itself: when it was collected, when it was entered into HMIS, who entered it, and which project is responsible for it.

The Metadata Elements are intended to facilitate reporting from HMIS, to simplify the writing of programming specifications, and to provide an audit trail. These elements do not represent an attempt to standardize the way that an HMIS stores data. As long as the HMIS is able to accomplish the purposes identified for the Metadata Elements, the software is not required to use the exact metadata elements listed here. Future programming specifications for reports will reference these Metadata Elements. The Metadata Elements are:


5.01    Date Created 

5.02    Date Updated

5.03    Data Collection Stage

5.04    Information Date

5.05    Project Identifier

5.06    Enrollment ID

5.07    User Identifier

5.08    Personal ID

5.09    Household ID




Some project types are more complex and require additional data collection instruction. Although the following information is also provided within each individual data element, it is all collected here for ease of reference for HMIS Leads, System Administrators and End Users managing these project types.

Street Outreach


Coordinated Entry

CoCs with HUD-funded SSO-CE projects are required to collect Coordinated Entry (CE) data elements in HMIS. Also, regardless of funding source, all CoCs are strongly encouraged to collect CE data in HMIS using these standardized elements.

CE data collection implementation may vary based on CE project setup, and CoCs should collaborate with HMIS Leads and vendors to ensure proper HMIS set up to meet data collection and reporting requirements. Depending on whether a CoC's system has a single front door or multiple front doors to CE, the HMIS setup may include one CE project or multiple CE projects.

Beginning October 1, 2021, all CoCs with a CoC Program CE grant will be required to produce a CE-specific Annual Performance Report (CE APR). The CE APR is unlike other CoC APRs in that it is generated across the entire CoC rather than a specific project. Additional information about the CE APR can be found in the CE APR Programming Specifications.

On occasion, it is expected that a Continuum project that does not participate in HMIS by collecting and entering client-level data will be a source of information about the whereabouts of a client. The Current Living Situation data element will be one factor in reporting to determine whether a CE client is still actively seeking assistance. As a result, it may be necessary for the CE project to record that element on behalf of a nonparticipating project. In those cases, the CE project will use the field ‘Living Situation verified by’ to document the Project Name of the project that reported an updated status for the client during case conferencing.


'Night-by-Night' Emergency Shelters



'Entry/Exit' Emergency Shelter and Transitional Housing

Day Shelter


Permanent Housing: PSH and RRH