The Chairman of the Senate Finance Committee has saluted the new Commissioner of Social Security for going forward with proposed rules to allow use of electronic wage reporting to reduce overpayments.
So I'm going to be curious on how this is going to go down. WorkCDRs are a mandate from congress, I'm pretty sure. So right now, so long as the claimant signs an 8240, SSA can just access the electronic wages that are being referenced. Of course they are access manually by logging into the Equifax (WorkNumber) program and then keyed into eWork. I haven't seen anything concrete of how this fits into the bigger picture. So are the wages that SSA receive going to automate the actual WorkCDR so that a human doesn't have to touch it? Very VERY unlikely with SSA's ancient technology. So will the wages just automatically just post to the specific program (eWork) where SSA processes WorkCDRs? This really isn't going to save a lot of time unless the agency is about to rollout some miraculous new program that automates a lot of the WorkCDR workload in general, which is also highly highly unlikely.
Realistically, the agency should work to automate WorkCDRs where the wages are clearly not SGA, even that would cut down on a lot of tedious, time consuming work. WorkCDRs where Trial Work Period months are involved, or even SGA-EPE suspension cases happen, or possible subsidy/irwe cases, would/may still need completed by a competent CS to cross the T's and dot the I's on them.
I've been doing work CDRs for 30 years, and am very, very good at them. As a result, I know what I am talking about on this.
Firstly, Equifax's Work Number only contains a fraction of employers. The employers pay Equifax for this service. The records aren't always accurate, and some participating employers even elect to lock down their employee payroll info within the service so that is there but difficult (and sometimes even impossible) for SSA to access. And, employers enroll and dis-enroll from the service all the time. There are also many other payroll services besides Work Number - I can think of at least 5 other ones just off the top of my head, and there are only a very few that SSA employees can even enroll to use.
On the SSA side of things, they'll never be able to automate this in eWork as it presently exists. Simply stated, eWork is too "fragile". The front end, data entry (while annoyingly time consuming in ways it shouldn't be), is...okay. However, the backend (where the actual processing happens) depends on POS and and the Disability Control File (DCF). DCF is a stinky, worthless piece of crap software that was obviously designed and implemented by intoxicated monkeys high on PCP-laced marijuana. There really isn't a word in the English language to describe how truly shitty it really is.
And, because of the way that eWork's back end is designed, it doesn't handle re-openings well. At all. To the point where all re-openings are exceptions requiring manual processing via MACADE.
Which is a major reason why work CDRs are such a mess. You are forced to make an assumption going forward on almost every single work CDR (i.e. is work SGA or not SGA continuing, or there turn out to be other work attempts we didn't know about when processing the initial decision that change the prior one). When that assumption made turns out inevitably to have been wrong and has to be reopened, the case becomes a reopening processing exception (which adds 3-12 months of processing time, depending upon the PC involved). And, of course, the claimant will then have (sometimes multiple) intervening work CDRs while the correction is still pending, all of which are now automatically processing exceptions themselves. And, get this - PC processes the decisions in order, because there is no provision to annotate that a subsequent work CDR supercedes a prior one and the BAs NEVER bother to look - they just process the now incorrect work CDR exception in front of them today and then the correction months and months down the road.
So, what it all boils down to is that, at best, this will simply add yet another WAC list to work. A list that nobody has time to do. HQ will tell their management minions that govern the working slobs to crack the whip and get them done (probably initiate within 30 days, given the current focus on overpayments as the management high priority issue of the last 5 minutes). Only problem with that is, there already aren't enough people to process the work we already have.
And, on that point, I can tell you from long experience there are a lot of SSA employees who truly have no business even thinking about touching a work CDR.....
I am back and I agree with this post entirely. Unless major tech changes happen, this is going to be a big stink burger for the agency, for at least a good while. Everything said about how eWork and DCF are intertwined is true. And DCF is a dumpster fire. The amount of times PC has to get involved on the back end of workCDRs is insane.
@10:58 (or anyone else in T2) - how do wages reported via SSAMWR or MyWageReport reflected in eWork? I suspect the automated payroll would come into eWork the same way. Do those wages require any human interaction? (SSI rep here who doesn’t process T2).
Yes, every single one of them require human interaction in the form of initiation of a work CDR that must be processed by a CS who understands how to do work CDRs.
Getting the wages into eWork isn't the problem - that is the easy part that pretty much any moron who can add numbers can do. It is the back end processing that takes all the time, effort, and knowledge to complete. And, that back-end processing is where all the problems come in. It can't be automated, because actual decisional judgement is required on the part of the adjudicator.
To put it in SSI terms, imagine if every other RZ you take won't process through the system but rather requires manual inputs.
And, for those manual inputs, you can't do them yourself.
Instead, you are forced to depend upon someone in an office in a galaxy far, far away to do the input for you. Someone you aren't allowed to communicate directly with, who sits on the case for 3-12 months, then simply ignores what you told them to do based upon policy and instead just does whatever the hell stupid thing pops up into their tiny little brains to allow them to remove it from their workload lists, uncaring that they are messing with people's lives. Suffice it to say, someone who never, ever can be bothered to check their work afterwards even if they actually tried to do it correctly. And, while all of this is pending, you have done subsequent RZs and all of them are now manual actions because the first one isn't completely processed. Rinse and repeat.
This pretty much describes the current Title II work CDR process to a 't'.
In short, it isn't getting the wages into eWork that is the problem. It is all the crap on the back end that doesn't work that is the problem.
CDR EXPERTS: As a rep, I never had a great idea for helping my clients GET a work CDR fast. The best ones would report immediately and think they’d done their duty. Call every month and remind them about wages, and thus to stop DIB. But that went on for years sometimes. I presume this is because of the EPE? I could see the contacts in the queries if I asked.
I want to know what a claimant can do to quickly and effectively terminate DIB and the related Medicare coverage. POMS says client can ask for payments to stop, and there is mechanism to stop Medicare that is long and onerous.
I know this sounds rhetorical, but if the electrician who broke his back at work and went back to work at SGA for the requisite 9 months after 5 years on the rolls with great benefits, who does he call or what does he do to effectively say “hey can you turn off the payments because I have gone back to work now, thank you for funding my recuperation to return to society, but I do not want an overpayment and I do not want your money.” Is it even possible to make payments and coverage stop within 1 month? 6 months? What is the fastest route to saving the government money and saving my clients from incurring unintentional debt?
This has been a long struggle in my practice in every state, though POMS is detailed about which processes are triggered when — but backlog. You don’t typically get paid for CDR work, but my former clients understandably call me down the line when this comes up for them. I want to streamline this so that the agency employees have to do the least amount of work for a sure CDR which saves the taxpayers coffers. There has got to be a way to refuse government money — I realize this is a bizarre statement. I need the key, my friends.
Thank you in advance for this hard work. I’ll do whatever I can to make it easier.
When they go to work (or as of their 9th TWP month), tell them to open a separate bank account and visit the local SSA office to change their direct deposit with SSA to this account. As of their payment date in the first month they project they are not due benefits (i.e., if they are not due a payment beginning March, they should go in on their actual check payment date in March), tell them to go to the bank and close the account with instructions to the bank that it not be reopened under any circumstances. This will cause any future direct deposit to be rejected by the bank back to the Treasury Department, which SHOULD cause the benefits to be suspended by SSA due to the returned check. As long as they do not provide new direct deposit information to SSA, the benefits should in theory remain suspended. If someone in the agency calls, tell them to tell the agency they are not due benefits and tell them to refuse to provide new bank data. In the event an agency employee (to get it off their list) reinstates the payments as paper checks without a contact with the client, just tell them to return every paper checks to SSA because of SGA work with a note requesting a work CDR be conducted based upon evidence already provided to the agency. Eventually, the agency would be forced to deal with the returned check issue which will result in a work CDR.
Funny story: I had the same idea. Used to tell clients this. However, the Treas direct deposit system literally just finds the new account when the other one closes. I looked at the data management used and this appears to be legit. Multiple different banks or types of accounts, deposit ends up finding its way there with no interaction from client. I would not have believed it had I not seen it more than once. This appears to be a newer security measure and it’s got me stumped TBH.
The paper trail idea is great it just doesn’t get action swiftly. If this is impossible, I understand, it’s just frustrating and I want to do the best I can for my clients and to make sure the money gets to stay with the people who need it more.
So I'm going to be curious on how this is going to go down. WorkCDRs are a mandate from congress, I'm pretty sure. So right now, so long as the claimant signs an 8240, SSA can just access the electronic wages that are being referenced. Of course they are access manually by logging into the Equifax (WorkNumber) program and then keyed into eWork. I haven't seen anything concrete of how this fits into the bigger picture. So are the wages that SSA receive going to automate the actual WorkCDR so that a human doesn't have to touch it? Very VERY unlikely with SSA's ancient technology. So will the wages just automatically just post to the specific program (eWork) where SSA processes WorkCDRs? This really isn't going to save a lot of time unless the agency is about to rollout some miraculous new program that automates a lot of the WorkCDR workload in general, which is also highly highly unlikely.
ReplyDeleteRealistically, the agency should work to automate WorkCDRs where the wages are clearly not SGA, even that would cut down on a lot of tedious, time consuming work. WorkCDRs where Trial Work Period months are involved, or even SGA-EPE suspension cases happen, or possible subsidy/irwe cases, would/may still need completed by a competent CS to cross the T's and dot the I's on them.
I've been doing work CDRs for 30 years, and am very, very good at them. As a result, I know what I am talking about on this.
ReplyDeleteFirstly, Equifax's Work Number only contains a fraction of employers. The employers pay Equifax for this service. The records aren't always accurate, and some participating employers even elect to lock down their employee payroll info within the service so that is there but difficult (and sometimes even impossible) for SSA to access. And, employers enroll and dis-enroll from the service all the time. There are also many other payroll services besides Work Number - I can think of at least 5 other ones just off the top of my head, and there are only a very few that SSA employees can even enroll to use.
On the SSA side of things, they'll never be able to automate this in eWork as it presently exists. Simply stated, eWork is too "fragile". The front end, data entry (while annoyingly time consuming in ways it shouldn't be), is...okay. However, the backend (where the actual processing happens) depends on POS and and the Disability Control File (DCF). DCF is a stinky, worthless piece of crap software that was obviously designed and implemented by intoxicated monkeys high on PCP-laced marijuana. There really isn't a word in the English language to describe how truly shitty it really is.
And, because of the way that eWork's back end is designed, it doesn't handle re-openings well. At all. To the point where all re-openings are exceptions requiring manual processing via MACADE.
Which is a major reason why work CDRs are such a mess. You are forced to make an assumption going forward on almost every single work CDR (i.e. is work SGA or not SGA continuing, or there turn out to be other work attempts we didn't know about when processing the initial decision that change the prior one). When that assumption made turns out inevitably to have been wrong and has to be reopened, the case becomes a reopening processing exception (which adds 3-12 months of processing time, depending upon the PC involved). And, of course, the claimant will then have (sometimes multiple) intervening work CDRs while the correction is still pending, all of which are now automatically processing exceptions themselves. And, get this - PC processes the decisions in order, because there is no provision to annotate that a subsequent work CDR supercedes a prior one and the BAs NEVER bother to look - they just process the now incorrect work CDR exception in front of them today and then the correction months and months down the road.
So, what it all boils down to is that, at best, this will simply add yet another WAC list to work. A list that nobody has time to do. HQ will tell their management minions that govern the working slobs to crack the whip and get them done (probably initiate within 30 days, given the current focus on overpayments as the management high priority issue of the last 5 minutes). Only problem with that is, there already aren't enough people to process the work we already have.
And, on that point, I can tell you from long experience there are a lot of SSA employees who truly have no business even thinking about touching a work CDR.....
9:41 here
DeleteI am back and I agree with this post entirely. Unless major tech changes happen, this is going to be a big stink burger for the agency, for at least a good while. Everything said about how eWork and DCF are intertwined is true. And DCF is a dumpster fire. The amount of times PC has to get involved on the back end of workCDRs is insane.
Stop the insanity and apply the AET to DIB. If someone exceeds the AET three years in a row do a medical CDR. Simple.
ReplyDelete@10:58 (or anyone else in T2) - how do wages reported via SSAMWR or MyWageReport reflected in eWork? I suspect the automated payroll would come into eWork the same way. Do those wages require any human interaction? (SSI rep here who doesn’t process T2).
ReplyDeleteThey are pulled into eWork automatically but the review and effectuation of the WorkCDR is all still don’t manually by the CS.
Delete@10:38pm,
ReplyDeleteYes, every single one of them require human interaction in the form of initiation of a work CDR that must be processed by a CS who understands how to do work CDRs.
Getting the wages into eWork isn't the problem - that is the easy part that pretty much any moron who can add numbers can do. It is the back end processing that takes all the time, effort, and knowledge to complete. And, that back-end processing is where all the problems come in. It can't be automated, because actual decisional judgement is required on the part of the adjudicator.
To put it in SSI terms, imagine if every other RZ you take won't process through the system but rather requires manual inputs.
And, for those manual inputs, you can't do them yourself.
Instead, you are forced to depend upon someone in an office in a galaxy far, far away to do the input for you. Someone you aren't allowed to communicate directly with, who sits on the case for 3-12 months, then simply ignores what you told them to do based upon policy and instead just does whatever the hell stupid thing pops up into their tiny little brains to allow them to remove it from their workload lists, uncaring that they are messing with people's lives. Suffice it to say, someone who never, ever can be bothered to check their work afterwards even if they actually tried to do it correctly. And, while all of this is pending, you have done subsequent RZs and all of them are now manual actions because the first one isn't completely processed. Rinse and repeat.
This pretty much describes the current Title II work CDR process to a 't'.
In short, it isn't getting the wages into eWork that is the problem. It is all the crap on the back end that doesn't work that is the problem.
CDR EXPERTS: As a rep, I never had a great idea for helping my clients GET a work CDR fast. The best ones would report immediately and think they’d done their duty. Call every month and remind them about wages, and thus to stop DIB. But that went on for years sometimes. I presume this is because of the EPE? I could see the contacts in the queries if I asked.
DeleteI want to know what a claimant can do to quickly and effectively terminate DIB and the related Medicare coverage. POMS says client can ask for payments to stop, and there is mechanism to stop Medicare that is long and onerous.
I know this sounds rhetorical, but if the electrician who broke his back at work and went back to work at SGA for the requisite 9 months after 5 years on the rolls with great benefits, who does he call or what does he do to effectively say “hey can you turn off the payments because I have gone back to work now, thank you for funding my recuperation to return to society, but I do not want an overpayment and I do not want your money.” Is it even possible to make payments and coverage stop within 1 month? 6 months? What is the fastest route to saving the government money and saving my clients from incurring unintentional debt?
This has been a long struggle in my practice in every state, though POMS is detailed about which processes are triggered when — but backlog. You don’t typically get paid for CDR work, but my former clients understandably call me down the line when this comes up for them. I want to streamline this so that the agency employees have to do the least amount of work for a sure CDR which saves the taxpayers coffers. There has got to be a way to refuse government money — I realize this is a bizarre statement. I need the key, my friends.
Thank you in advance for this hard work. I’ll do whatever I can to make it easier.
@12:55pm,
ReplyDeleteHere is one trick you can use:
When they go to work (or as of their 9th TWP month), tell them to open a separate bank account and visit the local SSA office to change their direct deposit with SSA to this account. As of their payment date in the first month they project they are not due benefits (i.e., if they are not due a payment beginning March, they should go in on their actual check payment date in March), tell them to go to the bank and close the account with instructions to the bank that it not be reopened under any circumstances. This will cause any future direct deposit to be rejected by the bank back to the Treasury Department, which SHOULD cause the benefits to be suspended by SSA due to the returned check. As long as they do not provide new direct deposit information to SSA, the benefits should in theory remain suspended. If someone in the agency calls, tell them to tell the agency they are not due benefits and tell them to refuse to provide new bank data. In the event an agency employee (to get it off their list) reinstates the payments as paper checks without a contact with the client, just tell them to return every paper checks to SSA because of SGA work with a note requesting a work CDR be conducted based upon evidence already provided to the agency. Eventually, the agency would be forced to deal with the returned check issue which will result in a work CDR.
Funny story: I had the same idea. Used to tell clients this. However, the Treas direct deposit system literally just finds the new account when the other one closes. I looked at the data management used and this appears to be legit. Multiple different banks or types of accounts, deposit ends up finding its way there with no interaction from client. I would not have believed it had I not seen it more than once. This appears to be a newer security measure and it’s got me stumped TBH.
DeleteThe paper trail idea is great it just doesn’t get action swiftly. If this is impossible, I understand, it’s just frustrating and I want to do the best I can for my clients and to make sure the money gets to stay with the people who need it more.
Thanks to anyone with advice.