top of page

FINDING THE RIGHT SPECIALIST

A project to integrate 3rd party search to enable GPs to easily find the right specialist

PROJECT OVERVIEW

I designed the integration (UX and interaction design) for a partner’s search application into Helix.

Helix, a relatively new cloud-based practice management and clinical system for GP market, relies on a user-entered address book/database of specialists which GPs could refer to. For new practices in particular, or indeed any GP, this means it is difficult to find suitable specialists available for expert management of a patient’s condition - as there is no built-in directory provided with which they can reliably search. Instead, GPs would use a keyword search using a search engine to find a specialist with the required skills (including their sub-speciality), at a location convenient to the patient.

KEY PLAYERS

Front-end engineer, Developers, QA, Product Managers (internal & external), CEO (external), General Manager Marketplace (internal).


CONSTRAINTS & CHALLENGES

  • As this was the first such integration into Helix, we were unsure of the amount of UI and/or workflow changes required

  • There was a short timeline for research and design activities before development was due to start

  • There was no budget for research

  • The partner was in Sydney but the internal development team and product manager were in Queensland

  • New technology stack ​

THE PROBLEM

We were required to integrate a partner’s online database of specialists into Helix, without interrupting the doctor’s workflow, while ensuring the right amount of visibility of the partner’s solution. The partner’s dataset was a lot richer than the current simple in-built implementation of the address book/directory.

BubbaYodes.png

THE PROBLEM

Chronic Disease Management is one of the major health challenges in Australia today.

Chronic Disease Management is huge problem from a health and a cost perspective. The Australian government, through Medicare, gives GPs the opportunity to treat patients with chronic diseases by providing monetary incentives in the form of specific Medicare Item codes to bill at a higher rate. Patients are also given 5 subsidised visits to Allied Health Practitioners (e.g. physiotherapists, podiatrists etc.) per calendar year if they meet certain eligibility criteria.

 

The challenge was to build a solution which could be launched from MedicalDirector’s clinical applications (Clinical and Helix). The solution would be cloud based and would offer a quick and easy way for clinicians to create a care plan for any patient who had qualifying chronic diseases.

DISCOVERY & INITIAL RESEARCH

SUMMARY

  • Led a discovery workshop with the partner organisation to understand their solution, and start defining the scope of the project

  • Interviewed the Commercial team to understand business needs including contractual requirements

  • Investigated technology possibilities relating to search and search patterns. E.g. Federated search, auto-suggest patterns

  • Understood how the current software works (“as is”) and audited the software to find all the places where the address book surfaces within Helix

  • Found open support and Jira tickets relating to writing referrals and the practice’s address book of specialists

USER RESEARCH

SUMMARY
  • Interviewed in-house subject matter experts and created a research guide to help with the process

  • Conducted Contextual Inquiries at a number of medical practices, interviewing general practitioners to understand what they think about when they refer a patient to another medical practitioner

  • Created an affinity map of the research findings

CI questions.png

Research guide

CI Example Referrals.png

Contextual Inquiry notes

PROBLEM SOLVING

SUMMARY

  • Paper-prototyped the solution, through multiple iterations

  • Organised a critique with the wider design team as a means to quickly produce a viable prototype for testing

  • Developed a clickable prototype to do usability testing using Sketch and InVision

  • Tested the prototype on in-house experts and general practitioners

  • Iterated on the design after feedback from test participants

  • Workshopped with the development team to discuss various options, based on the testing results

Crazy 8s Directories.png

Crazy Eights

Initial process flow directories.png

Initial proposed workflow

Early prototypes.png

Early prototypes

FEATURE PRIORITISATION

The time available for the development team had been compressed due to external factors and I worked with the product manager to help prioritise the proposed features of the integration. From the results of the affinity mapping, and after conducting usability testing, I asked the participants to rank the importance of some of the hypotheses of the proposed solution. I chose to combine what might be separate steps because of the limited time available.

Likert scale priotisation.png

PROTOTYPING - SOME EXAMPLES

Research insight: GPs often re-refer to the same specialists for a patient.

User need: Quick access to previously used specialists for each patient.

I included an empty state screen that lists specialists a patient has previously been referred to.

 

Outcome:

  • Gives the GP instant access to the practitioners they're most likely to refer to again

  • Minimises the amount of typing/searching required to find the right specialist.

Initial Referred To.png

Research insight: Many specialists are in close proximity to the GP's practice.  Other times the GP may search for a specialist which is close to the patient's home.

User need: Find a specialist near a particular location.


I included a drop down list, pre-populated with the practice's suburb and the patient's suburb, with an option to choose an another entirely.


Outcome:

  • Minimises the amount of typing/searching required to find the right specialist

  • Reduces the amount of irrelevant results. 

Location defaults.png

FUNCTIONAL PROTOTYPING

Owing to time pressures, and the development team being unfamiliar with the technology stack, I worked with the design team’s front-end engineer to prototype the partner’s API set and also provide scaffolding for the development team to use our Design System hxui.io.

LESSONS LEARNED

There was a high level of anxiety from the development team associated with this project which meant they were pushing back on critical parts of the solution. In order to make progress I made sure the team were fully briefed on the results of our research and testing. Also, by helping them with a working prototype, the team was a lot more comfortable with the work they needed to do.

NEXT PROJECT

Chronic Disease Management

bottom of page