A translation application for healthcare professionals to better connect with, assess, and treat their non-English speaking patients.
Healthcare professionals need a way to bridge the communication gap and interact more clearly with non-English speaking patients because language barriers cause frustration and feelings of vulnerability as the intake and initial assessment processes take longer than normal. In a survey of healthcare professionals, 50% reported the intake process for non-English speaking patients takes an additional hour. The extended process can affect the life of the patient and also the lives of other patients waiting to be assessed.
Healthcare professionals must serve/treat the entire population for those that visit their facility. However, in the US, not all patients are English-speakers and healthcare professionals are able to communicate in every non-English language.
Therefore, the problem is when a non-English speaking patient goes to an Emergency Room in a primarily English-speaking facility, there is a communication and connection gap leading to an extended ER visit time for the patient, a significant delay in the ability to check-in and treat additional patients, and significant emotional impacts for both professionals and patients.
In the midst of the COVID-19 pandemic, the ability to assess, treat, and release patients quickly has become increasingly important to all. The intake process proceeding smoothly is critical as this is the first point of contact a healthcare professional has with a patient and sets the tone for the interaction, level of care, and communications with the patient.
Using a Google Form survey and through user interviews, we were able to boil down the pain points of healthcare professionals to the following:
Our preliminary research suggested that a language translator application that worked faster than manual input in tools such as Google Translate would be more beneficial to healthcare professionals along with some way to be able to foster a connection between healthcare professionals and patients.
After speaking with a few healthcare professionals and conducting a survey, we determined that an active translation application would be the most helpful in alleviating their pain points. Due to the majority of timing roadblocks occurring during the triage/exam stages, we took the approach of developing a basic information and triage form so that providers may have most of their more common questions answered. We also wanted to incorporate a way for physicians to feel more connected to their patients on a personal level.
The application displays the patient intake form with an ability for the patient to select their native language for their intake questions to be displayed in. The patient can then fill the form out in their native language and the data would then be displayed in the native language of the healthcare professional.
The healthcare professional can also actively translate each question by touching the question which results in the question flipping to display the question in English. The patient intake form would include different types of questions (i.e., multiple choice, single choice, open questions) to help medical professionals better understand their patients. Using this form would apply to patients of sound mental status and patients not deemed as an immediate admit to the ER (gunshot wounds, missing limbs, and other obvious items that need immediate care).
We have also included an option for the healthcare professional to introduce themselves with a photo and their title/specialty/credentials. We also included an option for the healthcare professional to have a recording of their name to help the patient when the professional's name may be difficult to remember/pronounce.
After we showcased our prototype, we learned that having large buttons that are easier to read were important. One area we weren’t sure about was how many questions to put on the screen at once. Should we do one question at a time, or 3-5 questions on a screen at a time.
We decided to go with 3 questions at a time with a scrolling page, rather than a next page button. Also, we didn’t need to have audio readouts of each button, but could add a toggle switch to activate the audio readouts. Ultimately we added the audio readouts to the product backlog, and focused on the core triage and intake form.
Backend - Heroku
Backend - Golang
Backend - The most difficult part was hosting the application on Heroku because there was a bug that led to an application error.
Backend - It doesn’t have any scaling issue as I followed the domain approach which simply follows the business model. This makes it easier and gives room for scaling.
Backend - There are different entities to work with and during scaling there would be more.
Chris and Emma may conduct user feedback after CoLab has ended so that Chris may build out his design portfolio.
Future iterations of the product would include additional features including:
Being able to work hand-in-hand with a designer and developer was eye-opening in that I was able to gain multiple new perspectives on how to approach problem solving. From a functional standpoint, I had never worked with Figma so that was really awesome to get hands-on experience with. The entire experience taught me that products are far more complex than they present on the surface - it’s difficult to deliver significant value in such a small amount of time.
I Imagined a product designer’s job was to make pixel perfect icons, smooth interactions, and beautiful UI. But my experience taught me that I enjoy talking with users about their pain points. This research is vital to the product design process because it makes sure that the team is solving the right problem from the start. Having a beautiful UI is at the top of the pyramid, but the user research is the foundation on which that product is built.
I was able to work with people from different time zones and create time to have meetings at midnight. Hosting my backend application on Heroku was a real deal, prior to this time, I never had a business hosting my application on a “free” platform by myself. I learned a lot from it and I was able to overcome the challenge.
Planning out the project extensively before starting development made the development process incredibly quick. By building out the application in components, I was able to reuse many parts of the code which also helped the development process to be organised and quick.
It was a new and unique challenge to work on such a diverse team that brought many talents to the table. Coordination across multiple international time zones is extremely difficult. However, our team worked extremely well together and had an overall positive experience despite the difficulties of building a brand new product from the ground up.
