Listen to the Podcast on Apple Podcasts

Listen to the Podcast on Spotify

Transcript

Chenny (1:02):

Hello, everyone. Welcome to the next edition of our Products That Count podcast series, focusing on healthcare, especially our care catalyst series. Today, we have a great guest from Simplify Healthcare, Daniel Knies.

He’s a seasoned healthcare IT leader with more than 25 years of experience in the payer segment. He currently serves as Senior Vice President of Claims1™at Simplify Healthcare, where he leads innovation in claims configuration and automation. Daniel has deep expertise in architecting online transaction processing systems and driving efficiency in critical areas such as benefits and provider data management.

His mission is to revolutionize healthcare workflows through technology, delivering scalable solutions that empower payers to streamline operations, reduce complexity, and improve outcomes for members, providers, and organizations in an increasingly complex healthcare ecosystem. Welcome, Daniel.

Dan (2:10):

Thank you. Thank you for having me.

Chenny (2:12):

I appreciate it. Of course. So we discussed before, and I wanted to get a sense of what motivated you to pursue a career in healthcare leadership.

Dan (2:24):

So I’m just trying to determine how far back to go with that question, right? So right out of college, I was fortunate enough to start at a small company that built pharmacy benefit management platforms, PBM systems, and that is really the foundation and where I started getting into both claims adjudication, from an insurance perspective, and online transaction processing, you know, fast turnaround, sub-zero second transaction processing within a platform, and really addressing that space. And so, it was there that I was really motivated and got ingrained in the healthcare industry.

And following along with the PBM platform, I started as a founder of a company in the early 2000s, basically saying, well, if the pharmacy world can be connected in real time and adjudicate claims in real time, then why really couldn’t the rest of the industry? Why are medical claims processing and dental claims processing? Why is that such a slow process within the industry today?

And so that’s what really then continued to drive my passion to really solve that problem and carrying that even into Simplify Healthcare, onboarding and standing up those systems. And yet, we are not real-time across the board with transactions. You can see mandates coming from CMS that are kind of pushing the world into that mode.

So, price transparency, the fire standards that are emerging “right now for communications from the EMR over to payers and from provider to provider. So I think there’s a lot of laws and governance being put in place right now, I think to push the market to real-time, which again, from a Simplify Healthcare perspective, looking at ways to help move the needle on the configuration and the provider data management will only help facilitate and allow real-time claims to be processed in the future.

Chenny (4:37):

Awesome, awesome. So real time, can you explain how it is being done today? It was interesting to hear you say that Fire and Interoperability for our audience who are not from healthcare. Fire stands for F-H-I-R, Fast Healthcare Interoperability Resources.

It’s a standard for the healthcare industry to go into more real-time as in the other industry. So, how do we do today? How do we process the claims today for our audience?

If you can just give us a quick, the need for real-time that comes from how we are doing it today.

Dan (5:20):

When you look at the pharmacy world, for example, and you walk into your standard drug store, they have your insurance information. And through their practice management system or their online point of sale service system, they submit the claim in real time to a back-end payer platform and a PBM platform, which goes through thousands of rules to determine if that claim should be paid, what the co-pay should be calculated, and gives that response back to the pharmacy. And like I said, within, you know, within seconds.

And so, the patient at the counter knows how much they owe before they even walk out the door. Now, if you compare and contrast that to the medical world, you go see your doctor, they may have some idea of what the claim is going to cost, the only thing they will actually collect from you at that point in time would be a co-pay. Then that claim gets submitted, and it may take up to 15, sometimes 30 days for you to realize how much you owe the provider.

So, from a transparency perspective, you know, the provider submits that file, that file gets turned into, typically, what is this? It’s an ANSI transaction called the X12837. That X12837 gets sent to a clearing house. The clearing house batches claims together from different providers to send to a single payer system. And when the payers receive that, they go ahead and adjudicate those claims. It may go through multiple stages. It could be a pre-scrubbing phase that happens in batch with the X12837. It then goes into the adjudication platform, where it will calculate and go through all the various rules for a specific benefit plan. And from there’s typically a payment process that is executed sometimes on a weekly basis, sometimes on a daily basis. It all depends on the payer’s technology stack, which then aggregates all of the claims that it receives since the last time it ran and determines what the total payment amount should be per provider. That is then typically extracted into another batch file called the X12835, which is then sent either go back directly to the provider themselves or sent to a payment aggregator who then will eventually cut the check or cut an EFT payment to those providers. So there are just a lot of stops along the way within the current medical world.

If there are prior authorizations involved, if there are more complex conditions involved, then you typically have to coordinate with the payer for medical management. There are laws being looked at right now regarding prior authorization. I’m not really up to date totally on them. I just know that laws are happening around prior authorization and possibly the ability to start removing those. And so that also is a delay within the whole payment process to get those claims paid.

Chenny (8:22):

Wow. So this is the current process, which is antiquated. When we walk into the pharmacy, by the time we walk out, we know the co-pay, how much is going to be out of pocket, whereas when we go and see the provider, that’s not the case. And now we know why.

“Multiple stops, right?

Dan (8:48):

Multiple stops. And it could definitely be more complex. There are other payment systems out there.

For example, a payer may contract with a company that does pricing. And so they may have to take that file and send it directly out to a repricer who can re-adjudicate and price those claims. If it’s out of network, they were in network. So, I mean, the network arrangements could be fairly complex, where the payer may send that claim to different tiers of individuals to actually price those claims. So, that just adds to the overhead and the complexity of it as well.

Chenny (9:26):

Absolutely. Absolutely. And in all of this, the members will be scratching their heads.

“What’s going on? I didn’t expect this bill. Why does this cost this much?”

So, yeah. Yeah. And then this is where the experience, right?

For those who are in a vulnerable situation, putting them through this expense that they didn’t anticipate. And that puts them in a very difficult spot. So, now, that’s where your organization comes in, Simplify Healthcare, I’m assuming, right?

So, can you provide an overview of your product and services? Because FHIR interoperability will take us forward, but adoption of FHIR interoperability is, in my eyes, the industry has just started doing that, and it’s a way to go, but the problem has to be solved. We gotta simplify the healthcare itself.

“So, what a perfect segue. Can you throw out an overview of the products and services from Simplify Healthcare?

Dan (10:31):

Absolutely, and thank you for that question. So, I started at Simplify Healthcare at the end of 2023. So, about 18 months into my journey, a little over 18 months into my journey with Simplify Healthcare.

Where prior to that, my whole career was focused on really building the adjudication engines and all those other parts of doing the adjudication, developing and cutting the checks and the payment process, spending my whole career developing that, and then connecting up with Simplify Healthcare. When you look at these claim adjudication engines, they’re fairly complex in nature from a configuration perspective. You have to build benefit plans. It’s typically down at a code level. It’s very detailed work that has to occur within those platforms today. What payers face as a challenge is finding and keeping talent long enough to understand all the nuances of that claim adjudication platform.

Simplify Healthcare looked at the problems around the claim adjudication system, not claim adjudication itself. Those problems were manual data entry into those platforms, which is complex. Then, when you start thinking of benefit plans, the ability to file plans to CMS, the ability to file plans at a state for the exchange business, for the Affordable Care Act, and the ability to be able to build custom plans around self-funded insurance in the ASO world.

And so, all those dynamics allowed Simplify Healthcare to focus on three, four different products. We have a Benefits1™ product, which actually manages and controls the filing to the state, and it’s your full benefit catalog. Like, how do I define a benefit plan? What are the stages for me to define that benefit plan? And how do I file that benefit plan with the government entity who needs to approve that plan? And so that is our Benefits1™ application, and it kind of has everything related to, you know, managing the benefit plan.

We then have the Provider1™ application, which is everything around provider data management. It includes provider data management with standardization and the ability to build standardization around the data that’s being entered, as well as provider contracting and provider credentialing. Those are the two main products. 

I’m on a product called Claims1™, and where Claims1™ sits in the middle is between, again, that complex claim adjudication engine on the right-hand side, and then those very business-centric applications on the left-hand side, namely Benefits1™ and Provider1™. So, from a Benefits1™ perspective, you can say, I have a chiropractic visit that’s a 20-dollar copay. To make that little word and turn it into the configuration with a core adjudication platform, depending on which one it is, it could be fairly complex.

You need to define service categories and put the specific procedure codes in those service categories. There are just multiple layers of configuration that need to occur to build and support that one would align with in that benefit plan that says chiropractic 20-hour copay. What Claims1™ actually does is we built a tool that understands the language on the right-hand side and understands the language on the left-hand side, and can build and do that translation in the middle. So that it shelters the individual from having to know the complexities of that core adjudication platform and allows Claims1™ to really build the plan of what it would actually look like in that native syntax. In the user, then, what they have to do is review the plan and not manually type in the configuration within those platforms. Again, we do that for both provider data and benefits data.

The other product we have is Xperience1™. That’s our AI-driven customer service experience platform, which really sits and kind of focuses on the benefits themselves and how benefits can be interpreted. And so it’s kind of an enabler with native connectivity to both Salesforce and or Microsoft Dynamics.

And then, of course, there is our SimplifyX™, which is our whole AI flagship product for any little other use case throughout the health insurance company, the health payer, you know, we can help automate with our AI company. And we use that AI from SimplifyX™ in all of our products as well, from just different things, of actually comparing quotes or they’re helping compare benefit plans, looking at comparisons within provider data, are all kinds of parts within that SimplifyX™ that kind of feed into all of our products.

Chenny (15:31):

Wonderful, wonderful. This is pretty neat. And how do you bring in for our audience in the payer space, if you want to kind of equate this to the real world, right? When your customers are payers, right? At the end of the day, TPAs, ASOs, and then the insurance companies that offer it as a full benefit to the employers and for the employees. So, your target customer segment is insurance companies, correct?

Dan (16:06):

That is correct.

Chenny (16:07):

Yes, sir. There are close to, if my number serves me right, it’s about 400 plus insurance companies today. They’re doing this work, be it for Medicare, Medicaid, or employer-sponsored. 

So, the product that you have built is agnostic to all these different lines of business. You target all the insurance companies. 

Dan (16:31):

That is correct. So the Claims1™ product is agnostic to the different lines of business. The Benefits1™ product is focused more on lines of business.

So, for example, our Benefits1™.Medicare understands the bidding process for the bid submission to CMS. When you’re going to build a new Medicare Advantage plan, the different guardrails and the mandatory fields that are required for that to be submitted. So that comes kind of already pre-built to support Medicare Advantage.

We have another one that’s pre-built to support Medicaid. We have another one that’s pre-built to support ACA and commercial. And so, the Benefits1™ is where that gets a little more targeted because there’s a lot more knowledge that is industry and or line of business-specific that happens in Benefits1™.

But from a benefits perspective, when you go down into configuration within the core adjudication platform, Claims1™ understands, this is how this service must be configured within that platform. And therefore, it is a line of business agnostic. It really, at that point, doesn’t care what the source is.

“We also have the ability to take into Claims1™ other external sources. So, let’s say that a health insurance company already contains a benefit catalog, for example. We can receive that data directly into the Claims1™ product and do that same work. Even if it’s not connected to Benefits1™, if it’s connected to Benefits1™, the invitation is much quicker because we then have the full connected benefit journey, we like to call it, with Benefits1™ and Claims1™ into the claim adjudication platform. But again, if it’s an external source, we can pull that in. But Claims1™ would still then be agnostic to that line of business.

And as is Provider1™ is pretty agnostic, provider data is pretty agnostic to the line of business as well. But Provider1™, again, all of our products contain the ability to build what we call guardrails. So, there are a lot of products that you could just enter provider data without any sort of limits, guidelines, or criteria that force you and the user to not miskey data.

Well, Provider1™ has all that capability built in to enable the user to set those rules, set those guidelines. And that could be line of business specific. So if you’re defining a contract, let’s say at a network level, and if the network is related to Medicare business, you may have to have additional attributes populated, like a Medicare ID number must be mandatory.

So, a lot of those things you can do within the platform as well, and support the data cleanliness within the system.

Chenny (19:17):

Gotcha, gotcha. This is pretty much what you are doing is you are simplifying the processes, the workflows that are your target customers are looking to do, and you’re improving their productivity at the end of the day. Your solution is going to help them do their business workflows in a very productive manner using your solution.

“Am I phrasing it right?

Dan (19:45):

You are phrasing it accurately. Yes. It’s all about increasing quality and reducing manual work to build those plans.

In Claims1™, it’s all about taking the person who would be manually keying that configuration into the adjudication engine and shifting left. Instead of them actually having the key data, let them review data that’s actually going to be configured automatically via the platform. That basically allows them to do a couple of things.

Number one, it increases the duration of their selling season at the end of the year. If your lead time today is 60 days to build the benefit plan, and with Claims1™, we can make that lead time 10 days, 8 days. Obviously, you can continue selling all the way into December and be ready to adjudicate claims starting January 1st.

So open enrollment in most insurance companies starts within like around October 1st, and typically by the end of October or November 1st, they want to shut that down, sometimes extending it through the end of November. But every insurance company really needs to be planned to start adjudicating claims starting 1-1. Theoretically, it’s not going to be until 1-3, unless there’s an emergency room exam. 

But based upon what I said earlier about how slow it is in order to get a claim even into an insurance company, you probably have until January 5th before you start seeing claims from January 1st. You do have a little bit of time, but they need to produce ID cards, they need to generate the benefit booklets, and all that member-facing material needs to be given to the member ahead of the January 1st renewal period. It’s really during that period that we can extend that cycle by reducing the amount of time it actually is to configure the application within the system.

So that’s one of the, definitely one of the benefits to doing that. The other thing that we do within Claims1™ is that, what typically happens in these claim adjudication platforms is over time, users will build the same rules over and over again. So they may say, Hey, I need to build a deductible rule for $1,000.

They may not know one already exists. So, Dan will build one for $1,000 and then John will build one for $1,000, and then Cindy will build one for $1,000, which just leads to what I like to call configuration bloat within these claim adjudication platforms, which over time may and can affect the adjudication performance within that system, because there’s just a lot of rules that are being added that don’t necessarily need to be there. And so what Claims1™ does is it can recognize, and again, it’s also configurable, but it can say, I already have the $1,000 deductible rule, I do not need to create another one.

Now, if there’s a segregation that needs to happen where we want to take 1,000 deductible rule for Medicare versus Medicaid, so that there’s no reuse across lines of business, Claims1™ can support that. There’s also typically what happens in these claim adjudication platforms, is that users have to come up with unique IDs for rules. And again, from a user perspective, it’s kind of like giving an ID to everything that’s out there, and you start to come up with naming conventions, ways to do that, and what they call smart coding, but even then, it becomes complex to maintain.

Claims1™ can handle that smart coding and do that for the individual, so that the user trying to think of those rules and how to build different IDs for the rules, we kind of remove that complexity from the user and have them not do that work. So we can maintain that also within the Claims1™ platform.

Chenny (23:39):

Got you. This is extensive data operations, and as we all are grappling with these recent trends with AI and interoperability, you talked about FHIR. And with AI and interoperability, if the data can move through the pipes pretty fast, and if AI can help automate these workflows, it can definitely bring down the total cost and improve the experience.

So how do you see the role of technology in healthcare today, given that you’re dealing with so much data?

Dan (24:20):

The role of technology, very multifaceted for sure. I can take it from a couple of different angles. So one product that we’re also integrating, you’ll want me back up before I say what the product is, but there’s also within the whole benefit configuration, within that adjudication platform, after the user does that manual configuration today, there’s typically a testing cycle that has to happen to ensure that everything was configured and set up correctly.

So they’ll go through a set of test claims and a test suite in order to make sure the deductible and all that is calculated and configured correctly within the platform. And so what we’re doing now in Claims1™ is also doing an integration of a component that we’re calling Claims Test, which will use AI-based inference to determine that I have a benefit plan that was already there. A user is making a plan change for that plan coming into the, let’s say, for 2026, they’re increasing the deductible, or they’re changing the way chiropractic’s handled.

What we’re building into the Claims1™ application is the ability for the system to recognize and know what that change is and go ahead and build a suite of test claims that would be required in order to meet that, and test that plan change that’s going to be occurring. So we’re basically putting that directly into the product. And kind of when I look at that, it’s no different, the way I treat configuration of the claim adjudication engines is no different than how I would treat code, like if a developer were developing C-sharp.

And so if they’re in C-sharp and they go ahead and check in the code, there are CI/CD tools that are constantly executing. We have QA automation internally that we use. Obviously, that’s going through a test suite to make sure that there’s been, from a regression perspective, there has been nothing hurt when that change happened. And that’s the same way I look at kind of claim tests enabling a CI/CD pipeline for configuration into these core adjudication platforms.

So that’s one aspect of technology that we’re bringing in. The other aspect of AI is really changing how we can look at building applications, how we interject changes into applications, how we advance our technology forward, everything from having AI analyze code from a performance perspective, having it look at data from a pure organization perspective.

There are a lot of places where AI makes the technologist be able to get through their jobs much quicker, having AI in their back pocket and able to use that AI to do that work. And everything, from checking performance to writing unit test cases for their code. A lot of that’s becoming pretty mainstream with AI, where it makes the developers a lot more efficient in delivering the software.

And the software is coming out with a lot more quality because of it. 

Chenny (27:28):

Gotcha. So, you’re not just providing a capability to your customer in workflow automation, you’re also using consuming AI to build your product, right? So that is the trend that we want to hear.

That it’s not just about delivering capabilities, it’s also about consuming AI for shortening our development cycle or improving the quality of our product. This is pretty neat. And this is a perfect segue for my next question.

How do you approach innovation within your organization? And what processes are in place to foster the culture of creativity, experimentation, or upskilling? In other words, how does your organization stay agile and adaptable to evolving market trends and customer preferences?

Dan (28:22):

Yeah, so we take a couple of different approaches with that. Within my Claims1™ team specifically, you know, staying relevant, I like to call it, is a very important topic to me. It ensures engineers’ futures, it ensures the product’s futures.

And so always staying relevant is kind of the key phrase that I use within my teams. So, we have obviously set up an agile scrum, like most of the world today. We review the enhancements; we have an open forum across our teams that allows every idea to be heard.

There are no bad ideas. The only bad idea is the idea that hasn’t been spoken. I’m sure that’s a quote from somebody, because I know I just didn’t make that up.

But there are different perspectives that people have when they look at a product, when they use a product, and whether they’re brand new, looking at a product, or have been on it for years, there’s always a way to look at it through a different lens. And there are tools that you can use on the market that allow you to kind of model that, like Figma, for example, is a UI-based tool that you can kind of build what your screen would look like. GitHub Spark, you know, that’s, I think, kind of raising some eyebrows in the industry right now, allowing you to build applications.

And we enable, you know, my team members are enabled on some of those tools to really think about the problems differently. And once the problem is identified, we pick a path and we decide to do that, we pick a path. Now, every decision made may not be the right decision, but being able to pivot because you’re an Agile company is what’s critical.

And so we go through that process on a regular basis. We review the tools. We’ve evaluated the tools, obviously, with our end users from a pure product perspective and Agile review perspective.

And again, we constantly solicit feedback from both internal and external. And just think of the challenges that we’ve had in the industry and how we can address those.

The final part of that is really then allocating, you know, you have to keep the lights on. So you have Scrum teams dedicated to specific, you know, functions within our claims one product. And then we do reserve bandwidth for extra work for R&D work, we like to call it. And we use performance ratings to put people on separate projects.

And that’s within Claims1™. And overall, within Simplify Healthcare, we also have an innovation kind of R&D leader within the organization. And if we have an idea overall for the product that would be outside of the Claims1™ application, we have the ability to take developers from my Claims1™ platform.

It could be even QA and BA as well. I can take parts of a Scrum team and assign them to these little six-week projects, where we say we’ll go prototype something for six weeks. And they get to go and explore kind of those new technologies out there.

So it’s been rewarding. We see a lot less attrition within engineering. I think engineering is a high-turnover kind of area anyway.

And within Claims1™, we’re seeing a pretty low percentage of attrition right now. And I think those are just some of the ways that we are, you know, encouraging team, combating that and helping that. 

Chenny (32:13):

Wonderful, wonderful. So being relevant it’s the number one thing, be it as a product being relevant, as an individual contributing to the product world, being relevant. And what you said is constantly having the team interact with your customers, to understand what their feedback is, and helping you to be relevant, right?

So wonderful. And this brings us close to the end of our podcast today, but before I let you go, right? With your industry experience with products like Simplify Healthcare’s, with Claims1™, and other products, if you were to provide advice, what advice would you give to aspiring healthcare entrepreneurs looking to make a difference in the industry today?

Dan (33:07):

Yeah, it’s kind of funny. I think back in my career, and you know, the first company I started, I was the fifth employee there, and obviously started my own company. I was one of three guys, and we built software and grew that company to, you know, 100 employees.

The first company I helped grow to like 160 employees. And one of the things I always said was you really need to understand the business and understand the opportunity and the challenges at a business level. From a development perspective, programming languages are going to change every five years.

It’s kind of a trend. I mean, I don’t know how many times I rewrote the same application from a UI perspective. We went from JavaScript to XML-based dynamic generations of screens, to, I should say, all the way back to VBScript.

And the advancements in technologies keep happening, but you’re still ultimately trying to solve the same business problem. So staying within an industry and really becoming a master and understanding that industry up and down, I think from a long-term perspective, is really going to help anybody who wants to be entrepreneurial within that space. If you’re a developer and you love coding and so you want to go code in the auto industry, then you want to go code in the healthcare industry, that is fine, but you probably won’t advance as far in your career just being a coder or a developer than you would if you really kind of focus within an industry and really focus on part of that.

Like healthcare industry is very complex. You have providers, you have revenue cycle management on the provider side, you have the payer side, which is the whole adjudication space, you have the selling side, which is the brokers and product delivery.

So, there are many different facets. And then of course you have, I shouldn’t even say, then you have pharmacy, dental, vision, medical. And that’s if you don’t even go into life insurance and all those other sectors within the overall insurance industry.

So that would be my advice. My advice would be to find an industry that you’re interested in. If it’s healthcare, find a part of healthcare that really interests you. And then once you get ingrained into that, there are always these new ideas that come up throughout your career.

That again, go back to our last topic, which is, you know, we’ll keep your career relevant. It’ll keep your interest peak. And you still have the ability to keep learning the newest tools that are hitting the market through AI and technology.

Chenny (35:47):

Gotcha, gotcha. Very, very, very apt. Very apt.

As a closing thought, right? Looking ahead, what do you envision for the future of healthcare? And what role do you see yourself playing in that future?

Dan (36:00):

Well, my role for sure is going to be to help, keep bringing a level of automation to some of the adjudication platforms out there. I believe we will keep walking toward a real-time ecosystem. So, a more consumer-centric healthcare delivery ecosystem across the board, from payer to provider to member.

And technology is going to keep having a different play from, of course, AI. And how that’s going to get interjected into the platforms, how it’s going to make them more efficient, should hopefully reduce costs overall within healthcare, which should increase outcomes for all of us from an AI perspective. You know, there are a lot of companies out there focused on very specific drug and disease states, I should say, disease states, that they’re leveraging AI to help improve patient outcomes, help reduce costs in those same verticals.

And I think that’s going to be ultimately where we need to be.

Chenny (37:05):

Well said, well said. Automation. And somehow you can reduce the cost of care, right?

With the ballooning debt over our head, and every child born in this country today coming up with more than $60,000 in debt, even before they go to elementary school. So, this is an incredible cost that we are all working on. So, thank you, Dan, for joining me today.

And folks who are listening to our podcast, thank you for joining me today. And I look forward to continuing this conversation and exploring the future of healthcare with our next guest. Until then, have a great time.

For a more detailed discussion about our solutions and how we can help your business:
GET IN TOUCH