NAMPI 2026 session transcript

Presented by Optum State Government Solutions

Speakers: Kevin Hutchinson, James Lukenbill, PhD, and Ulyana Peychev

Kevin Hutchinson   00:00:07

Good afternoon, everybody. Welcome. Come on in and get settled.

Thank you, everybody, for coming in this afternoon. We really appreciate it.

We're in the final stretch, right? Hopefully everybody's had a good session so far and a good conference so far.

And in the next hour, hopefully we'll have some good conversations too.

On that note, I know at a lot of the sessions you can come up at the end and ask questions.

We would love to have you jump in, raise your hand and ask questions as we go along.

The only kicker is, because this is all streaming and online, you do have to ask into the microphone.

So you can jump up at any time, but you just have to ask your question into the microphone.

So with that housekeeping taken care of, welcome.

This team is from Optum State Government Solutions, and we're here to talk about practical techniques for using large language models in Medicaid fraud detection.

It's quite a mouthful, but the premise here is, yes, there's AI and machine learning all around, and there's talk about some very specific areas, but it really can permeate the entire process, and we want to talk about that a little bit today.

My name is Kevin Hutchinson. I am AVP of growth with Optum State Government Solutions, and I'd like James and Ulyana to introduce themselves.

James Lukenbill   00:01:55

Hi, I'm James Lukenbill. I'm an analytics strategic product manager with Optum. I've been with Optum for about 20 years.

Ulyana Peychev   00:02:13

I'm Ulyana Peychev. I'm a senior data analytics manager. I've been with Optum for seven years.

My experience starts with full revenue cycle case development, and now I'm leading a full operations team for postpay and prepay solutions.

Kevin Hutchinson   00:02:33

There we go. Great.

All right. So today's agenda is going to follow a framework of about these five basic steps.

First, we're going to take a minute to define the problem that we want to talk about.

And the problem is that program integrity isn't all about just creating more leads.

Analyst capacity is one of the biggest problems that we have, and how can we use modern technology to address that?

Then we're going to go to a framework of three different questions that we're going to continue to refine and revisit throughout the presentation.

Can it find it? Can machine learning and AI find it? Can we prove it? And will it hold up? That's the final check at the end.

We're going to wrap up with some takeaways and next steps for us all.

So the first thing is the program integrity problem.

I'd like to ask you one question.

Is there anybody out there, any agency folks, that have analysts, reviewers or investigators who are waiting for work to be done?

They could really be getting to work if only they had more leads.

There's nobody here.

I think it was Ashley from Colorado yesterday. I don't know if she's here or not, but if I'm quoting her directly, she said, "We're up to our ears in leads. We don't need more leads."

Leads are an incredibly big part of the process, and AI and technology can continue to bring them through.

But some of the problems are that we have more claims to review than we have capacity to review them.

Investigations can take a long time.

Are there efficiencies in 2026 and beyond that we can use to make these investigations and reviews faster?

And finally, not really a problem, but a challenge: at the end of the day, these all have to hold up.

These have to hold up whether or not you're using AI to come to these conclusions.

So again, these three questions. The first is, can it find it?

Can machine learning and AI be used to find it, and how can it be better than what it is?

Before, we'd come to these sessions and these conferences, we'd trade ideas, we'd take notes, and somebody would say, "This is when we had a dental case, and this is when we did something else."

And we'd come back and say, "Oh, we should do dental." And you'd take it from there.

Well, what if you didn't go to that dental session? What if you didn't catch that one and you didn't think of that idea?

How can you use AI to look at the data itself and have it tell you what you could potentially be looking at, at a more holistic level?

Can you prove it? Once you have these ideas, what's your source data behind it, what's your written rationale and where's the person in the loop? How can the person support that?

And finally, will it hold up?

No matter how much you use AI, Claude is not going to be in that appeal. ChatGPT is not going to be testifying.

You have to be able to defend and explain how you used AI to come to your findings.

But the good news is AI can do a lot. AI can do a lot of new and innovative things.

First of all, democratizing data.

Before, you would have to call up some sort of analyst or programmer to write SQL code and start running a query in some programming language.

Now, with language models, you can do those searches yourself. That is a fundamental change.

But it doesn't end there. Then we want to start talking about automated workflows.

How can you change the workflow throughout the process, using AI to make things more efficient and more effective?

And finally, wrapping up with dynamic insights. Not just insights, but dynamic insights.

How can you use AI to adjust in real time, and adjust dashboards in light of what the findings are?

We've had clients tell us, "Yes, we have dashboards and reports, but we're worried that even with the reports and dashboards, we're going to miss something."

How can you use agentic AI to not only generate these reports, but also call out what's most important?

So there are multiple layers that we can be looking at.

So that tees it up a little bit. I'd really like to pass it off to our experts now, and James Lukenbill is going to walk us through a little bit of history and where we are now.

James Lukenbill   00:07:56

Thanks, Kevin.

So let's go back in history here.

Does anybody remember mainframe SAS back in the '70s, where you'd have control files that you'd have to submit, and then wait a while and see if those things worked? Anybody remember that?

A few people do. All right. I came in after that.

Then in the '90s and 2000s, we had MMIS edits and manual audits, so we were getting some SQL. And in the 2010s, we had predictive analytics.

Then in the early 2020s, we got governed cloud data platforms, where we actually have elastic capacity available to us.

And finally, today, what we're really going to be talking about is agentic AI investigations, where we really have a new generation of tools available to us.

So this is in the "can it find it" bailiwick.

I'm going to touch on this generic architecture for agentic program integrity.

The way we conceptualize it, we have a deep research orchestrator, which is an agent.

We're going to get into a demo in a little bit, where we'll make this conceptual stuff a little more real.

But we have various agents below it. We have a policy-to-SQL agent, which Ulyana will demo in a little while.

We have a query agent, a graph pattern analysis agent, an anomaly agent and then an agentic investigator.

That agentic investigator is one of the things we've conceived that really brings all the leads together.

We have all these capabilities that run behind the scenes, and this is what really brings it all together and prioritizes all that information.

So again, this is just a generic agentic program integrity workflow.

In our system, we have traditional SAS that runs behind the scenes.

You have provider peer group studies, like who's three standard deviations from the mean. We have hundreds of analytics that may be running and writing data to the tables.

That goes into a metadata repository and a results repository.

And we have spike results, which look longitudinally over all of the information that's coming in. Each time you load the database, is there a spike? It's going to inform you of those spikes.

The net-net of this diagram is that all of it gives the agentic workflow engine the ammunition to sum up who the providers are that you could go after.

As Kevin was saying, not many people are saying, "Oh, if only we had some leads here."

So "can it prove it" is the next thing we're going to talk about.

I'm going to bring up Ulyana, who's going to talk about our policy-to-SQL engine. Go ahead and handle the slide, and then I'll switch it over.

Ulyana Peychev   00:11:32

So how can we prove there's fraud without just saying, "I feel it. I know something is there"?

Let's pretend we're fraud, waste and abuse investigators. It's a typical Monday.

You're logging in, you have your coffee, your Teams messages open just in case you find something juicy, and you have your claims view, right?

And now what? Where do we go?

How do we know what our analytic focus is going to be, or what our case leads are going to be?

In order for us to know what is wrong, we first have to know what is right.

And in our Medicaid role, we start by looking at policy. We look at CPT books, CMS documentation and so forth.

From observations, we've noticed that it takes about 28 hours to review policy, and that's just in basic terms.

We have some obstacles. For example, not everybody agrees on the interpretation. It could be an outdated policy. Someone might say, "Hey, this isn't even the right policy we're looking at."

So there are always those obstacles, right?

And even after you go through that, you still have to take your idea and put it into your data. And what happens there?

Some of us are extremely good with policy. Some of us are extremely good with SQL.

But what if you're not that great with SQL, and now you have to write your own query, and you're taking a SQL crash course just to get going, or you're outsourcing it?

All of this takes quite a lot of time for most of us as investigators.

So right now, I'm going to show you our policy-to-SQL tool, which makes it possible for us to do this quicker and more accurately.

In some states, we were able to create over 300 analytics within a year because of the availability of this tool.

James is working on that. He said it shouldn't take more than a minute.

James Lukenbill   00:14:50

Yeah. I'm lucky I get to mess around with a GPU scaling setting on my computer for this. So thanks to the tech guys.

Ulyana, I'll let you go ahead and get up here and demo away.

Ulyana Peychev   00:15:11

OK. This is better. That's good.

So how this policy-to-SQL tool works is it ties your state policy and the data mart to a specific state, so we're able to quickly upload the policy here.

As you can tell, it says "Upload policy documents."

What it does is read the policy quickly and provide results. And these are quantifiable results.

And it doesn't take 28 hours. It usually takes about three to four minutes, and sometimes even quicker.

The cool thing is that it's not just for policy. You can upload CPT books here. You can upload CMS documentation and have it link it all together to provide various scenarios.

As it reads the scenarios, it lists them below, and you're able to quickly review them.

For example, this one is about autism, and it's talking about certain age groups. And it doesn't stop there.

Once you have your policy identified, by clicking Generate, you're able to generate a SQL query quickly. So you don't have to take that SQL crash course.

You can see what it does here: "Generate SQL query." You have it all listed for you.

From there, you can copy it, put it into your data mart and quickly use it in your system.

With that said, if you're reviewing the data and thinking, "Well, let me change this out a little bit," there are certain prompts you can use that will modify your query, even differently from the current policy, and bring back the results for you to continue using for your analytics or your case leads.

Any questions on the policy tool? OK, I will pass this back to James.

James Lukenbill   00:17:47

All right, so we'll be getting into some demos in a little bit here.

One of the things I wanted to talk about, and I think this is applicable to everybody that has a cloud platform out there: we happen to use Snowflake, so we have something called Cortex Code in Snowflake. But Databricks has Genie. Microsoft Fabric has Copilot agents. Oracle has Select AI. And Google and AWS have flavors of this as well.

So what I'm going to show you is generally applicable. This is our flavor of it.

Essentially, we have a React interface that interacts with an API, but these capabilities are generally applicable regardless of your tech platform.

What this really does, as Kevin was talking about, is democratize data access. Even with the policy-to-SQL engine, you have the SQL and you can run it in a SQL editor.

But this really provides a way to have a conversation with the data.

And this has really matured since March of this year. So this is recent stuff.

We're going to talk about a couple of capabilities that we've implemented. Again, these are capabilities that many platforms have.

We have an agentic investigator. With this, nurse investigators can write code and ask questions of the data, and you can ask follow-up questions, so you can really have a good conversation with the data. And then agents work the case.

You'll see the various steps it goes through when I do the demo. It does what we'd call schema discovery, where it goes out and finds the data.

Prior to March of this year, with some of last year's capabilities, you'd have to tell it what data to go after. You don't have to do it that way anymore.

And then of course, you need to have an investigator follow up on the results and look at them.

The cool thing is, in a lot of program integrity investigations with our tools, for a number of years we'd say, "OK, you've got peer group profiling," and then the investigator would go open up a BI tool, pull all the claims and investigate it that way.

This way, you can prepare a data set for investigation within the tool, make that data available, store it for posterity and attach it to a case management tool, so you can make it static.

So I'll give you a little demo here and see if the GPU scaling will be my friend again.

Kevin Hutchinson   00:20:52

While James is pulling that up, just to reinforce: I've been doing this for a long time.

And to reinforce that theme, the notion of generating a whole bunch of leads to start and then having to go through them all, the limiting factor historically has always been not enough people.

Well, with the advancement of AI, that can completely change this equation that we've been stuck in since the advancement of data analytics to identify enough leads.

So we could be entering a new era: the end of not enough people, potentially.

James Lukenbill   00:21:34

So of these capabilities, I'll show you the virtual investigator first.

This is a capability that we developed to bring everything together and allow people to organize leads. I'll make this full screen.

This provides an overview of all the leads within the system.

But where it really gets interesting, as Kevin was talking about, is that we really need to rank the providers. This provides a way to rank the providers, and then you can drill through.

And the cool thing, and really where the LLMs come in, is that it provides this kind of dossier on each provider, so you can understand what's going on: the case algorithm signals, the billing pattern signals, the member and population signals.

And then it flags all the algorithms that this provider is in. It shows the spike analysis. It shows the peer group profiling. So it really brings together all of the analytics, and this is what you drill down through in order to look at the prioritization.

So that's one of the capabilities. The thing I think we're getting increasingly excited about is this agentic investigator.

In this case, we have a couple of cases that we went into, so I'll go ahead and grab one here. One of my faves is this professional claim study.

I'm not going to submit this, because it took a little while. But literally, I just typed this out, submitted it, went and mowed the lawn, and came back and it was baked for me.

As you can see, I used this prompt up here. I said, "You're the top fraud data scientist in the country," just to give it a little context about who it's supposed to be.

Then I told it to look at professional providers, told it what kind of claims to look at, and told it what kind of output I wanted.

It replies, and as you can see, it goes through and finds the data that it needs.

It says, "Excellent, I have the top 10 cases. Now let me create the PDF dossier and Excel spreadsheet."

In this case, we created an Excel spreadsheet for easy upload to a case management system. And then it provides the scoring and the top 10 identified providers here.

And this is the dossier that it provided. I didn't tell it exactly what I wanted. This is what it decided was a good dossier.

This is a PDF that gives you the top 10 providers identified for investigation and provides the executive summary, the methodology and, probably most importantly, the risk scoring.

You can see all the associated information. It shows the algorithms and the preliminary findings.

Another item it produces: you just ask it, "OK, I need a batch file that I could upload to a case management system," and it will provide all this information.

If you know exactly what the upload format is for your case management system, you can certainly specify that. And it provides the study metadata as well.

So this is something that's really coming to the fore.

This is a hospice study that we put together. Somebody mentioned hospice studies the other day during this conference. Yeah, it was yesterday.

We just typed this in and said, "Oh, it would be cool to take a look at this."

This was: display members who stayed in hospice for an unusual length of time, such as three standard deviations from the mean, without previous medical history before the admission date.

It goes through, and it didn't find anybody with no medical history, but it did find some people who were in hospice for an extremely long time. And then it gives you the rundown on this.

And then we followed up with it. It asked, "Would you like to relax the no-prior-history criteria, for example, fewer than five paid claims, or use a different look-back window?"

And I just asked it, "What minimal history did the members have?" And it'll come back with that information.

So again, it democratizes the ability to just chat with your data within a data mart or a data warehouse to find some pretty cool results.

Here's another example. This is an ABA fraud dashboard. One of our analysts said, "OK, I'd like a dashboard on this," and it provides a dashboard. You can click on this and drill down and things like that.

So it's becoming so advanced that you can create your own dashboards and your own analytics. On top of this, we have people creating their own user interfaces for this information.

It's kind of an exciting time to be alive, especially if you didn't have the best SQL skills before.

Audience member   00:28:17

[Partially inaudible] Using that to compare pharmacy data with claims data and find the anomalous things in the claims data. So we're talking about comparing policy with the claims data?

James Lukenbill   00:28:47

Oh, yeah. You can actually upload policy to this engine. There's an upload capability. If I had some policy right now, I would give it a shot.

But you can upload policy and other things. We actually use this to create load routines. If there's a layout to load data, you can give it the layout as a PDF and it'll create the load script for you.

I don't have an example of that right now, but yes, that's one definite way to explore it and expand it. Good point.

I'm going to go back to this here. I wanted to show one thing.

A lot of people ask us, "Well, who's going to validate this thing?"

One thing you can ask it to do is provide a validation data set, and it will pull together a validation data set for you.

As I was saying, you can make this validation data set static so you won't lose it. If you load data again to update your claims, this can stay static in the data warehouse.

I'll show you one more thing here. We have this AI Assist capability.

One thing we're doing, not just for program integrity but across our product suite, is this AI help. You upload all your product documentation, and then you can chat with it.

It's essentially a RAG, or retrieval-augmented generation, model in the background.

So I can say, "How do I run a peer group profiling study?" and click Ask AI, and it will go ahead and provide a summary of what you need to do. In this case: select the data rules, create the study.

This is applicable to our own tool, but it could be anything else. It's essentially a RAG model.

So if there are any questions on this... If not, I'll turn it back over to Kevin. That concludes the demos.

Kevin Hutchinson   00:31:50

I'm going to wrap things up as he moves on, but if there are any questions about any of the demo capabilities, we're happy to respond to those.

This slide is just summarizing where we are with this. There are a few different impacts.

I think "days to minutes" is self-explanatory. How quickly we can access data in such a meaningful way has changed rapidly.

More interesting to me is the broader view. Gone are the days of looking at a single claim or a single provider without the bigger context of how they fit together.

These AI models can bring together claims and providers and make connections in ways we haven't been able to in the past.

And what's really exciting, as the transition into the next section, is better-evidenced cases.

If it's not done right, you may have a reviewer who was maybe taking good notes, maybe not taking great notes, and then it comes around to the appeal. That'll be a big factor.

The evidence and documentation available all along the way, which we've tried to show you around validation and verification, is there, and it builds a much stronger case if it's done well.

So that's what I wanted to wrap up with: is it going to hold up at the end of the day?

We are in something of a renaissance of AI. We're also, I think, in something of a dark ages of AI slop.

There's just a lot of AI out there that isn't trustable and isn't believable.

How are you going to make sure you're using AI effectively, in a way you can defend, without it being AI slop?

There are a few key considerations. You've got to start with governance. Governance isn't an afterthought. Data governance, all along the way.

Establish that framework from the get-go, and make sure it's reliable and referenceable throughout your process.

It has to be transparent and explainable. The paper trail has to be there. The process has to be documented, and you have to understand it in order to explain how it worked and how you came to your findings.

A common conversation in AI, and for good reason: bias and equity safeguards. You have to make sure your AI specialists and your AI models are cognizant of any biases that could be built in.

And the last two: for it to be defensible, you certainly don't want your entire case to be uprooted or undermined because you didn't have your standards in place.

Make sure you have your interoperability standards set from the get-go.

And make sure your lifecycle management, like security incident response playbooks, is set, so that nothing is undermined after you have all these great findings and great results.

So again, AI can't do this all on its own. Make sure the human is in the loop.

Some things to keep in mind: SQL can be wrong. You have to make sure you understand it and look at it. It is an amazing tool, but you can't follow it blindly.

Be cognizant of schema and policy drift. James showed some really powerful examples of how AI can plug into the schema and into the policy. Make sure you continue to monitor this as it evolves.

AI can be an incredibly powerful tool to help identify, connect and prioritize, but AI can't decide. People have to decide. Don't lose sight of that: adjudication is not autonomous. People are making those decisions.

And you have to understand the limits around explainability. Where your model can't show what its reasoning is, you want to be aware of that and make sure you're setting the proper flags.

And same as the last point, be constantly aware of making sure that privacy and access are at the forefront with these models.

So to wrap this up, a few key takeaways to leave you with.

Think about the entire workflow. Don't think about AI as a tool you can just superimpose. Think about your process, think about your problems and think about how AI can assist throughout the entire investigation, not just the detection process.

Always keep people in the decision.

Defensible beats impressive. We've heard lots of really cool stories this week, and I love hearing them. But a solid single might beat swinging for the fences sometimes, if you can absolutely be in a good position to defend it.

So I'd leave you with a step to think through your processes and maybe one of your biggest problems. Again, not "How do we get more leads?" but some of the other limitations.

Think through how AI could potentially take those on, and see where we could go. And of course, we'd be happy to help you throughout the process.

So with that, any questions? James, you've got your microphone up there. I'm feeling a lot of the questions are going to be for James.

Audience member   00:37:53

Hi. When you're prompting your tool with a question, are you uploading just a policy that's relevant to that specific question, or can you upload an entire library of administrative rules, policy articles and coverage determinations for it to sift through?

James Lukenbill   00:38:18

Great question. With our policy-to-SQL engine, you've seen that we've uploaded the policy and then it creates rules for us. With the agentic investigator, we're just starting to scratch the surface of what we can do.

As far as uploading an entire policy library and running that against the database, that sounds like something I'll probably be doing tonight, but I haven't done it extensively.

We're just scratching the surface on these capabilities, and more capabilities come out all the time.

For the foundational models behind the scenes, we just set the AI to auto. A lot of people ask us, "Hey, what model are you using?" It will choose the best model, so it's not incinerating too many tokens on a lower-end task. It'll use a lower-end model instead of something like Opus.

But if you loaded a bunch of policy there and asked it a very complex question, then it can use one of the frontier models.

Audience member   00:39:25

I understand that the capabilities are going to continually scale as the models are updated by these companies, so what you're able to do now may change as that advances.

If you have an existing library of policy information and things change, an update happens, a new one comes into effect and replaces the previous one, have you thought about ways the AI itself can intelligently know what to use, so it doesn't hallucinate on previous policies?

James Lukenbill   00:40:05

Yes. One of the things we do is just give it the URL.

If you have Medicaid policy that's stored publicly, which most Medicaid policy would be, you can give it the URL and have it continually update itself.

That's what we've done in some cases where we're looking at Medicaid policy or data we need to load. We just give it the URL for publicly facing sites.

Audience member   00:40:32

OK, thank you.

James Lukenbill   00:40:35

Thanks.

Kevin Hutchinson   00:40:37

Any other thoughts or questions? Well, if there's nothing else, we really appreciate your time in joining us today. Thank you.