TLDR: Led product for Frontida, building adaptable Electronic Health Record systems for underserved medical clinics.
Role: Head of Product
Skills: User research, AppSheet, team management, fundraising
Table of Contents
- Frontida’s Conception & the Journey to No-Code
- The No-Code Hypothesis (Post-Greece)
- Working with Floating Doctors in Panama
- Developing a Low-Code EHR
- On the Ground in Panama + Following the Iterative Development Process
- Personal Product Management Lessons
- Where Frontida is Currently
Frontida’s Conception & the Journey to No-Code
Born in a USC class dedicated to developing solutions for Greece’s refugee crisis, Frontida started out with the aim to help overburdened medical volunteers in Lesvos’s largest refugee camp. Not only is the camp terribly overcrowded with over 13,000 refugees, but we also found that medical providers struggled to provide care for the overwhelming number of patients requiring treatment. Their paper system is fragmented and it is incredibly difficult to monitor vulnerable patients.
The problem: Relying on paper records is an organizational headache that puts lives at risk. Clinics lose records, volunteer’s handwriting can be illegible, and doctors struggle to find critical patient information in a time-sensitive manner.
Electronic Health Record (EHR) systems are nothing revolutionary. They exist across established environments and provide a critical service to healthcare providers worldwide. Yes, their UIs could be easier to navigate and yes, they could be more accessible to patients and doctors, but, in essence, they serve their purpose. The big challenge, however, is that these systems cost tens of thousands of dollars, and are out of reach for many clinics/non-profits in underserved communities.
Frontida thus embarked on a journey to develop a custom solution for Greece and fill the gap that was left by these legacy systems.
The No-Code Hypothesis (Post-Greece)
After developing a simple patient onboarding system and beta testing the product in Greece, Frontida faced a huge challenge. Our product was coded from scratch thousands of miles away, which meant we had to make a few assumptions when developing the tool. Upon deployment, volunteers gave us a lot of feedback on fixes the app required, but the turnaround time to incorporate feedback took weeks if not months. Furthermore, the chaos of the camp meant there was not a continuous feedback loop, and the team struggled to make our tool as valuable as it could have been.
Covid-19: Curveball
When Covid-19 struck, the need to organize patient information and protect refugees became even greater. Our volunteer contacts asked for a solution, and – given the short turnaround time and the simplicity of the contact tracing tool they were asking for – we decided to build the system using no-code tools. Surprisingly, it worked great. Adoption was quicker than our fully coded out application because any of their feedback could be incorporated in days, if not overnight.
A Hypothesis:
We began to develop a hypothesis. Given the contact tracing app was performing more effectively than our EHR, what if we built an entire EHR with low-code tools? It could theoretically allow us to:
- Develop tools quicker
- Incorporate rapid feedback
- Build cheaper (especially without expensive devs)
- Train clients to use and update the app by themselves
Theoretically, being the key word…
Working with Floating Doctors in Panama
Through our work in Lesvos, we got connected with Floating Doctors (F.D.) in Panama. Floating Doctors is an NGO that provides medical services to indigenous populations scattered across the Bocas del Toro archipelago. These populations live in villages that are extremely remote and – in most cases – entirely cut off from the outside world. Unfortunately, health outcomes for these populations are extremely dire with high burdens of disease and malnourishment. FD was eager to work with us in validating our low-code hypothesis in the hopes of developing an EHR for their clinical operations in over 30 different villages.
Developing a Low-Code EHR
The work began to build a solution that could serve FD. My team was broken down into 2 halves: the medical team (med students and professionals) and the development team (building the low-code EHR). For the next 5-6 months, I led the team to develop an EHR. Our workflow:
After testing a variety of low-code / no-code tools, we decided to work with AppSheet as our preferred partner. It uses Google Sheets as its database, which makes it more accessible for anyone joining the team.
Thinking long term: If our hypothesis panned out, we wanted to make sure we were developing a tool that could be scalable to other clinics and would not be pigeonholed into the unique requirements of FD. For this reason, product development initially focused on the Core EHR: a template that could serve as the underlying, scalable EHR framework for future clients. After the baseline was configured, we began creating a fork of the core EHR focused on customizing the solution for Floating Doctors.
On the Ground in Panama + Following the Iterative Development Process
In October 2021, we visited Panama and followed FD volunteers to three villages: Sharkhole, Valle Escondido, and Cerro Brujo. We found ourselves immersed in the lush mangrove forests, hiking through dense vegetation, and following these seasoned volunteers to reach remote villages and set up clinics.
Day 1: Shadowing and Observing How Volunteers Use Paper Records
During our first day at FD, we shadowed the doctors during their remote clinic in the hopes of understanding the operations at a level of detail you simply cannot get from abroad. All of us helped out and placed ourselves in the volunteer’s shoes to understand the experience better. It was chaos, but there was a method to the madness. Shoutout to my high school Spanish classes that came in handy as the only method of communication with most patients 🙂
Currently, FD uses a paper-record keeping system that is costly, inefficient, cumbersome, and results in wasted time and misplaced patient data.
The daily clinical operations follow a process like this:
And here are just a few of the pain points this process entails:
- Accumulating patient records takes up valuable time every evening. Patient files can be misplaced or damaged.
- Transporting documents in heavy trunks is laborious, especially with long, arduous walks to clinics. Documents waste space in the canoes as well.
- Each clinical visit sees wasted time when doctors have to find relevant patient history. Important information may be overlooked.
- Post-clinic debriefs involve sifting through the boxes of records again.
- Treatment codes don’t get inputted automatically.
- The government-mandated transcription and scanning of each sheet is costly, and handwriting legibility issues often lead to translation errors.
When we got back to camp, we debriefed with the doctors and I held a session to introduce and familiarize them with our EHR. The presentation started smoothly, but pretty soon we realized everyone had differing levels of technological proficiency, and people were falling behind. We rolled with it and broke up into smaller teams with each Frontida member pairing themselves up with a few volunteers.
Every team member took copious notes throughout the day, and we shared them after a big dinner. Painstakingly, I sifted through everyone’s feedback, categorized features, listed out all the bugs, and put together a development priority list. After a few hours of pushing some critical fixes and planning for the beta test tomorrow, I was ready to crash. It was an exhausting first day, but we learned a lot.
Day 2: Testing our EHR Alongside the Legacy Paper Record-Keeping System
We saw emerging signs that our hypothesis was correct: Doctors were astounded that we were able to incorporate some of their feedback just overnight. It seemed like our hypothesis was proving to be true; the bulk of foundational development work had been pivotal for us to be able to fix the smaller usability issues.
But after that initial success, things started to fall apart. Doctors used the tablets while we transcribed alongside them on paper records. Quickly, the doctors began running into critical issues that forced them to revert to paper documentation.
Issue 1: Our EHR was designed with offline functionality, but because FD had indicated that satellite internet would be provided, we designed features that allowed us to sync patient information between tablets. After our satellite internet stopped working, this syncing workflow we had trained doctors on fell apart.
Solution: We would have to reorganize the system so that each patient’s data was localized to a single tablet. Then, syncing to the centralized database could occur whenever a team returned to base camp.
Issue 2: We designed “user profiles” that resembled each of the distinct stations in the clinic: admin, patient intake, medical provider, and prescriptions. We had understood each of these stations to be distinct; however, we realized that volunteers often bounced between stations and needed to access all clinic functionality.
Solution: We observed the “stone” system used by the admin table to track each patient as they moved through stations. This behavioral insight was incorporated into our EHR by eliminating user profiles, giving each volunteer full access across stations, and letting them tag the patient at each stage of the process (like the stones).
These were just two of the many problems we encountered. Our work was cut out for us.
Day 3: A 24-Hour Sprint to Revamp our Product
The team stayed up late incorporating boatloads of feedback. Low-code advantages began to shine. We were on a roll. Feature after feature got checked off our list. The app began to transform. After a late-night grind, we tested the changes with a mock clinic we designed, and things were looking up! We decided to attempt another beta test, this time using only our EHR.
Day 4: FD Uses Frontida’s Updated EHR
The doctors woke up the next day to what seemed like an entirely new system. Although there was still some refinement to be done, we presented the FD team with the bulk of what they asked for, and there was a look of shock and astonishment. Many of the doctors had worked with traditional corporate EHRs before, and they couldn’t believe their eyes. Eagerly, they played around with the EHR and familiarized themselves with the changes before the clinic ahead.
This time, we were only using the EHR system based on the agreement that our team would copy down the data collected into their paper systems after the day was over. But this meant our EHR was flying solo.
After a bit of getting used to it, doctors began seeing the speed and efficiency through which they could care for patients.
- Some doctors really appreciated the voice dictation features. Others started picking up their pace with rapid typing.
- Doctors seemed to exclaim with excitement when patient history would autofill on their tablets. “It saves literally minutes each time I’m looking for medication history for example”- one doctor noted.
- And offline functionality worked flawlessly!
Personal Product Management Lessons
Creating Psychological Safety
Given that Frontida’s team was volunteer-based, a major challenge was to encourage participation and incentivize hard work.
- Giving ownership to team members on projects helped prevent social loafing
- I also strived to make the team a safe place for people to fail. As with the nature of being a volunteer, other priorities do come up and team members had to feel safe asking for help and being transparent about other priorities. Without psychological safety, falling behind would become a vicious cycle of guilt, and volunteers used to fade out of the team. We embraced a team dynamic of helping each other out.
Balancing priorities
I learned the hard way that there is such a thing as too much user feedback. Doctors often could produce infinite feedback.
It helped to work with stakeholders that had aligned incentives to prioritize feedback. For example, running things by FD admin (who was paying for development services) helped us prioritize needs vs. nice-to-haves.
Furthermore, sometimes a volunteer’s feedback may simply be a reaction to change. It’s the age-old adage from Henry Ford “If I had asked people what they wanted, they would have said faster horses.” An EHR often has friction during adoption, but that shouldn’t mean avoiding new workflows altogether.
Engagement during Standups
Rapport and team dynamic were especially strong amongst Frontida members given our mission-orientedness, but our daily standups also helped a lot.
- Hosting a quick game or fun question during each standup increased participation and enthusiasm.
- I incorporated a technique I learned from my wonderful friend @Glory Kanes. Every few standups, a different person would take lead over a particular research/product sprint. By personally stepping back, team members learned to look at each other for help and everyone on the team had the space to become a leader.
Things don’t always go to plan.
From beta tests gone awry to team members going incommunicado, preparing for unexpected changes was another lesson I kept facing.
- Maintaining resolve as the leader. When our first beta test ran into critical issues, team members began panicking. At junctures like these, it was critical to stay strong and give clear directives that help people adapt.
- I heard a phrase similar to: “If you’re going to give me shit, find me a shovel.” When problems arise, it’s easy to admit defeat or cave into a catastrophe mindset. Creating a culture where teammates help each other find solutions gives everyone a clear sense of direction when all feels lost.
Where Frontida is Currently
A few months of rigorous pressure testing later, Floating Doctors was ready to start shifting over clinical operations to Frontida. There were some more minor changes we made along the way, but the no-code hypothesis was validated! Development time and speed of incorporating feedback were two of our biggest advantages.
Frontida is now being used across 30 villages, serving over 800 unique patients!
Additionally, through word of mouth alone, we’ve been put into contact with additional clinics that want to beta-test Frontida’s EHR.
Check out Frontida’s website here, and please don’t hesitate to reach out to me if you are interested/know a use case for our product.
And, of course, a HUGE thank you to my team:
- Ziyi Xu
- Jack Lyons
- Laura Roed
- Lauren Yen
- Joshua Manlutac
- Vivianna Camarillo-Guenther
- Quincy Guenther
- Kristof Oswald
- Kareem Khalifeh
Anants Blog 