How Tia created Appointment Check-in | The Tia Take

As the Product Manager of Tia’s Membership Product, I build things to keep members happy.

Tia thinks about Product a little differently (learn why here). Our most recent product launch, Appointment Check-In, which I will call ACI here on out, is a great example of our product development process in action.

Tia gets paid by insurance companies based on the services we deliver. We must send insurance companies *a lot* of correct information to get paid. Any mistake can mean a week-long or month-long delay. When this gets delayed, cash issues can ensue for clinical teams… we are thus highly incentivized to avoid this.

In the pre-Covid world, when a patient came to the Tia clinic, there were multiple steps to verify this info:

1. The patient checked in with a non-Tia iPad app and entered demographic + insurance data
2. The admin checked info for correctness
3. The admin checked insurance coverage and copay
4. The patient signed consent forms

The experience was long and convoluted and error-prone. Up to 70% of initial entries had errors! It would take hours on the phone to rectify with the insurance companies.

When Covid hit, we had to shut down our clinic and offer services virtually. We couldn’t check patients’ info in the same way- so we used this moment as an opportunity to rethink the entire workflow to optimize for time & revenue, and make it safe for a covid world.

Tia’s product development process

Is there a market for it?

YES! We knew we needed to check-in patients in a virtual & Covid world. And we knew that our pre-Covid process was less than exemplary. After talking to our patients and admin team, and researching other software options, we felt that for ACI to embody our Care Philosophy we needed to build it ourselves.

What's in the product?

Building the product requirements for ACI was tricky. It wasn’t just an isolated tech product, it required technology & process to execute exceptionally for multiple end-users.

I shadowed Tia’s Clinic Manager to understand the pre-Covid process and found out:

• How easy it was to make errors documenting demographic data
• How often we had a payment method on file for a patient that was not valid
• How challenging it was to solve payment & insurance issues over the phone
• How confused patients were about their insurance status
• How much time it took to check-in a patient
• How impossible all these steps were in a virtual world

I used this research (and the very specific insurance needs) to help inform ACI’s patient requirements.

I also saw how many different technologies (Dr. Chrono, TiAdmin, GoogleSheets, Square, Intercom) were needed to accomplish just one task and how hard it was to navigate between all of them. This insight inspired the entire design of the admin interface we built.

What is the experience?

After writing the basic product requirements, I worked with the design team to flush out the product experience for both the patient and admin team. We brought in engineers and operators along the way to provide feedback to ensure we were building the right thing. We did user testing to ensure that the experience was intuitive.

How do we build it?

ACI seems like 5 simple steps of data collection, but there is a lot going on! While the engineers were building the tech product, the operations team worked on updating their procedures and processes.

The step that required the most work for both engineering & operations was insurance.

At Tia, we believe in explaining the why behind any medical decision. We felt it was essential that we followed the same philosophy with ACI and used it as an opportunity to educate members on their coverage.

For us to verify a patient's coverage, we need to find out whether a patient 1) has active insurance 2) has a plan covered at Tia. This is challenging because there is no central database that stores all of this information.

We explored several options and eventually decided to build our own system using Change Healths API. On Tia’s side, we collect name, birthday, insurer, and group number. When we send Change this information, they tell us whether or not the patient has active insurance and the name of the plan they are on.

The operations team used to check coverage using a list of plans on a Google Sheet. The team worked directly with engineering to turn this list into an internal database. When Change sends back a patient’s plan name, we look to see if it is on our list. If it is, the patient is covered at Tia. We display this status to the patient so they know what to expect.

How do we get people to use it?

We knew that a brand new check-in experience would be confusing for patients, so we made sure to educate them early. We also send texts before every appointment reminding patients to check-in too!

On the Admin side, we held training sessions on how to use the admin interface and created a Slack channel where the team could ask any questions that came up.

How do we make it better?

We launched in the middle of November, so ACI hasn’t been live for long.

We use MixPanel to track product flows and we were able to quantify our success + failures quickly. I kept a tight loop with the admin team and we made updates to the product within the first few days (for example, a $50 credit card preauthorization for every appointment is too much!)

We have plans in our upcoming roadmap to make sure we iterate and enhance the experience, on both the patient & admin side.

As you can see, building and launching ACI was no small feat and it took many different teams deploying different toolkits for the launch to be successful.