• Skip to primary navigation
  • Skip to main content

Holly Evans Design

Connecting the dots that build your experience

  • Experience Design
    • Case Study: Medicaid enrollment microsite
    • Case study: MyLTSS Manager
    • Case study: Designing for scalability across brands
    • Case study: LTSS referrals
    • Case study: Virginia Beach Law Group
    • Service Design: Improving the exam room experience
  • Branding & Marketing
    • Logos
    • Mariners’ Museum Ad Campaign
    • Amiraj – Modern Indian Kitchen Branding
    • Schooner Virginia
    • Glen McClure self-promo
    • Hampton Streetcar 390
  • About Me
  • Get in Touch
  • Show Search
Hide Search

Case study: MyLTSS Manager


The project

Many of the providers supporting Long-Term Supports and Services (LTSS) are non-medical, such as a construction company that might build a wheelchair ramp or an installation company that might install a special alert system. Referred to as “atypical providers”, they range in company size and many times have no experience with medical coding or jargon. They needed a way to get all the information and task-based forms in one easy-to-use spot.

The Problem

Fragmented member information

Previously, atypical providers had to gather member information from various sources that had been faxed or emailed. It was on them to keep it all sorted, not to mention remember it. Needless to say, it’s easy for things to fall through the cracks.

Manual claims, delayed payments

The standard claims form included too much coding and jargon that was foreign. They would submit invoices manually that often had missing or incorrect information. The result was significant delays in payment. And lots of manual work for payers.

Our objective

To create a one-stop-shop for atypical providers that:

  • Provides a comprehensive member profile with easy access to all relevant details, including their personal story, case description, care plan and more.
  • Enables them to easily create claims that eliminated errors and would be paid quickly.

My role

  • UX design
  • User research
  • Visual Design

Collaborators

  • Business stakeholders
  • System analyst
  • Solutions architect
  • Scrum team
  • UX design team

Research

Working directly with the business stakeholder, we quickly became BFFs and spent over a month mapping out all the providers types that fall under atypical, there goals and challenges. We built a clear picture of who they are, how they work, and the pain points they face.

A major issue, we learned, was that, payment per member was often somewhat low. So for them to have to struggle to manage information and experience significant delays in payment was often making them feel it just wasn’t worth it. To keep providers happy, we needed to make it easy peasy.


The Solution

Member Dashboard

The member dashboard provides a list of all the members the provider has on their roster, as well as often needed details like Member ID and DOB. Both pieces of information are cruicical to quickly verify the correct individual, as patients can sometimes have the same names.

Additionally, the green check and red x give let the provider know if the member is currently enrolled in Medicaid. In the Medicaid population people often fall in and out of eligibility, due to missed notices of cancellation, or changes in employment.

Member Profile

The profile provides all the information a provider needs to work with a member. For example, My Short Story is information provided from the patient, details about them that they want providers to know. Health Information shows conditions that are affecting the patient.

Other sections round out the complete picture of the members needs, support system and plan of care.

Claims

The standard 837 claims form is 43 fields, many of which an atypical provider has no idea how to complete, nor do they have to. That form simply didn’t work for them. The alternative was invoicing manually, causing significant payment delays and frustration.

We needed to fix that.

By selecting members right from member dashboard, we were able to autopopulate their information behind-the-scenes. Not only does the provider not have to manually enter it, they don’t even have to see it! First cluster of inputs gone!

Next, because the provider is logged in, there is no need to have them fill out all of their information again. We were able to eliminate manual entry of organization detail

Lastly, by providing a settings pop-up we were able to ask the provider to input information about the member once, and save it in their profile. Something that would have had to be done time and time again in the standard from.

All told, by collaborating with the amazing architects, analysts and scrum teams, we were able to bring the total number of fields from 43 to 7. Woo hoo!


Key Learnings

This project was full of valuable lessons in collaboration, communication and about the users themselves. I also learned a ton about working with back end systems and how, it truly does “take a village”.

Like what you see?
Cool, let's chat!

2024 Holly Evans