The BriovaRx Connect Provider Portal is a digital web portal for providers who prescribe specialty medications through BriovaRx. The portal was originally built on a third party vendor's platform. The decision was made by the business to move the portal to an internal platform and add additional functionality. One of my tasks was to update the process for registering provider offices to the portal.
Pen and paper
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:
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.
In the previous ecosystem with the external vendor, the process for registering a provider office and its various users was incredibly manual.
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.
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.
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.
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 BrioveRx admin or a specialty practice user) might use thinking about the connection between those prescribers and non-prescribers:
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.
Sketches were converted to wireframes in Axure to discuss with the development team for feasibility during grooming and refinement sessions.
Once the wireframes were accepted by the product manager and development team, UI styling was applied and the designs were handed off for development.
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.