A common problem facing NEMT brokerages is managing data – particularly when it is being input, transferred, or exported. When using several disjointed platforms for your operations ("Spaghetti" systems as we like to call them), managing all the information can be complicated and time-consuming. This type of system could work in the short term, if there are only two systems that need to connect or "talk" to each other. However, once more functions are added, things can easily get messy, creating a "spaghetti monster".
We had the opportunity to chat with Kris Lyon, former Brokerage Manager for Lane Transit District, to learn about her firsthand experience working with complicated, spaghetti systems. She illustrates the difficulties she faced when using disparate systems; using DOS-based, SQL-based and Delphi systems within the same processes and having to jump back and forth between three to four different platforms to perform a single function. She also gave us valuable insight on the benefits of switching to an integrated NEMT system:
I worked in two different roles using with the Spaghetti system. I began as the Brokerage Manage for Special Mobility Services (at that time, the contractor for Lane Transit District's RideSource service) I oversaw all call center, provider, and financial operations for the NEMT service. RideSource operates ADA paratransit, NEMT, Medicaid Non-Medical, DD (Developmental Disabilities) work trips and many other transportation services from a variety of funding sources. I was able to see the ‘Spaghetti monster' grow as process after process was developed to meet the various needs of operations. There were two web-based systems, and each was written (by the same person) in different SQL coding platforms. Other systems were built in order to move data from one system to another. For example, information would be pulled from multiple fields in the DOS system and put into the SQL database. Conversely, information from the SQL systems needed to be parsed into the appropriate DOS system fields. It was complex moving large amounts of data between systems multiple times daily. The operations staff called moving trip information out to the provider portal affectionately as "the push". This "push" was an important step – without it, for example, providers wouldn't receive their trips and the call center wasn't able to import billing data. If this step got missed by chance, the process ended up being almost 5 times longer.
I then moved on to work for Lane Transit District directly and oversaw the contractor operating the RideSource services. Part of my role was ensuring the service ran as efficiently and effectively as possible. Since all technology we used was built in-house, there was always the possibility that if something happened, support for these critical systems would not be available. To track down a financial issue, I often needed to have access to three different databases – call center, providers, and brokerage finance.
As a part of the Lane Procurement Team, we developed a rigid RFP, and required all potential vendors to provide a 2-hour demonstration on how their software would handle around 7 different scenarios. We were checking that the software we purchased was able to take our input data and provide the output data necessary for the RideSource operation. The only software able to provide this for us was TripSpark's NEMT software, Novus. Once we made our selection, we were able to transition to work with the TripSpark team and had an incredibly valuable and fast go-live in under 12 months. With Novus, we immediately realized that everything needed to operate the service from the initial ride booking to claims and payment was tracked in one system, meaning there was no reason to have multiple logins.
Everything was so complex, and most people could not keep straight what information was in which system and how they interacted with each other in order to support operations. Most people were familiar with one or two systems but not all, so they had no idea how the information moved or even what information moved for that matter. Schedulers did not have the same views as the providers which made troubleshooting issues difficult. As the manager I spent a lot of time as a technical resource for offsite providers.
On average, the billing staff saved nearly 20 hours per week simply by being able to view the same screens as the providers and by having direct access to the same information in real-time. The process of "the push" ended immediately because there was no reason to transfer data from one database to another. We were able to see which trips were not paid, giving us the opportunity to correct errors and resubmit claims for payment. It was amazing - our agency immediately saw a 20% increase in revenues as claims and financial information was readily available and not spread across three systems (Brokerage Finance, Transactions, Finance).
Also, some of the tasks we needed to complete required us to transfer information from one database to another, exporting that information to a spreadsheet, sorting the information and finally, inputting responses back into the first database. It was complicated when it didn't need to be. In Novus, I could easily look up claim rejections without having to access a different database and perform more than one process to see why a claim was rejected.
Using an integrated service improved efficiency simply by ending the need to have multiple logins for multiple pieces of software. You only need to have one program open and move between the different screens to get to what you need. More importantly, our staff didn't have to be trained on multiple programs, each with their own unique set of nuances and login processes.
In a world where advanced technology and real-time data is at our fingertips, there's no reason to still be using a messy spaghetti system. Using a single dedicated NEMT platform can save you and your staff a lot of grief; ultimately saving your agency time, improving your bottom line, and ensuring company-wide efficiency.