housing inventory service

Function

A web service that stores, retrieves, and enables editing of current and historical housing unit inventory. Unit level housing inventory is required, so that the proper per-unit capacity is matched to the correct household size. For each unit, we will store:

• housing unit uuid
• project uuid (which indicates project type)
• address
• number of beds (actual)
• number of beds (max)
• unit vacancy (boolean)
• unit in service (boolean)
• reservations
• client assessment id (VI-SPDAT)
• client id
• metadata
• family/single/unit (boolean)
• notes
• metadata

#Functional Requirements of Housing Inventory Storage Component

• All functionality must be exposed via an API posted at Housing Inventory Anypoint API Site
• All API calls must be authenticated via HMISLynk's existing OAuth service with normal HMISLynk user accounts
• Housing Inventory Manager should be a new role set up within HMISLynk's user service

#Technical Implications of Housing Inventory Storage Component

database schema changes to add per unit tracking (aggregate already exists)

web service implementation

use existing auth service, role based access controls, HMIS APIs, and notification microservices

API publishing on AnyPoint for app developers to reference

per unit eligibility:

• a new table called eligibility requirements, that has the unit id as the foreign key. Then how do we represent a requirement? Just a series of random text strings, or do we have predefined picklists?
  • eric [3:26] Maybe a date range constraining the effective/end date of the requirement. Also Gender picklists. Age category picklists, etc..
  • javier [3:27 PM] That is actually something we have been working on as well. I think we need fields for all UDEs and income, disability, housing status and residence prior to project entry not to mention age [3:27] And chronically homeless calculation

Testing

Documentation

original image is here