Open jtoder opened 10 years ago
I changed the partial, state, and other SSN values to "DKR" instead of "missing."
Also, I agree with you that it would be good to separate these values into their own category. Conceptually, they are neither DKR nor missing. I think this would be good for others to give their input on.
In the APR we only count the SS# as "missing" if the field is blank. For the MUST Ministries program that we've been using as our test program (ES YR SF+FC Elizabeth Inn Shelter, 1/1/13 - 12/31/13) - the APR has 16 with DK/R; the app has 2 clients with missing SS# and 14 with DK/R. Of the 2 that are counted as missing - one has ID Type = State and the other has ID Type = Other. In keeping with our APR logic, these should be counted as DK/R rather than missing. Our logic in programming the APR was that the question was asked, but because client didn't know the SS# they used whatever form of ID they had with them. Often (as is the case with these two clients) they are children.
I think this is part of a bigger subject. I submitted an enhancement request last year to separate the SS# data element from any other ID questions - make them into two separate data fields because I think it confuses things the way that it is. There is no "other" or "state" value in the data standards. I think we need to know definitively if there is or is not a SS#. E.g., is the client using a State ID because they don't know their SS# or because they refuse to give it or because they don't have one?. Using another type of ID in this field, as it is now, leaves those questions unanswered.
Another thing (probably unrelated to this app) - even in the new data standards this isn't clear. What if client has no SS# - for example an infant who hasn't gotten one yet? I don't think any of the responses in the new data standards are appropriate: full, approx, client DK, client refuses, and Data not Collected - which is defined as "user .. did not collect or simply does not have the information to enter a response that does not present a false answer." "User doesn't have the answer" is not the same as "client doesn't have a SS#."