Closed benefitkitchen closed 8 years ago
We could certainly start looking into it and see what kind of headway we could make with the data owners. It would be up to the data owners whether to implement an API.
Quick clarification -- by federal poverty level are you referring to the Census poverty thresholds or HHS poverty guidelines?
@declan, @greggish, @lloydbrodsky, would you care to weigh in on this request?
Also seems it would be useful for many Code for America projects. So please ping your CfA friends.
Hello Elizabeth,
I'm looking forward to figuring out how DDOD works. This is my first foray... I hope it's an appropriate, well-formed request.
Regarding your question: my primary interest is re: HHS poverty guidelines.
Best, Dan
On Wed, Sep 30, 2015 at 4:56 PM, Elizabeth Hsu notifications@github.com wrote:
We could certainly start looking into it and see what kind of headway we could make with the data owners. It would be up to the data owners whether to implement an API.
Quick clarification -- by federal poverty level are you referring to the Census poverty thresholds or HHS poverty guidelines?
— Reply to this email directly or view it on GitHub https://github.com/demand-driven-open-data/ddod-intake/issues/49#issuecomment-144540327 .
Daniel Beeby • Technical Director • Self-Sufficiency Solutions • http://benefitkitchen.com/
@benefitkitchen welcome! I assume you found DDOD through the wiki http://ddod.us, but if not, that's the place to start to get oriented. Basically, DDOD is a platform for users to let HHS agencies know what data needs they have that aren't yet being met. DDOD acts as a moderator to try to help you find the right data and interact with the data owner; DDOD doesn't own any of the data, so if and how data improvements are made is up to the data owner. We try to make the process as transparent as possible -- so this conversation on GitHub is public, and you may see other users chime in agreeing with you on the need for the data or with suggestions for how to get the data. Everything eventually gets documented on the wiki as a knowledge base/reference for the public and other users down the line.
Your request is perfectly appropriate and well-formed -- and it's also fine to come to DDOD before you have a well-formed request and we can help you to better specify your request and turn it into a formal "use case." We'll often come back with clarifying questions (like the one I had) because the better we can specify the request and articulate the value to the data owner, the better case we can make to the data owner for data improvements and also to check in to see if what we've uncovered will meet your needs.
If you'd like to discuss further by phone, please drop me an email at elizabeth dot hsu at hhs dot gov and we can set up a call.
Back to your data... is this the data that you'd like to see delivered as an API or some other machine-readable format? http://aspe.hhs.gov/2015-poverty-guidelines
Thanks!
Thank you Elizabeth. Yes, those are the data.
Best Dan
Sent from my cordless phone. Please excuse brevity and errors. On Oct 1, 2015 9:18 AM, "Elizabeth Hsu" notifications@github.com wrote:
@benefitkitchen https://github.com/benefitkitchen welcome! I assume you found DDOD through the wiki http://ddod.us, but if not, that's the place to start to get oriented. Basically, DDOD is a platform for users to let HHS agencies know what data needs they have that aren't yet being met. DDOD acts as a moderator to try to help you find the right data and interact with the data owner; DDOD doesn't own any of the data, so if and how data improvements are made is up to the data owner. We try to make the process as transparent as possible -- so this conversation on GitHub is public, and you may see other users chime in agreeing with you on the need for the data or with suggestions for how to get the data. Everything eventually gets documented on the wiki as a knowledge base/reference for the public and other users down the line.
Your request is perfectly appropriate and well-formed -- and it's also fine to come to DDOD before you have a well-formed request and we can help you to better specify your request and turn it into a formal "use case." We'll often come back with clarifying questions (like the one I had) because the better we can specify the request and articulate the value to the data owner, the better case we can make to the data owner for data improvements and also to check in to see if what we've uncovered will meet your needs.
If you'd like to discuss further by phone, please drop me an email at elizabeth dot hsu at hhs dot gov and we can set up a call.
Back to your data... is this the data that you'd like to see delivered as an API or some other machine-readable format? http://aspe.hhs.gov/2015-poverty-guidelines
Thanks!
— Reply to this email directly or view it on GitHub https://github.com/demand-driven-open-data/ddod-intake/issues/49#issuecomment-144723628 .
Thanks -- will start looking into it.
I know that calculating eligibility is a serious challenge for many people in many contexts -- from service referral to benefits enrollment to affordable housing etc -- and income is one of the harder components of eligibility. This would be a small but significant piece of a hugely important puzzle.
Thanks for the endorsement, Greg.
cc @noah-t @lomaxrx @sariyie @daguar
Looks like ASPE already has the data in CSV, XML, and JSON (see links just above the html table): http://aspe.hhs.gov/dataset/2015-poverty-guidelines
Is there anything else beyond what is published here that would be useful (e.g. historical information)?
We've actually prototyped this already over at CFA: https://github.com/codeforamerica/fplapi cc @mapsam who has led that work.
Indeed! Project idea began here: https://github.com/codeforamerica/project-ideas/issues/70 and has been implemented as a really crude Flask API that just uses a JSON file as the datasource, instead of a database. You can query the API like
http://localhost:5000/api?size=3&income=2000&income_type=monthly
and it returns
{
amount: 20090,
amount_nice: "$20,090",
fpl_percentage: 119.46,
info: {
year_base: 11770,
year_rate: 4160
},
request: {
household_size: "3",
income: 2000,
year: "2015"
}
}
I liked this suggestion, which seems to fit what you all have been talking about.
One thing you might consider, though, is putting the data into a standard format (e.g. JSON, YAML, CSV, etc.) and separating it into its own repo, which can then be included as a submodule in your API project
The next step, other than hoping for @daguar to write all of the tests for me, is to deploy on to heroku or something comparable and figuring out how to properly update the percentages on a yearly basis as CPI updates nationally.
This is great progress everyone. Thank you for locating the file. The annual upkeep is an important element of that. Since we'll be utilizing the data, I'd be happy to be on the team helping keep it fresh.
There are also "two kinds" of federal poverty level... there are "fall" and "spring" numbers (some benefits use the most up-to-date numbers and some use the older version for an additional period). I'll talk with our numbers mavens to ensure when/how/why we use the other numbers... but my point is this: It might make sense to keep historical numbers for folks who want to do comparisons or use these different datasets for other reasons. So we might wan to have a current_year variable so that we can do current_year - n to get old data.
Historical numbers are definitely important. They already exist as JSON in the API and you can add year
to the query. If no year is added, it defaults to the current year.
Also, feeling inspired yesterday I pushed the FPL API up to Heroku and it works at a real URL now!
http://fplapi.herokuapp.com/api?size=3&income=2000&income_type=monthly
@mapsam Thanks -- I'm going to link to this on the wiki entry for this use case, which I started here: http://hhs.ddod.us/wiki/Use_Case_49:_API_for_Federal_Poverty_Guidelines
Looks like you are using the HHS ASPE data and are storing the data within the API as you linked above. I noticed that ASPE has different guidelines for contiguous 48 vs Alaska and Hawaii: http://aspe.hhs.gov/2015-poverty-guidelines and http://aspe.hhs.gov/dataset/2015-poverty-guidelines. Is this not something most folks worry about or because there is no adjustments for Alaska and Hawaii in the poverty thresholds?
@benefitkitchen Regarding the "fall" and "spring" numbers -- is this just a matter of using current year vs prior year numbers? I believe the government only updates the poverty guidelines once a year, but correct me if I'm mistaken.
@mapsam -- I added info re: your API here: http://hhs.ddod.us/wiki/Use_Case_49:_API_for_Federal_Poverty_Guidelines#Long_term_implementation
Please feel free to edit if I missed anything or got anything wrong. Thanks!
Last year's numbers will do the trick.
I updated specifications section of http://hhs.ddod.us/wiki/Use_Case_49. @mapsam, @daguar, feel free to suggest changes.
Hello Folks,
Can someone tell me if there are plans to update this for 2016?
Best, Dan
On Tue, Dec 8, 2015 at 11:24 AM, Elizabeth Hsu notifications@github.com wrote:
Closed #49 https://github.com/demand-driven-open-data/ddod-intake/issues/49.
— Reply to this email directly or view it on GitHub https://github.com/demand-driven-open-data/ddod-intake/issues/49#event-485833427 .
Daniel Beeby • CTO • http://benefitkitchen.com/ • 212-849-2773
@mapsam Did you want to update your Heroku hosted app? @benefitkitchen, there's a chance I could find a home for this tool as well. (Disclaimer: I'm referring from the standpoint of the DDOD initiative. I don't represent HHS.)
Thank you, David.
This is pretty simple to update, we just need to be sure that somebody's going to do it in order to switch our code over to use the API.
This would need to be added for 2016 "2016": { "base": 11880, "rate": 4160 }, The "rate" remains the same for 2016 (at $4160). The 2017 numbers come out Jan 20.
Best, Dan
On Fri, Sep 9, 2016 at 3:42 PM, David X Portnoy notifications@github.com wrote:
@mapsam https://github.com/mapsam Did you want to update your Heroku hosted app? @benefitkitchen https://github.com/benefitkitchen, there's a chance I could find a home for this tool as well. (Disclaimer: I'm referring from the standpoint of the DDOD initiative. I don't represent HHS.)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/demand-driven-open-data/ddod-intake/issues/49#issuecomment-246018392, or mute the thread https://github.com/notifications/unsubscribe-auth/AKKcg0bwbmW_m8NucbX7MhSZjtVINRuQks5qobapgaJpZM4GGzk- .
Daniel Beeby • CTO • http://benefitkitchen.com/ • 212-849-2773
👋 hi all
I've made a pull request adding the 2016 numbers provided by @benefitkitchen above. I'll deploy to heroku once things look good.
Did you want to update your Heroku hosted app? @benefitkitchen, there's a chance I could find a home for this tool as well.
Worth noting the current free tier this heroku app is on should not be relied upon. Code for American can't guarantee it being up 100% of the time, and I can't guarantee it will be updated promptly.
I'll comment back here once the updates have been deployed!
Successfully deployed!
http://fplapi.herokuapp.com/api?size=3&income=2000&income_type=monthly
Thanks @mapsam! Way to rock the spirit of community provided solutions! 👍
BTW, one day this would be the perfect service to move to Chalice, which is AWS's way to implement serverless functions in Python: http://david.portnoy.us/python-serverless-microframework/
Isn't this the kind of thing that should be adopted by the gov? It's great that members of the community have engineered a solution, but this is a matter of public service.
Hi @greggish, I think you hit upon the right world: "should". Often well meaning program owners in government simply don't have the resources, sufficient procurement flexibility or regulatory authority to make important services happen. This is the primary driver for spinning DDOD off into a nonprofit initiative outside of government.
I get the challenge. It's a problem. But when a non-profit takes on responsibility that should be assumed by a government: now we have two problems.
The federal poverty level (FPL) is used to determine eligibility for a number of federal, state, and local social support benefits.
e.g. a benefit eligibility calculation might look something like: if { [head-of-household-income] < 185% * FPL-for-[N-family-size] } then {eligible for .2 * FPL-for-[N-family-size] } Return benefit amount.
and would translate in numbers to: if { $2000/mo < 185% * $1647 } TRUE {eligible for .2 * 1647} Benefit amount: $329.4
I develop these sorts of algorithms and I have to maintain a calculation that updates twice/year. Ideally, this is the sort of data that could be queried dynamically via an API and returned to webapps that use the FPL as a means test for these or other benefits or systems.
Is this something that ddod could do for us??