Pathology is the branch of medicine responsible for the study of disease, including its diagnosis and mechanisms by which disease occurs. The pathologist is typically the doctor who provides the conclusive diagnosis, so correct and relevant information as the pathologist completes his/her work is important in leading to accurate diagnoses.
Until quite recently, pathologists examined cases and made diagnoses by looking at section of tissue and cells down the microscope. Increasingly, pathologists are using digitized versions of such slides, created by scanning the slides at various levels of magnification. This provides potential for faster diagnosis, better sharing among doctors, and room for innovation in the digital pathology space.
With this project, the goal is to develop an application that provides a pathologist with a view of digital slides, and that display relevant, contextual and helpful information at the time when the pathologist needs it in making a diagnosis. The final product must fit within the workflow of a pathologist, otherwise it will not be used.
This project is being completed as my Fourth Year “Capstone” project, and is something I am actively working on, along with three teammates. I am responsible for conducting user research and synthesizing the resulting information. Additionally, I am responsible for defining the user-facing flows and interfaces that will make up the application.
Neither I, nor my teammates on this project, are familiar with the field of pathology; as such, the first task was to better understand the user. To begin, we contacted a number of pathologists across the country, asking if they would be willing to spend time walking us through their day-to-day workflow. This initial email made very little mention of digital slides or image processing in order to minimize their bias coming into an interview.
We received a number of responses from pathologists, eager to speak about their processes and responsibilities. I devised a set of questions targeted at gathering information about various parts of the workflow, then hosted interviews via phone and video conference. The responses received as part of these interviews were incredibly informative, and help form a better picture of exactly what a pathologist does, how they complete their work and the tools they use to do so, as well as frustrations they experience. Several of the doctors commented that we had “really great questions”, which was really nice to hear!
I compiled the audio files and transcripts of the conversations I had had with pathologists, and found that a good way to synthesize this information was into the following diagram, which provides a basic understanding of what pathologists do, as well as some explanation as to why they carry out such actions.
I have used this diagram in explaining the work of pathologists to peers, and have found that they are able to understand this unfamiliar field much faster with this visual.
Establishing User Flows
Through conducting interviews, it started to become clear what functionality would be required in software designed for pathologists. Through compiling the data, and speaking with my teammates, a set of user requirements was developed, ranging from specifications about performance of the system in terms of speed and usability, to the various features that are to be built.
With this information, I started drawing out the various features to be built, and how these would link together on various screens. This initial diagram is displayed below.
Working with my teammates, we refined this basic diagram into the following functional diagram, which details possible paths a user might take when using this application. The turquoise boxes represent different screens (or parts of a screen), while the purple diamonds represent user inputs or actions. I also wrote up some use cases to be included on this diagram, as this gives some idea of the different functionality that should be available on each screen.
This diagram has served as an effective communication tool between me and my teammates, as we are able to point to a specific screen of piece of functionality, see how it relates to other parts of the application, and helps us get on the same page about how the software will function at a high level.
We also concluded that a desktop application would need to be built – pathologists are not fans of current web-based software, and mobile devices, particularly tablets, are not commonplace in most hospitals or labs.
From the functional diagram above, I have been working to develop mockups for each of the screens indicated on the diagram, and an interactive prototype to display the overall functionality of the application.
I began by sketching out various screens on a blackboard to gather quick feedback from my teammates, and get an idea of how they will link together. I then took these sketches and iterated upon them until I arrived at mockups that I felt were ready to show pathologists to gather feedback on the product.
The first screen, below, is the “Case View” screen, which allows a pathologist to examine a particular patient case that has been assigned to them. It includes patient information, clinical history, and then a slide viewer that highlights “regions of interest”, as determined by the artificial intelligence algorithms that lie beneath the surface of this software. To determine what information is required as part of the Patient Information and Clinical History, I spoke with several pathologists, as well as conducted online research which led me to the pathology requisition forms of many hospitals. I standardized the fields required, and displayed them here.
After spending more time thinking about how the user will interact with this software, I realized that dropping a pathologist directly onto a screen that displays a list of cases for them to examine would likely be a bit disorienting, and overwhelming. As such, I have created a “Home” screen that pathologists will see when they first log into the platform. This provides them with an overview of what has changed in the system since they previously logged in, giving them a sense of activity and where they should direct their attention.
After having developed the screens for the application, I created a more detailed diagram as to how the screens work together, and also the inputs and outputs from this user interface system. The PDF version found here is likely easier to read than the image below, given the size of the file!
In showing our current prototype application to several pathologists, we have received overwhelmingly positive feedback, with doctors saying that this software could save them time, and ultimately money to the government. They see a huge possibility in being able to search databases of images and cases, as this is something not currently available, but would provide a new wealth of information at their fingertips.
I have spent time conducting usability testing with multiple pathologists, and the primary issue I have identified is pathologists have difficulty understanding the machine learning outputs being displayed on the screen. Through some research, we have found that this is actually a common problem with complex outputs, and doctors also look to understand why a certain decision was made on their behalf. This is an area that will require future work.