RFC: a standard for applying for a service

[volkanunsal]

This is a continuation of the discussion I started on the OpenReferral mailing list. From the end user's perspective, finding a service is not enough. You also need to think about how the people will apply for the service. This entails downloading the application forms, taking a photocopy of the documents you need to send, and so on, that can still be hassle. I believe that is the hardest part for the end user, and there are companies trying to solve that issue here in New York, but I think this would be a great extension to the Ohana API.

If the admin users could specify the steps the end user needs to take in the app, then it would simplify both the end user's job and their own. An example of a Makefile would be:

Step1: Fill out the form XYZ and ABC Step2: Take a picture of the forms and upload them to the app Step3: The API receives your application and submits it for review to the admin

What do you guys think?

[monfresh]

This sounds like a great idea in theory, but I think there are some practical challenges to think about.

There already is a how_to_apply field in the DB that can be used to describe the application process. Ultimately, the quality of this data lies with the person entering it. Here's an example that is fairly detailed: http://www.smc-connect.org/organizations/san-mateo-county-human-services-agency/redwood-city-office-1?keyword=CalFresh

In the example above, the Human Services Agency already has an online portal where end users can download and upload forms and applications. They also already have a process in place for reviewing the applications, which might not be compatible with the one you're proposing.

Sending an end user's application to the API for review by an admin assumes an organization would be willing to receive and process applications via that channel. That would be a conversation that needs to happen with each individual organization. Or perhaps in some cases a local government might be mandating the use of Ohana.

There are also privacy and security considerations since people will be uploading sensitive data.

I don't currently have the time to work on or think through a complex feature like this, and I'm not sure if Code for America would be willing to maintain it once our work under the Knight Foundation grant ends in January (which doesn't involve building any new features), but if you have the time, go for it. Maybe a gem might be the way to go for this, assuming you would be willing to keep maintaining it.

What do you think?

[volkanunsal]

You bring up lots of good points. The security issue is the trickiest to resolve, in my view. You need to have a trusted middleman to store the documents in this transaction. The alternative is to have the documents be submitted directly to a host specified by the service provider, so no untrusted party needs to touch them.

The most minimal scope of this feature might be a form builder of sorts that allows admins to

1) Upload a CSV file of form questions given to them by the service providers 2) Modify the acceptable parameters on the site 3) Specify an endpoint the user can submit their applications

This would generate a JSON file that can be used to setup a dynamic form on the frontend. The service providers need to be convinced to specify their process in this format, which might be a bit unlikely if they already have a process in place, as you point out. They have to be really motivated to experiment with a new approach to their intake process.

The pain point, as I see it, is on the users of the services, not on the providers. And making the application easy (entirely digital) for users when the existing pathways are hosted on unusable web forms or on PDF files is the real challenge.

I know others are already working on parts of this. The easiest thing to do would be to start to create some spec for intake processes and try to gain mindshare for that from the service providers, which might eventually trickle down to the end users through governments that mandate the use of Ohana, as you put it.

[volkanunsal]

This paper identifies a potential solution to the secure file storage problem. Adding here for reference:

http://snap.stanford.edu/class/cs224w-readings/clarke00freenet.pdf

[monfresh]

Thanks for your thought and research. This is definitely an interesting problem to solve, but I don't think this discussion should happen in a GitHub Issue. I'd like to keep Issues solely for bugs or requirements that need to be implemented. The discussion around potential new features should happen via pull requests. That way, we can distinguish legitimate issues from enhancements that might or might not be built. I'd like to strive for zero open issues, but I think it's OK to have pull requests open for a while.