Ready evidence for payment integrity, audit, and RADV

The request is in. The file that would answer it is still a search.

A payment question, an investigation, a risk adjustment data validation request, or an audit letter arrives on a clock the team does not set. The decision may already be recorded. The complete evidence behind it often is not. Claims, clinical documentation, pharmacy activity, provider review, and earlier rule versions sit in systems that were never asked the same question together.

The week that follows is familiar to finance, payment integrity, fraud investigation, compliance, and audit. Someone searches, reconciles history, gathers documents, and assembles a record under a deadline. A payment analyst cannot see the action, the parties, the rule version, the supporting facts, the decision owner, and the source in one place. An investigator starts by rebuilding the encounter. Audit response becomes a hunt for whether the documentation existed.

The same gap shows up before money moves. A claim, a risk-adjustment submission, or a provider action can proceed while a required document is still missing, because that gap is not visible at the moment of the decision. That is the operating situation. It is not a recovery total, and it is not a result for a named organization.

Signals arrive faster than a defensible record.

Healthcare organizations take in signals from claims analytics, clinical documentation, provider reviews, pharmacy activity, fraud detection, risk adjustment, program oversight, and audit activity. A claim anomaly, a documentation gap, a provider concern, a pharmacy issue, an audit request, or a program-integrity finding can each require a payment action, an investigation, a recovery, a dispute response, a referral, or a regulatory answer. When that moment arrives, the supporting evidence is frequently spread across rules, documents, and earlier decisions. Teams search systems, research rules, reconcile history, gather documents, and assemble a record under a deadline they do not control.

The proof page describes that reconstruction as slow, manual, inconsistent, and costly, and as something that makes decisions harder to explain or defend. Investigations take longer. Recovery waits on a file nobody can quite assemble. Audit response becomes a fire drill. This article uses that description as the problem. It does not convert it into a dollar figure, a recovery rate, or a result for a named organization. The public aim is faster, traceable, and defensible healthcare decisions. Those words describe the standard the work is built toward. They are not a published savings total.

The domains the site names are payers, providers and health systems, pharmacy and pharmacy benefit managers, and government and healthcare programs. The operational teams named alongside them include finance and payment operations, fraud investigation, and compliance, risk, and audit. The decision and the audience change. The need does not. Payers need evidence behind claims and payment decisions, payment integrity, fraud investigation, recovery, provider network actions, risk adjustment, audit, and compliance. Providers and health systems need it behind coding, clinical documentation, revenue integrity, payer disputes, quality decisions, and the findings that support contracting, credentialing, tiering, or another provider action. Pharmacy needs it behind formulary decisions, rebates, pharmacy claims, network management, utilization review, recovery, and regulatory response. Government and program teams need it behind oversight, grants, audits, investigations, referrals, and administrative decisions. Complete, traceable, defensible evidence is the common requirement.

A proof record is the basis of the decision, not another alert.

A healthcare proof layer, as this site describes it, connects the data, the checks, the decisions, and the supporting evidence into one traceable record that is maintained as the work happens. It complements the systems that detect, adjudicate, score, and execute. It does not replace claims administration, payment integrity tools, clinical systems, provider and pharmacy data, scoring models, or compliance policy. Those systems still generate the signals and the decisions. The proof record preserves the basis of the action so a later reviewer is not starting from a blank page. Existing systems can identify a signal, score a risk, or record that something was decided. They do not, by themselves, keep the explanation in a form the next team can use.

The record the site describes has six parts. The decision: what happened, when, and the financial, clinical, or operational consequence. The parties: the organization, provider, member, patient, pharmacy, ordering entity, or program participant involved. The controls: the rules, policies, models, versions, thresholds, and exceptions that informed the decision. The evidence: claims, clinical records, pharmacy data, source documents, and supporting facts. The decision owner: the rule, model, analyst, clinician, investigator, or other authority responsible. The provenance: source, timestamp, version, integrity, and custody history. Leave one of those out and the file may still look complete to the team that built it. It will not answer the question a later reviewer actually asks, which is why this action was taken, on what basis, by whom, and from which version of the rule.

The underlying evidence can stay consistent while the record is organized for the audience in front of it. The same evidence core can support pre-payment review, recovery, investigation, audit, risk adjustment data validation, appeal, a provider action, a regulatory response, or legal review. The point of keeping it continuously is that the organization is not rebuilding the case from the beginning each time the audience changes. A payment reviewer, an investigator, and an audit response team should not need three incompatible stories of the same encounter. They need one record that can be read for the decision each of them has to make.

Prevent, pursue, and defend.

The business framing on the site is prevent, pursue, and defend. Prevent means seeing missing, conflicting, or unsupported evidence before paying, holding, denying, scoring, approving, or referring. The proof is created before the organization acts, which is a different posture from explaining a decision after someone has already challenged it. Pursue means connecting facts, rules, history, relationships, and financial exposure so an investigation, recovery, recoupment, escalation, or correction has a basis. A signal becomes a substantiated action only when those pieces travel together. Defend means keeping the basis of a payment, provider, pharmacy, network, risk adjustment, audit, appeal, or regulatory decision so the organization can show why the action was appropriate. Different decisions, different actions, one continuously maintained evidence foundation. This page does not attach a savings total to any of the three.

That framing also says what the proof layer is not. It is not another alert stacked on the alerts the detection tools already raise. An alert says something may deserve attention. A proof record says what was done, why, and with what support. Action-ready operations still belong to the organization: hold or pay, investigate, recover, remediate, correct, refer, disclose, or defend. The record makes those actions explainable. It does not take them away from the teams who own them. Embel Assist's work is to help the organization decide where that evidence capability is worth making operational, then to fit it to the data, systems, workflows, governance, and operating model already in place.

RADV is one use of a broader evidence practice.

A risk adjustment data validation request asks for source documentation that a submitted diagnosis was supported at the time of care. It names particular encounters and codes. It does not ask whether the organization generally does careful work. The response clock starts when the request arrives, not when the record has been found. An organization that can only answer by searching manually across systems that were never designed to be queried together is working against a deadline that was not built around its process. The teams that respond in an orderly way are usually not inventing a new method on the day the letter arrives. The connection between the diagnosis, the encounter, and the supporting documentation was kept as decisions were made.

The site lays out four moves. Correlate: keep payment-driving diagnoses and encounters connected to the supporting clinical documentation. Detect: find unsupported diagnoses, missing attestations, documentation gaps, and other items that need review. Package: assemble what is needed to support, correct, repay, or investigate further. Act: route the encounter to defend, correct, repay, or investigate. Documentation strength and potential exposure can be understood before the request arrives only if that connection was built in advance. RADV is one application of the broader evidence capability. The same muscles serve payment review, investigation, appeal, and audit. A written policy is not the same thing as a retrievable record of a specific decision. When evidence lives in several disconnected places, a question that should be answerable from the record becomes a project of manual reconciliation.

What ready looks like on an ordinary day.

Ready evidence is not a binder assembled the week a letter arrives. It is a record a reviewer can open while the decision is still fresh and find the six parts in one place. A payment analyst should be able to see the action, the parties, the rule version, the supporting facts, the decision owner, and where those facts came from, without asking three other departments to export spreadsheets. An investigator should be able to start from the same core and add the relationships and exposure the case needs, rather than rebuilding the encounter from scratch. An audit response should be a retrieval and a packaging step, not a search for whether the documentation ever existed. If those readers still begin with a hunt, the proof layer is not yet operational, whatever the architecture diagram says.

The same test applies before money moves. If a claim, a risk-adjustment submission, or a provider action can proceed while a required document is missing, the prevent step has not been wired to the decision. Holding, paying, denying, scoring, approving, or referring should be able to see that gap first. That is a workflow change, not a report scheduled after the fact. Embel Assist's implementation work is aimed at that change inside the client's environment: the record is produced as the work happens, the teams who act can see it, and a later challenge does not require a new research project.

What Embel Assist takes on.

Embel Assist helps organizations choose the priority decision or workflow, assess how evidence is reconstructed today, and define what value a ready record would change in that slice of work. Design then names the proof record, the approved sources, the system connections, the controls, the users, and the actions the record must support. Approved sources can include claims, clinical documentation, provider and pharmacy data, policy, model versions, and history. The architecture has to say how the proof layer sits beside detection, adjudication, scoring, clinical workflow, payment, and reporting, without pretending to replace them. The operating model has to say how evidence moves into review, investigation, recovery, audit, correction, repayment, referral, appeal, or defense, and which teams share the record.

Implementation configures and tests the capability in the client-controlled environment, aligned to the identity, access, monitoring, security, governance, and data controls the organization already uses. Cross-functional handoffs matter here. Clinical, finance, payment integrity, fraud investigation, compliance, audit, provider network, pharmacy, legal, and operational teams cannot each keep a private version of the story. Operational readiness sets ownership, training, monitoring, reporting, and support so the record is used on ordinary days, not only when an audit is announced. Later optimization extends the same evidence foundation to additional decisions rather than standing up a separate reconstruction process for each one.

A practical start is one contained workflow, an accountable owner, and success measures the organization defines for itself. The site's examples of that first slice include a retrospective review of high-risk claims, a focused risk adjustment data validation readiness cohort, provider-performance or network-action decisions, and an audit or recovery workflow that today depends on significant manual reconstruction. Begin there. Show that the record can be produced as the decision is made. Then extend it. Proof, in the sense this challenge uses the word, is how an organization stands behind what it knows when action, review, or defense is required. Embel Assist's role is to make that capability operational. It is not a shortcut around the systems, policies, or professional judgment the organization already relies on.