The engineering team are responsible for all the digital wizardry at the heart of DrDoctor. Their mission is to maintain the digital infrastructure to provide the best possible quality for our platform. Here at DrDoctor we work in two-week sprints, following the Agile project management structure. This means all projects are judged as two-week units which encourages us to manage our work better and to achieve more as a team. Last month, the Nerds (as they have self-proclaimed their department name!) decided to take on the great challenge of building ad-hoc messaging as a DrDoctor feature, all within a single sprint.
The goal was ambitious and the need for this new feature came about as we wanted to focus on two goals for our partners, and one goal for ourselves:
- Reduce admin workload (trying and failing to get through to patients on the phone)
- Give patients a better user experience of booking/ changing appointments
- Practice making quick features to test in trial (change our way of thinking)
Patients and booking teams find it hard to communicate with each other. The only avenue for communication tends to be phone calls. Reaching someone on the phone can be tough. You need to call them at the right time, when they are in the right place and when they are able to hold a private conversation. Patients often call hospital booking teams when they have questions relating to their appointment. If they want to book a new appointment or reschedule an existing one. Booking teams are often busy due to the sheer number of calls they receive, and patients often complain that booking teams don't answer and their calls go to voicemail. Booking teams often say the same, they struggle to help every patient over the phone.
As a result of this, patients often get booked into any available appointment slot based on clinic availability alone. When this happens, patients are not Involved In the decision-making process and are not given the chance to tell hospitals the scheduled appointment doesn't suit them. When patients are allocated appointments, they aren't available for in the first place, they end up missing them. These resulting DNAs cost hospitals a lot of money and waste valuable resources that could have been redistributed to benefit someone else that could have made it to the available appointment slot Instead.
Clearly a solution is needed to fix this. We decided to attempt building a messenger-style feature for communication in the DrDoctor web portals. This means that patients can send an ad-hoc message to booking teams. It also means that booking teams can send messages to an individual patient. Each party gets notified when a new message comes in and they can reply to each message directly.
Building a technical feature comes with a set of challenges and when time is limited it’s important to ensure all design decisions are made with the right components and tech and scalability is kept in mind. Luckily our team soon learnt that we have a decent tech architecture in place and our internal approach to coding works. By following DrDoctor best practices a process that otherwise could have taken far longer, was achieved within a short timeframe. This verified our internal processes are right.
The team divided the ad-hoc message feature’s functionality into three categories based on what they wanted to achieve. What they must, should, and could achieve. The aim was to complete all capabilities listed in the ‘must’ category.
At the end of the project the team achieved all components in the ‘must’ category. They also completed all the components in the ‘should’ category and most of the ‘could’ category.
Our co-founder and CTO Perran decided to measure the team’s confidence ratings every day during the course of the sprint. He asked the team how confident they were on a scale of 1 – 10 in completing the project.
The results were telling:
Working together as a team is a core-value at DrDoctor and we take great pride in our ability to collaborate with each other, with our partners, and with other solutions through interoperability. Setting our goals high means that we push ourselves harder and also find creative ways in delivering the tech that will really help the NHS.