CASE STUDY
Patient Self-Service Payment Plans
CASE STUDY
Digital Consent for Payment Plans
Even though most payment plans are created over the phone, the prior solution required a wet signature for autopay payment plans (the patient must sign a paper contract, in person).
This solution provides practice staff and patients a way to create and authorize autopay payment plans remotely.
COMPANY
athenahealth
MY ROLE
My contributions were in UX design, the responsive design approach, generating detailed designs for dev, and implementation with dev. User research, concept validation, and scoping were completed by the time I joined the team.
THE TEAM
1 product owner
2 designers
4 engineers
THE PROBLEM
Autopay plans can only be authorized by patients in person, which causes the following issues:
- Patients who are not physically present in-office have limited payment options; they must pay in full or they can sign up for a statement-based plan (if the practice offers it). They risk being sent to collections if unable to pay in full or if they miss payments.
- Statement-based plans require manual payments, which can be a hassle for patients and increase the likelihood of missed or partial payments.
- Most practices set up statement-based payment plans because autopay plans require collecting an email and signature. Statement-based plans drive up statement generation costs and are less likely to collect the full balance (Patient Pay Yield).
BUSINESS IMPACT
This feature will impact several key performance indicators (KPIs):
- Improve patient and practice satisfaction by reducing friction and removing blockers for autopay plans
- Improve Patient Pay Yield (PPY) on larger bills (>$200)
- Increase in the % of autopay plans in relation to statement based plans (autopay plans have a 6.44% higher yield than statement-based plans)
- Reduction in paper statement generation costs
THE SOLUTION
Provide patients with the ability to authorize an autopay payment plan online, without needing to be physically present in office.
APPROACH
User research, concept validation, and scoping were completed by the time I joined the team. Because I would be designing the solution, I needed to quickly gain context and understand the decisions made thus far. The first thing I did was consume all the available documentation and resources, and I spoke to subject matter experts to understand the problem and constraints. Additionally, I spoke to stakeholders to define what success would look like for this initiative.
My initial questions:
- What do our users (the patients) need? What is the current user journey?
- What do our clients (the practices) need?
- What are the business requirements?
- What are the constraints?
Here's what happened when a patient received a large medical bill, prior to our solution.
In an ideal world, a patient could set up a payment plan all on their own online (see Patient Initiated Payment Plans), but we didn’t have the resources to complete that work until Summer of 2023.
In the meantime, what could we do to provide patients and practices more flexibility and control in regard to payment options? Our research has shown that patients are more likely to feel comfortable paying if given flexibility and control over their payment options. Flexibility and control help with the anxiety and stress that come with a large medical bill.
Our team met with the internal legal and compliance to determine requirements for legally binding digital "signatures."
DESIGN CHALLENGE
How do we enable patients to create an autopay payment plan at home, without a wet signature?
USER JOURNEY
I created this storyboard displayed below as a collaborative tool for our team to visualize the end-to-end user journey.
DESIGN APPROACH
Focusing on clarity and brevity, the final design approach provided remote users more flexibility and control over their payment options.
IMPLEMENTATION CHALLENGES
Existing technical constraints posed a challenge for the payment plan details section. Our initial assumption was that the balance would be divided by number of payments resulting in equal installments (i.e. $524.80 balance/9 installments = $58.31 per installment). However, developers found that the payment plan data that existed prior to this work divided the payment plan balance into installments by amount and the last installment was the remainder (i.e. $524.80 balance = 9 x $50 installments and 1 final installment of $24.80).
After collaborating with other designers and conducting user testing, I went with proposed solution #2. For clarity and transparency, my design emphasized that the final installment would be different, while also ensuring that it did not seem too removed from the other installments to avoid the patient making an incorrect assumption that they were being charged an extra fee. See below for explorations.
Another area of focus in this work was the responsive design behavior. I ensured that our solution worked for mobile, medium screens like tablet, and large desktop screens. I worked with my developers to constrain the table with payment plan details so that the content on the ends of each row were not too spaced out. Additionally, the agreement text needed to be 50-75 characters per line for optimal readability.
RESULTS
Although this feature was intended as a bridge solution, it had immediate and high impact for both our clients and their patients, as demonstrated below.
- Client Quotes
- “It makes it easier. We don’t have to do all the follow-up calls with the patients.”
- "This is something we’ve been waiting for quite some time, so very exciting. For those who have statement plans already set up, now we can give them this offering.”
- “I’m really excited about [this feature]. Because our workaround was: They would call; we’d collect their credit card information; then my team would email me a copy of the agreement. I would then have to go to HelloSign, upload it into HelloSign, format it, send it to the client, then get it back, and it was kinda this huge bulky process. So when that summer release came out, there was a party at our office. So that was a really, really fabulous update.”
- Patient in-app satisfaction survey
- 85% were extremely satisfied
- 95% said it was clear and understandable
- 95% said it was useful
- 91% said it improved how comfortable they feel having this payment plan on autopay
- Conversion
- Overall workflow conversion at 89%
- Overall workflow conversion at 89%
- Success Metrics
- % of plans that are autopay went from roughly 28% right before the alpha (Oct 2021—Feb 2022) to about 35% in Sept 2022
REFLECTIONS
Every project or initiative is a learning opportunity. A few of my primary reflections from this one:
- Something is better than nothing (sometimes). This solution felt a like a Band-Aid initially, but it made sense as I dug into the problem and context. Practices and patients needed something now. This was a relatively low effort, high impact feature. And there was a long term and higher level-of-effort solution in the pipeline.
- The person designing is often not the person who conducted the research. Jump into the problem space with curiosity and questions. Although I came on after the user research and concept validation were completed, I did my own research to understand the context before jumping into designing. I also asked a lot of questions and collaborated with engineers, product, and fellow designers.
- Communication with developers and product early and frequently is an essential part of the process. While making decisions about what to display, it was crucial understand our data constraints. Additionally, it was important to understand existing functionality and also the feasibility of enhancements for the desired responsive design behavior.
- Documentation, documentation, documentation. I was able to get up to speed because the documentation existed, and I was able to find it. Reminder to all, please document.
CREDIT
Sara Wells (Principal Designer) - Authentication and legal considerations, research, scoping, strategic oversight
Vamsi Namburi (Product Owner) - Feature scoping, cross functional liaising
Greg McNew (Principal Developer), Zona Gilreath (Lead Developer) - Back-end build
Jacob Roseland (Lead Developer), Harshvardhan Dewangan (Senior Developer) - Front-end build