Discrepancies between APR and Data Analyst App – special needs

[jtoder]

When I run for agency = MUST Ministries, program = "ES YR SF+FC Elizabeth Inn Shelter," dates 1/1/13 - 12/31/13: Because the app is looking at all records for each client and the APR is only using the last program enrollment, I would expect your app to have at least as many errors as the APR. However, the APR shows 1 missing data element for each of the special needs and the app shows zero.

[jrodri30]

I addressed this issue. For the report you mentioned, the DQ app now shows 4 enrollments with missing special needs info.

There's something I can't figure out, though... Each of these enrollments is associated with a different client -- that is, 4 unique clients have missing special needs during this time period, which doesn't jive with the APR. Here are the client keys:

1374242 1374569 867941 1370373

I checked each of these clients on Pathways COMPASS, and they are indeed each missing special needs info for a 2013 MUST enrollment. So does that mean the Pathways APR should be showing 4 missing special needs instead of just 1?

[jtoder]

The actual one client that is missing a special needs record at entry in this program in 2013 is 1361440. I looked at all of the 4 clients that came up as missing here, but I didn't see that any of them are missing special needs records at entry to any of their programs. A couple are missing special needs at exit to other programs (1370373 and 1374569) but the other two are not missing any special needs in 2013, as far as I can tell.

[jrodri30]

I'm still a little confused. If you go into Pathways COMPASS, switch to MUST Ministries, search for client 867941, and navigate to the client's Elizabeth Inn program enrollment...

... you can see that there is an empty special needs record at program entry:

However, the PED export says differently:

This is confusing. Via ODBC, we can see that the client has two special needs records at program entry for the same enrollment...

One is showing missing data, the other is not. So it appears to be a glitch. So just to be clear: In cases of duplicate records like this, we should assume that the one with data is the correct record -- right?

[jrodri30]

Just noticed the text in the COMPASS photo: "A Special Needs record exists for this client, but it cannot be displayed here because you did not create it." I guess it's simply that I don't have access to it via COMPASS, and that's why it appears to be missing.

However, the duplicate records in ODBC is still an issue, and my question about that still stands.

[jtoder]

MUST has their special needs protected at the user level, which means that only the person who inputs it can see it.

I just looked through the tables via SQL Developer to refresh my memory and I'm pretty sure that it's handled like this: if client has more than one special needs record for a collection stage for the same program (which is very likely to happen at an agency with "protected" special needs like MUST has), the record with the latest create date is used. I don't know if record create dates were included in the ODBC schema. Were they?

[jrodri30]

I don't have access to a "create date," but I do see an "update timestamp" field. Would that work?

[jtoder]

You'll need to ask Tony. My understanding is that every time you hit "save" on the special needs record you are creating a new record. That's there's no such thing as updating a special needs record (or cash or non-cash for that matter). I just experimented with a client in ORCTest and changed something in the exit record and a whole new special needs record was created.

However, when I look in the Special Needs table I see three fields: create_date, update_date, and update_timestamp. It looks like update_timestamp is the same as the create_date; both include dates and times and they're the same. So maybe Tony uses the update_timestamp for this purpose - to determine which record to use in the reports.