Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CalFresh & So Clean: Dead simple CalFresh application #6

Open
lippytak opened this issue Apr 26, 2014 · 14 comments
Open

CalFresh & So Clean: Dead simple CalFresh application #6

lippytak opened this issue Apr 26, 2014 · 14 comments
Labels

Comments

@lippytak
Copy link

BLUF: CalFresh & So Clean is a dead simple CalFresh application (yes yes we can change the name fineeeeee)
Project Needs: Dev + designer + Jake to run interference with SF (mostly done!)
Status: Pie with serious interest to do this soon
UPDATED! Status: In progress (Dave and Jake)

Here are some important facts:

And the idea:

  • Create a 3 question form that populates the official application and faxes it to the CalFresh office in SF (415-355-2300)
  • I already ran this by people on the inside. They say JFDI. We'll process a few official applications this way and then take it to the CA consortium that runs mybenefitscalwin.org: "This is how it could be."
@lippytak
Copy link
Author

Soliciting @abhinemani's thoughts...

@daguar
Copy link
Collaborator

daguar commented Apr 26, 2014

Really basic questions:

  1. How would they establish eligibility for someone with just those 3 fields?
  2. Will the enrollment process be significantly delayed / outcomes poorer using this approach?
  3. Is the agency obliged to follow-up?

@lippytak
Copy link
Author

  1. They wouldn't. To be clear, even the 55 screens and hundred questions via mybenefitscalwin.org is insufficient to establish eligibility. The basic flow for CalFresh is always application > interview (phone or in person) + repeat until all verification docs are confirmed.
  2. IMO it will increase the agency burden but decrease client burden all around. Not sure about delays.
  3. Yes, not sure about timeframes. But agency needs to respond to all applications. The likely next step here would be to schedule a phone interview.

@daguar
Copy link
Collaborator

daguar commented Apr 26, 2014

Per our phone chat, one way to deal with concern about having the application sent through an API is to have a big disclaimer modal at the beginning in easy-to-read language explaining what will happen.

For example…

We're going to fax your application in using something called 'SERVICENAME' (with URL).
To do this, SERVICENAME will have access to your application for a few minutes -- after it's been sent, we'll tell them to delete it.

  • If you do NOT want this to happen, click 'I want to print and mail my form'.
  • If this is OKAY, please click 'I understand and consent to you faxing the form for me'.

On Apr 26, 2014, at 1:56 PM, Jake Solomon notifications@github.com wrote:

They wouldn't. To be clear, even the 55 screens and hundred questions via mybenefitscalwin.org is insufficient to establish eligibility. The basic flow for CalFresh is always application > interview (phone or in person) + repeat until all verification docs are confirmed.
IMO it will increase the agency burden but decrease client burden all around. Not sure about delays.
Yes, not sure about timeframes. But agency needs to respond to all applications. The likely next step here would be to schedule a phone interview.

Reply to this email directly or view it on GitHub.

@daguar
Copy link
Collaborator

daguar commented Apr 26, 2014

I'm happy to do the dev work on this.

In Ruby, it looks like we can programmatically fill out the forms with:

@daguar
Copy link
Collaborator

daguar commented Apr 27, 2014

I've successfully got Ruby writing to the CalFresh application PDF.

This file is the the application with each field filled out with its hidden name (e.g., "Text1 PG 1"):
https://drive.google.com/file/d/0B_Nnbo5KGxNwWG9fVElWNlVFT0k/edit?usp=sharing

@daguar
Copy link
Collaborator

daguar commented Apr 27, 2014

Code under development here:
https://github.com/daguar/calfresh-and-so-clean

@lippytak
Copy link
Author

Running out the door but here is the VERY basics:

data elements

  • household size (people you "purchase and prepare food with")
  • household monthly income (gross)
  • elder or disabled person in the household (yes/no)
  • receiving SSI (yes/no)
  • citizen (yes/no)

income threshold (http://aspe.hhs.gov/poverty/14poverty.cfm)

  • 130% FPL general case
  • 165% FPL if elder or disabled in the household

eligibility
if income < income_threshold and citizen and not receiving SSI return "probably eligible!"

sources

And the form: http://www.cdss.ca.gov/cdssweb/entres/forms/English/CF285.pdf

Note that ONLY name, address, signature, and probably contact info will get printed to the form. The other questions are just so we can give helpful context like "you probably aren't eligible because XYZ, but you can apply anyway!" Actually determining income with deductions and all is a longer process.

@lippytak
Copy link
Author

Moved to application repo: https://github.com/daguar/calfresh-and-so-clean

Would love your thoughts on this one, @jmadans

@jmadans
Copy link
Member

jmadans commented Apr 28, 2014

I really like the idea of using the fax loophole to create an alternative, much more stripped down online application process. You should check out http://www.expunge.io/, if you haven't.

A few thoughts:

  1. We really, really need a stock of people signing up for Calfresh to test this approach and track how the follow up deviates from the in-person or web application response (number of touch points on either side required for completion and overall time taken to get enrolled). How do we do that?
  2. Does this work for or against HSA's metrics? If they are judged on how many unique applications they get then this is the easy acquisition hack they have been waiting for. But if the metric that matters is more like the percentage of people in the funnel completing to enrollment then maybe not so much.
  3. Are we trying to prove that people will apply online if the form is dead simple?
  4. My biggest worry is that the snail mail follow up and multiple follow-up interviews leaves everyone with the same conclusions that led to the current online application.

@lippytak
Copy link
Author

Thanks! My responses:

  1. We really, really need a stock of people signing up for Calfresh to test this approach and track how the follow up deviates from the in-person or web application response (number of touch points on either side required for completion and overall time taken to get enrolled). How do we do that?

I think goal of MVP is to process a small number of official applications (1-3 people from our own network, like you nudge nudge, or high touch at 1235 with clients in lobby) through this route to show "how easy an online application could be" and then take this demo to the next CWDA to start influencing the CalWIN consortium. I don't think quantitative metrics or deep research is necessary for this goal, but let's discuss if you think otherwise.

  1. Does this work for or against HSA's metrics? If they are judged on how many unique applications they get then this is the easy acquisition hack they have been waiting for. But if the metric that matters is more like the percentage of people in the funnel completing to enrollment then maybe not so much.

The most relevant metrics are probably caseload (they always want growth), participation rate (CA is notoriously bad), and administrative cost/application. They don't really care about absolute # of initial applications. Making a dead simple online application probably is good for the first two and bad for the third. This is a real tradeoff for the agency and the reason we can't scale this up arbitrarily...because it necessarily shifts some of the initial burden from client to agency.

  1. Are we trying to prove that people will apply online if the form is dead simple?

Two thoughts. First, I think we're trying to demonstrate that real human service applications can be dead simple. Second, we're furthering Dave's point that the primary online application for most services doesn't need to address every possible corner case, but rather should solve the 80% case gracefully and only ramp up when required.

  1. My biggest worry is that the snail mail follow up and multiple follow-up interviews leaves everyone with the same conclusions that led to the current online application.

Agreed. Sadly that's how mybenefitscalwin.org works right now so I wouldn't expect any big changes. Currently you apply online > get a letter > do your interview > exchange verification docs > get official enrollment decision. All we're doing is making the first part dead simple (I may be misunderstanding what you mean by 'same conclusions that led to the current online application').

@TianaWertheim
Copy link

Right now we don't know how much/many Eligibility Workers rely on the data submitted via the cumbersome online MyBenefitsCalWIN application. If they basically scratch it and start from the beginning with the interview, the So Clean application wouldn't cause more work per app. If that's the case, the only increased admin burden would come from the likely increase in online apps.

I bet there is great variation in how EWs handle online apps. It's probably worth doing some interviews with them.

@lippytak
Copy link
Author

I spoke with a couple EWs so far about this so far but will continue to probe. They don't scrap it but they often verify the info anyway. It sounds like a shorter initial application will lengthen the phone interview a little bit, but not much. Of course EWs would prefer more info upfront, but it doesn't seem to add too much burden (~5 mins) during the interview. We now have an internal HSA team (one from records mgmt, one EW, one from MEDS team) to help us smooth out the process and strike the right balance of upfront client burden. I'll keep you posted as we learn more.

@daguar
Copy link
Collaborator

daguar commented Sep 25, 2017

I've removed the label "prototype"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants