In part one of this two part series, learn more about how claims and denial management platform Encoda was developed to revolutionize medical billing. In part two, discover how Encoda is streamlining the claims process by offering robust reimbursement automation and analytics.

7 Questions for Bronson Cox, COO and Co-Founder of Encoda

Bronson Cox is the COO and Co-Founder of Encoda, a cloud-based, claims and denial management platform that bridges the workflow gaps between practice management systems, clearinghouses, and payers. By focusing on powerful rules based on claims and denial management intelligence, Encoda’s mission is to drive home the importance of understanding and better managing claims data pre-and post-adjudication—all while allowing their clients to collect the most amount of money, in the shortest amount of time possible.

In part one of this Q&A, Bronson talks to us about the founding of Encoda, their mission and why medical practices are leaving money on the table by not proactively managing their claims data.

1. Talk to us about Encoda’s mission. How do you help practices transform the way they deliver care?

To deliver care, practices need money. How do they get money? They have to fix how they interact with the patients and the expectations they have of the patients paying their bills. They must engage technology, and with Encoda, they can understand how much money they should be going after on the patient side.

2. With that said, what was the initial mission of Encoda, and how did the company come to be?

It was late 1994. I was hired as a field engineer by Bob Lee, who would later go on to co-found Encoda with me. At that time, we were working with medical practices and “computerizing” their manual paper processes, which was a big change—there were a lot of emotions for the end users. For us, we experienced how billers worked during that time, and how they mostly wore out their keyboards. It was interesting to see that early on, but it wasn’t about billing for me—yet.

Fast forward, and our company was sold to what eventually became WebMD. I had worked my way up through IT and started within the medical management environment, or hosted services for medical practices. That’s where I started getting more hands-on with the direct software; we were implementing, training, and doing end-to-end implementation for medical practices, so we had to learn the software and where the limitations were. We had to understand multiple practice management systems that rolled up into an environment where we were supporting six different practice management systems.

Essentially, we learned the Rosetta Stone idea of medical billing, and when you look at Encoda today, we base a lot on that notion. At the end of the day, practice managers all had a notion of a claim, a notion of a procedure, and a payment that had to be applied against it. Ultimately, it’s just a financial package, where you’ve invoiced the insurance company for an amount and are paid a certain amount. However, government regulation and guidelines, as we saw, tended to complicate the entire process; we got to experience that during those 11 years with WebMD.

3. The time spent at WebMD sounds like it made a major impact. How did that experience lend itself to the founding of Encoda?

I then got a call from Bob who had gone to work for a large client, a roll-up group. They went from a five-person pediatric group to 129 providers, and they had a similar problem—they had to negotiate with insurance companies, requiring them to operate as if they were one large medical group under a single tax ID. On the technical side, that created a big problem; each of them had their own practice management system they conducted outbound billing from. But when the payments came back from the insurance company—whether electronically or on paper—it was a mix of those 35 environments in a single check.

So, they had to create a solution, and they did what every medical practice does at first—they “manumated” their process, which was a term we stole from the auto industry back in the ‘70s. Essentially, it’s a computerized version of the manual process; it’s an identical process. You’re just hitting keys instead of pushing paper, it wasn’t actually improving anything. The computer system itself couldn’t pull apart those payment documents and put the payments back where they were intended to go.

4. It sounds like that was the impetus for starting Encoda, is that safe to say?

Yes, for sure. Bob Lee was both a long-time friend and mentor of mine. When he called and asked to help recreate a new environment that could address this big problem, I left WebMD after 11 years and moved up to New Jersey. We started the process of training and learning the way they do things.

Once we became more hands-on, we asked questions around posting payments, following up on AR, etcetera—and that was the beginning of an 18-month project. At the same time, the medical practice went from 129 doctors to about 190, while their medical billing team went from 75 FTEs to 45 FTEs.

That’s how we started on the journey. At that time, Bob was the visionary of the solution; I was really learning a lot about that side of it all. However, I did bring my years of running data centers at WebMD to the table, both the knowledge of the technology and the ability to put pieces together, which resulted in realizing what Bob wanted to do. Essentially, we were the perfect complementary pair.

5. With that said, tell us how you articulated and executed on Bob’s vision at that time.

Bob called it a ‘cockpit,’ which was an interesting notion. Basically, he created an environment that rode over the top of 35 different systems, and the system figured out how to write payments back. At the time, it didn’t worry about if the payment was coming in a certain way. When studying how the data flowed back and forth, we learned a lot about the industry we now lived in. For instance, X 12 is the standard and the basis for a lot of systems in society, but no one sees it; it’s an invisible environment but is behind every money transaction you do. If you go to the ATM and take out money, you’re using X 12 behind the scenes to communicate with the bank.

In 2004, medical billing adopted X12 laws which were included in the new HIPAA laws that were released. But when the laws were released, along with them came little subtext. That was, if a medical practice could exchange compliant X12 data files with an insurance company, then they couldn’t be charged to process those transactions. And as a result, that flew in the face of clearinghouses.

6. Clearinghouses play a large part in the billing process. Can you explain their role, and how they impacted the development of Encoda?

Clearinghouses were created similar to the railroad system; you have all these different gauge tracks that were built into different locations. However, the issue becomes the different gauge or width of track. Cars running on railroad A, for example, couldn’t continue to run on railroad B, until the government standardized the width of all tracks. The next thing you know, we can go across our entire nation on one single railroad. The big thing that connected the West to the East during that time was the ‘Golden Spike’ era.

Within the medical industry, we should have seen that same ‘Golden Spike,’ but the industry took a turn in a different direction, because that’s where money was being made. If you were Aetna, for example, you had your own style of receiving information from medical practices—this includes how data is structured. However, United Healthcare and Cigna could want their data formatted differently, and now you have a problem. Medical practices had to maintain a hundred different ways to submit claims, which lead to the clearing houses cropping up.

It was the clearinghouses that said, ‘Hey, we’ll worry about what the insurance company wants. You send it our way and we’ll translate it for you.’ However, another issue popped up, which were the X12 laws. Everything was standardized in theory, and it should have been where the medical practices developed one standard to submit claims based off of. But none of the project managers spoke X12 at the time.

It was the learnings during that time that impacted the founding of Encoda the most—we made our system talk X12. And by making it talk X12, we learned if you fingerprint the transaction before it leaves, you can identify fields that are not allowed to be modified by the payer or the clearing house, and you get the same information back.

7. It’s clear how you responded to market challenges and the environment as it continued to evolve. Can you talk about what’s changed since then?

The biggest change has been with the clearinghouses themselves. In our early journey, we tried to use the data that was sent from the larger clearinghouses, but we found they hacked the data to suit their own needs and the communication with the practice management system. They would change the data, and unfortunately, they were changing it in such a way that they were technically corrupting the information.

With the information coming from the clearinghouses not being the pure data, it forced us to really interpret and understand why the payer did what they did. And because of that, we shifted away from the clearinghouses and started going direct, essentially becoming our own clearing house and talking directly to the insurance companies. We did that for about seven or eight years, until the clearing houses caught on to X12.

Finally, the clearinghouses spent the time and effort to standardize their business, because it made sense for them to do so. At the same time, we realized it was costing us a lot to be a clearinghouse, which isn’t our core competency. So we started shifting back to using their information after we tested the data and found it to be accurate. That was the biggest change. The clearinghouses went from feeling as though they owned and controlled the data, to them acting as more of a ‘pass through.’

This is part one of a two-part series. To learn more about Encoda’s vision and value, check out part two of this Q&A

Show Me How it Works!

"*" indicates required fields

This field is for validation purposes and should be left unchanged.

Recent Posts