HUD PIH Notice § 2020-02

                         U.S. DEPARTMENT OF HOUSING AND URBAN DEVELOPMENT
                                       WASHINGTON, DC 20410-5000




OFFICE OF PUBLIC AND INDIAN HOUSING


Special Attention of:                                  Notice PIH-2020-02
Public Housing Agencies (PHA);
Section 8 and Public Housing Administrators            Issued: February 26, 2020
HUD Directors of Public Housing
PIH Program Center Coordinators
Public Housing Division Directors                      Expires: Effective until
                                                       amended, superseded, or
                                                       rescinded

                                                       Cross References:

Subject: Section 209 of the Economic Growth, Regulatory Relief, and Consumer
Protection Act: Guidance for Shared Waiting Lists
    1. Purpose: Through this notice, the U.S. Department of Housing and Urban Development
       (HUD) complies with Section 209(e) of the Economic Growth, Regulatory Relief and
       Consumer Protection Act of 2018, Pub. L. No. 115-174, by providing guidance regarding
       how to facilitate the voluntary use of shared waiting lists among public housing agencies
       (PHAs) and owners of multifamily properties that receive assistance from HUD. This
       notice also describes and responds to public comments received in response to the
       Federal Register notice entitled “Section 209 of the Economic Growth, Regulatory
       Relief, and Consumer Protection Act: Initial Guidance” (84 FR 4097). Because of
       differences in the way that PHAs and owners of HUD-assisted multifamily properties
       operate, this notice focuses on shared waiting list software and common application for
       PHAs.

    2. Background: Section 209(e) of the Economic Growth Act (signed into law May 24,
       2018) requires HUD to make software available that would facilitate the voluntary use of
       shared waiting lists among PHAs and owners of multifamily properties receiving
       assistance from HUD. Additionally, HUD is required to publish procedural guidance for
       implementing shared waiting lists and how to obtain the software.
         On February 14, 2019, HUD published a notice in the Federal Register (84 FR 4097),
         soliciting comments on implementing shared waiting lists.




                                                  1
          HUD specifically sought comment on:
                   HUD’s suggested definition of “shared waiting list software;”1
                   The types of PHAs and owners might be best candidates for shared waiting lists;
                   Unique needs of owners of HUD-assisted multifamily properties;
                   Software security needs in providing access to, and using, shared waiting lists;
                   Examples of operational shared waiting lists; and
                   The role of HUD in the development and support of such software.

        3. Public Comments: In response to the February 14, 2019 notice, HUD received a wide
           variety of comments from five organizations that represent PHAs, multifamily property
           owners, and a nonprofit policy institute. The following list summarizes the comments
           HUD received by topic area.

   i.     Definition of “shared waiting list software”. Definition of “shared waiting list software”.
          Commenters agreed with HUD’s suggested definition of “shared waiting list software” which
          was defined as “software that enables a household to submit a single application to get on
          multiple waiting lists”. Commenters also suggested that voluntary waiting lists be based on
          geography (limited to state boundaries), and internal lists that encompass all housing
          assistance programs as possible methodologies for defining “shared waiting list software”.
          HUD Response: HUD is further clarifying that “shared waiting list software” as
          any computer program or script that enables a household to submit a single application for
          multiple waiting lists, which will be accessible by multiple interested PHAs. This approach
          was supported by public commenters and offers a variety of demonstrable benefits to
          families, PHA staff, and property managers.


  ii.     Best candidates for a shared waiting list. Commenters suggested the best candidates for a
          shared waiting list may be: PHAs that convert to project-based vouchers or rental assistance
          under the rental assistance demonstration (RAD) program; PHAs and owners that receive
          applications from similar applicants; PHAs that share a geographic area of jurisdiction, and
          PHAs in densely populated, urban areas where there may be many smaller PHAs with
          overlapping service areas, or places where there is a county-wide PHA whose service area
          also encompasses smaller town or city-level PHAs. As an example of shared waiting list
          working in a shared geographic area, a commenter noted that in Massachusetts a statewide
          Housing Choice Voucher (HCV) waiting list is shared because all PHAs have statewide
          jurisdiction under law, which allows a PHA to administer any vouchers issued from the
          waiting list.



1 HUD’s suggested definition of “shared waiting list software” was “software that enables a household to submit a single

application to get on multiple waiting lists” (as opposed to software that allows multiple PHAs to select prospective tenants from
a single waiting list).


                                                                2
                    HUD Response: HUD agrees that PHAs and owners that operate programs, or
                    possess characteristics noted by commenters above, may be good candidates for
                    shared waiting lists. However, HUD acknowledges that there may also be other
                    programs/characteristics that could lend entities to be good candidates for shared
                    waiting lists. As discussed later in this notice, HUD is not mandating common
                    applications or shared waiting lists, nor is HUD making specific recommendations as
                    to the types or locations of PHAs that should be considering a shared waiting list or
                    common application. Rather, this notice is providing information about some
                    administrative and policy considerations that may help guide PHAs in making the
                    operational decision to adopt a common application or shared waiting list with
                    another PHA.

           iii.     Unique needs of owners that may make using a shared waiting list difficult.
                    Commenters noted that owners may face difficulties when using a shared waiting list.
                    This includes challenges related to integrating a shared waiting list with Violence
                    Against Women Act (VAWA) restrictions, incorporating waiting list management
                    into a management review (HUD Form 9834 - Management Review for Multifamily
                    Housing Projects) and identifying other owners or PHAs that are interested in a
                    shared waiting list.

                    HUD Response: HUD agrees that covered housing providers2, in the context of
                    implementing VAWA, including owners (or representatives that administer
                    programs on their behalf) of HUD-assisted multifamily properties, may face
                    difficulties implementing a shared common application or shared application pool.
                    HUD’s guidance for PHAs and owners/management agents (O/As)3 regarding
                    requirements for implementing the VAWA Final Rule, for example, state that: (1)
                    PHAs, O/As, employees (or those who administer assistance on their behalf,
                    including contractors) must not have access to the information unless explicitly
                    authorized by the PHA or O/A for reasons that specifically call for these individuals
                    to have access to such information under applicable Federal, State, or local law (e.g.,
                    the information is needed by a PHA employee or O/A to provide the VAWA
                    protections to the victim); and (2) they may not enter any of this confidential
                    information into any shared database or disclose this information to any other entity
                    or individual, except to the extent that the disclosure is: requested or consented to by
                    the individual seeking VAWA protections in writing, required for use in an eviction
                    proceeding, otherwise required by applicable law.




2 A “covered housing provider” refers to the individual /entity that operates a covered housing program, as defined by each

program in its regulations, and that has responsibility for the administration and/or oversight of VAWA protections; incl. PHAs,
sponsors, owners, mortgagors, managers, state and local governments or agencies thereof, nonprofit or for-profit organizations.
3 An entity that owns, has possession of, or is responsible for day-to-day front responsibilities for a property assisted under a

multifamily program.


                                                                  3
       The prohibition against entering this information into any shared database, however, does
       not preclude a PHA or O/As from entering this information into a database system used by
       the PHA or O/A that meets all requirements for securing sensitive personally identifiable
       information (PII), including the Privacy Act of 1974 (5 U.S.C. § 552a), as long as the
       requirements listed above and provided at 24 CFR 5.2007(c) are also met. For more
       information see 24 CFR 5.2007, PIH 2017-08, and H-2017-05.

iv.   Software security. Commenters noted that any software system with shared access should
      be handled through a secure network, which includes data encryption, database security and
      backup, protecting the confidentiality of personal information, and determining who has
      accessed personal information. The commenters added that the information could be stored
      on protected HUD servers or the servers of outside vendors contractually obligated to meet
      industry standards in safeguarding personal information.
      HUD Response: HUD agrees. The notice provides guidance on software security
      features (i.e., tools) and functionalities (i.e., how tools are used) that should be
      addressed to ensure PII is safeguarded and protected in accordance with federal,
      state and local laws.

v.    Examples of implemented shared waiting lists. Commenters noted the success of the
      Housing Link system in Minnesota and the effectiveness of the Massachusetts system. The
      latter includes a single application that is simultaneously added to all housing choice voucher
      waiting lists, an applicant ranking system based on the preferences described in the
      administrative plans of the participating PHAs, and a software platform provided by private
      vendors who also offer technical support and training for the PHAs and call center support
      for applicants.

      HUD Response: HUD reviewed the application and waiting list management processes of
      PHAs in Maine, Massachusetts, Minnesota, Mississippi, Rhode Island, Utah, and other states
      and determined that shared waiting list software (as defined by HUD) can reduce the time
      burden on families, administrative burden for PHAs and owners and create administrative
      efficiencies.

vi.   Mapping and Neighborhood Characteristics. Commenters suggested that any software
      should give users the ability to enter a location, locate all subsidized housing within a
      selected distance, and provide information on neighborhood characteristics (such as school
      quality and accessibility to mass transit) where subsidized housing is located.

      HUD Response: HUD is opting not to develop and maintain this type of software because it
      would not allow PHAs or owners/agents to customize the product to best suit their needs; it is
      inconsistent with the approach that HUD has taken with Form HUD-50058 (Family Report),
      Form HUD-50059 (MTW Family Report) and inspection protocols for its rental assistance
      programs, where HUD has defined the parameters for software, and allowed the commercial
      market to develop the software. HUD believes that the private market can adapt more quickly
      to emerging technologies than HUD can.
                                               4
vii.     General comments. Commenters supported shared waiting list software as a burden-
         reducing measure for PHAs and applicants alike, suggested HUD engage with private
         vendors for the development of shared waiting list software, and requested additional clarity
         on how the software would work. Commenters also suggested that the software should
         include:

             The ability to create an official record of selection from the waiting list in order to
              demonstrate and record that an applicant was correctly selected from the PHA’s waiting
              list in the order described in their administrative plans (Section 8 Management
              Assessment Program - Indicator 1);

             Either the full range of HUD rental assistance programs on the waiting list, or just one
              program, at the PHA’s discretion;

             Allow an applicant to easily make changes to an application and apply those changes to
              all of the waiting lists the applicant is on;

             Allow applicants to find out their waiting list position; and

             Give applicants the option to fill out a paper application and submit it to a PHA to enter
              into the system.

         HUD Response: HUD has taken these comments into account and provides guidance to
         address these concerns for consideration.

    4. Methodology of Shared Waiting List Software, Common Applications, and Shared
       Applicant Pools. Based on public comments and a review of application, waiting list
       and selection processes for several small, medium and large PHAs, HUD is providing
       guidance that facilitates the use of shared waiting list. This notice provides a definition
       and description of shared waiting lists, common applications, shared applicant pools and
       their core features and suggested functionalities, respectively. It also includes
       administrative and technical considerations for effective planning and implementation.

         The suggested features and functions referenced are not intended to be exhaustive, but
         rather considerations that facilitate discussions with PHAs receiving HUD assistance.
         The development of shared waiting list software and common application solutions
         should include input from appropriate stakeholders.4



4 Although the terms “application” and “software” are related, and sometimes used interchangeably, they are not synonymous.

An application (common application) is related to a feature or a tool. It allows families to provide and update information. The
software is related to functionality. It allows multiple PHAs or owners of multifamily properties receiving assistance from HUD
assistance to access application information.

                                                               5
         After reviewing public comments and studying existing practices, HUD defines shared
         waiting list software as “any computer program or script that enables a household to
         submit a single, common application for multiple waiting lists.” A common application
         is defined as “a single application form that is used by more than one PHA.” In order to
         effectively utilize a common application, it must be interfaced with shared waiting list
         software. An output of the common application and shared waiting list software is a
         shared application pool, a scenario where a group of PHAs have access to common
         applications of applicants to one or more of their programs, which are maintained in a
         database.
         Based on public comments and review of application processes, HUD determined that
         many PHAs in Massachusetts, Mississippi, Utah, Rhode Island, and Maine currently
         utilize a single, common application and shared waiting list software (as defined above)
         to share information. However, they maintain a unique waiting lists for each
         participating agency, and select families according to selection polices described in each
         agency’s Administrative Plans.5

    5. Definition of a Common Application for PHAs and Required and Suggested
       Functionalities of a Common Application. A common application is a single
       application form that is accepted by more than one PHA. A common application offers
       clear benefits to families seeking housing assistance, PHAs and property managers.
       Using a single application to apply to multiple PHAs saves time and reduces the
       complexity and confusion about the application process for families.
        a. Common Application – Requirements: The common application form must meet all
            HUD requirements for applications, including those found at 24 CFR Part 5, subpart
            L and 24 CFR 982.201 seq. and 24 CFR 960. At a minimum, the information
            collected must be sufficient to enable the PHA to select participants from its waiting
            list. These include, but are not limited to:
                  Applicant name
                  Applicant social security number (SSN)
                  Household composition
                  Required unit size
                  Income information
                  Citizenship status
                  Consent to a criminal background check and income verification




5 Salt Lake County and Salt Lake City use common application for both its HCV and public housing programs.



                                                             6
          The application form must also contain any additional information necessary to make a
          preliminary determination about overall program eligibility for the program in question
          and allow applicants to indicate which PHA(s) and program(s) they are applying to.6
          Any electronic form must comply with digital accessibility requirements, including the
          effective communication requirements under Section 504 of the Rehabilitation Act
          (Section 504) and the Americans with Disabilities Act (ADA), and Section 508
          requirements (see Section508.gov), state/local security requirements, and various
          state/local web standards. Specifically, HUD reminds PHAs that they must:
                    Take appropriate steps to ensure effective communication with individuals with
                     disabilities through the use of appropriate auxiliary aids and services whether
                     forms are electronic or hard copy, pursuant to Section 504 and the ADA;

                    Take appropriate steps to ensure that applications are accessible, particularly to
                     individuals with disabilities, elderly populations, and Limited English Proficiency
                     (LEP) populations by translating such materials into languages other than English.
                     For more information regarding LEP requirements, please refer to HUD’s LEP
                     webpage.

                    Be able to process paper applications to accommodate individuals who are unable
                     to access an electronic form. Otherwise, they must offer a reasonable
                     accommodation, or alternative application processes for those populations.

          Since an application form involves PII, HUD would remind PHAs about their
          responsibilities to keep this information secure. PHAs using a common application
          should procure a single protected, encrypted submission process. PHAs must comply
          with State/local security requirements and the transmission of applications must be
          managed in such a way that PII is always properly secured and should be only accessed
          by PHAs to whom the applicant has selected can see it. See PIH 2015-06 for more
          guidance on Privacy Protections for Third Parties.

     b. Common Application - Suggested Functionalities: HUD recommends that the application
         clearly state and collect enough information for all participating PHAs to properly
         determine waiting list status for applicants, including local preferences. It should also
         ask if the applicant requires a designated accessible mobility unit, a designated
         accessible sensory unit, a unit with mobility or sensory features, or any reasonable
         accommodations.

     6. Shared Applicant Pools: A shared applicant pool is a group of PHAs that maintain a
        common database of all applicants to one or more of their programs. To be feasible,


6
  Determination that an applicant “family” meets the income limits of a HUD program and has provided specific information and documentation
of other family information (i.e., Social security number and citizenship information).
                                                                     7
these PHAs must use a common application to reduce discrepancies in applicant-
provided responses. Applicants would indicate that they were applying to one or more of
the participating PHAs.
A shared applicant pool is easier to manage with a software solution. Application pools
require information to be available to multiple PHAs at a time, which suggests a need for
a common database that can be accessed securely and remotely. The database would
allow participating PHAs to generate a unique waiting list for their PHA from the
applicants in the database, using criteria and preferences selected by the PHA. See
Section 8, Implementation Considerations – Use of Preferences for additional
information.
PHAs in areas that are densely populated, particularly those that have geographically
proximate or overlapping jurisdictions are good candidates for a shared applicant pool.
This allows applicants to reduce the amount of time spent on the application process, but
also allows them to submit applications to more PHAs. This would give individual PHAs
a broader application database. It also can reduce administrative burden by freeing up
staff time to perform other functions.
An example of a shared applicant pool is the pool maintained by the Massachusetts
Chapter of the National Association of Housing and Redevelopment Officials
(MassNAHRO). MassNAHRO maintains a shared applicant pool for approximately one
hundred PHAs. By in large, as a public commenters noted, they use a common
application and shared waiting list software to “generate a unique waiting list for each
PHA by sorting all applicants based on the PHA’s local preferences, which typically
include a local preference for households living or working in the PHAs jurisdiction.”
Their pool has multiple features that enhance the efficiency of a shared applicant pool,
such as sending reminders to applicants to update their contact information periodically,
and a dashboard where applicants can see the status of their application and update their
profile with new demographic information.
   a. Core Features of Shared Applicant Pools: The core features for a shared
      applicant pool include the same features of a common application. In addition, to
      be feasible, this likely needs to be an electronic database of some type.
      Applicants would need to be able to apply to one or more of the participating
      PHAs. The database would then allow participating PHAs to generate a waiting
      list from the applicants in the database, using criteria and local preferences
      selected by the PHA.

   b. Technical and Functional Suggested Features: There are over 3,000 PHAs that
      administer HUD’s public housing and/or HCV programs throughout the United
      States and its territories. With such diverse organizations (and needs), there are
      many technical and functional features that should be consider when developing a
                                         8
                    shared applicant pool. See Appendix A, Technical and Functional
                    Considerations for more information.

     7. Implementation Considerations (Common Applications and Shared Applicant
        Pools): The use of a common application or shared applicant pool is a voluntary choice
        on the part of participating PHAs, and the benefits of the system against the cost of a
        common application or shared applicant pool must be weighed.

          Before beginning the process of creating a common application or shared applicant pool,
          PHAs should evaluate the goals and objectives that they are seeking to achieve. The
          solution selected will depend on the results of that evaluation. Implementing either (or
          both) a common application or shared applicant pool may:
               Increase housing opportunities for families, and help improve vacancy/occupancy
                  rates;
               Reduce burden on applicants; and
               Allow PHAs who prefer a regional approach to assisted housing to work together
                  on their admittance policies.
          Before starting the procurement and development process, in order to determine the scale
          of automation and functionality that will be needed for implementation, HUD
          recommends that any PHA that wants to start a common application software, or tool
          process, reach out to nearby PHAs. In doing so, potential partnering PHAs should
          consider (for example):
                   Establishing an ongoing management process for maintenance, updating
                    functionalities, procedures for transferring existing applications to a new shared
                    applicant pool, purging the shared applicant pool, etc. This should be formalized
                    through either a memorandum of understanding (MOU) or a memorandum of
                    agreement (MOA);

                   Developing a process for handling applicants who have received or rejected
                    assistance from another PHA; and

                   Developing policies on how much information a participating PHA should be able to
                    see about decisions made about an applicant by other PHAs, such as rejection from
                    the waiting list or an offer of assistance from another PHA.7


7 Per 24 CFR 982.205, PHAs cannot remove an individual from a waiting list for the housing choice voucher program or change

their position on the waiting list based on their receiving or turning down other housing assistance, including public housing. For
the public housing program, HUD would remind PHAs that there may be “good cause” reasons that an applicant has turned down
a unit at a PHA, such as the unit being inaccessible to employment or educational facilities. This should not prevent an applicant
from receiving other offers of assistance.


                                                                9
8. Implementation Considerations (Use of Preferences): PHAs are strongly cautioned to
   carefully consider the fair housing and civil rights implications of any preference that
   might be adopted, and to undertake the appropriate programmatic steps to implement
   such preferences.

   Furthermore, PHAs maintain their responsibilities for establishing an application and
   selection processes that are fair, consistent, ensure compliance of Federal statutes and
   regulations including civil rights and fair housing laws, and preserve the integrity of its
   programs. HUD regulations require that all families have an equal opportunity to apply
   for and receive housing assistance, and that PHAs affirmatively further fair housing goals
   in carrying out Federal programs. See 24 C.F.R. § 5.105(a)) for a description of the
   nondiscrimination and equal opportunity requirements applicable to PHAs. As such, the
   PHAs’ application and selection policies, and any local preferences must be stated in its
   Administrative Plan and/or Annual Plan.

   HUD reminds PHAs that selection criteria and preferences for admission must be
   selected very carefully after conducting a thorough analysis of the fair housing
   implications; failure to do so may result in the risk of shared liability across the waitlist.
   Special care should be used by PHAs to ensure that criteria and preferences do not
   discriminate on the basis of race, ethnicity, disability, familial status, or any other
   protected class, under Federal, State, and local fair housing and civil rights requirements.
   Furthermore, PHAs are required to PHAs are required to adhere to court orders or
   settlement agreements, conciliation agreement, or Voluntary Compliance Agreements
   with the government or a private party. See 24 C.F.R. § 960.206 for the Public Housing
   program; see 24 C.F.R. § 982.207 for the HCV program.

   Additionally, PHAs are considering “homelessness” as a preference, for example, should
   consider coordinating and standardizing definitions of homelessness. PHAs should agree
   on whether an applicant must be living on the street or in a shelter to be considered homeless,
   or whether the definition is broad enough to include those without a permanent residence

   and who are residing at friends’ or families’ housing or are in a temporary situation such as
   living at a motel.

   Participation in a shared system should not constrain the PHA’s ability to advance other
   requirements or policy goals such as establishing local preferences to prioritize working
   families, or targeting homeless individuals or persons receiving supportive services for
   assistance.

9. Vendors: HUD is not recommending specific vendors for software development.
   Instead, HUD recommends contacting local industry groups such as the National
   Association of Housing and Redevelopment Officials and the Public Housing Agency
                                             10
   Director’s Association for information about vendors who have developed similar
   software or have the capacity to develop software for PHAs.

10. Information Contact: If you have any questions, please contact Nora McArdle -
    (Nora.C.McArdle@hud.gov), Office of Policy Program and Legislative Initiatives, Office
    of Public and Indian Housing, Department of Housing and Urban Development, 451 7th
    Street SW, Washington DC 20401. Persons with hearing or speech impairments may
    contact this number via TTY by calling the toll-free Federal Relay Service at 800–877–
    8339.




                                                              /s/
                                       R. Hunter Kurtz, Assistant Secretary
                                       for Public and Indian Housing




                                          11
                                        Appendix A
Technical and Functional Considerations: There are a host of technical and functional features
that should be considered when developing a shared applicant pool. Many of the features center
around usability for front-end and back-end users; functionality of the application; interface
requirements that allow software to be used in various web-browsers; security/system
requirements; case management functions to manage application processes; and modest (or
wide-ranging) reporting and data analysis functions. Some of the considerations are listed
below.
          a. Usability. PHAs should work with the software developer to test the system for
             usability by both PHA staff and applicants. This should be done with actual
             program participants, and PHA staff. Software development should include a
             development environment, a test environment, and production environment,
             training environment, along with the ability for change control.

          b. Interface Requirements. PHAs should make sure shared applicant pool software
             incorporates the following:
                    a Web browser interface to view data and system modules and
                       components using all commercially available browsers such as Internet
                       Explorer, Firefox, Safari, etc.;
                    the ability to interface with or include a document management system;
                    a user interface for mobile devices;
                    a speed optimized screen processes for frequent and repetitive data entry
                       tasks;
                    the ability to import and export data in a variety of standard formats,
                       including fixed width, comma quote delimited, Excel spreadsheets, and
                       PDFs;
                    the ability to interface with the new system to upload and export
                       applications and other data; and
                    extranet access for approved PHAs/parties.

          c. Security/System Requirements. The shared applicant pool software should
              comply with various system requirements and therefore should:
                    allow or restrict, by user or group on multiple levels (e.g., System
                     Administrator, Local Administrator, PHA administrator, applicants,
                     reviewers the ability to access, or update data);
                    create an audit trail for every field that was added, changed, or deleted
                     (and sometimes viewed) and should also be able to track the details of an
                     individual applicant, a type of applicant or program, a PHA or the entire
                     system;

                                              12
          include the ability to easily query detailed data and totals for use in
           reports;
          include a secure log-on for all administrators and applicants;
          maintain historical data of every field changed in the system;
          include the capability to detect and track software bugs;
          be able to be backed up using common disaster recovery strategies;
          include a process to purge the waitlist which should be managed by a
           central administrator using both standard mail and email; and
          include the ability of the PHA to add individuals to the pool themselves,
           such as when a Project Based Voucher (PBV) participant is moving from
           their unit and needs to be added to a PHA’s Housing Choice Voucher
           (HCV) waitlist.

   PHAs may want the system to have the functionality of an internal administrative
   development tool(s) that allows certain management users selected by the PHAs
   to be able to make changes to certain forms and functionalities of the shared
   applicant pool software without the need for external programming services. This
   would allow PHAs to make changes to these areas based on changing
   programmatic needs. Identifying which users, their roles, functions, and
   limitations of their ability to make changes should be spelled out by agreement by
   all PHAs participating in the database.
d. Online Services. The shared applicant pool system should include online services
   for applicants, PHAs, and the public. The requirements for online services should
   include:
      the ability to allow an applicant to apply for specific program(s) and
         locations (for the PBV program), as well as perform other tasks related to
         the application including updating information and checking on status;
      a secure log-in capability that provides authorized access to secure applicant
         data;
      the ability for applicants to view their own data for tracking the status of the
         application, data corrections, and updates, and to remove themselves from
         the applicant pool at their discretion;
      the ability for applicants to update their contact information on a continuing
         basis;
      the ability for applicants to amend their application with updated
         information that corresponds to local preferences, such as homelessness
         status, or veteran status—this should include a warning to applicants if such
         changes will possibly place them lower on the waiting list and PHAs are
         further warned not to rely on this information without a duly adopted
         preference that complies with fair housing and civil rights requirements;

                                    13
        alerts for applicants if they are about to be purged from the shared applicant
         pool and, when applicable, information on remedial actions that can be
         taken to avoid being purged;
        the ability to upload and store document attachments (.pdf, .doc, .gif, etc.) as
         a part of the application process, particularly a history of the applicant’s
         background;
        the ability to selectively block personably identifiable information from
         view; and
        an extranet function that allows approved PHA staff to obtain and enter
         applications.

e. Application Functionality. The software should allow PHAs to customize their
   workflow and manage their current application processes. Some of application
   functions to be considered should be:
      the ability to allow applicants to apply online, or for PHAs or an applicant
         representative to apply online on behalf of an applicant;
      the ability to alert the applicant of missing required data during the
         application process and not allow an application to be submitted until all
         information is complete;
      the ability to allow staff to process and track all initial applications and
         updates;
      the ability to perform an automated review of the applicant at the time of
         submittal to establish the basic eligibility of applicants based on data
         provided including income and household composition;
      the ability to determine the types of programs and the range of unit size the
         applicant is eligible;
      the ability for an applicant to track an application, which includes milestone
         and due date tracking with alerts and reminders for upcoming or overdue
         documents; letters; and tasks, as well as memo fields so that applicants can
         input information;
      the ability to generate notifications, both as part of a batch process and as
         part of an on-demand process;
      the ability to search for and identify duplicate applications to ensure that
         each application is unique;
      the ability to assign a unique ID number to each applicant that will stay with
         them throughout the process;
      the ability to prompt staff to verify contact data at set intervals; and
      the ability to transmit alerts through multiple methods, including Short
         Message Service (SMS) text messaging and email.


                                     14
f. Case Management Functionality. The software should include functions to
   manage the application processes. The application functions that should be
   considered are:
      the ability to establish uniqueness of applicant;
      the ability to define and log types of events or actions relating to an
         application (e.g., submittal of application, changes to application, offers of
         housing, and refusals of offers of housing);
      the ability to define and utilize types of reminders relating to the
         application (e.g., alert and remind applicants of a purge of the system, offer
         of housing or request for additional information or need to respond);
      the ability for authorized PHA staff employees to attach documents to
         specific applications as a record of applicant history that other PHAs can
         see (e.g., criminal background checks, employer references, student
         transcripts, PHA history); and
      the ability to assist applicants with their applications with phone and email
         support (e.g., forgotten password, username, waitlist status).

g. Data Analysis and Reporting. The shared applicant pool software should be able
   to generate reports, dashboards based on stored data in the databases and various
   types of outputs (e.g., reports, letters, reminders). The output functions that
   should be considered are the abilities to:
     generate letters, mailing labels, emails, correspondence;
     edit correspondence;
     generate mailing labels;
     create a variety of “canned” reports;
     create ad-hoc reports, defined by user; and
     create real-time display/dashboards of information from the shared applicant
        pool.




                                    15