AMWELL

Federated Recommendation Engine (FRE) Sample App

 
 
 

Overview

Telehealth clients wanted to display their services to various consumer aggregator sites to increase visibility of their health services and participate in an exchange marketplace model. This would empower patients to efficiently access a range of services, compare offerings, and seek cost-effective care.

My goal was to design the Federated Recommendation Engine (FRE) sample app within a fictitious consumer aggregator portal to show how it would allow patients to find recommendations for services and practices based on their location, insurance plan, and desired service type.

 

Company
Amwell

Role
Individual Contributor — UI/UX Design

Team
Worked alongside PM and Eng in review sessions and ad-hoc meetings for alignment.

Duration
March - May 2020

 

 

Brainstorm session with product

I collaborated with a product manager to brainstorm the FRE capabilities and determine what key designs were needed to visualize the concept.

The FRE would allow clients to surface practices within a health enterprise prior to log-in or enrollment. Depending on what patient data was collected, the FRE results would show a marketplace of options or directly route them to a specific option.

  • Marketplace
    The patient would view multiple options with price transparency. Regardless of insurance coverage, this was an opportunity for local health systems to gain brand recognition.

  • Direct routing
    The FRE had enough information about the patient to push them towards the right options of care.

 
 
 

After discussing the overall concepts, I formulated my design plan.

  • In phase 1, I designed flows to demonstrate all the basic ways patients could use the FRE to view marketplace and direct routing recommendations.  

  • In phase 2, I designed an enhancement to demonstrate price transparency within recommendations if additional information about insurance plan details were collected in the FRE.

  • In phase 3, I designed flows to demonstrate how a patient’s identity would be passed from the FRE to the SDK app. 

 
 
 

Created The Exchange Member Portal homepage

Initially, I created the fictitious portal homepage without the FRE so that I could focus on establishing the style direction. 

  • Color

    Since the member portal served health needs, I created a color palette that represented trust and care and selected blue as its primary color. The palette also had orange tones to serve as a complementary accent.

  • Imagery

    Navigating health experiences could often feel overwhelming, so I curated images that would bring about positive emotion. I chose friendly and comforting images that also followed the color palette.

  • Logo

    I designed the logo using a blue color to represent trust and care. From the blues, I chose a navy color to give the brand its visual distinction and emphasis.

  • Homepage content

    I created placeholder content for educational resources and membership benefits to bring the portal site to life. 

 
 
  • FRE design

After the style was established, I designed the FRE within the homepage content so that it spanned horizontally to maximize space for content. I also used a light blue background to separate the FRE from its surrounding content. For the CTA button, I used a green color to resemble positive action and to keep it visually distinct from the portal brand blue colors. 

 
 
 

Phase 1: Allowed patients to find search recommendations based on location, insurance, and service

Wireframe
In phase 1, I created wireframes to visualize the overall flow from the FRE within the member portal to the selection process and to the SDK app.

 
 
 

Mapping out results
Additionally, I mapped out all the basic combinations patients could input into the FRE to clarify what information to portray in the results. Since location was the only required field, I outlined the following four possible inputs and its outcomes.

 
 
 

Final UI

  • For flows 1 and 2, I designed a marketplace of options. I created enterprise logos that represented brands of fictitious health systems and hospitals.

 
 
  • For flows 3 and 4, I designed direct routes to options. The cross-installation practice logos for therapy showed an example of how patients can be directed to a specific option immediately.

 
 
 
 
 

Phase 2: Search recommendations showed real time eligibility calls into price sensitivity

Wireframe
In phase 2, I updated the wireframes to show where the cost information would appear if additional details about insurance plan were collected in the FRE.

 
 
 

Mapping out results
I mapped out the enhancements to flows 2 and 4 as those initially showed basic collection of insurance plan data. In the updated flows, the patient could input additional details about their insurance plan. By doing so, patients could now select a service or practice with cost sensitivity in mind.

 
 
 

Final UI
In phase 2, I updated the cards to show cost differentiation tied to insurance coverage.

  • In flow 2, patients could discern options with price transparency at the service selection page.

 
 
  • In flow 4, patients could discern options with price transparency at the cross-installation practice selection page.

 
 
 
 

Established card component

In both phase 1 and 2, the results at the enterprise, service and cross-installation practice level were all displayed in a card component for consistency.

Additionally, I designed the insurance coverage flag as a configurable element that could be turned on or off to help patients understand if services or practices were covered by their insurance plan.

 
 
 

Phase 3: Allowed single sign-on, dynamic enrollment, identity verification


Wireframe

In phase 3, I created wireframes to show the three different processes that were being carried out to transfer a patient’s identity from the portal to the SDK app.

 
 
 
  1. Automatic enrollment

    In this scenario, the FRE client had previously collected data about the patient, so the patient was automatically enrolled behind the scenes. Since the patient would flow seamlessly into the SDK app, there was no UI screen needed for this flow.

  2. Partial enrollment

    In this scenario, the FRE client attempted to enroll a patient who was an existing member on file, but was missing some required data. After service or practice selection, the patient was prompted to fill out missing information fields before moving forward into the SDK. To address this issue, a new page was needed.

I wireframed the following UI patterns to collect missing data.

  • In option 1, the patient would only see missing fields, but this could cause confusion without showing the already existing information stored in parallel.

  • In option 2, the patient would see existing information as well as missing fields. All fields were editable, but this could cause complexity. If patients could edit the fields for existing information, this change would not push back to other areas where this information was stored and would result in a mismatch during enrollment.

  • In option 3, the patient would see existing information and missing fields, but the existing information would be displayed as read-only. This was the best solution as it ensured no changes to existing data, but would also show context to patients while collecting missing information.

 
 
 

Final UI
I designed the partial enrollment page re-using the pattern from the FRE for consistency. Information collected in those fields were positioned vertically for ease of scannability. The CTA was placed on the right hand side similarly to that in the FRE. After the patient completed the partial enrollment, they moved forward into the SDK app.

 
 

3. Identity Verification

In this scenario, the FRE client already had the patient as a member on file and all the required information, but still needed to verify the patient’s email address due to security reasons. After service or practice selection, the patient would need to verify their identity. The FRE client would send an email to the patient to ensure that they were the true owner of the account. After confirmation, the patient would move forward into the SDK app. 

 

Verification page

Verification email

 
 

FRE designs showcased a portal that housed a centralized application server that returned recommendations based on consumer input

This app concept was an innovative solution that allowed clients to leverage a new way to engage and route members to an enterprise prior to log-in or enrollment. It was an interesting challenge to ensure that the design could accommodate various options and use the power of components to ensure consistency.