Slàinte Mhath (“SLAN-cha vah”) is a traditional Celtic /Gaelic toast meaning “Good health to you.” And that was the challenge, when working through a complex collection of Medicaid support apps. There were core functions shared among states, to be sure — but each state manifested these in slightly different ways. The wish for good health became a challenge to make sure that’s exactly what we provided, no matter where the user lived.

The project

The project was actually a collection of projects, because each state Medicaid program was, in turn, an individual client of our client, a Medicaid administrative services aggreagor and provider to the states. That meant that, even though it was a federal Medicaid program that lay at the heart of each design, and there were core functions and requirements common to all state Medicaid programs, the particular ways the program was implemented in each state could vary wildly. A shared type of project could be implemented quite differently (with very different eligibility requirements), as well as the number and type of Medicaid programs offered. Finally, there could be varying needs for multilingual access: some states offer English-only, some include Spanish and/or Vietnamese and/or Tagalog…. whatever the local Medicaid demographic most needs.

The modalities

This is an unusual case, in that voice was overwhelmingly the modality of primary concern, with chatbot a distant second. At first glance, it seems odd, but given that this application was geared toward Medicaid-registered medical providers calling from their offices, it made perfect sense: the people calling are medical office administrators, calling from desk phones with mountains of records in front of them. Their need is for a voice-forward interface that can help them quickly process large amounts of repetitive data.

Still, there were situations in which reference to the state’s Medicaid web site was unavoidable — if there were questions about the provider’s enrollment status, or a particular claim, or forms needing completed. Some states were actively looking into incorporting Visual IVR technologies, but these are largely incompatible with desk phones, and rely an mobile phone technology, so voice remained the overwhelmingly preferred modality.

​The strategy

The design strategy focused on the common elements of Medicaid, regardless of the particular state:

• Provider enrollment in the Medicaid program.

  • The requirements for eligibility, as well as the forms and identification required. This information remained largely static, across states, but could not be acted on within the IVR, because of the need for signature and/or completed forms; we had to refer to one or more web sites.

• Provider authentication

  • The accepted forms of identification could vary from state to state (each state has its own Provider ID method, in addition to the National Provider ID), but there was enough commonality to detect and leverage patterns.

• Claims

  • Again, the accepted lookup criteria varied, but every state would accept lookup by claim number.

• Member Lookup

  • This was the actual Medicaid patient receiving services

    • This criterion was used either to look up claims and their statuses, or to determine if the patient in question was eligible for particular services, under that state’s Medicaid guidelines

These areas were then combed for common functionality and methods of functionality, so that a shared “framework” or “scaffolding” could be constructed, upon which the state’s customization could then be hung. So, while a complete call flow would be counter-productive to display here, the skeleton framework can be detected from this replica of an Intent Mapping page — it represents a typical configuration with which the framework would begin.

The outcome

Developing a framework or “scaffold” approach enabled the design and development teams to streamline the creation process while simultaneously delivering highly customized, fully functional, consumer-facing Medicaid IVRs. Designers and project management could also focus much more of the pre-design process on gathering, documenting, and focusing requirements so that, by the time the designers were ready to begin actively designing the interaction flow, the “fingers to the keyboard” time was minimal, and development could begin that much sooner. Our client was happy, because their clients were happy.