I was testing my manual patch to the CA module chronicity calculations that I have been using since we found the issue in 60.3 in 61.1.3 by comparing the client profile version of chronicity to the one reported by the CA module.

Running the following query, I was finding some cases where the client had become chronic (according to the CA calculations) but their profile was still saying “No” for chronically homeless, and the opposite situation as well where the client was no longer considered chronic but the client profile still said “Yes”.

SELECT clients.[ClientID]

      ,clients.[IsChronicallyHomelessYN] as ClientProfileChronicallyHomeless

      ,ca.[ChronicallyHomelessYN] as CoordinatedAccessChronicallyHomeless

      ,ca.HomelessIn365Days as CoordinatedAccessHomelessIn365Days

      ,ca.HomelessIn1095Days as CoordinatedAccessHomelessIn1095Days

  FROM [dbo].[HIFIS_Clients] clients

INNER JOIN vw_CoordinatedAccess ca ON clients.[ClientID] = ca.[ClientID]

where clients.[IsChronicallyHomelessYN] <> ca.[ChronicallyHomelessYN]

I see the same issue in both environments (60.3 and 61.1.3). In our QA (copy of production updated last week), there were 12 examples. In production there were 200. Checking into the details, it looked like the CA calculation was pulling the correct numbers for the chronicity check (after the fix I applied) but the client profile version of chronicity was not updating on it’s own.

Running sp_UpdateClientChronicityStatus manually with a NULL ClientID parameter updated all the client profiles and after running this, there were no more records that had a mismatch between their profile and what the CA module said for them.

Similar to the issue with client state not updating automatically, it seems like I can put a band aid on this by creating a SQL job that runs sp_UpdateClientChronicityStatus nightly.