Navigating the maze of patient onboarding

An overview of the patient onboarding landscape of Patient Access APIs

Historically, if you're a digital health app looking to connect to a user’s health information, you might try integrating with EHRs, working with a health information exchange, or asking users to manually input their health data into your app. None of these options were ideal. As of 2021, the game changed as the Interoperability and Patient Access final rule (CMS-9115-F) from the Centers for Medicare & Medicaid Services (CMS)came into effect. The rule requires CMS-regulated payers to make health information available to patients through application programming interfaces (APIs) and to exchange data with other payers. This means that whether you're a digital health app or a patient, you can freely access health data from your current and past health plans.

However, integrating with every health plan’s API is challenging and time-consuming. That’s where Flexpa comes into play. Flexpa is the fastest way for your digital health app to connect to new Patient Access APIs. We’ve connected to over 300 health plans and are continuing to grow. 

What we want to discuss today is what we’ve seen in the landscape of payer implementations for their Patient Access APIs. Namely, we want to focus on how each of these implementation methods affects the patient’s onboarding experience and ease of use using this capability.

We have so far classified over 500 payer implementations into three categories:

1. Single login access plans

2. Dual login access plans

3. Dual login access plans with an invite code 

To help illustrate these patient experiences, let’s imagine you are a patient going to a new healthcare provider, BoulevardMedical. When you walk in, instead of the normal fill-out-all-this-paperwork workflow, they now ask you to quickly sign in to your health plan VitalCare on the tablet. They say doing so will automagically sync all your past health data. Amazing! 

You take the tablet, and here’s where the experience branches based on VitalCare’s implementation of their Patient Access API. In the next few sections, we’ll describe how they work, and any points of dropoff during those experiences. Dropoff is when a user abandons a workflow and doesn’t arrive at the intended result. For these APIs, dropoff would be a user abandoning the process anywhere before a successful login.

Single login access

With this implementation method, on the tablet login screen you might see: “BoulevardMedical uses Flexpa to connect to your VitalCare Health Plan.” 

How it works

In a single login world, you would walk in, be presented with a tablet, select your health plan with Flexpa, input your regular username and password from your member portal, and bam, all your claims are synced. You hand the tablet back and you’re swept in to see the doctor. Just kidding - waiting rooms are a whole other problem.

This experience is usually the result of when a payer develops their own Patient Access API solution in-house or connects their portal’s identity provider to their FHIR server vendor. A few payers in this category are Humana, Centene, Sentara, Commonwealth Care Alliance, and Amerihealth Caritas. A payer who uses an identity vendor in their regular vendor portal and reuses it to connect with their FHIR vendor can also make this experience possible.

Onboarding experiences in this bucket have the least friction - in fact, they’re quite simple. The logical (and quite frankly, reasonable) expectation of users is that a login screen donning their health plan’s logo will take the same credentials as their health plan. Matching that mental model reduces friction and it doesn’t feel to the user like their data is being shared with a new party. 

Challenges

Let’s take a look at where the dropoffs might occur in this scenario. Each red diamond on the right side of the diagram represents a sufficiently high-risk dropoff point. 

Dropoff for a single login flow closely mirrors general login challenges across technology sectors. These include the accurate recall of usernames and passwords, willingness to create a new account, concerns about privacy and security, etc. 

Dual login access

With this implementation method, on the tablet login screen you might see:  “BoulevardMedical uses Flexpa to connect to your VitalCare Health Plan, which uses HealthID for identity verification.”

How it works

Walking into BoulevardMedical, you are presented with the tablet, and the login page looks a little unfamiliar, but you go with it since you trust the judgement of your doctor's office. You try your regular username and password, but it doesn’t work. You’re instructed by the receptionist to go through a separate registration/verification process, which requires your member ID, birthdate, and address. You stumble on the member ID format and try a few options with and without those hyphens, until you get it. Now you can log in, and your data is synced. Not too bad - it’s still better than filling out all those forms you’re used to. 

In this category, a payer has decided to outsource their interoperability solution to a vendor like Edifecs, 1up, or Inovalon. These vendors typically require a separate identity verification which sometimes necessitates a separate account creation. 

Challenges

On top of the dropoff that we see with the single login experience, we add a few more. The primary hurdle here is that vendors are usually not end consumer-facing. This means that a brand that is unrecognizable to patients is asking for their password. Most of these vendors don’t have the interface polish of a modern D2C website that consumers are used to these days. This reduces trust, which causes dropoff. 

Another dropoff we have observed is that the data sync between the payer and vendor is not in real-time. This is especially problematic during enrollment periods or firsts of the month when new members’ plans begin. If the patient rosters are not synced, the vendor will not be able to find the member, resulting in an error. 

Lastly, these verification forms sometimes have different data validation requirements that are not made clear to the user. For example, we have seen that sometimes the member ID needs to be in a specific format without hyphens, it is not clear which ID is being asked for, or the first name field is actually first name plus middle initial. 

While troubleshooting with one of our payers’ vendors, even they said:

"There can be a few things happening. [Member lastname] may be a married name. The member ID may be mistyped… And yeah, [they] may be with a different region than we administer." -FHIR server vendor

Dual login access with an invite code

With this implementation method, on the tablet login screen you might see:  “BoulevardMedical uses Flexpa to connect to your VitalCare Health Plan, which uses HealthID for identity verification and requires an invite code from VitalCare to begin.”

How it works

Time is a flat circle, and you’re walking into BoulevardMedical yet again. You get the tablet, find your health plan, and are taken to a vendor page. You attempt your regular credentials but it doesn’t work so you click “register”. So far, all familiar to multiverse you, the overlord of the payer login multiverse. But now, you notice that an enrollment code is required. You see that you may have received it in your email, so you go inbox-diving on your mobile device to no avail. It says you can call your insurance company to request one, but you’d rather fill out the long forms at this point than stay on hold. 

The payers that fall in this category have been the hardest to crack. On top of separate account creation and verification, payers using vendors in this category must preemptively generate an enrollment code that is sent to users via an email or snail-mail campaign. If they’re not generated en-masse, a member must call into customer service and request a personalized code. These codes last 6 months if generated. 

Challenges

The biggest problem here is communicating what an enrollment code is to the member in a way that they can communicate it to the payer. Ideally, the frontline member services agents know what the enrollment code is, but in reality, the program is new, it’s not widely requested, and is a small piece of all the knowledge these agents need to retain for their day-to-day. The time it takes to be on hold, escalate to an agent lead, and do gymnastics around the confusion is frustrating and time-consuming. We at Flexpa have personally worked with two members with payers of this structure, guided them through phone calls, and have been unable to obtain an enrollment code.

A member of a plan that has this implementation method expressed her frustration in a support ticket to us recently:

"It doesn't take me to the [health plan] login. It takes me to [vendor] login. My [health plan]'s user name is not my email address, but on the [vendor] login page that's the only kind of username it allows is an email address. If I try my email [health plan] tells me that it's wrong. I even went to the support chat and asked and read the link that it sent me to... And still same thing."

Bringing it all together

Now you should have a high level understanding of the various implementation methods seen in the Patient Access API landscape. Breaking down those 300+ payers that we’ve integrated with, here’s how the categories break down. 

Each method discussed has increasing amounts of user friction involved. To summarize the challenges, we’ve laid out the primary points of dropoff in the following table. 

By far, dropoff during the login process on a health plan’s side is the primary reason we see for unsuccessful user connections. At Flexpa we run a robust user testing program to ensure our connections with health plans are up and running. The program has generated over 1,500 unique users going through our system and ~30.7%* of them have reported issues logging in that were due to additional registrations required. 

So, what do we do with this information?

If you’re a payer reading this, we urge you to work with your vendors to create a smoother experience for the end patient and transition to a single login user experience. 

We understand this is a large project, so in the interim, there are several simple quality of life improvements we would highly suggest such as:

• Adding instructional text to your login screens that this is not the same login as their member portal, and directing a user to register.

• Make the registration link visible on the sign-in page. We have seen many login pages that don’t give members a recourse if they’ve never registered before.

• Ensuring that your login screens are co-branded between health plan and vendor portals so it is recognizable by the user.

As a customer of Flexpa, you won’t need to worry about much of this complexity as we do our best to obfuscate it, and walk patients through the process within the context of our connection tool, Link. End users also have a connection guide at their disposal should they need it. The landscape is complex, but we want to eat as much of this pain for our customers and their end users as possible. As the courier for the user through this flow, it is our responsibility at Flexpa to simplify the user experience while maintaining a high bar for data privacy and security to ensure user data is protected. 

If you’re curious to learn more about Flexpa, check out our website here and developer documentation here.