Carena’s patient-facing portal is a white-labeled product designed to work within the branding requirements of hospitals and health systems across the country. The portal’s main responsibility is to bring new and returning patients through the intake process, collecting all of the necessary patient information to have a virtual visit with a doctor or nurse practitioner.
The Carena patient portal experience is fragmented. In all, there are over 40 different health systems and over 120 hospitals using Carena’s products. For the portal, there are two backend frameworks and a half a dozen templates. The information collected is sent to a health care provider. When patient eligibility is confirmed, the system puts the patient into the queue. If all of these systems are aligned, Carena would have better visibility through data and more control over the patient experience.
The primary goal was to bring all of the systems into alignment while easing the burden on the user. This included making one universal template that would satisfy the requirements that the six templates tried to accomplish. Along with creating one universal template, the new intake system had to be compatible with the provider and administrative facing product.
The secondary and tertiary goals were to include two major new features; the user dashboard (My Account) and appointment scheduling.
I was the owner of this process. Throughout the project, I held regular meetings with stakeholders at each stage to open up the work for feedback. I made sure to continually update my documentation for the rest of the company to reference. More details pertaining to my methodology are provided below.
I started off with gathering requirements. This included interviews with Client Operations, internal Admins, Product Managers, and other key stakeholders. Next, I mapped out the existing six main variations and identified the weaknesses. I identified all of the exit criteria and streamlined the process to reduce the number of steps potential patients would have to take to find out if they are eligible or not. Compiling my notes from interviews and research, I sketched a user flow map. After a few iterations, I created a final high-level user flow map.
After reaching approval with all teams, I broke down each page in its own flow to illustrate progressive disclosure and contextual responses.
To test the patient flow, I started to introduce various user scenarios to make sure all of the logic was sound. Once I was happy with the architecture I had client operations, admins and product managers, Web production specialists, and the UX team review the new patient portal architecture.
My architecture became the backbone of the new version of the patient portal intake system. The next steps incident setting up criteria for user testing, testing the specific user scenarios with member programs and guest programs and compare the results with the results of my previous in-person user testing for the YHS 1.0 site.