How to Make Unstructured Payment Rules Queryable for Explainable Claims Review
Improper payments are not always visible from the claim alone. The real answer often sits inside the rules that decide whether that claim should have been paid in the first place.
That is where payment integrity gets messy. The rules are spread across coverage policy documents, procedure codes, diagnosis codes, and overlapping rule conditions.
In this Community Call, Previsant Insights co-founders, Satya Sachdeva and Doug Ramsey, walked through how their payment integrity platform tackles that problem with Memgraph. The platform ingests source documents, uses LLM-driven extraction to identify rules, stores the resulting entities and relationships in Memgraph, and applies that rule knowledge to claims review with explainable evidence.
Missed the live session? Watch the full Previsant x Memgraph Community Call recording to see the architecture walkthrough, live demo and Q&A.
Here are the key takeaways.
Key Takeaway 1: The Real Bottleneck Behind Waste and Abuse Detection
Claims data is usually structured. The rules used to judge those claims often are not. That creates the first bottleneck for waste and abuse detection. Before a team can review claims at scale, it needs to know which rules apply and where the evidence lives.
In the Medicare Supplement scenario covered in the demo, payment decisions depend on information buried inside payment and coverage documents. Those documents define what should be paid, what should not be paid, and under what conditions.
For an analyst, the question is not only “does this claim look wrong?”
The more useful question is, “which rule applies here, and what supports that decision?”
That is hard when one document allows a procedure for a diagnosis, another adds conditions, and another prohibits a modifier for a procedure code. If those rules stay trapped in separate documents, analysts have to connect the dots manually. That does not scale.
Key Takeaway 2: The Knowledge Extraction Layer
Previsant’s platform starts by ingesting source documents and claim records.
The documents include PDFs, CSV files, text and web content. The claims data is structured, while the rules live in unstructured or semi-structured documents.
The platform uses an ingestion and extraction layer to identify rule entities from those documents. This is the step where the platform starts turning unstructured rule documents into structured rule knowledge.
The goal is not to make the LLM “decide” whether a claim is valid.
The goal is to extract the rule knowledge hidden in the documents so it can be reviewed, modeled, queried and applied later.
That includes rules such as:
- Medical necessity rules
- Billing rules
- Coding rules
- Duplicate claim or procedure rules
This step is where raw documents become usable rule knowledge. But extracted rules alone are not enough. The system still needs to understand how those rules connect.
Key Takeaway 3: Storing the Rule Relationships
After extraction, the next challenge is connecting the rules to the claims they affect.
A payment decision usually depends on how a procedure code connects to diagnosis groups, modifiers, medical necessity rules, exceptions, and rules from other documents. Finding one relevant paragraph is not enough when the answer depends on several connected conditions.
This is where Memgraph carries the relationship layer.
Previsant stores the nodes such as providers, procedures, diagnoses, and rules, along with their relationships in Memgraph, then links that rule structure back to claims data and supporting evidence. That lets analysts move beyond basic document search and ask relationship-driven questions, such as:
- Which rule applies to this claim?
- Which diagnosis code is required for this procedure?
- Which rule explains the denial reason?
- Which document text supports the decision?
The point is not to replace document retrieval. It is to give the rule network a structure that analysts can inspect and query.
Key Takeaway 4: RAG, Graph, and Hybrid Querying Serve Different Jobs
Previsant does not treat RAG and graph as competing choices. The platform uses both because each one solves a different part of the workflow.
ChromaDB stores document chunks for questions over unstructured text. Memgraph stores the resulting entities, rules, and relationships. The LLM layer sits on top and supports three query modes.
- RAG mode answers questions over selected documents.
- Graph mode answers questions over relationships stored in Memgraph.
- Hybrid mode combines document content with graph context.
That separation makes the workflow practical.
When a user asks about documentation requirements for billing, a document-grounded answer may be enough. When a user asks for all rules associated with a procedure code and the required diagnosis groups, the graph becomes necessary. When a user asks about prohibited modalities or rule conditions across documents, hybrid querying can bring the source text and relationship context together.
The demo also showed that natural language questions can be converted into Cypher for graph queries, with results visible in JSON format.
That gives users a plain-language interface without hiding the technical layer underneath.
Key Takeaway 5: Defining the Graph Model
A graph is only useful if the model behind it is useful.
That is why the demo showcased the schema configuration before query examples.
The application lets users define what should be extracted and stored in Memgraph. In the schema configuration, the examples shown included entities like medical articles, CPT codes, diagnosis codes, medical necessity rules, and code groups.
It also lets users define relationships. For example, a procedure code may cover a set of diagnoses.
Then comes the detail that can make or break document-heavy extraction work: Synonyms. Different documents may use different terms for the same concept. Procedure code, CPT code, and HCPCS code can refer to closely related coding concepts in this workflow. If the system treats every term as separate, the graph becomes noisy fast.
Previsant’s platform lets users define synonyms so equivalent terms can map to the right concept in the graph.
That is not a nice-to-have. It is basic graph hygiene.
If your schema is vague, your graph will be vague. If your relationships are unclear, your queries will be weak. If synonyms are ignored, your graph will fragment concepts that should be connected.
Start with the model. Then build the graph.
Key Takeaway 6: How the Audit Engine Supports Explainability
Extracted rules only matter if the system can apply them. Previsant’s audit engine applies the extracted and modeled rules against claims data and shows which claims pass or fail based on those rules.
In the demo, the platform had:
- 1,007 claims scanned
- 5 denied claims
- 1,002 passed claims
- 26 rules used
The dashboard showed which claims were denied and the reason behind each denial.
The denial reason is the important part. A payment integrity workflow cannot stop at “deny this claim.” It needs to show the rule, the relevant document text, and the relationship that supports the decision.
That is what makes the output useful for an analyst. The value is not just finding a claim that needs review. It is giving the team enough evidence to act on it.
Key Takeaway 7: Human Review Keeps the Rule Set Usable
Rule extraction should not become a black box. Previsant’s platform includes a rules management step where domain experts can review the rules discovered from unstructured documents.
They can inspect what was found, fine-tune the rules, adjust them, or remove rules that do not make sense for the workflow.
That matters because payment integrity is too sensitive for blind automation. A weak rule can create noise. A missing condition can lead to a bad denial. A duplicate or poorly classified rule can waste analyst time.
The goal is not to remove the human from the loop. It is to give analysts and business experts a better starting point, with the extracted rule knowledge organized enough to review and apply.
Key Takeaway 8: The Same Pattern Applies Beyond Payment Integrity
The walkthrough focused on Medicare Supplement payment integrity, but the pattern applies anywhere decisions depend on rules buried in source documents.
Healthcare teams could apply similar graph-backed workflows to prior authorization, clinical knowledge graphs, administrative cost reduction, or connecting clinical data with policy and claims guidance.
The same pattern can also apply outside healthcare. Property and casualty insurance, private equity, retail, and banking all deal with rule-heavy documents and decisions that depend on relationships between entities.
The common thread is simple. If your rules live in documents, and your decisions depend on how those rules connect, document search alone will not be enough. You need a graph that can represent the relationships.
Wrapping Up
Previsant’s payment integrity platform shows what it takes to make waste and abuse review practical at scale.
The work starts with source documents that contain payment and coverage rules. Those rules need to be extracted, connected across documents, applied to claims, and traced back to evidence that a human can inspect.
Memgraph acts as the graph layer for that workflow. It stores the extracted rules, entities, relationships, conflicts, and context needed for explainable claims review.
Watch the full Previsant x Memgraph Community Call recording to see the demo, architecture walkthrough, and Q&A in more detail.
Q&A
Here’s a compiled list of the questions and answers from the community call Q&A session.
Note that these are paraphrased slightly for brevity. For complete details, watch the full community call recording.
- What Drives Organizations to Look for Explainability and Auditability?
- The major driver is cost leakage. There is an estimated 9% to 13% claims tax, meaning claims coming through that should not be paid. That leakage affects carriers, consumers, pricing, risk profile, and actuarial performance. The goal is not always to prove intent. Sometimes a claim is wrong because someone made a mistake. The system still needs to find it, explain it, and support the next action.
- What Should Teams Keep in Mind When Starting With Memgraph?
- Start with a good model. Before building the graph, decide what you want the graph to store and what you do not want it to store. Define the relationships clearly. Handle synonyms early. Memgraph gives teams flexibility, but flexibility does not replace graph modeling discipline.
