Learnings from Kenya on post hackathon health tech project

On the web, you’ll find tons of articles and blogs about hackathons: how to organise them, how to promote them, how to create momentum … but almost none about what happens after ! This silence has created some « distrust » towards event-based innovative ideation, often considered as a trend and show-off for startup-like-minded individuals, not necessarily familiar with the problem they’re trying to solve. 

At Techfugees, we wanted to give you a private insight into the implementation phase of a hackathon organized in 2019 with Techfugees Kenya, Oracle Kenya, iHub, Samuel Hall and Kenya Red Cross Society (KRCS), and where we’re at. 

 

The hackathon was organized to answer health-related challenges faced by refugees and the Kenya Red Cross Community Health Volunteers (CHVs) in Kakuma Refugee Camp and Kalobeyei Settlement: how to facilitate sanitary alerts and make sure care is being delivered at the right time ? Working hand in hand with an identified implementation partner, the Kenya Red Cross Society, who has the resources and confirmed the need of deployment of such a solution on the ground, to co-design and follow-up post hackathon was a must-have to ensure the long term impact of the hackathons for displaced persons in Kakuma. Initial technical specifications were shared to the hackathons participants to make sure the propositions were meeting the real use case. 

The winning team, Faceless Hackers, presented a 3-moduled application to improve the efficiency in clinical conditions management in refugee camps in Kenya with an e-health solution that makes it easy to report, monitor, assess and act upon health related problems: 

• A mobile application for refugees to report health issues to the relevant authorities. It would automatically pick up the location of the person reporting the case, to facilitate tracking.
• A USSD app acts as a backup to the mobile application. It is used to report emergency cases, where it picks up the user details and their geographical locations. The USSD app will be useful where there’s limited internet connectivity, and for users with feature phones.
• A Web Dashboard  is used to track patients’ progress and analyze the reports from refugees and CHVs, such that outbreaks can be flagged early and appropriate measures can be taken in due time.

Step 1: Setting up the pilot planning and clear expectations

Right after the hackathon, the first step is to contact the whole winning team to evaluate the willingness to continue developing the project on a volunteer basis, if no funds are available, as it was the case for this specific example. This stage is crucial, as developing a usable product from the mock up is no small task, and motivation is key to success: it takes time, rigor and effort. 

Once the team is set up, with identified leads (front/back end development, product manager, design, business developer), it is time for the legal agreements to state, black on white, who is doing what and in what time capacity. At this stage, we generally use a Memorandum of Understanding between the partnering organization (Kenya Red Cross) and Techfugees, until the team sets up a legal entity and takes over. 

We got support from a legal volunteer, Kristina Tumas, to answer the team’s questions, regarding financial obligations, IP, timeline, team development over time, logistics for field visit (as the team was based in Nairobi and the pilot took place in Kakuma, 700km away), what happens if there is delays in the production…

Trust is very important before starting this kind of long term partnership. The goals, vision and values must be aligned and Techfugees acted as intermediary between the volunteers and the KRCS to facilitate mutual understanding and collaborations on an equal foot. The team signed up as KRCS volunteers to enter into the agenda of the organization and enable some staff members from the Innovation Department to commit time to the follow up and field deployment. 

 

Pilot launch, demo post hackathon, June 2020, watch the replay here

Step 2: Product development and follow-up

Once the MoU is signed and the expectations are clear for all the stakeholders involved, one can move to the definition of the communication methods. We set up regular bi-monthly calls to get live updates on the development of the product and assess continuous needs in term of support: 

• Medical information to facilitate the symptoms identification and co-design user journey; 
• Mentoring for business development (how to sustain the project post-pilot); 
• Mentoring and volunteer support for technical dev support (perks…) ; 
• Communication support (visual identity of the project, articles for updating our community of the achievements)
• Translation needs … 

In parallel, we used a private shared Slack channel for document sharing and written recaps with the list of tasks and to-dos (you can now use Slack Connect), as well as Whatsapp for urgent asks. Two pieces of advice: 1/ do not duplicate platforms, as it might unnecessarily complexify the communication 2/ only add in the loop active members of the project not to dilute the conversation and add extra-work with changing PoC. You should know who you are expecting in the follow-up meeting and what for ! 

Initial budget drafted by the Faceless Hackers 

Questions you need to ask yourself as innovator:  

As the products (USSD, app and Dashboard) were being developed, several questions arose in terms of usage, data privacy, accessibility, impact measurement. This is where the personas work and our Guiding Principles come into play to orient the reflection. They need to be addressed and thought about at the very beginning of the project: it’s never too soon to think about: 

• Human centered design: How are refugees involved ? How will the feedback collection take place during the pilot ?  Template of survey
• Data privacy: where is your solution going to be hosted ? What kind of data do you really need to make the service effective (and not which one you can easily collect)? 
• Accessibility: what kind of devices can the users ? Do the users have access to the internet or should an offline version be a priority ? In what languages must the product be available ? What is the level of digital and alphabetic literacy of the users ?  

Following this pilot, we, at Techfugees, are currently working on how to turn the Guiding Principles into an easily actionable framework (check our open collective knowledge base here).

 

Step 3: Pilot testing and product improvement

We started our pilot in Kakuma, Kalobey in December 2020 for 3 months. At that time, the USSD and dashboard were ready for feedback and the app was still under development. We asked a couple of questions to the KRCS to explain how the pilot was conducted and what was learned from the field:

 

 

 

 

 

👉 How many people tested the USSD / Dashboard? 

The pilot surpassed the targeted households of about 500 HHs as it reached about 2000HHs in village one all who were involved in the implementation process.The pilot targeted 500HHs in Village 1 where KRCS operates. A total of 320 USSD reports have been sent so far by the CHVs and the community members. 30 CHVs were involved in the pilot alongside the entire village 1 community members.

👉 How was the feedback collected? 

The pilot made use of various methodologies. Feedback was collected through a combination of field records, volunteer interviews, CHVs records and interviews,  community interviews, and internal interviews and recording by the staff.

👉 How was the community engaged during this process of the field pilot implementation?

Initial community entry meetings involved project inception meetings with Ministry of Health and Government officials in Turkana county. Meeting were organized with local Government leaders which included the area chiefs, assistant chiefs and local 40 neighbourhood leaders who all attended a sensitization meeting on the project. CHVs, volunteers and a number of community members  were the main users of the USSD application during the field pilot and the PHOs from KRCS would respond to the reported cases on the dashboard.

 

👉 Outcome and feedback for improvement: 

During the pilot, Over 350 cases were reported via the E-health watch application. Community health workers were able to refer to several cases found in the community using the USSD such as down syndrome, under age pregnancies, TB suspects, 2 mental cases traced, immunization defaulters, accidents and injuries, chronic cases and malnutrition cases traced. Child with down syndrome and serious septic wounds in the head identified and successfully managed.

In conclusion, the pilot confirmed that E-health watch enabled improved access to health services by providing a continuous reporting of health issues as well as potential analysis of the data in order to inform the community of future disease outbreaks. 

Some areas of improvement were also reported: 

• The exact location would make the location of identified cases however the breakdown that was provided was helpful;
• Realtime updates on the dashboard;
• The USSD application could not be used by Airtel subscribers, this leaves out a number of people.

👉  What happens concretely once you receive the information on the dashboard?

KRCS staff that manage the dashboard are able to see the newly reported cases on the dashboard. The newly reported cases as reported appear top of the list. The admin who is a KRCS staff then allocates the cases to health officers for immediate attention. With the phone number and location shared when a case is being reported, the health officer with the help of CHVs are able to track down the case and provide medical care.

 

Step 4: Pilot closure

 

👉 Is the team from the Hackathon continuing independently or is the project taken over by the implementation partner? 

From the very start, we had identified the Kenya Red Cross as our deployment to take over the volunteers in case the project was to stop or if the hackathon team had no time, funds or willingness to continue. The desire of the volunteer entrepreneurs to set up a legal entity of their own is key for the long term sustainability of the project, and if this step is not taken, the project must be handed over in order to raise funds.  For Faceless Hackers, it was decided that the project would be internalized by the Kenya Red Cross following the pilot in Kalobey. At Techfugees we want to thank all volunteers who contributed and made this project possible, especially Allan Mukhwana and Cliff Gor, the two developers who believed in it ! 

👉 How to ensure a good handover? 

The handover is a critical step for the project to continue and might be difficult. This is a list of the main areas (non exhaustive) we looked at for the handover. Starting with a recorded demonstration of the product(s) always helps to grasp the stage of development and the vision for the newly onboarded individuals joining the project.

• Visual Identity: this is the easiest part ! When the project is taken over, it’s up to the Kenya Red Cross to keep the previous visual identity (logo, social media, design chart…). In our case, the visual identity was still at a very early stage and mostly developed during the Hackathon, with no coherence over the different modules nor official public presence. 
• Storage: the storage and domain names must be taken over too. For the dashboard (https://faceless.rocks/ for the dashboard)
• Code: the code was hosted on GitHub and shared with the Techfugees team. Having a “readme” obviously facilitates the handover. The code was shared with the technical team and handed over by ZIP file.

👉Was the pilot successful and will the project continue? 

For any pilot, the impact measurement must respect a clear set of KPIs to evaluate. In our case, the first pilot testing was promising but more work on defined KPIs is ongoing, including :  

• # users (USSD + App + Dashboard)
• # sanitary alerts received (USSD + App)
• # sanitary alerts answered  (USSD + App)
• Average time per answer (USSD + App): what is the time saved by health intervention in comparison with regular interventions 
• Click rate on the knowledge base (present in the dashboard): how is sanitary awareness level affected (before/after survey). 

The randomized controlled trial (sampling) would be an effective approach to measure the impact on the field both on qualitative and quantitative data.

A second testing is necessary before the scaling phase, in another area near Nairobi, targeting urban refugees in Mukuru is in preparation to make sure the app (now ready), USSD and dashboard are flexible enough to be used outside of Kalobey by the Kenya Red Cross teams and refugees outside of Kakuma, in a different geographical setting. 

In order to support the effort, we’ll be bringing new partners onboard and we launched a crowdfunding campaign in June: click here to donate and support the scaling of this project: bit.ly/TFKenya . We count on you ! 

 

Follow the team on Facebook & Twitter
Donate here to support E-health Watch Development

Contact them at kenya@techfugees.com