Helping the Help Desk
The problem
Help desk administrators receive daily requests to manage the modification of health professional records within a network of hospitals.
These requests include data for the creation and modification of these records.
The information from the request must be validated and transcribed by an administrator in various parts of the management software, without a clear order and without a unified way to perform that task.
This complicates the process and requires administrators to have the necessary experience to properly navigate and manage the data within the system.
15-40: Unforced errors
- Ticket handling becomes a slow and inefficient process, due to multiple factors: the dispersion of data in different sources, the presence of obsolete fields in forms requesting information no longer used for management, and the request for information that the administrator does not necessarily know.
- Frequently, tickets arrive with incomplete data: This forces administrators to search for and validate missing information from external sources, such as websites or phone calls, generating an unnecessary additional workload.
My oportunity
I had the opportunity to create a process from scratch to centralize the efficient management of health professional data. I managed to reduce response times and free up administrators' time for other more urgent tasks.
- Data was unified in a logically organized dashboard, which decreased the loss of context during the task.
- Inherited fields from old forms that didn't correspond to the current workflow were eliminated, avoiding confusion.
- Automatic consumption and validation of information from external sources was implemented: Manual searches and possible errors due to data transcription were reduced.
Understanding
Inter(views)
To understand the dimension of the problem, I followed these steps:
-
Understand the data model (What is a
health professional record for the machine?):
I interviewed the technical manager, who provided me with an overview of the data model representing a health professional and the relationships between the different entities and attributes involved in that domain.
-
Identify the registration process:
I interviewed the administrators who perform the registration task to understand the steps involved in managing the health professional's record in the management system.
-
Identify the dispersion of data and information sources:
I discovered that the model of a "health professional record" is distributed across different tables (similar to multiple Excel sheets). Administrators must navigate the forms within the corresponding tables to create a modification of the records.
These interviews allowed me to understand how the data model was and how its fragmentation created an additional task for administrators: Assembling the health professional's information from multiple sources and data, which unnecessarily complicated and slowed down the process.
After receiving this ticket with missing information, they needed to manage the creation of professional records across different data tables , as there was no unified and simple process in place.
It was like looking for multiple needles in one haystack.
The ticket, the cause not the problem
Like any process, this task starts with a simple step: receiving a data management request ticket.
Thanks to the interviews, I realized that tickets generally did not contain all the necessary information for management, had outdated data that the administrator had no way to validate, or were asked to associate work data within a health structure that the administrator didn't have to have in their head.
Proposal
Write to organize, Draw to visualize
The next step I took was to write out the process step by step, as if it were a script. This allowed me to define moments and data categories to describe and visualize the process.
After arriving at the categories that created the record in the system (identity, profession, and workplace), the question was: If the data we need is not in the ticket, nor in the administrator's head, where can we get it from? If we could get it at all.
Even if you dream it, (not) everything is possible
Let's focus on 2 data points that found very different solutions:
007
Within the categories that create the "health professional" model, we can find identity data, profession data, and data relevant to the workplace within the organizational structure of a health institution that belongs to a network of multiple institutions.
In the case of professional data, there is a critical piece of information which is the license, that is, whether the professional is authorized to practice their profession. It's not a minor detail.
As expected, this data, although critical, sometimes might not come in the ticket, or if it did come, the administrators had no way, in principle, to validate that this data was the correct one within the system.
What did the administrators have to do? Pick up the phone (if they had it) and hope that call would give them the lottery numbers. In other cases, see if they could get it from some official database of licensed health professionals.
What I achieved: The development team could consume that data directly from the official database to bring the updated data, and the administrator only had to contrast the information offered by the system with the data declared in the ticket.
Things can go wrong
Another challenge for administrators was entering the correct place of professionals within an institution. For example, a cardiologist should be working in the cardiology department.
Where was that department in the institutional organizational chart? Was that department located in the same place in all institutions of the network? These were answers that had to come from the administrator's head, and no, they didn't know everything. That department was not necessarily found in the same place, and most of the time the administrator had no way of knowing where it was located.
The organizational chart structure had 4 levels and the workplace could be hidden in almost any of them. Until now, they could only select it from a very long list.
Where I failed: I didn't manage to get it implemented because I didn't anticipate the technical complexity of the solution. I didn't anticipate the technical complexity of the solution. The design proposal was to offer a system where the selection of one level would limit the offer of the next level to only the items related to the specialty being sought.
In case they knew the place, it could be entered in a search field to automatically filter the levels and visually show the path in that institution for that type of professionals (this was aimed at facilitating the task and also offering them that information for free).
Impact
- Data and task were unified in a logically organized dashboard, which reduces the loss of context during the task.
- Inherited fields were eliminated from old forms that didn't correspond to the current workflow, avoiding confusion.
- Automatic consumption and validation of information from external sources was implemented, reducing: Manual searches and possible errors due to data transcription.
We effectively reduced unforced errors that occurred due to redundant transcription of information and shortened the time professionals needed for this task, simplifying the task into an efficient and understandable process.
💪🏼 The new design reduced task completion time by 57% (from 7 minutes to 3 minutes).
The original process
After the redesign
