You can get a good grasp of the size and complexity of HMIS data by perusing the HUD's HMIS Data Dictionary [0]. It shows the business objects and their fields, allowing you to get a rough ERD-like idea of how the HUD views HMIS data. Many HMIS systems, from what I've heard and seen (I've only done a little work in the space), don't use this as a data model internally though or if they do it's not exposed that way through their APIs if they even have APIs that they're willing to let you use. Presumably though, they must have to report it that way to the HUD for funding.

I agree, it would be great to have a fresh, pragmatic take on this data, and I'll be reading more about that Built for Zero framework.

One Center of Care (CoC) I talked to talked about their old HMIS system from a private company who charged something like $70K/yr (iirc) to keep using their software. That seemed excessive to me, but they didn't seem to mind too much. Migrating off would have been extremely difficult anyway. Their bigger stated need was the ability to easily send data from their system to other CoC systems in the area as the people they were helping moved around or were transferred to more relevant services. Each time those people encountered another CoC, basically the intake process would have to be started over again at the new location, which was a drain on both the receivers and givers of services.

We tried a couple attempts at making a sort of hub for pulling and pushing data to the various systems, but only one entry system company was very supportive, while we had to tread carefully around some of the HMIS system makers who seemed very protective and unwilling to expose or share their APIs if they had any. One big challenge was finding a single unique identifier for each person across systems, which is why a local by-name list like the article mentions is very intriguing.

[0] https://files.hudexchange.info/resources/documents/FY-2022-H...