MEDICAL SOFTWARE
Cegedim Health Care - Medical Drug Dictionary
Project Overview
A full remodel of the Drug Dictionary with new functionality moving from old existing software, to a new platform designed for a cloud based system.
This software is used by GP Practices and Pharmacies to choose the correct drugs for a patient by allowing them to access all information relevant to each drug from cost and pack size to posology and contraindications.
Project Time: 2-3 months
Role: Lead UX / UI Designer
Tools: Figma, Jira, Zoom, Slack, Confluence, Miro, Design Library, WCAG
Research
-
Usability tests
-
Interviews
-
Questionnaire
Identifying the Problem:
The current software does not meet legal requirements and does not display all required information in one screen view. It is also missing many important drug information factors such as pricing, product codes, availability etc.
My Research Plan:
-
Bring together all relevant work tickets and legal document requests associated with the drug dictionary software.
-
Study old software and create a list of 'what's missing' from the legal requirements requests.
-
Host meetings with our external GP group to understand the requirements from the users POV. What information to they need to view immediately? What's less important etc. This allows me to create an information hierarchy.
-
Host meeting with the Product Owner and team to discuss functionality limitations with the old and new software.
Analysis
-
Affinity Diagram
-
User Flow
-
Team Workshops
I Identified 109 work tickets related to the drug dictionary through confluence and various meetings with the product owners. I categorised these into legal requirements and software design requirements.
By evaluating the current drug dictionary and hosting a usability session observing users completing a task I discovered the following:
-
Over 20 key drug facts are missing when viewing a drug.
-
The user has to open multiple pages to gather all the information they require, this is very time consuming.
-
A GP only has 10-15 minutes with each patient so there is not a lot of time to be searching software for relevant information.
-
The system design is dated with no usability flow, small text and small icons resulting in the information being difficult to read.
-
There is no information hierarchy.
Design
-
Sketching
-
Figma
-
Design Systems
-
WCAG
Prototype
Prototype Presentation
I created a recorded walk through of the prototype for my presentation meeting with stakeholders, showcasing the functionality of the new drug dictionary.
The Drug Information
I designed the drug card in stages, starting with a top card that would show all relevant information to do with price, warnings, product codes, manufacturer, drug class and any relevant tags.
This developed further to include user alerts and stock notifications.
I used my accordion component to display further information about the drug, posology, side effects, ingredients etc placing this under the top card component. This layout is consistent for all drugs with only the relevant information being displayed in the correct field for each selection.
As they are designed as multiple components (see image on the right) these components can be used in other areas of the software to display drug information or potentially different information.
'I don't read half the information as its not relevant'
GP 1
'I need to close my drug dictionary window to view other patient information'
GP 2
'The system is just so old fashioned and not intuitive'
GP 3
'I need to see side effects and contraindications whilst viewing a drug option'
GP 4
Lets start with drug selection
From basic sketching and extensive research through our design library, I began to build a drug list component. The new component was developed from smaller component pieces within our design library. This created my drug list allowing me to categorise drugs according to their drug class.
Any components I could not source I custom built following our design guidelines.
Always aware to keep these components generic as they could be used again somewhere else within the software.
The Information Challenge
Considering the existing software with its flaws and my legal requirements, the amount of information to be displayed per drug was extensive.
I wanted to display this in a quick to find and easy to read format, keeping in mind that the information within the components could be used somewhere else within our software.
By creating an accordion component which opens to display further information when clicked, I was able to categorise the extensive list of drug information and create an information hierarchy allowing all of the legally required information to be displayed.
I ensured the drug list and the selected drug were visible on the screen at the same time to comply with these new regulations by developing the layout design with the tree on the left and the selected drug results on the right.
Bringing it all together
I brought in the accordion component to display further information about the drug, posology, side effects, ingredients etc. This is part of the legal requirements from the government in which our software has to comply.
This is also designed as multiple components as you can see on the right, the plan again is that these components maybe used in other areas of the software to display drug information or different information.
This screen was also designed for tablet.
