Introduction
For the past couple of years, I have been working as a UX designer at one of the leading tele-radiology companies in India. This case study would be a witness to the tech solution for one of the major operation workflows, the company depended on.
An imperative part of the system is the transition of a radiology case submitted through the platform efficiently. Time is a critical component of this industry as a person's life depends on the platform's ability to deliver reports at the set out time. And, stumbling upon the increasing caseload on the platform, the team had to come up with a way to increase the efficiency of the product.
The following workflow was designed to help the operations team, coordinate the cases, correctly and complete maximum cases over time.
Initiation
The operations team is a base of over 15 individuals titled Case Coordinators who coordinate the critical cases between the Hospital and the Radiologist for efficient and improvised reporting.
At this point, I did not come across a teleradiology system as multifunctional as ours in this industry. So, the references were mostly with us. The most insights were drawn by the company's history and quality evolution. After few conversations with domain and platform experts in the company, here is what I learned.
Age Bracket of the users - 21 to 55.
Gender ratio is considered to be equal for both.
Educational bracket- 70% graduates.
The case coordinators assign the cases to radiologists according to the radiologists' expertise and priority. They coordinate with the different stakeholders like the hospitals and diagnostic centres till the completion state of the case in the platform.
There are a lot of human biases while assigning.
The rads who are newly onboarded often get missed out by the case coordinators because the coordinators rely on the memory of the radiologists' qualification and expertise.
Too many lists of cases, with little to no visibility on the case's state in the platform, makes it difficult for the coordinators to detect the present state of the case. Often resulting in miscommunication amongst the company and clients.
Highlighting few key insights.
Process
Here, I would like to vouch for the development framework we have adapted as a team.
We followed the Five-element of UX Design to turn our idea into a workable product. There we collaborations and brainstorming in all the steps on the way up, followed by testing with real users of the platform.
User Research
After the initial hypothesis was drawn, the next step was talking to users and understanding their behaviour towards the platform.
I conducted several Semi-structural user interviews with the coordinators on how they are using the current platform(old interface). They spoke about their pain points in the UI, how they dealt with clients and other departments for various challenges they faced on the platform on daily basis.
Here, it's important to note, being the insider of the company, the focus was primarily on their method of operating the system. Rather, inclining towards their stickiness towards the platform, Normally how I would approach, in the case of the external users.
User Groups
Usual Coordinators - who handles the normal cases incoming on a daily basis.
Scan specialists- who handle complicated rework and return issues.
Both groups are eventual case coordinators.
sneak peek to transcripts
Accumulating all the key pointers, I built the various empathy maps, corresponding to each target user group. Presenting them in the written form for understanding the context better.
Empathy Mapping of User Groups
👨🏻
User Group 1 : Usual Coordinators.
Characteristics : Handles predefined set of clients. Dedicated. Senior at work.
User Goals
Maintain and coordinate the cases to the completion stage.
Maintaining the estimated time on the platform.
Assign and reassign the cases as soon as possible in case of system failure.
Accessibility of assignment.
Information needed to achieve goals
Name of the center.
Complexity of cases.
Professional capacity of radiologists.
👩🏻💼
User Group 2 : Scan specialists.
Characteristics : Has the ability to read scans. handles rework and return cases.
Pain points
Difficulty in checking rework status.
Most of the time, radiologists don't know where the rework reason is to be found, they have to assist them in those situations, mostly send the reasons through other, more visible message portals.
User Goals
Reassigning rework cases after accessing the reason.
Contacting the centers for collecting the return cases on any of the reasons - clinical history, suboptimal study, a missing document, etc.
Information needed to achieve the goals
Visibility in the status of a return/rework case.
Analytics of rework and return cases over time.
Visibility towards documents, timestamps and details of the case through time.
Rework reasons to be shown more prominently.
After analyzing the research, I redefined the problem statement and the pain points we needed to address through this project.
Challenges
How Might We..
Make the platform competent to view all the information needed by the coordinators to assign the cases to radiologists.
Show the information regarding the professional capacity of the different radiologists.
Help coordinators detect the status of a case at any given time without having to open the case completely.
Help them sort the cases on the set parameters they need.
Facilitate uploading documents in the platform and maintain the timestamps of upload.
Make the rework reasons easily accessible to the Case coordinators.
Show them the number of rework and return cases completed over time.
Show them, the pool of cases they coordinated over time.
Enable discrete communication system between the coordinators and the radiologists.
Now that we have our Research Analysis in place, the next step was to ideate!
Ideation
An initial brainstorming session was done to figure out the direction of the solution.
If I needed clarity on the potential or developmental limitation of the solution, I would discuss few pointers with the whole product team as well.
I started creating sitemaps to generate understandable workflows to discuss my thoughts with the team and simultaneously work on the feedback to bring the whole team on the same page before creating screens. I used Whimsical Board to create a clean and fast sitemap.
Low Fidelity
After a rough workflow, I went ahead with making wireframes. The process aimed to plan the contents of each screen and chalking out the overall workflow. Simultaneous discussion with the tech team, so that they can work on building the backend requirements, while I utilize that time to create high fidelity prototypes, to communicate the exact UI and feel of the workflow.
UI System
The screens were build using Adobe XD. And mostly for the purpose of running it initially with the users and moving forth to be able to be handed off to the developers for deployment.
Since we followed the Five-element framework, the team preferred to build the system and test it aptly with the users.
Workflow
All the cases were brought under one unified list, recognized through their status throughout all the users of the platform. This included the operations team as well as the external users. Moreover, the status tag was identifiable in the backend of the system as well. Each case was linked with the correct stakeholders managing the case, and viable options were opened to these users. These options helped them handle the case. Tracking the status of the case, enabled the system to come up with an approximate time of completion, and the same information could be used by the coordinators to communicate with the external stakeholders regarding the case.
Solutions
User Pain-point
"The case table is prolonged and we have to see so much information we need to see before assigning a case to a radiologist, sometimes we miss information. "
Context - All the contexts would be in regard to the old interface. There was a prolonged list (exceeding the screen width) of information that was important to assign cases to the radiologist. This would exceed their cognitive load. The coordinators who were new often struggled to assign cases and took more time in completing a caseload.
Solution-ing
The unified case list screen consists of a table that consists of all the basic information needed by the coordinator to assign a case, i.e. Hospital name, Modality, Patient details. So they do not have to open a case completely to check the basic details.
The CASE LIST TABLE also consists of a column to ' assign radiologist' where coordinators can readily assign the case through a selection dropdown. This dropdown consists of sections on the basis of the doctor's expertise and a dynamic search bar, to help the coordinator, chose from the vast list of radiologists. In addition to that, the radiologists online are indicated through a green dot by their name.
On click of the percentage button, a modal comes sideways which shows the intermediatory details needed by the coordinators need in addition to the basic details for assigning. These include the timeline of the case, Patient age, and gender, modality study breakup, collaboration requests, documents attached, Number of messages, etc. This is an intermediate modal that appears and disappears with one click. This acts as a quick view of the case.
User Painpoint:
"In the platform(old interface), there are so many case lists for different stages of the case, that sometimes the case is lost and we are unable to track which list we should search."
"There are so many different lists, I don't even know what they mean and contain. I only have to open them when a case is lost and we can't find where it is. It causes immense delay to release the case, and the centersblame us."
Context - The old platform had numerous different case lists for cases on various different touchpoints of their lifecycle. There was no unified search mechanism, hence once out of sight of one stakeholder of the case, would be lost in the system.
Solution-ing
All the cases were brought under one common list, with the status system to understand where the case is in the whole lifecycle.
The names of the statuses helped the back-end team and case coordinators to understand if, yet to be assigned to the radiologist, if it’s in the process to a radiologist to be reported, or with the Quality Assurance team to be reviewed, so on.
Unified search is given on the top of the list, which contains all sorts of filters and checkpoints for searching through the cases.
The status is always visible to the case coordinator on his/her main case study list.
The cases can be filtered by the coordinators as they need on the basis of date, name of the hospital, name of the doctor, statuses. We have identified the most used status filters and kept it on the top of the table so that it’s easily reachable by the coordinator.
User Painpoint -
"Some centers are very impatient if the process gets very long and time-consuming. The center technicians demand the cases to be completed if they have sent to our system."
Context- The interface had no visibility of the estimated time to complete the case, and hence no means to hold up the trust of the centers, and they showed their impatience by calling the coordinators continuously to express their distrust, as a result distracting the coordinator. This causes unpleasantries on both sides.
Solution-ing
According to the status of the case, an estimated time of completion is calculated by the system (considering other factors like modality of the case, or the complexity of the case), and the percentage of completion is visible on the case list to the care coordinators.
On partially opening the case (from the percentage button), a rough timeline is visible to the coordinators and the centers, which helps in holding up their patience. (Doherty Threshold Principle).
User Painpoint-
"In the platform(old interface), there are so many case lists for different stages of the case, that sometimes the case is lost and we are unable to track which list we should search."
"There are so many different lists, I don't even know what they mean and contain. I only have to open them when a case is lost and we can't find where it is. It causes immense delay to release the case, and the centersblame us."
Context - The Scan specialists are specially entitled to handle rework and return cases, but since the interface is incompetent to identify cases having an additional rework or return workflow, it is difficult for them to track the cases they have completed over time.
Solution-ing
All the cases are identified in the common list, through their 'rework' or 'return' status. The status system is further expanded to accommodate statuses like 'rework complete' or 'return complete' so that it can be identified through the system.
A fully capable search workflow has been created over the case list.
The cases can be filtered by the coordinators as they need on the basis of date, name of the hospital, name of the doctor, statuses. We have identified the most used status filters and kept it on the top of the table so that it's easily reachable by the coordinator.
"Reason for rework given from the client does not have the radiologist name, and I have to download the report to check that."
Context - Since the scan specialists cannot view the details of the case, it is often needed for them to download the case to view the basic information like the reason for rework and which radiologist had reported and at what time, even sometimes they have to download the images with are large Dicom files, and the time lag from all of this affects the speed of completion.
Solution-ing
On opening the case entirely, we have put the information into various tabs, for the full visibility of the case in identifiable sections. The general info tab consists of all the information of the case along with the reasons for rework at the top.
The Reports tab consists of all the reports that have been submitted against the case, in the descending order of time, along with the name and contact details of the radiologist, and the reason for rework (if it is a rework or return case).
The sections also include an image viewer which enables the coordinator, especially the scan specialists to be able to analyze the case without having to open it on a separate image viewer, hence saving a lot of loading time.
"The technicians do not provide proper details, after a certain time when the radiologist looks at the case and realizes that certain documents are missing, the center is intimidated, and they claim that they have uploaded the document, as a result, there is miscommunication, dissatisfaction, and delay."
Context - Often the coordinators are trapped in a situation where the technicians forget to upload a document that is crucial for reporting. Now when the radiologists return the cases, the technicians deny that they didn't provide the document on time. And we can't go in conflict with our own clients.
Solution-ing
The Documents tab consists of a time log of all the documents uploaded against that case, along with the name of the uploader, and timestamp of upload. This includes even the documents sent through messages. This ensures visibility to everyone.
"Since the messages linked to the case are visible to both the centers and the radiologist, the rads might message remarks like, "I don't want to report this, I am going for a break", which creates a wrong impression in front of the client. "
Context- The radiologists are assigned the case, after which they remark that they need a break or they are not comfortable reporting the case. Since the messages in regard to a case are common, often the client can see these messages.
Solution-ing
The message tab consists of separate channels are established with respect to each case, which consists of one on one chats between stakeholders. This solved the issue of keeping conversation discrete between coordinators and radiologists.
"When I am handling a rework or return case, I don't know who had attended the initially, unless I download the report to check the name of the radiologist or ask amongst my colleagues extensively. This causes a delay in reassigning the cases."
Context- The scan specialists were especially entitled to handle the return and rework cases, hence, they always received a case that was previously reported or previously handled by some other 'usual coordinators'. They however had no visibility of it in the old platform.
Solution-ing
The activity log tab consists of a time log of all the actions taken for that case throughout the platform. This helps especially if the case has been handled by more than one coordinator, to give visibility to the later person, how the case has traveled through the system.
Hereby presenting the whole workflow in brief.
Conclusion
This workflow is currently in development, so we are discovering new micro issues to solve every day. As a result, I will have to update this case study over time until it is complete.
Please reach out to me for feedbacks.
Comments