Recognition over recall. Recommended journey page
was designed to better visualise a journey.
Forms became multiple choice.
Progress bar was added to
show transparency of system
structure.
OrthoLogIQ
Problem
OrthoLogIQ (OiQ) is a dashboard designed for clinicians to Remote Patient Monitor patients, using the data collected from the MotionSense app. Remote Patient Monitoring codes are used by clinicians, looking to reimburse for remote monitoring.
Feedback informed that clinicians were spending too long finding and triaging patients on the existing site.
Brief
Redesign OiQ so that clinicians can more easily remote monitor and triage patients.
Analysis of the Problem
SITE AUDIT & AREAS FOR IMPROVEMENT
Myself and another designer bucketed our audit observations into a concise list of areas of improvement.
Previous OrthoLogIQ site
KEY TAKEAWAYS FROM COMPETITOR ANALYSIS
The competitor analysis focused on features which review and action patient alerts. Successful products allowed clinicians to search for patients on a patient list/card view and sort a case load by compliance, pain and recovery phase. A system to manage alerts by creating a To-Do also seemed like an effective way for a clinician to create an action for themselves, or other clinicians.
mymobility Clinician App, was one of four direct competitors that were analysed
Design Concepts
Each concept showed an alert being reviewed and actioned. One noticeable variation was to separate alerts and patient list.
We asked each clinician to complete this task using prototypes of what's shown below. We also asked for general feedback.
1. SEPARATE PATIENT LIST & ALERTS
This concept included UX/UI/UE enhancements to the patient list, and a home for all alerts to be viewed in a single place. Alerts link to specific data points and notes that can be added to followup.
2. THE ULTIMATE PATIENT LIST
The list is interactive, giving the user the option to expand a row for more detailed information of that week.
Alerts are displayed on the patient page using a journey style view.
3. LIVE ACTIVITY FEED
A list of activity that is on-going, the live activity feed provides an up to the minute indication of what’s happening, allowing the clinician to ‘follow’ patients that they want to follow.
The live feed provides a way for the HCP to be more immediately informed about what is happening with patients via 'posts' and can help the user prioritise and plan activities for a given day.
4. PATIENT PINBOARD
Patient 'post-its' (cards) display a summarised view of each patient side-by-side with a more complete metric set available via the expand button.
(Left) HCPs can create their own personalised pinboard using the 'Pinned Patients' tab, which essentially acts as a focussed patient list.
(Right) HCPs have the option to view the pinboard in 'journey mode' (by selecting the toggle in the top right-hand corner) to visualise patients across the various phases in the care continuum. This more immediately puts the metrics into this context.
NEGATIVE FEEDBACK
Both concepts 3 and 4 were soon dropped once it was clear to us that clinicians were finding these views too overwhelming. The Pinboard was a particularly bad use of space and the card looked a bit soulless without a patient picture.
WATCHING ALERTS
An interesting part of the conversation around alerts was configurability. In other words, setting a threshold for when a clinician is alerted. A high pain score, for example, might have less significance in isolation, as opposed to a streak of high pain scores.
A solution to this (without using algorithms) was the ‘Watch alert’ feature. This would move selected alerts to a separate tray, to be tracked and reviewed when more data was collected.
KEY CLINICIAN FEEDBACK
Feedback from clinicians steered us closer to concept 2 (right). This concept combines content from the Patient List and Alerts into a single view. The list gives the user the option to hover over Progress and Alerts views for more detailed information without clicking into the Patient Page.
PRODUCT VISION
Rounds of feedback and testing informed us of a vision that best served clinicians as well as address areas identified in the audit. The vision for Patient List (where you search) and the Patient Page (where you action an alert) was as followed.
PATIENT LIST
Patient List contains demographic info, alerts and follow up/schedule data to speed up daily triage:
-
First screen presented upon login
-
Hoverable alerts highlight patients who are non-compliant
-
Filter option for pinned patients
-
Custom tab to add and view a filter which is regularly checked (example shown: high pain scores during early recovery)
-
Patient Search (top-right) is accessible on all screens
PATIENT PAGE
Patient Page provides the necessary patient detail information and key metrics without having to scroll.
-
Overview is contained within tabbed view (no scroll)
-
Right sticky pane containing regularly accessed features as part of triage
-
Alerts
-
Appointments
-
Notes
-
-
‘To-do’s’ added for tasks that need to be followed-up on by the clinician
After reviewing an alert, the user ‘actions’ a comment adding a free text comment and ‘@’ tag another user to review (creating a to-do for that user).
Final Design and Impact/First release scope
We had to be efficient about features that would be implemented in the first release. We prioritised critical features that would allow a clinician to triage a patient in reduced time. We agreed that features which weren’t critical, for example features for pinning patients, customisable alerts or tagging other clinicians would not make the this release.
PERFORMANCE AND IMPACT
Clinicians using the new design would take around 20-30 seconds to triage a patient. This was a marked improvement on the old system. We measured this using analytics that I deployed, which recorded every component clicked as well as page viewed. We also received positive feedback when we spoke to clinicians who used both the old and new design.
