Cascade enrollment/update data to auto exits - Stop the Data Not Collected madness
Currently, auto exits only populate the Destination with No Exit Interview, everything else is Data Not Collected. Why is it not assumed that the enrollment or most current assessment data is not relevant for an auto exit? If the client walks away from the shelter, and is manually exited, the data cascades, assuming their situation has not changed. The auto exit makes their exit outcomes worse, and Data Not Collected makes our Systems Performance Measures sink deeper than the Titanic. These happen to be some of our error rates for the latest CAPER -
Destination-85.93%;
Income and Sources at Annual Assessment-82.93%;
Income and Sources at Exit-85.37%.
The State is expecting that error rates should be under 25%. The funding coming into our communities is affected by bad data results. How is this sustainable if your customers lose funding, thereby no longer being customers? We should not have to take extreme measures like lobbying HUD to make this a requirement via "programming specs". If the data cascades for a manual exit, it should also cascade for an auto exit.
Amy Vargo
shared this idea
1 comment
-
Tyler Uhlig
commented
To add to this - I think I understand this not being on exiting to inactivity. There's also a case to be made for exit on housed when move-in date is the trigger (as there is no exit screen to connect with that to cascade from, nor is it guaranteed to be related to the date of move-in on the entry screen there).
The one I don't understand is exit-on-housed from another program exiting them. The data is there and the destination cascades. Can this be implemented as a first step?
I still do agree with strategies for reducing the DNC prevalence across the board, but at least for exit-on-housed I don't see why it shouldn't cascade data that is definitely there (and it already cascades destination somehow).