I tried to hack justice and this is what happened…

​Last Monday through Wednesday, I had the pleasure of attending HackJustice, a three day long socially-focused legal tech hackathon. The hackathon was specifically aimed at helping the Refugee Advice and Casework Service (RACS) improve their process of getting a barrister’s opinion as to the prospects of success an asylum seeker may have at judicial review, and then getting counsel to run the review case in court. The hackathon was the first of its kind in an Australian law school, and provided law students with exposure to hackathons and creative problem solving using technology.

Judicial review is the review of an administrative government department decision in court. Such review is the final avenue an asylum seeker has before being detained by the Department of Immigration and Border Protection (DIBP). Upon positive response from counsel as to the prospects of success at judicial review, RACS requests the barrister to run the case, or, if the barrister cannot, RACS refers the case to another barrister. This is called the Justice for Refugees or “J4R” program.

On the first day, numerous industry recognised speakers spoke about the advent of legal technology in improving access to justice, RACS outlined the challenges they face in helping their clients, asylum seekers, be granted justice. Mariam Hammoudy, who oversees the J4R program, explained their current processes, and what they hoped to achieve from the hackathon.

I then met my new team members. They were all UNSW combined law students: Will, a fourth year Commerce/Law student, Lee, a third year Commerce/Law student, and Daniel, a first year in Actuarial/Law. We were delivered an in-depth problem brief, and a copy of the forms used, as demonstration of the current J4R process. HackJustice was different to other hackathons that I’ve attended, in that rather than suggested technologies being used to use to solve self-identified problems, each team was given the problem and instead presented the method, processes, and technologies they would use to solve it. All teams having the same problem brief, did, however, lead to numerous very similar solutions being proposed.

The main issue RACS presented was with their current paper-form-based barrister referral service, notably with incomplete or incorrect forms leading to significant delays and additional administrative burden. On questioning, RACS said that following-up an incorrect referral application can take them between two to three months. An asylum seekers only has around 28 days to file for judicial review, before being regarded by the DIBP as ‘unlawful’, and potentially being placed into immigration detention. The asylum seeker can’t afford the time it takes, and RACS, operating on a substantially reduced budget since 2014, doesn’t have the resources to deal with this administrative overhead.

Our team went straight into brainstorming, and looking at the paper forms to understand the existing process, to determine how it can be digitised and made more efficient by applying technology.

We started by discussing our ideas, and then progressed onto whiteboarding a rough wireframe of an app that would assist an asylum seeker’s case worker in filling in and submitting their application for referral. Following that, we also discussed the back-end technologies processing that would have to be performed behind the scenes to tie our solution together efficiently. I also proposed an access-code based barrister briefing solution that could replace attachment-laden email briefs to the barrister seeking their initial opinion, and then collecting their response as to the merits. We proposed that this be integrated into broader scheduling and assignment system so that if the initial barrister is unable to run the case, it can automatically assign a new pro-bono barrister.

On our second day, we continued iterating on our ideas and proposed processes, leading to a late-night hangouts call between our team as we finalised our proposed processes and messaging for the pitch that would come tomorrow. Will also finished working on his comprehensive visual concept prototype that would be demonstrated the next day.

On the Wednesday, we finalised our presentation deck, and then had to explain our proposal to the organiser a UNSW academic, notable for their involvement in open law database AustLII, in three minutes as part of a selection process to eliminate down to the top 10 teams to pitch at the closing ceremony. We hurriedly answered his questions, and quickly demonstrated our prototypes.

The short list was not revealed prior to a team being called upon to present, so every team, including ours, was working on refining our pitches up until the closing ceremony time at 1pm.

At the closing ceremony many teams, with very impressive proposals, took the stage.

We were called to present, and apart from minor technical difficulties, I think we did a decent job. Our team sat on the edges of our seats the whole time, waiting for our team number to (hopefully) be called, so it was relieving to be called to pitch.

Following the presentations, a short intermission took place as the judging panel conferred to decide the top three teams. As the placings were announced, we sat with a feeling of nervousness, yet mostly a lack of expectation. There were many very strong competitors, so when we were called as first place winners, it came as an unexpected surprise.

As first place winners, we’re now hoping to be working with Gilbert + Tobin’s innovation practice, g+t<i>, to bring our ideas and processes to fruition for RACS.

I was glad to participate in this hackathon to support RACS, and explore efficiencies that can be gained through technology in the community legal sector. HackJustice reinforces my feeling that exposure to legal technology, ideation, design thinking, and (non-legal) problem solving is what is going to distinguish law school graduates going forward. I envisage hackathons of a similar nature expanding across law schools in the future.