Case Study: A returning traveller drop-in clinic at HTD

The Challenge

At the clinic, travellers who have returned from the tropics and are acutely unwell turn up without requiring an appointment to get treated by specialists in tropical diseases. The team had been managing its patients using a combination of spreadsheets, a big notebook for review cases, a central document management system for letters, and an access database for capturing research data.

We were tasked with understanding the needs of the front-line staff as well as the research interests of the department, and designing a service that met those needs.

What we did

We started by working closely with clinicians who had worked in the clinic, mapping the various different journeys that a patient takes, from when they first arrive, to when they leave the care of the service. (That was either when they were sent home, or when their details were crossed out in the big paper ‘review’ notebook.)

We also tried to understand who the different people involved with delivering the service are. As with most clinical services, they operate with multidisciplinary teams, with people performing different functions within it. We made sure that we understood the perspectives of the nurses and administration staff, the junior doctors, and the consultants.

Building on these insights, we came up with a set of user journeys that we felt would cover all of the different paths through the service. At this stage, we hadn’t built anything - we had sketches, descriptions of things, and lots of notes from conversations with the people who would end up using the service.

At this point, we shared these ideas with the future users, to see what they thought, and what we’d gotten wrong. We made a few adjustments, and started to build our first prototype.

We built the service using the OPAL framework, re-creating the journeys we’d discussed in working code. Once we had a working prototype, we started showing it to users - gathering their feedback, and making adjustments based on what they told us.

After iteratively following this process for a number of weeks, we reached a point where everyone agreed that we had a service that would support all the different teams in delivering care, while also capturing high quality data to enable service audit and research.

The result

We launched the service in September 2015, where we were able to replace the various previous systems overnight. For the early weeks we were in constant contact with the clinical staff, making sure that we responded to the small issues that only real-world use of a service throws up. Despite a few small issues, the transition has been a complete success.

Even in the first few months since launch, enough data has been captured about the work of the clinic that several abstracts for papers have been submitted, and the team is now able to conduct clinical audits about their activity that would previously have taken days or hours in just minutes.