AIDD UX
Problem
Experience design of a tablet-first intelligent system for medical records and diagnoses.
Description
The hospital already had a digital system in place for managing records, test results, and diagnoses. However, it was only accessible via desktop computers in the staff offices. The bedside viewing of records or taking notes was all done on paper. Doctors held the file in hand while they examined the patients and filled in the information.
How about a tablet with intelligent assistence on-board?
Empathize
As the sole designer on the team, I visited the hospital to get a feeling of the environment. I also interviewed a number of doctors and residents to gather insights into their mindset and work process.
This led me to three aspects that required attention:
1. Context of use A hospital is a complex setting with various human, physical, and digital parts. Designing for such an environment requires a holistic and sensitive view. Also, upon entering the hospital, you instantly get the overwhelming sense of time and urgency! The time for the medical personnel is precious. So, the AIDD design should be clear and explicit, with as few distractions as possible.
2. Terminology in use The medical field is filled with technical terms that a medical UX naturally needs to apply. Proper terminology is critical not only for usability but also for the patient safety. During the interviews, I noted of the technical terms and asked for clarification when needed.
3. Procedures in use Every personnel in a medical facility follows strict procedures. As such, the doctors expect the system to mirror these procedures, from the steps patients go through to the field labels on the examination sheet. I obtained permission to review several medical records and examination sheets to better understand the details. The examination sheets were invaluable resources to shape the structure of the design. As well as the terminology.
Define
To better understand the problem, I summarized interview information and turned it into user needs statements, such as the one shown below. Describing the needs from the practitioner's point of view was particularly useful for designing the interface sections and steps.
Additionally, I conducted card sorting with three hospital residents. Since I was interested in learning the umbrella terms and categories, I decided on an open card sorting.
Sorting 40 cards, the results varied greatly between the three residents: 3, 6, and 9 groups! After reviewing the categories, 7 groups of actions seemed reasonable. The following is the information architecture I extracted.
Ideation
From the beginning of the project and in parallel to other steps, we ideated on UX and UI. Some features, such as the medical history timeline, required lengthy discussions since they were crucial to the experience while being open to innovation.
Tablet App Wireframes
The enter screens afforded login for different roles, each with different access levels to patient files. A 'Recent Users' row provided quicker access for users who frequently used that device.
As patient records were identified by name and ID, I designed the screen around those as prominent fields. The interface naturally provided searching and filtering functionalities as well.
As our research revealed, a patient's file included two mainly distinct phases, which were accessed at separate times (often by different personnel): (1) history and P/E, and (2) diagnosis and medication. The card sorting results also confirmed this.
When a patient entered the hospital, their medical history was recorded, along with the P/E and the chief complaint. Later, the doctor would read this record and input the tests, diagnoses, and medications.
Accordingly, I decided to make the interface navigable between the two phases. However, since users rarely needed to quickly switch between the two, I made them accessible via buttons on both sides. They were easy to press, yet they took up only a small portion of the screen. Additionally, during the first phase, no button was shown on the right side as there was no diagnosis. Then, during diagnosis, the doctor could easily access the history by pressing the 'History' (left-side) button. Oh, and they also resembled the tabs on a physical folder!
Also, I learned that a persistent display of the patient's general information would be necessary in the design. It was a simple feature, yet it saved doctors from having to refer to the first page frequently. Thus, there was a fixed top bar for the patient's information.
An essential feature of the UI was the ability to go through body systems and enter symptoms. Rows and sections were traditionally represented on an examination sheet. Here, I designed a prominent horizontal carousel to navigate through systems and their symptoms as ‘tags’ to add to each system. Later, these symptoms would be displayed on a body schematic as an efficient overview (to save the doctor’s time during diagnosis).
Now, the stand-out feature of our system: intelligent DDx engine! Since displaying the DDx suggestions alongside the physician's diagnosis was necessary, I dedicated a column on the right side of the Diagnosis page to them. This gave the DDx enough room to list all the information without interfering with the doctor's diagnosis. The doctor had the DDx on the side while entering the diagnosis. I also added an option to close the DDx output.
Finally, the physician could input the required medication, therapy, or tests to be done. At the end of the process, a complete overview of the history, P/E, diagnosis, and prescription was displayed for review. This page had a straightforward vertical scrolling through the sections.
Desktop App Wireframes
A further goal for AIDD was to provide a comprehensive, unified experience in the hospital. Hence, I also designed a desktop-specific UI for a physician's office computer.
The desktop UI design was based on capitalizing the expansive screen space. I assumed the application was running in full-screen. Two fixed bars at the sides displayed general information, the date and time, and provided access to the menu. The main section in the middle provided the functionalities.
An important feature of the desktop system was efficient searching by name, national ID code, or patient reception ID.
The patient records were displayed in rows, with each row containing the ID and the date of creation. The appointments involved in that record were listed as well. The physician could open each record in a full page and view its details. To make navigating between appointments easier, the page included date buttons at the top.
The patient's history was always accessible to the physicians via the button on the right side bar. As an intelligent system, AIDD would summarize the patient's history and highlight key points to save the physician time.
Similar to the tablet design, the physicians navigated the patient record's sections using tabs on the side. The tabs provided easy navigation and did not interfere with the main elements in the middle. The history-taking and P/E pages provided a similar experience to the tablet version, but with more details, and were adapted for mouse and keyboard input. The medication and tests page is also more comprehensive, with several options for quickly entering information.
Finally, the diagnosis page! Here, I gave the doctor the ability to mark each diagnosis as final or edit it on the spot. The DDx Engine suggestions were displayed similarly to the tablet version, though with a button to add them to the diagnoses.
Thank you for reading along this use case to the end! :) You can reach me by email or Linkedin messaging for comments or consult in your projects.