OnCall: An app to help doctors better organize their work

I would prefer if you read this report since it’s a more detailed description of my design process, but if you don’t have time here you can find a short explanation of the final result

Doctors and Emergency shifts

I’ve always been interested in the healthcare system. When it gets better we all benefit from it.

Our hospitals are full of people that devote their lives to save and improve ours, that’s why I fell so compelled to try to do my part and help improve the system and the life of this people in any way I can. That’s how I started talking to doctors, to try to understand their work and the struggles that come with it. Soon the topic of 24-hour emergency shifts and their difficulty to efficiently follow which patients needed their attention came up, and that’s how the journey to create OnCall app started.

The shifts

Some context. In Spain, almost every medical speciality (cardiology, gynecology, nephrology,…) requires that some of their doctors stay in the premises of the medical center for 24 hours, to intervene in any situation that may occur out of the normal work schedule (illness is rude like that, doesn’t care about schedules). This situation is understandably stressful. Imagine that you’ve been at work for 18 hours, is past your normal bed time and you still have the responsibility of the well being of your patients.

I decided to go deep into this subject to understand their process and possible pain points that may occur. In a situation like the one that I just described, any task or endeavor that is not working efficiently could delay and affect a delicate situation.

I started talking to doctors from all over Spain (I interviewed 13 in total during the whole process) and my suspicions were validated when I asked them to describe with single words the situation. Here are some of the words that kept coming up in the interviews:

• Tiredness
• Stressful
• Exhausting
• Mentally and physically demanding
• Chaos

In these interviews I also took the opportunity to make a task analysis of their process, meaning a walkthrough of all the steps they needed to take during the process, to understand how they are tackling it in different hospitals and to identify if there is any recurring pain points.

The doctors that I interviewed were specialists who were currently or recently working in hospitals from Canary Islands, Galicia, Madrid, Seville and Bilbao. This conversations gave me a good understanding of the similarities all over Spain and about how this process was from the point of view of specialists.

I mentioned the word specialist a couple of times in the last paragraph. This is because my focus was on doctors who are in the second line of attention, they are only called when an Emergency Doctor has examined the patient and requires the opinion or action of a colleague specialized in a concrete branch of medicine.

But before going even a little deeper, let’s put it all into context.

Meet Daniel M.D.

Daniel is a radiologist located in Tenerife. His work as a radiologist is to assess images from CTs, MRIs or ultrasound test, in order to give a diagnosis.

As I mentioned before, specialists like Daniel don’t immediately attend to patients when they arrive to the hospital, they’re called when required after a doctor in the first line of the ER has examined the patient. When Daniel is sitting in his desk this is how the process is for him:

1. He gets a call from a doctor from the emergency room asking for a test
2. Daniel asks some questions about the case and writes down the information that is relevant for him.
3. He either agrees to the test or asks for further evaluation from another specialist
4. After the test is agreed and completed, he evaluates the results
5. Finally, he makes a diagnostic decision and writes a report. At this point his responsibility with that patient is finished

After understanding the process for people like Daniel, I created an Affinity Diagram to gather all the insights that I got from my research and to try to understand the connections and trends.

Some interesting insights that I got from it were:

• A lot of doctors save interesting cases to follow up even if they’re not in charge of them any more
• Doctors lose a lot of time going to the computer to check if results of requested test have come in
• Doctors are really interested in knowing how many patients they have attended to in their various emergency shifts

But I’m leaving to the end the insight that really stroke me as I was conducting the interviews, and was confirmed on my Affinity Diagram. And it was the answer to this question:

“How do you know the number of patients that you have left to attend to, or that are under your responsibility at any given moment”. There were different reactions to this question, but always the same answer: “Notes on a piece of paper.”

I was surprised by this and I followed up with another question: “What happens if you lose that paper?”. And I’m going to sum it up with the answer that a hematologist gave me:

“Apocalypse”. — Patricia (hematologist)

A lot of doctors had lived that situation, and the only thing that they could do was trying to remember what they had and trusting that if they didn’t show up for a specific patient someone would notice and call them. I know what you’re thinking, don’t they have a software that fix this? Of course I asked that and the answer was no (at least for the public sector). They have software to check information, see how many patients are checked in in the ER or what the previous doctor has reported about them, but there was no option to see a list or spreadsheet of the patients in the ER that needed their specific attention. This made this paper (written by themselves in a blank sheet) very important. Some doctors put their names on them in case they lose it, or even have special papers of different colors in order to make it easier for someone to find it and give it back.

Example of a doctor’s piece of paper with personal information redacted

As I described for the process of Daniel, in this paper they usually write the name and number of the patient but also the relevant information they need in order to do their job, for example the kind of pain the patient has or existing tests.

The problem

Having gathered all the information previously described, it is very important for me at this point of the process to clearly state the problem that I’m going to be tackling. This helps me focus on the main insights found in the research throughout the whole design process. It’s also very useful when it comes to communication with co-workers or stakeholders. In this case my problem statement was:

Doctors on call need a way to keep track of the patients they have to attend to because they rely on paper notes that are easy to lose.

As part of this stage of the process, which we call define, I also create at least one User Persona based on the information that I gathered during the research, which in this case I presented to you earlier as a way to better explain my findings. This Persona works as a sum up of the insights that I got and as a way to empathize with the real users of the prospective app. It also works as a lighthouse during the decision making process. In this case, when deciding what to prioritize or which way to go I could think about Daniel and ask myself “what does Daniel actually need?”, “what’s going to be more useful for him?”.

What to make

Once I had defined the people, the context, and the problem, it was time to actually decide what my app would do. In order to make that decision I created some User Stories with the needs and goals of the possible users. I use User Stories because they’re easily translated into features, their structure makes sure that I always think about the user’s goals and, being this short statements that fit into a sticky note, I can then physically rearrange them using a prioritization technique. Here are two examples of User Stories:

“As a Doctor on call I need to access a list of the patients that I have left so that I remember all of them”.

“As a doctor I need to know what patients I’ve treated so that I can follow their evolution and evaluate my own work and process”.

After I distilled this stories I used the MoSCoW prioritization technique to decide what was really needed for an MVP of this project and what things would be good to have. Here you can see an example of the process:

It finally came the time to translate all this work into an interactive interface. It was clear from the interviews that a phone application was the best option. The doctors referred that they had it on them during the whole shift everywhere they went, and that they didn’t have trouble using them inside the hospital.

During the ideation and prototype stages of the process I ended up settling on this main sections for the app:

• On Call: The central part. Once a new shift is activated, doctors can log the patients through their patient number, write notes about them, access their tests and mark them as done.
• Follow up: Users will have the ability to save patients that they want to follow up on, those patients would be stored in this part of the navigation. Doctors do this for different reasons, like wanting to make sure there diagnosis was correct or finding that particular case interesting for education reasons.
• History: During the research, doctors either were already quantifying the number and kinds of patients that were treated in their emergency shifts or wanted to start doing it, so in this section they can find a history of the patients and shifts that have been logged.
• Settings: I add this as a relevant section because here users are able to customize their experience, mainly stating which patient data is important for them to have in the patient page and also which one should be used as identifier in the list view.

Before translating this ideas to interfaces, I developed a visualization of how the User Flow would work with all the sections to figure out what navigation made sense and to guide my design process.

I started sketching on paper the main sections of the app and testing some layouts, trying to see if people understood the structure I was creating. I soon moved onto my computer to develop low fidelity prototypes, with more clear and structured content to properly test with users.

Some low fidelity iterations: Patient List and Follow Up

Some low fidelity iterations: Patient Page

At this point I noticed that lists and scrollable content was going to be an important part of the app, so I analyzed some apps that are already making a good job with them to get inspiration and to try to understand conventions that users are already accustomed to. Pocket Cast, Wunderlist, MyFitnessPal or social media apps like Instagram were very useful to look at.

One of the things that came out time and time again during user testing was how important it is to make clear what parts were clickable and/or editable. Some of the things I did to tackle that problem was to add a hint “tap to write” in the sections meant for the user to write their own notes.

Final version

When moving into high fidelity I focused on giving even more visual clues to which parts were information to read and which parts were for the user to edit and use. You can see an example of that in the patient screen above, where I separated the information of the patient in a card, more distanced from the rest of the data. I also used the copy and the color of the text to be as obvious as possible.

In order to maintain the focus of the user’s attention and reduce the cognitive load, even more important in a stressful situation, I used progressive disclosure to hide the patients that were already dealt with, but I kept them easily accessible under Show completed. Another interesting thing that came up during testing was some confusion about the “order by” options, which I ended up solving using the two arrows next to the selected option.

One last thing that I want to point out is the color code that you can see in the list view and in the patient information. This information comes from the data inputed by the administrative staff to their database when a patient is admitted in the hospital and has 3 values: urgent, less urgent, and not urgent.

Demo

Finally, you can find an interactive prototype of the final result. While interacting with it I invite you to imagine that you’re Daniel and to explore some of the things that you can do:

• Start the shift
• Add patients through their patient number
• Add notes about the patient in each field selected as relevant by you in settings
• Check patients from previous shifts that you want to follow up on
• Check your history of shifts
• Personalize the fields of the patients that are relevant to your speciality or to yourself as a doctor
• Also in settings, select which field is the most efficient to identify patients in the list view

Click here to view the project `On Call app`

Next steps

• Test, test and test. I was able to test this prototype with 3 doctors and other non-doctors collaborators, but I think is important to get more feedback from prospective users to identify any factors that can be improved or discover use cases that I haven’t think off.
• Investigate more about the technology used to storage patient information in Spanish public hospitals, like the Fast Healthcare Interoperability Resources and of course, the security measures to make sure that the commodity of the app doesn’t interfere with security and privacy (some of the things that I propose is that, in order to use the app, the medical center has to activate your session, only working in the center’s private internet connection).
• Make sure that this tool and the measures that I can propose are in accordance to Spanish and European privacy laws.

Learnings

Working on this project has been one of the most interesting experiences of my career. It really reinforced for me the importance of spending time digging into the context, frictions and people involved in a process. Task analysis, interviews and user testing really paid off when showing the final result to doctors that told me how they wish they could use an app like that in their workplace (what a feeling to get that response!)

Also, taking into account the conventions used in the most common apps, helped guide some design decisions into something that users could feel that they were already familiar with.

And finally, being able to receive constant feedback from users and fellow designers was key to break blockers and take the project even further.

Thank you for reading and please, if you have any feedback or comment don’t hesitate to contact me on LinkedIn or at hectormrb@gmail.com.