AR
Ali Ryder 🧑‍💼 Staff
about 2 hours ago
Open
Reconfigure Case Manager field to make it more consistent across modules

Currently, when a module includes a caseworker, the information about the caseworker is stored in a module-specific table, such as HIFIS_Cases, instead of the more generic HIFIS_Services.

Specifically, it is present in HIFIS_Diversion, HIFIS_SPDAT_Intake, HIFIS_VAT_Intake, HIFIS_Cases, HIFIS_HousePlacements, and it's possible that I'm missing one or two.

In contrast, the Reason for Service field is present in the HIFIS_Services table instead of the module-specific tables, despite the fact that Reason For Service is, like Caseworker, not present in all modules. Specifically, it's not present in Case Management, or Housing Placements, or Storage or SPDAT or VAT, and there may be more.

It would be beneficial if information about the Caseworker was stored consistently, in the field HIFIS_Services.CaseworkerID, and have it be null in the modules that don't contain a caseworker field, similar to Reason for Service. This would allow higher level analysis in particular - create a report showing all services, broken down by type, by reason for service, by program, by service provider, and now by caseworker too.

🧙‍♂️Case Management ↩️Diversion 🛡️Housing Loss Prevention 🏠Housing Placements 🌡️SPDAT & VI-SPDAT 🌡️VAT 🔼Improvement
Comments
No comments yet. You can still be first!