Building a tech tool for sensitive data

In 2011, US-based organisation Physicians for Human Rights launched the Program on Sexual Violence in Conflict Zones, after identifying that many survivors do not come forward to report their cases. They began by working with a variety of stakeholders who are each responsible for some aspect of documentation around the incident, to improve their technical skills in documenting and preserving forensic evidence to support local prosecutions of the crimes.

Their responsible data challenges centred around digitising the process of communication and information collection between these partners, bearing in mind that the data they are collecting and working with is of a very sensitive nature. They engaged in a thoughtful process of assessing needs and working out what needed to happen before engaging in any technology development, then iterating upon the application, Medicapt, that was developed.

Based on an interview with Karen Naimer, Director of their Program on Sexual Violence in Conflict Zones, the challenges they faced and mitigation strategies they engaged with are related below.

In conflict zones, few survivors of sexual violence end up coming forward to report their experiences, for a number of reasons; stigma, fear of reprisals, or not knowing who to turn to, for example. The Program on Sexual Violence in Conflict Zones is aimed at helping those survivors who do come forward increase the likelihood of successful prosecutions by training clinicians and other first responders to more effectively collect, document, and preserve forensic evidence of sexual violence to support allegations of these crimes. The programme focuses its efforts in the Democratic Republic of Congo, and Kenya.

Background

The programme began by bringing together people from various sectors who are involved in the process of gathering evidence to support a case: doctors, nurses, police officers, lawyers and judges, so that they can explain to each other their specific roles and responsibilities. Through multiple in-person workshops, they realised that documenting evidence of sexual violence to be used in court needed multiple steps from each of the stakeholders.

They realised that there were many obstacles to be overcome in order to better coordinate this collaboration, which at the time, took place via sharing information on paper between multiple stakeholders; transport is limited, the roads are terrible, and the cost of paper, photocopying and printing was very expensive.

the challenges

standardising data collection

Given that mobile phone penetration is high in the regions in which they are working, especially Kenya, they began to think about a way of using mobile phones to share the necessary information. Their first step was thinking about how to standardise the information collected as at the time in the DRC, there is no nationally adopted standard document or medical intake form for sexual violence. Before moving further on the ‘technology’ aspect of the project, they identified this gap and through a series of in-person workshops and iterations, they worked closely with local partners to understand what the different needs were, and in what format data should be collected. They then worked with their cross-sectoral network to develop a forensic medical certificate that would focus on very specific needs that lawyers and judges would need to see for these cases.

This meant that the information required as medical evidence could reduced to a single document that the doctors could submit as evidence in court, and that police could use in their investigations – essentially, making it easier for relevant data to be collected in a useful format, by all parties involved in the process. Having the hard copy printed form was the first stage of this process towards collaboration on data collection, and it is now being used in hospitals in North and South Kivu.

digitising data collection

As a first step, they looked at off-the-shelf technology options that might have been suitable for their needs. Working with a company responsible for a survey platform used in public health situations, they put their certificate into the already-developed platform, and tested it out in January 2014.

It turned out that putting their standardised medical certificate into the platform resulted in a very cumbersome process for clinicians who had to use it. They field tested the platform with 7 clinicians from different hospitals in Eastern DRC, who were already on board and committed to the project. From this experience, they learned two major things: that convincing them of the benefits of the technology was not an issue, but that this platform in the format it was in, was not feasible.

iterating upon their tool choice

To work out what would need to be in a useable and effective digital platform, and what needed to change from what they currently had, in January 2014 they held a 3-day workshop with people from their network, asking them: what would be in your wishlist for this technology, and what would the ‘must-haves, should-haves, and could-haves’ be, for the technology to be useful? Participants suggested ideas that they had expected, but also many that they had not anticipated. They collected all of these ideas, which then informed the process for the next phase of development.

From January 2014 onward, they undertook a big landscape analysis of existing technology tools at that point, to see what off the shelf options there were to identify a new model for this platform. This included interviewing many different technologists, privacy experts, and those working in public health, and as a result, they realised that no existing technology options met the specific needs that they had identified, and so that they needed to develop their own technology.

By the summer of 2014, they had identified a software development company to work with, and sat down with them to design and develop a mobile platform that met the needs of their end-users in the field. Their initial idea was to pilot and test the platform in communities they had already been working with, but with the possibility of it being adapted for global use.

reality check

A year later, in January 2015, they went back to the same clinicians who had taken part in the field test a year previously, as well as a couple of new people, and introduced them to Medicapt 2.0. The clinicians felt ownership over the design and the application when recognising that their comments had been prioritised, and that all of the features that had been classed as “must-haves” were present in the new version.

lessons learned

The process of developing Medicapt is still ongoing, but at the time of talking, Karen had already identified a number of key lessons dealing with making decisions around technology.

Looking around for existing tech solutions was helpful for them to work out exactly what they wanted from they end product, even though they didn’t end up using one in the end.

Deciding to redirect their course wouldn’t have been able to happen without the support of funders who trusted their decisions, and they were able to back up this decision thanks to ongoing feedback from end-users. Making that decision took courage, too – being able to flexibly change plans, budgets, team allocations and their strategy, wasn’t easy, but they realised that having the priority in mind of building something actually useful was far more important than sticking to their original plan.

Finding a development team who really understood the sensitive environment in which they were working, was also tricky. They took their time in choosing a company, and spoke to a lot of people, and in the end, were very happy with the company they ended up partnering with: Karen recommended taking time to find the right home for the product, rather than rushing into any partnerships, and being very clear in explaining their needs. They also made sure to have ongoing, almost constant communication with the development team – even bringing one of the developers to the region to field-test the product.

Throughout the process, they have been working with the mantra of making mistakes early on in the process, and redirecting based on these mistakes. They also tried to bring end users of the product into the process from the earliest stages, rather than waiting for any kind of “perfect” product to share.

Given the sensitive nature of the data shared and collected, they have been in conversation with a number of technologists and security experts, and even though they’ve had a number of ideas of features that could make the product better, they seem to be waiting for security solutions before implementing them.