Citations and run-ins with law enforcement are incidental to being homeless. People experiencing homelessness are up against multiple barriers to accessing the justice system and are often ill equipped to handle legal issues on their own. When people miss court dates or fail to resolve citations, penalties are applied, bench warrants are issued, and these citations become major barriers to securing employment and housing. Case managers can help, but they can't act on information they don't have. By equipping case managers to support homeless clients in resolving their legal issues, we remove barriers to self-sufficiency.
What it does
This system allows case managers to subscribe to clients' legal issues, with their consent, from multiple court, jail, and probation/parole systems. Case managers act on these alerts in accordance with their agency's policy and the client's individual goals.
Case managers enter their clients' information in a web interface and indicate the types of events to which they would like to subscribe. At specified intervals, the incident monitoring service searches public databases for matches to the clients' personal identifiers. The message broker uses this information to generate events in a standard format, and publishes the events to the incident management application. The case manager receives alerts when new events are found.
Examples of legal issues that will generate an event are:
- Citation issued
- Court appearance scheduled
- Charges filed
- Warrant issued
- Sentence entered
- Client booked into jail
- Client released from jail
- How we built it
Challenges we ran into
We pursued a fairly ambitious architecture for this project. While it gave s a lot of flexibility, we bumped up against limitations where we didn't expect them.
We deployed to Heroku, but Heroku add-on providers hobble their software until you subscribe at a pricey level.
Accomplishments that we're proud of
Our team brought almost half the women who participated in the hackathon. That's a sad state of affairs, but we're proud that we were not plagued by a lack of gender diversity.
On top of that, we had a wide range of experience, with a team member who has almost no coding experience, two juniors, and two seniors. We all learned a lot.
Our approach gave us a lot of flexibility, and we took advantage of it. Our team has diverse experience, from .Net to Erlang to Ruby and Perl. We took advantage of our experience by using a microservices architecture that consolidates the responsibility of the code and makes for clear boundaries between services.
What we learned
We deployed to Heroku, in spite of previous experience with things not working as expected, or things not working as expected until you commit to a hefty monthly fee. We probably should have just gone to AWS, but that increases our reliance on devops, and we wanted to ship more end-user value.
What's next for incident-plaform
There's only one thing to do next, and that is to show our minimal functionality to users and see what it inspires in them. From that testing, we can imagine several things may come next.
- Integration with electronic health records to allow seamless use for mental health providers and others
- Adding more case management functionality
- Improved security and real data
- Configuration of sources near case managers who want to use our product