How Lines of Code Can Save Lives

Human Rights First: Asylum Analysis

• Human Rights First is a non-profit organization that assists asylum seekers who live in Washington DC, New York City, Los Angeles and Houston TX who do not have or cannot afford legal representation, to obtain help with a claim for asylum or other protection-based form of immigration status. Asylum seekers come from around the world and when they need help securing their privilege to live in the United States of America, they come to Human Rights First
• The app that is being created for this labs unit is helping Human Rights First track historical case data from immigration hearings and board of immigration appeals hearings. In tracking and assimilating this data, HRF hopes to identify patterns in outcomes of hearings based on where the asylum seeker if from originally, why they are seeking asylum (gang violence, ethnicity, etc..), language spoken and credibility of the defendant. If patterns can be discovered between a judge’s ruling and one of the above reasons, lawyers can work to defend asylum seekers in a more proactive and strategic way that does not play into the bias of the judge. If the bias of the judge becomes too overwhelming and anyone who fits that description regardless of their situation is denied, there is data to bring to the government agency to correct the bias of the judge through legislation.
• The product that I worked on to solve this problem is an implementation to view the pdf of the case file without needing to download it first. This allows administrators from HRF and refugee representatives to check the case file pdf alongside the important data that is scraped from the document to ensure that the scraped data is accurate and conforms to what is on the pdf. This will ensure accuracy when the representatives are going over the data for an upcoming case that is similar to an historic case. I also engineered an approve and reject button that allows administrators to check unreviewed case files that were uploaded by refugee representatives They can then approve the case if it is appropriate and send the data to the case file database or reject the case if appropriate and erase the record completely. When the RR (Refugee Representative) views this same case upload page, they will see a submit button because the other buttons are only visible when logging in as an admin. I also redesigned the view for important data from cases in the case overview page so that it is easier to understand for the end user and the design is comparable with the rest of the app. This contributes to the larger goal of the group in that it allows for the scraped data from DS and the added fields to be checked against the pdf document in a much more user friendly manner. The backend created new databases and endpoints to point unapproved/approved cases toward when an admin or RR submitted/reviewed a document.
• The fears/concerns that I had going into this Labs project was that there may be things I need to accomplish that I did not know how to do. Up until the point, I had been creating my code base from scratch in projects or altering an existing code base very minimally. I was expected to learn an already existing code base and add a substantial contribution to it to make the app better for the end user. This was somewhat intimidating but I feel I rose to the challenge and delivered well-developed features that matched the current code base.

Screenshot of the organization homepage

Screenshot of the asylum seekers page

Technical Features and Challenges

My main contributions to this project were creating a react function that is controlled with state management to allow pdfs to be extracted from the uploaded file and viewed in app for comparison against scraped data retrieved through the data science logic and engineering react buttons that can be hidden/unhidden depending on the user type logged in. I also

Functionality to view/hide buttons depending on user type

Functionality to show case pdf in the view pdf modal

Newly designed case overview page to view relevant individual case data

The largest technical challenge that I discovered was that there was no functionality that pointed toward a backend endpoint to view pdf data. The current pdf data was located in a sample file that showed a pdf but only as a sample when viewed. I discovered this problem when navigating through the app in my local repository. I saw that the pdf data pointed toward the sample data. I was able to overcome this obstacle by learning the current code base and creating a function that allowed the view pdf button to point toward the endpoint where the pdf data was stored and retrieve that data to be shown.

Where we are right now

The app is becoming very functional and in line with stakeholders requirements:

• The case overview page has been redesigned to be more understandable and viewer friendly
• Important data is being successfully pulled from the documents and transformed into json to be imputed in the case-appropriate and accurate upload fields to be submitted into the case database
• The only problem with this is the extracting takes quite a bit of time and the Heroku server times out after 30 seconds and sends a signal that the operation failed because of this.
• The pdf viewing functionality is built but because of the above issue, no data is transferred when this operation is executed
• New endpoints and databases for approved and rejected cases have been built so that when the admin approves/rejects a newly uploaded case, the cases go into the proper database and show accurately in the front end admin user queue
• The queue was not built during this iteration but the buttons for approving/rejecting a case are functional and send the data to the correct database
• There is enhanced searching capability that allows the user to search for one or more terms in the database to more accurately find appropriate case data
• Fields have been added to the scraper to narrow down the specifics of the case.
• These fields include: language spoken, one year filing deadline, interpreter access, indigenous status and determined credibility. These fields were also updated in the case upload form, search panel and case data columns

Future Recommendations

In the next cohort, goals could be:

• The scraper could return data to the case upload form so that new cases can be added to the repository
• The pdf viewer to be functional and return the entire case in pdf format. If the pdf is not available, there should be a text that states that the document was uploaded as a csv file. This functionality is already built but should be visible when the Heroku issue is fixed
• There should be an admin view that includes a pending case file queue so that the admin user can approve/reject submitted cases from that queue

The biggest technical challenge faced by the upcoming cohort:

• getting the Heroku server to process the data from the case files in a timely manner so that it does not time out and fail to obtain the data.

This can be fixed by:

• Implementing the python functionality with a C base
• Switching from Heroku to AWS for deployment of the app

I received feedback throughout Labs that I was always willing to help, proactive in problem solving, delivered deliverables in a timely manner and had great open communication throughout the project. Some ways that I improved during labs are better cross-team collaboration and really owning the project and features I was assigned.

This project furthers my career goals by giving me real world experience in working with an outside client to engineer and deliver features based on an agreed upon timeline. I also have experience in working with a team of frontend engineers, backend engineers, data science engineers, ux/ui designers and a project manager much as I will be doing in my career.