Last Updated: 29 September 2026
A hospital treats a patient, codes the visit and sends the claim to the insurer. When the insurer processes it, the claim may be denied, or it may be paid less than the contract requires. A single discrepancy is easy to overlook when a team is reviewing a large volume of claims. But a small discrepancy can point to a recurring problem across many claims. The stakes are real. According to figures published by SlicedHealth, roughly 10% to 15% of billed claims are underpaid by commercial payers, and nearly 65% of denials are never appealed. For rural and community hospitals working with thin margins and limited staff, that is revenue they have already earned and may never collect.
Founded in 2019 by Reese Walker and Reed Liggin, SlicedHealth builds software to close that gap. The Woodstock, Georgia company digitizes payer contracts, calculates what a hospital should be paid and compares that amount with what actually arrives. In late 2025, it launched SlicedIQ, an AI tool that lets revenue-cycle teams ask plain-language questions about contract terms, denied claims and appeal options, with insights drawn from contracts, claims data and relevant payer rules. SlicedHealth reports that it serves more than 140 hospital and health-system clients across 30 states, has analyzed over $2.5 billion in claims and has flagged millions in underpayments and contract variances.
Harshil Lodhiya, Chief Software Architect at SlicedHealth, leads the technical direction behind that platform. He designed Pattern Intelligence, an AI system that looks for groups of claims with similar payment problems instead of treating each denial or underpayment as a separate case. The goal is to surface payer, contract and workflow problems that can be difficult to identify when reviewing claims individually. His approach puts system design at the center of trust. As he puts it, "vertical AI trust is earned through the system design around the model." In other words, the evidence, checks and human review built around an AI model matter as much as the model itself.
The conversation explores a practical question: how do you build AI that teams can check, trust and act on? The interview examines why reviewing claims one by one can miss recurring issues, how Pattern Intelligence and SlicedIQ work together, what makes a detected pattern strong enough to act on, and what it takes to move AI from a prototype into daily hospital work. It also asks whether pattern intelligence can create more lasting value than a generic chatbot layer.
1. For readers unfamiliar with SlicedHealth, what does the company do, and what is your role as Chief Software Architect?
SlicedHealth helps hospitals make sure they are paid what their payer contracts say they should be paid. We digitize the contracts, calculate the expected reimbursement for a claim, and compare that expectation with the actual remittance. That gives revenue-cycle teams a concrete way to find underpayments, denials, and contract variances that can otherwise disappear in high claim volume.
As Chief Software Architect, I lead the technical direction behind that platform: the data and contract systems, the reimbursement logic, and the AI capabilities built on top of them. My job is not simply to put a model in front of users; it is to design a system that gives a hospital team evidence they can inspect and use in a real financial workflow.
2. What can hospitals miss when they review payment problems one claim at a time? Could you give an example of a recurring issue that is difficult to spot this way?
Claim-by-claim review is necessary, but it is a poor way to see a systemic issue. A reviewer may resolve or set aside a $25 or $75 difference without realizing the same payment behavior is occurring hundreds of times. The operational cost of investigating each small case separately can also make a meaningful aggregate opportunity look unworthy of attention.
For example, a payer may apply the wrong reimbursement logic to a particular procedure family when it appears with a specific modifier or place of service. Each remittance can look like an isolated variance. Across a population of otherwise similar claims, however, the repeated pattern can reveal a payer configuration issue, a contract interpretation issue, or a workflow problem that warrants one coordinated appeal strategy.
3. Where can AI help with these problems, and which decisions still require contract rules or human expertise?
AI is particularly useful for reducing the search space: grouping related claim outcomes, finding recurring signals across a large history, retrieving relevant contract and payer-policy language, and helping users summarize the evidence. It can make a team more likely to notice the issue that deserves expertise, rather than asking the team to manually scan every remittance.
It should not be the final authority on what a contract requires or whether an appeal should be filed. Expected reimbursement needs deterministic contract and reimbursement rules, and ambiguous clauses, incomplete records, clinical context, payer behavior, and appeal strategy require experienced people. In this domain, AI augments judgment; it does not replace accountable financial and operational decisions.
4. What is Pattern Intelligence, and how does it help hospital teams find recurring problems across large numbers of claims?
Pattern Intelligence is our approach to looking for cohorts of claims that share a similar payment outcome or discrepancy, instead of treating every case as a standalone event. It analyzes the attributes and outcomes around claims to identify groups that deserve a common investigation.
The output is not merely a list of “similar claims.” It gives a team a focused hypothesis: these claims appear to have a common variance, here is the scale and the supporting evidence, and here are the examples to examine. That lets a hospital prioritize patterns that may be recoverable at meaningful volume.
5. SlicedIQ lets users ask questions about contracts, denied claims, and payment discrepancies. How does it work alongside Pattern Intelligence and the tools SlicedHealth uses to calculate what a hospital should be paid?
The reimbursement engine provides the financial foundation: it calculates what the hospital should have been paid from the applicable contract logic. Pattern Intelligence uses the resulting claim and payment context to surface repeated discrepancies. SlicedIQ is the conversational layer that helps a user explore that evidence in plain language—such as asking what a clause means, why a group of claims was flagged, or what information may be relevant to an appeal.
Those capabilities are complementary, not interchangeable. A chat response should be grounded in the relevant contract, claim facts, payment data, and payer rules; a pattern should point back to concrete claims and calculations. The system is most useful when conversation helps users navigate verified operational evidence rather than asking them to accept an unsupported answer.
6. Pattern Intelligence examines many attributes of claims and their payment outcomes. At a high level, which types of details are most useful, and why is domain-specific context important when finding similarities in this data?
The most useful signals are the ones that explain how a claim was expected to be processed and how it was actually processed: clinical and coding context, service setting, relevant payment and remittance information, and expected-versus-actual reimbursement behavior. No single detail tells the story. The value comes from identifying combinations of information that consistently change reimbursement behavior.
We use domain-specific context because healthcare payment data has meaning that generic similarity methods cannot infer reliably. Two claims can look alike on a broad code or dollar amount yet follow different reimbursement rules; conversely, different-looking claims can share the same underlying issue. The important point is that payment and revenue-cycle expertise informs the analysis, without exposing the proprietary details of how those signals are represented or weighted.
7. The system uses HDBSCAN, a machine learning method that groups similar records without predefined labels. Why is that useful here, and how do you check whether those groups reveal a meaningful payment problem?
There is no need to use a sledgehammer to crack a nut. Large language models are powerful, but not every analytical problem calls for one. Well-chosen classical machine-learning methods can be more precise, easier to evaluate, and dramatically more cost-effective for structured, large-scale data. We can augment that analysis with an LLM where it adds real value—helping turn complex evidence into an explanation and decision support a user can understand—without asking it to do the underlying job of every component in the system.
We do not begin with a complete catalog of every payer error or denial pattern we expect to find. HDBSCAN is useful because it can discover dense groups of related claims without requiring us to pre-label all outcomes, and it can leave isolated records unclustered rather than forcing every claim into a group. That is a better fit for noisy, heterogeneous claims data.
A cluster is only a candidate finding. We test whether it has a coherent payment variance, sufficient volume and dollars, consistent supporting claim attributes, and an intelligible explanation under the relevant rules. We also inspect representative claims and compare the group with an appropriate baseline. The goal is not a mathematically neat cluster; it is a defensible operational issue.
8. When grouping similar claims, the system excludes the identity of the insurer and contract from its similarity calculation. What is the reason for that choice? At what point, if any, does that information become useful?
Including payer or contract identity at the clustering stage can make the system group claims simply because they share a label, rather than because they share meaningful payment behavior. Excluding those identifiers helps us discover patterns based on the underlying clinical, coding, operational, and financial signals. It also makes it easier to ask whether the same type of issue appears across contexts.
Payer and contract become essential after a candidate pattern is found. They help us evaluate the applicable reimbursement terms, identify where the pattern is concentrated, distinguish a contract-specific issue from a broader workflow issue, and frame the action the hospital should take. In short, they are powerful explanatory and prioritization variables, but not a shortcut for similarity.
9. A pattern is a starting point for investigation. What makes it strong enough to act on? How do you establish whether similar claims share the same underlying problem?
We look for convergence across several dimensions: a repeated and material variance, a consistent claim profile, a plausible rule-based explanation, and sufficient evidence that the cases are not coincidental. We also consider recurrence over time, the number of affected claims, estimated financial impact, and whether the team can act on the finding.
Establishing root cause means tracing the pattern back to source evidence. That includes the individual claims and remittances, expected-payment calculations, adjustment or denial codes, contract provisions, and—in some cases—the hospital’s own charging, coding, or authorization workflow. Similar outcomes are not enough; the evidence must support a common explanation before a team treats the group as one issue.
10. How do you decide which findings deserve a team’s attention? Small payment differences could add up, but investigating every anomaly could also create unnecessary work.
Prioritization is a balance of financial opportunity, confidence, recurrence, and actionability. A modest variance can be high priority if it affects a large, growing cohort and has a clear appeal path. A large single anomaly may be lower priority if its evidence is thin or if it cannot be resolved through a repeatable workflow.
We also account for the cost of human review. The product should concentrate a team’s time on findings where the aggregate value and evidence justify investigation, while preserving the detail needed to make a quick decision. The right metric is not the number of alerts; it is the number of useful, credible opportunities a team can turn into action.
11. What evidence can a user inspect to check a finding? And when the system presents a level of confidence, what does that tell the user about the result?
A user should be able to inspect the affected claims, the expected and actual payment amounts, the remittance and adjustment information, the shared attributes of the cohort, the estimated aggregate impact, and the contract or policy material relevant to the finding. Representative examples and a clear comparison with similar paid or non-flagged claims help the user validate the hypothesis quickly.
Confidence is an evidence signal, not a guarantee of recovery. It reflects how strongly the available data supports the pattern—for example, the consistency and separation of the group, the completeness of the evidence, and the strength of the rule-based explanation. It should help order review, not obscure uncertainty or replace a reviewer’s judgment.
12. SlicedIQ can explain contract terms and suggest steps for an appeal. How do you check the accuracy of those answers, especially when information is missing or contract clauses conflict?
We ground answers in retrieved source material and make that evidence available to the user. For payment questions, the answer should align with the relevant contract language, claim facts, expected-payment calculation, and payer guidance rather than relying on the model’s general knowledge. We evaluate the system with realistic questions and known answer sets, including ambiguous terms, exceptions, and conflicting clauses.
When material is missing or provisions conflict, the right behavior is to surface the ambiguity, identify what evidence is needed, and route the issue to a qualified reviewer—not to manufacture certainty. Clear boundaries, source attribution, and escalation paths are essential because an appealing-sounding answer is not the same thing as a defensible one.
Each chatbot is provisioned with additional customer-specific context, including supplementary materials and policies supplied by the customer. Those materials serve as the relevant ground truth for its responses, so the system can address questions in the context of that organization’s documented rules and practices rather than relying solely on general information.
13. What changed when Pattern Intelligence moved from a prototype into real hospital workflows? Were there assumptions you had to reconsider?
A prototype can optimize for whether it finds interesting groups. Production has to optimize for whether users can trust, understand, and act on them. That meant investing more in data normalization, explainability, evidence views, performance, permissions, repeatable refreshes, and workflow integration than the initial clustering experiment alone would suggest.
We also had to treat “interesting” as a much higher bar. Hospital teams work under real time constraints and have deep domain knowledge; they need fewer, better-supported findings and an easy way to disagree with them. The product improves when feedback is treated as part of the system design, not as an afterthought after model deployment.
14. Claims data may be incomplete or recorded differently across hospitals. How do you assess whether the data is reliable enough for the system to draw useful conclusions?
We do not treat every claim as equally ready for analysis or appeal. The system applies internal quality benchmarks to assess whether the claim record is sufficiently complete, whether a corresponding remittance has been received, and whether the expected-versus-actual payment comparison is reliable. It then uses confidence and variance-error thresholds to focus on claims where the available evidence supports a meaningful conclusion.
That filtering is intentional. We want to surface high-quality, actionable opportunities—not create noise from incomplete claims, unresolved processing states, or weak payment comparisons. By concentrating on completed claims with remittance evidence and a credible discrepancy, we give hospital teams a stronger basis for deciding whether an appeal or further investigation is worth their time.
15. Processing historical claims, organizing data for analysis, and updating patterns all take computing resources. Which part has been hardest to keep reliable and affordable as usage grows?
The hardest problem is usually the end-to-end data pipeline, not the clustering call by itself. Historical claims and remittances arrive in varied formats, must be reconciled with contract logic and changing reference data, and need to remain traceable after each refresh. If that foundation is late, inconsistent, or hard to reproduce, even a strong model becomes operationally unreliable.
16. Once the AI flags a problem, what happens next for the hospital team? Where is human review needed, and has feedback from staff led you to change the product?
The flag begins a review workflow. A revenue-cycle management analyst examines the affected cohort and source evidence, validates the expected payment and applicable contract terms, decides whether the issue is a payer variance or an internal process problem, and then takes the appropriate action—such as appealing, correcting a claim, escalating a payer issue, or changing a workflow. Humans are most needed at interpretation, prioritization, and the decision to submit or pursue an appeal.
17. As general AI models improve, what would show that Pattern Intelligence offers lasting value beyond a chatbot with access to the same claims and contracts? What lesson from building it would you pass on to someone developing AI for another industry?
Lasting value comes from bringing three things together: capable AI, expert human judgment, and a product foundation built for the domain. AI makes it possible to detect patterns, synthesize large volumes of information, and make complex evidence easier to use. Human expertise supplies the context, accountability, and decision-making that high-consequence financial workflows require. The product’s normalized data, contractual and financial logic, workflow integration, and audit trail connect those strengths into a system that can calculate expected payment, identify population-level issues, prioritize work, and support recovery.
Scale is a practical test of that value. Across hundreds of clients, millions of historical and incoming claims, and large contract libraries, sending every record and document through a general-purpose model would consume substantial time and tokens—and it would be difficult to make that process timely, predictable, or economical for daily operations. Pattern Intelligence applies purpose-built data processing and analytics to continuously narrow and structure the problem, then uses AI where it provides the most value. That allows the system to operate efficiently at scale while still giving users useful, realtime, and evidence-based answers.
The broader lesson is that vertical AI trust is earned when all three elements reinforce one another. Start with the decision a customer must make; build AI that is grounded in reliable source evidence and domain logic; give experts clear control and visibility; and measure outcomes rather than novelty. The model is essential, but it achieves its full value when it is paired with the right people and product architecture.
