Introduction

Specialty medications are high-cost, high complexity and/or high touch drugs that need to be dispensed by home delivery specialty pharmacies. Healthcare providers who prescribe these drugs often track the deliveries of these medications to enhance their communication with patients who are new to these prescriptions. With the decision to move the BriovaRx Connect Provider Portal (now Optum Specialty Pharmacy Provider Portal) from a third party vendor to in-house, the goal of the updated portal was to decrease calls to customer support by providing insight into patient prescription order tracking status and reduce manual-process tasks for BriovaRx admins.

The provider portal has three user roles with different authenticated views:

• BriovaRx Connect administrators
• BriovaRx Connect account managers
• Specialty practice users

Specialty practice users themselves are made up of two types of users: prescribers, i.e. doctors, nurse practitioners, physician’s assistants, or any user with a National Provider Identifier (NPI) and non-prescribers, i.e. nurses, medical assistants, office staff etc. Non-prescribers must be connected via association to a prescriber to see their patients because of HIPAA regulations.

The initial plan for this lift-and-shift project was to perform a code scrape and refresh the CSS styles to be more consistent with BriovaRx branding; however, this idea ran into legal issues. Even so, the project was still budgeted based on the original scope of the plan, so cost presented various complications for design along the way.

The previous registration process

In the previous ecosystem with the external vendor, the process for registering a provider office and its various users was incredibly manual.

1. Practice and user information was gathered and filled out via faxed paper form that an assigned account manager assists with completing
2. Each potential practice user provided a unique email address and prescriber users needed to provide their NPI and signature to attest to the terms and conditions
3. BriovaRx admins received an email with the image of the faxed form. They entered the form manually into a database and set up individual user accounts, logged in as each user,  sent association requests, logged back in as prescriber users to manually accept each association request, and then sent login credentials via email to each user once the whole practice had been set-up

Ever-changing requirements

When I was assigned to the project, I was the second UX designer to tackle the redesign. At the outset, the registration process had essentially been designed as digital versions of the faxed forms.

A sample of the wireframes of the initial digital registration experience

Along the way, the company decided to integrate with Salesforce, which meant that adjustments to the new registration screens were needed. Salesforce removed need for manual entry, since practice details and users could be called via API as long as they had been properly entered. However, due to budget constraints, the pages initially built still needed to be the basis of the newly designed screens, which meant keeping the number of pages and step tracker intact. Additionally, further budget issues moved the "Add new users to an existing practice" function for admins to the backlog, which meant the registration process I designed needed to accommodate for adding ad-hoc users after a practice had already been registered.

The design process

I started by writing out any questions I had, the problems I knew I had to solve for, and possible task flow steps. Then I started sketching out potential screen ideas.

Notes and sketches

An important part of the registration process is the association or relationship between prescriber users and non-prescriber users. This relationship allows non-prescribers access to the patient information of associated prescriber users. Initial sketches around the association process sought to determine the mental model users (whether a BriovaRx admin or a specialty practice user) might use thinking about the connection between those prescribers and non-prescribers:

• Are they thinking of the prescriber as the hub and then all of the non-prescribers in the practice are connected to that hub?

-or-

• Do they think about individual non-prescribers and to which prescribers they are connected?

Based on the business requirement to make sure that each non-prescriber had to have associations to a prescriber to be registered, the latter model was chosen to more easily allow the user going through registration to see that.

My next step was to map out the entire registration flow to ensure I wasn't missing any parts on the registration process in my sketches.

The registration process

Sketches were converted to wireframes in Axure to discuss with the development team for feasibility during grooming and refinement sessions.

Select wireframes

Once the wireframes were accepted by the product manager and development team, UI styling was applied and the designs were handed off for development.

Select high fidelity screens

Next steps

The migrated Provider portal is currently being launched with a set of pilot provider practices. Feedback from these pilot users will be used by account managers to better train future waves until such time that additional design efforts can be made on the portal. I hope to do research with providers who work with BriovaRx to improve Provider Portal beyond merely read-only order tracking and patient medical compliance assessments, as is the current set of features available in the current external vendor portal.