Income Errors Question

[AEReed]

Hello,

I have some folks who have been utilizing EVA to address/correct income errors. It’s been working great, as they are fixing the errors and re-uploading a new export to EVA, income errors they are fixing are disappearing. All good there!

However, when they do an export for the SSVF repository upload, using the same date range, the repository is kicking back a bunch of income errors EVA doesn’t reflect. The SSVF projects corrected their income errors, for their entries, which was reflected in EVA. It looks like the client has income errors related to previous entries, from other projects the VA repository seems to be flagging...like EVA is looking at clients' income within the specified projects entries only, but the repository is looking at the clients' entire income history for all entries.

I already put in a ticket with our vendor, and they are unsure why there is a discrepancy. They suggested I put in an AAQ, which I did, and wanted to check in with you as well. My next stop might be the VA repository help desk haha! :)

Thank you!
-April

[kiadso]

Hi @AEReed,

Great to hear that Eva is serving your users well regarding your income data. Can you specify what error you're getting on the SSVF side? (I happen to also work with SSVF and Eva, so it works out!)

Thanks for the information!

[AEReed]

Hi,

Oh good! Thank you so much. These are the income related errors showing up in EVA vs. SSVF, along with the number of errors/clients.

Eva:
14 Conflicting Income yes/no at Entry
7 Conflicting Income yes/no at Exit
44 Conflicting Non-cash Benefits yes/no at Entry

SSVF:
106 Incorrect Income Amount at Entry
2 Very High Income at Entry
22 Incorrect Income Amount at Exit
5 Very High Income Amount at Exit

[kiadso]

Hi @AEReed,

Regarding the SSVF's "Very High Income at [data collection point]", that is a warning on the SSVF side that does not exist in Eva, so those are different intentionally. Conversely, SSVF does not check for conflicting Non-cash Benefits data, so those are also all fine. So we're left with Eva's "Conflicting Income yes/no at [data collection point]" vs "Incorrect Income Amount at [data collection point]" on the SSVF side. Those should align.

Can you confirm that you ran your Eva export on the same date range as you ran your SSVF export and it had the same projects in it? One reason for the differences may be that Eva runs the Data Quality logic on the entire file, beginning with the Export Start Date and ending with the Export End Date. The SSVF errors (I think) would stop counting at the end of the most recent month but I'm not 100% about that. I would suggest starting your Eva file to align with the federal fiscal year and to end clean on a month if you're looking for these numbers to match. (So, Oct 1, 2023 through April 30, 2024) If this is already what you were doing, did you find any examples of enrollments that were being flagged by SSVF that weren't flagged by Eva? If so, could you look a few of those cases up in your HMIS and see if you're finding that SSVF is false-flagging or if Eva is under-flagging?

Thanks for your patience with this!
-Eva dev team

[AEReed]

Hi Genelle, Both reports were run for 10/1/23-5/6/24. That makes totals sense in terms of SSVF warnings that aren't included in EVA or vice versa....for the Conflicting Income/Incorrect Income that should be aligning though....none of the clients are the same. I got a list of clients with "Conflicting Income..." on EVA and another (much longer) list of clients with "Incorrect Income..." on SSVF. When I look at the client records, I can find the income errors, but I don't know why EVA isn't picking up the clients SSVF is and SSVF isn't picking up the clients EVA is. I did put a ticket in with our vendor as well. Should I send them the list of both clients, the errors, and which report they're from etc. so they can look at the records? Thanks! April Reed HMIS Application Specialist MaineHousing 26 Edison Drive Augusta, ME 04330 (207) 626-4694 Maine Relay 711 [USE THIS LOGO FOR EMAIL SIGNATURE] www.mainehousing.org<http://www.mainehousing.org/> From: Genelle Denzin ***@***.***> Sent: Friday, May 10, 2024 6:07 PM To: abtassociates/eva ***@***.***> Cc: April Reed ***@***.***>; Mention ***@***.***> Subject: Re: [abtassociates/eva] Income Errors Question (Issue #510) You don't often get email from ***@***.*** Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> EXTERNAL EMAIL Hi @AEReed<https://github.com/AEReed>, Regarding the SSVF's "Very High Income at [data collection point]", that is a warning on the SSVF side that does not exist in Eva, so those are different intentionally. Conversely, SSVF does not check for conflicting Non-cash Benefits data, so those are also all fine. So we're left with Eva's "Conflicting Income yes/no at [data collection point]" vs "Incorrect Income Amount at [data collection point]" on the SSVF side. Those should align. Can you confirm that you ran your Eva export on the same date range as you ran your SSVF export and it had the same projects in it? One reason for the differences may be that Eva runs the Data Quality logic on the entire file, beginning with the Export Start Date and ending with the Export End Date. The SSVF errors (I think) would stop counting at the end of the most recent month but I'm not 100% about that. I would suggest starting your Eva file to align with the federal fiscal year and to end clean on a month if you're looking for these numbers to match. (So, Oct 1, 2023 through April 30, 2024) If this is already what you were doing, did you find any examples of enrollments that were being flagged by SSVF that weren't flagged by Eva? If so, could you look a few of those cases up in your HMIS and see if you're finding that SSVF is false-flagging or if Eva is under-flagging? Thanks for your patience with this! -Eva dev team - Reply to this email directly, view it on GitHub<#510 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BB6XVRNC5YQID2W44UK5EJLZBVAHXAVCNFSM6AAAAABHLHQJZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBVGMZDKMZZGQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[kiadso]

Hi @AEReed

Ok, I have one more question before taking it to your vendor- when you upload the file to Eva, are you running that file with the same level of permissions and ONLY on the same SSVF project(s) you're uploading? I know some communities upload a single project at a time to SSVF, some upload both RRH and HP together. So if you haven't already, try using the same login to download both your Eva file and your SSVF file, using the same exact project(s), same dates, and see how that goes.

The reason I ask is in some systems, income records persist across enrollments that were created by different projects, so depending on visibility settings, so when you run an export of your entire system for Eva, you may be uploading a more accurate picture of the client's income across time since you're pulling in all the income records (regardless of which project the income record was created under.) This could be a thing that's happening. If not, then, yes, let's try working with your vendor!

Thanks,

Eva dev team

[AEReed]

Hi, That's a good question! I did actually double check with them already it was the same user, and they are using the same reporting group (which includes two SSVF projects) to generate both exports. I still have a ticket open with our vendor so I'll pass along the info regarding the checks EVA/SSVF do not have in common, and see if they can sort out why there are entirely different clients being identified for the checks they should have in common. Thank you! From: Genelle Denzin ***@***.***> Sent: Tuesday, May 14, 2024 2:26 PM To: abtassociates/eva ***@***.***> Cc: April Reed ***@***.***>; Mention ***@***.***> Subject: Re: [abtassociates/eva] Income Errors Question (Issue #510) You don't often get email from ***@***.*** Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> EXTERNAL EMAIL Hi @AEReed<https://github.com/AEReed> Ok, I have one more question before taking it to your vendor- when you upload the file to Eva, are you running that file with the same level of permissions and ONLY on the same SSVF project(s) you're uploading? I know some communities upload a single project at a time to SSVF, some upload both RRH and HP together. So if you haven't already, try using the same login to download both your Eva file and your SSVF file, using the same exact project(s), same dates, and see how that goes. The reason I ask is in some systems, income records persist across enrollments that were created by different projects, so depending on visibility settings, so when you run an export of your entire system for Eva, you may be uploading a more accurate picture of the client's income across time since you're pulling in all the income records (regardless of which project the income record was created under.) This could be a thing that's happening. If not, then, yes, let's try working with your vendor! Thanks, Eva dev team - Reply to this email directly, view it on GitHub<#510 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BB6XVRPBBHWODB5ASJTWLITZCJJMJAVCNFSM6AAAAABHLHQJZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJQHA2TIMJSGQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[kiadso]

Hi @AEReed,

Have you heard anything on this? We are so curious! :)

Thanks-
Eva dev team

[AEReed]

Hi Genelle, Thanks for being patient, I did get some clarification but I'm trying to wrap my head around what my next steps should be lol Wellsky said EVA is comparing sub assessment data to the yes/no "Income from Any Source" while SSVF is looking at the "Total Monthly Income" question - which is calculated based on what's in the sub assessment. Unless, if that question is answered manually, the manual answer is what's used instead. The way EVA is looking at it makes a lot more sense to me vs. how the SSVF is but maybe there is a reason. With that mystery solved, I'm a bit at a loss of how I can help our end users address income errors efficiently though. Our HMIS was closed for years, then visibility was opened up in 2019 and so half the time, users cannot even see income that needs to be ended in order to be corrected. I've been having folks click the "View Gross Income" button because it will show total income ($600 for example), but if they only see, say $400 in the sub assessment, there's like $200 that was never ended they can't see or fix. They have to put in a help desk ticket for us to fix it, but it's so tedious and time consuming. SSVF projects are the most impacted though since the VA really looks at income. Are both EVA and SSVF both looking at income the way they should be? Or if not, will anything be changed to align them? What do you think would be the best way for me to help them address these income issues for now? Thank you!

…

-April April Reed HMIS Application Specialist MaineHousing 26 Edison Drive Augusta, ME 04330 (207) 626-4694 Maine Relay 711 [USE THIS LOGO FOR EMAIL SIGNATURE] www.mainehousing.org<http://www.mainehousing.org/> From: Genelle Denzin ***@***.***> Sent: Wednesday, May 22, 2024 9:29 AM To: abtassociates/eva ***@***.***> Cc: April Reed ***@***.***>; Mention ***@***.***> Subject: Re: [abtassociates/eva] Income Errors Question (Issue #510) You don't often get email from ***@***.*** Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> EXTERNAL EMAIL Hi @AEReed<https://github.com/AEReed>, Have you heard anything on this? We are so curious! :) Thanks- Eva dev team - Reply to this email directly, view it on GitHub<#510 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BB6XVRL5ZCPCKIAQCUWFKOLZDSMRZAVCNFSM6AAAAABHLHQJZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRUHAYDCOBRGY>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[kiadso]

Hi @AEReed,
You're right, SSVF examines income data very closely and Eva's way of assessing conflicts is different. I know exactly what you are referring to with regard to "View Gross Income" as I worked with the system you're working with in my previous era! My previous community also worked through the process of opening up visibility and then dealing with the "fallout" from all of the Income/Non-Cash/Health Insurance data elements being suddenly visible and adding across projects. Our way of dealing with this was a huge push for users to really clean up these records. Once this was done, we turned off Total Monthly Income and just used the total from the income records as the "Total Monthly Income." Not supporting that way of doing it, and things may have changed since I was there, but I thought I'd share my experience with it in case that's helpful.

As a fuller explanation of what is intended by the Data Standards, here is an excerpt from the Data Dictionary about this:

Data for the fields of this data element should be logically consistent. It is expected
that an HMIS is programmed to enforce these rules or to notify users when
inconsistent data has been entered. If there is a “yes” response to ‘Income from
any source’ then at least one source of income must be identified. If a source is
identified, then a ‘Monthly amount’ must be entered. If a ‘Monthly amount’ is
entered for any source, then a ‘Total monthly income’ amount is required.
If there is a “no” response to Field 2 ‘Income from any source’ then the HMIS must
automatically record all sources as “no” and leave dollar amounts null or $0.00.
To reduce data collection and reporting burden:
• Systems are encouraged to auto-calculate total monthly income to avoid
mathematical errors and reduce data collection (generate a $0.00 for total
monthly income if ‘Income from any source’ = “no”).
• If a client reports receiving income, an HMIS may be designed such that
projects only need to directly enter “yes” for the income source the client
receives and have the HMIS automatically generate a “no” response for the
other income sources.
• An HMIS may facilitate data accuracy by automatically changing a “no” in
‘income from any source’ to a “yes” if source(s) and dollar amount(s) are
indicated.

So this could help you in further conversations with your vendor on this data. I checked internally and the Eva team is not planning to add further logic to catch differences in totals like the SSVF team does, based on other priorities, but we completely understand the frustration. The SSVF team, however, is willing to add the "Income from Any Source" logic to their data quality checks, so maybe that will help streamline your process a little.

Thank you for all the work you do!
Genelle

[AEReed]

Thanks for all your help! I do have one other question - is there someone at the VA our provider could inform about the onoing issues with trying to clean up the income errors? I feel bad if they are getting dinged for things when they are trying so hard to fix them but it just takes time. Thank you :) From: Genelle Denzin ***@***.***> Sent: Thursday, May 23, 2024 4:06 PM To: abtassociates/eva ***@***.***> Cc: April Reed ***@***.***>; Mention ***@***.***> Subject: Re: [abtassociates/eva] Income Errors Question (Issue #510) You don't often get email from ***@***.*** Learn why this is important<https://aka.ms/LearnAboutSenderIdentification> EXTERNAL EMAIL Hi @AEReed<https://github.com/AEReed>, You're right, SSVF examines income data very closely and Eva's way of assessing conflicts is different. I know exactly what you are referring to with regard to "View Gross Income" as I worked with the system you're working with in my previous era! My previous community also worked through the process of opening up visibility and then dealing with the "fallout" from all of the Income/Non-Cash/Health Insurance data elements being suddenly visible and adding across projects. Our way of dealing with this was a huge push for users to really clean up these records. Once this was done, we turned off Total Monthly Income and just used the total from the income records as the "Total Monthly Income." Not supporting that way of doing it, and things may have changed since I was there, but I thought I'd share my experience with it in case that's helpful. As a fuller explanation of what is intended by the Data Standards, here is an excerpt from the Data Dictionary<https://www.hudexchange.info/resources/documents/HMIS-Data-Dictionary-2024.pdf> about this: Data for the fields of this data element should be logically consistent. It is expected that an HMIS is programmed to enforce these rules or to notify users when inconsistent data has been entered. If there is a "yes" response to 'Income from any source' then at least one source of income must be identified. If a source is identified, then a 'Monthly amount' must be entered. If a 'Monthly amount' is entered for any source, then a 'Total monthly income' amount is required. If there is a "no" response to Field 2 'Income from any source' then the HMIS must automatically record all sources as "no" and leave dollar amounts null or $0.00. To reduce data collection and reporting burden: * Systems are encouraged to auto-calculate total monthly income to avoid mathematical errors and reduce data collection (generate a $0.00 for total monthly income if 'Income from any source' = "no"). * If a client reports receiving income, an HMIS may be designed such that projects only need to directly enter "yes" for the income source the client receives and have the HMIS automatically generate a "no" response for the other income sources. * An HMIS may facilitate data accuracy by automatically changing a "no" in 'income from any source' to a "yes" if source(s) and dollar amount(s) are indicated. So this could help you in further conversations with your vendor on this data. I checked internally and the Eva team is not planning to add further logic to catch differences in totals like the SSVF team does, based on other priorities, but we completely understand the frustration. The SSVF team, however, is willing to add the "Income from Any Source" logic to their data quality checks, so maybe that will help streamline your process a little. Thank you for all the work you do! Genelle - Reply to this email directly, view it on GitHub<#510 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BB6XVRJGNXPPAIEH5PIT2VTZDZDZHAVCNFSM6AAAAABHLHQJZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRXHEZTENBRGY>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[kiadso]

Hi @AEReed ,
I closed this without answering your question, apologies! You can email ssvfhmis@abtglobal.com with SSVF HMIS type questions!
Also, while we're here, is this still happening? I did get a notice from WellSky that your CSV export was corrected to include all subassessments attached to each enrollment that is included in your export, whereas that was not happening before. It seems like this change would affect what you described at least a little. I'm leaving this issue closed, but I wanted to follow up to see if that changed anything (and answer the question you asked.) :)
Thanks,
Genelle

[AEReed]

Hi Genelle, I haven't heard from anyone again regarding this issue so perhaps the corrections Wellsky made to the export did help. I did also advise them, while it's important to make sure data is correct and errors are addressed - there is a balance between how much time you invest trying to investigate every single income error. I told them to do their best, pick away at them, and reach out if they got really hung up on anything moving forward. Thanks for still following up! :)

…

-April April Reed HMIS Application Specialist MaineHousing 26 Edison Drive Augusta, ME 04330 (207) 626-4694 Maine Relay 711 [USE THIS LOGO FOR EMAIL SIGNATURE] www.mainehousing.org<http://www.mainehousing.org/> From: Genelle Denzin ***@***.***> Sent: Monday, August 5, 2024 9:17 AM To: abtassociates/eva ***@***.***> Cc: April Reed ***@***.***>; Mention ***@***.***> Subject: Re: [abtassociates/eva] Income Errors Question (Issue #510) EXTERNAL EMAIL Hi @AEReed<https://github.com/AEReed> , I closed this without answering your question, apologies! You can email ***@***.******@***.***> with SSVF HMIS type questions! Also, while we're here, is this still happening? I did get a notice from WellSky that your CSV export was corrected to include all subassessments attached to each enrollment that is included in your export, whereas that was not happening before. It seems like this change would affect what you described at least a little. I'm leaving this issue closed, but I wanted to follow up to see if that changed anything (and answer the question you asked.) :) Thanks, Genelle - Reply to this email directly, view it on GitHub<#510 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/BB6XVRLR4WHFF2AM5GIKI3LZP53NTAVCNFSM6AAAAABHLHQJZSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRZGA2TMNBVGM>. You are receiving this because you were mentioned.Message ID: ***@***.***>