Thaiyeb Hussain

In the Denial Management process in RCM (Revenue Cycle Management), we have been trying out few AI tools to help in understanding payer denial reasons and to suggest the team what to do next. The idea is to improve the speed of the resolution, but we realized something important: how can we ask the AI makes a big difference. For instance, if we just say something like “Tell us what this denial means”. The response we get is usually pretty vague, maybe it will say, “Coverage issue” and that’s about it. Not really useful. But then we tried changing the prompt slightly to “What should a denial analyst do if the remark says Coverage terminated prior to date of service?” That change made the AI give a much better answer. It said to verify the patient’s eligibility, and if the coverage really was inactive on that date, then update the insurance or transfer the balance to self-pay. That’s the kind of reply our teams can actually use. It sounds small, just a change in wording, but it totally changed the quality of the result. We went from something high and border to something actionable. So we design the prompt really affects how accurate and helpful the AI is. It is not about what the process required, it is about how we ask it. That is something we will definitely keep in mind as we use more of these tools.

In our payment posting process, there’s been ongoing discussion around how we can bring in AI to ease some of the workload. Honestly, it makes a lot of sense. A big chunk of what our teams do here is repetitive like Matching payments from ERAs or scanned EOBs, Entering them in the system, Checking totals It is rule-based and time-consuming. Payment Posting process is more suitable for automation. Now, if AI comes in, it is not going to replace the team. That is not the point. What it will do is take over the basic stuff like Reading payment files, Identifying the right accounts, Applying the amounts where it’s confident. So instead of spending their day doing data entry, our staff will shift into more of a reviewer role. They will be checking what the AI did, fixing anything that looks off, and stepping in when the system does not have a clear answer. Long Term Focus of the Team: It is not about speed anymore, it is about accuracy and judgment. People will need to spot inconsistencies, validate edge cases, and be comfortable saying, “Hey, this looks wrong and let me fix it.” Also, there needs to be a way for them to flag issues easily like when the AI misses a particular payer format or misreads an adjustment code. That feedback should go right into refining the system. The leads or supervisors will also have new responsibilities. Instead of just managing productivity, they will have to keep an eye on how well the AI is doing. Are there repeat errors? Are some payers consistently causing problems for the system? It is a bit of a learning curve, but over time, the system should get better. Especially if we create a strong loop for learning from mistakes. Key aspects to consider: We will need to train people not just on the new tool, but on how to work with it. It is not about using the tool blindly. They need to know when to trust it and when to step in. That balance is going to be key for this to work smoothly. So, in short AI can help a lot in payment posting, but only if we design the process to support both the technology and the people. The human role does not go away, it just becomes more focused, more skilled and honestly more interesting.

Observations from AI in Our Appeals Process In our RCM process, we have been using an AI tool to draft appeal letters, this helps in reducing time to prepare manually. It collects data like denial reasons, patient details, and payer rules from available supporting documents in the first draft. When we rolled it out, it did a good job. The letters were mostly spot-on and helped us get quite a few denials overturned. But over time, we noticed a few things started to slip and not in a way that set off alarms. Even though there are no errors reported, we could tell the quality wasn’t what it used to be. A few examples: The prompts feeding the tool was not updated for two quarters, so the letters felt outdated or missed key points. There were changes in the denial codes or policy from payers, but the AI was not able to recognize them or respond in the right way. Our Corporate Compliance teams have made updates to how letters should be written, maybe changes in wording or layout. But the AI continued using the older style. Because the system does not throw any errors, these kinds of changes quietly affect how well the AI performs. If no one’s checking, it can decline over weeks or months before it starts showing up in results. Signs That Something’s Off Here are some early signals we’ve learned to watch for: Appeal overturn rates drop, even though the types of denials and volume haven’t really changed. Team members are spending more time editing or fixing the letters before they go out. QA or nurse audits start flagging the same types of issues, problem with words, missing clinical reasoning, or formatting mistakes. During one of the MBR (Monthly Business Review), we get comments that payers saying the letters are not clear. Our client express concern over this statement. How We Stay Ahead of It 1. Regular Reviews Every week, we extract a handful of AI generated letters and assign to our senior QA to go through them manually. It’s not a big batch, but it gives us a sense of whether anything’s off. We also compare them with manually written letters to see if there’s a pattern or quality gap. 2. What We Track Metric When to Act Action Taken Appeal success rate Drops more than 10% below recent average Dig into specific cases, check AI inputs Manual edits per 100 letters More than 15% need rework Review prompt logic and update if needed 3. Spotting Data Drift We track changes in denial codes, document types, or shifts in payer policies. If something new starts appearing frequently, it may take as action to check the need of AI to be retrained or adjusted. 4. Real-Time User Feedback We have added a simple tagging feature in the letter review system. If our team sees something off, like wrong justification or missing details, they immediately flag it. We go through those tags monthly to spot any recurring themes and take action accordingly. Why AI Needs Closer Watch With regular systems, it’s usually easier to spot when something’s not right — you get an error message, or a result looks obviously wrong. But AI is different. Once it’s set up and passes UAT, we tend to assume it will just keep working fine. The most important part is, AI-generated content often considered as correct, hence we stop double-checking. That is when small mistakes start to creep in. And if there is no governance, the errors like outdated formats or missing key updates can cause bigger problems, especially when it affects compliance or our payer communication. AI is definitely useful, and it saves time no doubt about that. But it’s not something we can leave on autopilot. A bit of regular review, some honest feedback from the people using it, and tracking a few basic metrics can really help. It does not take much, just some weekly attention to catch things early before they turn into real issues.

Traditional audit methods emphasize procedural adherence of the process (Inputs, Outputs, Compliance). At times, it also audits human accountability. However, AI systems introduce dynamic, opaque, and non-deterministic elements that require a broader and more adaptive audit framework. However, this technique will not be more appropriate as decisions taken by AI are based on inputs given to the program. Expanded Audit Criteria for AI-Infused Processes: Model Design & Development: this is to understand flawed or biased training data can lead to systemic errors or unfair outcomes. Are the AI models trained on high-quality data? Did the model documentation covers the assumptions and limitations? Is the purpose of the AI model aligned with business objectives? Decision Traceability: One thing that stood out — we’ve got to be able to explain how AI is making decisions, especially for anything high-stakes. Can we walk someone through the logic or input that led to a particular output? Are we keeping a log of changes to prompts or how the workflow is set up? That’ll be important later. Fairness, Bias & Ethics: AI can behave oddly if the training data’s off. We don’t want something that treats one group unfairly without us even realizing. Have we checked if the model is biased — like giving different outcomes for different user groups? Is anyone reviewing this regularly, or is it a one-time test and forget? Monitoring & Drift: AI isn’t static. Even if it works well today, it might not tomorrow. Are we keeping tabs on how it’s performing week over week or month over month? If things start drifting or it gives unexpected results, who jumps in and fixes it? Human Oversight: Automation’s great — but we still need people in control. Do we have any control points where someone can step in and override a weird decision? Are users confident about when to trust the AI and when to double-check? Some Observations in my Experience: Results that are unpredictable or inconsistent No one taking ownership when something goes wrong System changes happening but not being recorded Unclear governance, Details of responsible SPOC Full reliance on a tool, people response that they did not build and don’t understand fully Real-World Audit Tips I. Build on What We Already Do We dont need a brand-new process. Just add sections to current audit checklists by looking at bias, model changes, decision logs, etc. II. Assign a Go-To Person or Small Team Someone needs to own AI governance. Ideally, someone who understands the tech but can also speak business risk. III. Push the System — Hard Try edge cases. Throw in unexpected inputs. See how the model reacts. We learn a lot from how it handles the “weird stuff.” IV. Keep a Short, Clear Record for Each Model Doesn’t need to be fancy. Just include the model's purpose, last test date, any known issues, and how often it gets reviewed or updated. Make Sure It’s Transparent, Fair, and Aligned Transparent: Can someone outside the tech team follow what happened and why? Fair: Regular bias checks — not just one-and-done Aligned: Is the AI helping meet business goals or just running because “we have it”? At the end of the day, the check points is not just about the technology. We need to be able to establish: “This is what the system did, here’s why, and we are confident it was the right call — or we fixed it if it was not.”

Over time, I have seen AI solutions built with fixed rules or static prompts slowly start to lose their edge. Not because something is wrong with the tool itself, but because the environment around it keeps moving. Things don’t stay the same in RCM. Payers revise policies, denial codes change and what worked last quarter might already feel outdated. You usually notice a few quiet signals first: People begin sidestepping the AI. Not openly, maybe, but gradually. When the user start overriding the auto suggestions by bot more often, it is a clear sign: they are no longer trusting it. Exception cases start creeping up. Say a model was good at flagging high recovery claims. Suddenly, key ones get missed. The model did not get worse, it just did not adapt to what has got changed. The rules stop evolving. I have seen this happen with logic-based bots or decision trees. They depend on someone updating the knowledge base, but if that does not happen? The tool quietly falls behind, even if no one’s yelling about it. So how do we avoid this kind of slow breakdown? Keep watching, even after launch. Just like we did track quality or productivity, I believe AI metrics deserve the same attention. Set it and forget it? That doesn’t work here. Loop in the people closest to the process. Sure, tech teams build the solution, but ops teams are the ones living with the outcomes. I always make sure there is a point person on the floor, someone who will raise their hand when things feel “off.” Plan for updates: not as a reaction, but as a routine. One thing that worked well in a past project: we aligned AI prompt reviews with our quarterly payer updates. That way, both the process and the tool matured together. At the end of the day, AI is just another part of the workflow. It needs feedback, tuning, and someone who owns it. If we treat it that way — not as something magical, but as something maintainable — we will see it continue to deliver results. If not, it will quietly stop helping, and we won’t realize until things go wrong.

The approach which I consistently use is the "Problem-First Framing" method. Before exploring any AI solution, I ask a simple but powerful question: “What critical business decision will this AI help improve, and how is that decision made today?” When it comes to AI in RCM, I have found that it is really easy for teams to get excited about what is possible, especially with things like predictive analytics or automation. But I try to slow it down a bit by asking What is the problem we are trying to solve?” Not just in theory, but in the real day-to-day situation, How are we handling it right now, and Where is the gap? These questions usually makes people stop and think. A lot of times, there is a tendency to jump into AI just because it sounds advanced, but the actual business need might not call for it, or atleast not right away. One thing that worked for me is to just talk through what the team is trying to improve. Like, is this going to help us bring cash in faster? Will it reduce denials or speed up claim processing? And can we realistically implement it with the data and systems we have? There was a situation not long ago to use AI to forecast resource needs. But after discussing it a bit more, we realized we could get similar value by improving how we schedule with existing tools. It was faster and easier, and we did not need to wait for a model to be built and tested. So we did that first. That does not mean we dropped the AI idea, we just delayed it. But that choice made more sense from a business point of view. For me, keeping AI tied to actual business priorities just come down to asking the right questions early and being honest about "what is really going to deliver value now vs. what is just interesting technology".

When I look at how things can go wrong in our process, the Swiss Cheese Model actually paints a clear picture. Even when you have got all the right checks in place, mistakes still manage to happen. That’s because it is not just one thing failing, it is usually several small gaps that all line up. Layers of Defense: For us, the layers of defense are things like SOPs, training programs, tool validations, QA checks, and so on. They are solid on paper, but in real-time operations, none of them are perfect. And they don’t always catch everything. SOP: It can go outdated if no one is keeping them up to date. Training: Training is given, but sometimes people don't get enough hands-on time with the tools, like the decision tree. QA Review: QA reviews are there, but if the sampling isn't representative, the biggest risks can be missed. I have also seen cases where a payers update came in, but our system or team didn’t catch up fast enough. It creates a real gap. Holes: So the “holes” are these small flaws, and if they happen to align, that is when an issue gets through. What helped me is shifting focus from individual errors to looking at the process as a whole, it makes me to ask, where did the system allow this? Business Excellence point of view: This model fits well with the tools we already use. For example, FMEA helps flag the areas where a failure is likely. SIPOC diagrams help me map where each control sits. And when something does go wrong I usually dig into it using the 5 Whys or fishbone just to see which layer didn’t do its job. When I am using DMAIC, this model naturally blends in. I first look at where the most vulnerable is. Then I check how often issues are slipping through. In the Analyze phase, I focus more on connections between gaps than on a single root cause. During Improve, it is usually about tightening up the controls; maybe refreshing training, rewriting an SOP, or adding a validation. Control, to me, is more about ongoing monitoring to make sure things dont drift back. What I like about this model is that it reminds me that it is not about blaming people. It is about designing a system that is strong enough to catch mistakes before they become problems.

Making Change Stick: My Take on Change Management in DMAIC Let me say this up front—just because a process change looks great on paper does not mean it’s going to work. I have seen technically brilliant solutions fall flat simply because the people involved were not brought along for the ride. Change management is not a side activity. It is front and center, especially in DMAIC projects. Here’s how I have seen it play out at each phase. Define – Before the work even starts This phase is where everything begins, and honestly, it sets the tone for the rest. It’s not just about writing a charter and stating the problem. It’s about getting people in the room who actually care or will be affected by the change. If they’re not aligned early, you’re already behind. In one of our accuracy improvement efforts, we were planning to roll out a Decision Tree tool. Before diving into anything, I sat with ops and quality folks to agree on how we define “accuracy.” It sounds simple, but definitions can differ across teams. We also pulled in training leads early—because what good is a tool if no one knows how to use it or sees the value? Measure – When numbers meet nerves Once we hit the Measure phase, things can get a bit tense. Teams start wondering: Why are we tracking this? Is someone checking up on us? It’s natural. That’s why I always try to make it about shared learning, not surveillance. I was involved in a dispute reduction project, working with teams in Chennai, Pune, and Manila. I made it a point to meet each team and explain how the data would be used—not to compare them, but to find patterns. I think that made people more open. The goal was never “who’s doing better,” but “where can we improve across the board?” Analyze – Time to get honest This is where people start talking about root causes, and things can get uncomfortable. You hear stuff like, “We have always done it this way,” or “That part’s not in our control.” These are real blockers. So, I try to keep the room neutral—no judgment, just curiosity. During a denial touchpoint review, I remember teams opening up about repeat manual work that felt pointless. It was not easy to hear at first, but we slowly shifted the conversation toward: What’s causing this, and how do we fix it together? That made a difference. Improve – Not just a fancy pilot So, you’ve got your ideas and now you’re testing them. But here is the thing people are not waiting for perfect; they want to know if the change makes their job easier. If it does not, they will quietly go back to the old way. I’ve seen it happen. For an RPA rollout in payroll, we involved the team right from design. After the pilot, we ran short check-ins to see what was working and what wasn’t. One user pointed out something the bot missed—and we fixed it the same week. That kind of feedback loop made people feel like they were part of the build, not just receivers of change. Control – Holding the line Once the numbers start looking good, the temptation is to move on. But without reinforcement, things fade fast. I have learned that even small routines help keep improvements alive. There was a project where we were pushing quality from 72% toward 95%. We introduced a basic dashboard to track progress, but more importantly, we acknowledged wins out loud. I remember when we first hit 90%—just a quick callout in the huddle, but the energy shift was real. That moment made the team want to hold on to the progress. If I had to sum it up: change isn’t about tools or templates—it’s about people feeling seen, heard, and involved. The rest follows.

In today’s rapidly evolving business environment, organizations are constantly under pressure to deliver faster, better, and more personalized services while controlling costs and navigating complexity. In the context of Healthcare BPO / RCM industry, where operational excellence is critical to ensuring timely reimbursements, accurate claim processing, compliance, and customer satisfaction. Traditional process improvement tools like Lean, Six Sigma, and RPA have helped eliminate bottlenecks and improve accuracy across front-end (example: patient access), mid-cycle (coding) and backend (AR follow-up, payment posting) functions. However, increasing complexity in payer rules, claim denials, unstructured documents (like medical records), and rising patient expectations are pushing the limits of traditional process improvement. AI technologies such as machine learning and NLP now offer an opportunity to not just improve, but completely reimagine how certain RCM processes work. The key challenge for leaders is knowing when to fix an existing process versus when to rethink it entirely using AI. Making the right call ensures optimal investment of time, technology and talent. When should a process be improved: Scenario Description and Example Stable and repeatable processes High volume, repetitive processes with consistent rules. Eligibility verification done via standard portals. Use RPA to automate screen scraping. Performance gaps exist Clear root causes and scope for waste reduction. Claim rejections due to incorrect modifier use. Use Six Sigma to reduce variation. Higher interdependencies Changes may affect upstream/downstream teams. Payment posting tied to specific clearinghouse formats. Standardize the templates to avoid disruptions. Low investment, High ROI Small optimizations yield fast results. Reduce manual touches in authorization status checks via scripting. Existing tools work well Tools like dashboards, audits, macros can solve the problem. Use Power BI to visualize claim age buckets and identify backlog trends. When should a process be reimagined with AI: Scenario Description and Example High cognitive workload Decisions involve data interpretation or unstructured content. Use NLP to extract denial reasons from payer PDFs or EOBs. Scalability barrier More volume = more headcount. Predict high-risk claims for denials using ML, instead of adding more resources in Quality team. Too many exceptions in the process Traditional rules-based automation fails. Claim status checks with multiple payer logics. Use AI bots that learn payer behavior. Process where real-time decisions needed The process must react quickly to data or events, delay in response might lead to missed opportunities. AI model to auto-route medical records for prior authorizations based on urgency/severity. AI can add unique value These are situations where AI does something that traditional process improvement or rule-based automation simply cannot because, a) the patterns are too complex for human detection, b) the data is too large or unstructured to process manually, c) the value comes from learning and adapting over time, which static systems can't do. In such cases, AI does not just make a task faster, it delivers new insights, predictions or capabilities that were not possible before. Using ML to identify root causes of denial trends before they spike.

How to Pick the Right Numbers: When I measure patient wait time, the temptation is to just pull what is easily available (example: Time from check-in to doctor consult). But that may miss important context or root causes. To ensure my metrics reflect the real process: Start with the SIPOC & Process Map This helps to visualize where delays happen, so I don’t just rely on one data point. May be the wait starts before check-in. Use the Voice of Customer (VOC) If patients complain “I waited for long time before anyone response me in helpdesk”, then I need to measure time from entry to first contact, not just from check-in. Focus on CTQs (Critical to Quality elements) Understand “What makes or breaks the experience?” A single long wait might impact satisfaction more than average wait times. Break Down the Wait Time into Key Components: Instead of measuring one overall figure, I would track: Time at registration Time waiting for nurse Time waiting for doctor This breakdown helps identify specific bottlenecks in the process. Balance Leading and Lagging Indicators Lagging: total wait time Leading: number of staff on shift, patient volume/hour This gives early warning signs. Tricks to Catch Bad or Incorrect Data Gemba Walk or Time Study I will observe the actual process for a few patients. Compare this to what is recorded in the system. Discrepancies are red flags. Check for Missing or Impossible Values Negative wait times? 0 minutes for a complex step? We could spot these using basic filters in Excel. Run a Control Chart or Histogram Early Abnormal spikes, flat lines or bimodal distributions might mean inconsistent measurement or data entry errors. Logical validate Compare time stamps from two sources. For example: EHR vs manual logs Front-desk data vs patient-reported times Use Operational Definitions Everyone must record data the same way. “Check-in time” must be clearly defined. When patients enter the door, or when they are logged into the system? Pilot Before Full Measurement I will try data collection method on a small sample. Fix issues before scaling. Quick Example: If we track only “average wait time” from EHR timestamps, but the nurse doesn't log start time until after triage, we miss the true wait. Solution: Add a “patient greeted” timestamp by the front desk as a new data point based on what we learned from process observation and VOC.