A coding finding ages badly when its rationale lives only in the original reviewer’s memory.
Set the product demo six months after a fictional audit. The reviewer has changed jobs. A replacement auditor receives only the case identifier and must explain why the claim was flagged, which rule version applied, who resolved the disagreement, and whether the correction reached its destination.
That future-date exercise is a demanding medical coding audit software evaluation. The product has to preserve a decision, not merely display one.
The durable unit is the finding record
For each audited claim, the system should connect five kinds of evidence.
| Evidence | What the buyer should inspect | Failure signal |
|---|---|---|
| Source | Note version, order, report, claim data, payer response | A reviewer cannot tell which record was examined |
| Rule | Named rule source, version or effective date, and relevant section | The finding says only “policy mismatch” |
| Finding | Specific code, modifier, unit, diagnosis link, or documentation issue | A generic risk score replaces an explainable issue |
| Decision | Reviewer, timestamp, disposition, rationale, and escalation | An override erases the original finding |
| Closure | Correction, resubmission or education action, owner, and proof | A closed status has no downstream evidence |
The FY 2026 ICD-10-CM guidelines say that the classification’s conventions and instructions take precedence and stress the need for consistent, complete record documentation (CMS and NCHS). For Medicare procedure coding, CMS publishes the NCCI manual and edit resources, while warning that the edits do not cover every possible incorrect combination (CMS NCCI manual, CMS NCCI FAQ). A useful audit record therefore names the authority it used instead of presenting every flag as universal truth.
Run a five-artifact acceptance test
Bring synthetic records modeled on the services you actually bill. Include a clean claim, an ambiguous case, a documented correction, a case affected by a rule update, and a record with missing support. No real patient data is needed for the first product test.
Ask the vendor to produce these artifacts from the exercise:
- The immutable input packet and its ingestion time.
- The finding with the exact rule reference and effective date.
- The review record, including a permitted disagreement and escalation.
- The corrected output without deletion of the prior state.
- A portable export that another auditor can understand without the vendor’s interface.
Reject a demo that substitutes screenshots for exportable evidence. Screenshots may help a reviewer orient themselves, but they are poor material for filtering, reconciliation, or a later independent review.
Force rule precedence into the open
Coding reviews often involve more than one authority. A claim may touch the current diagnosis-code instructions, procedure-code guidance, a payer’s coverage rule, an NCCI edit, a contract term, and an internal workflow policy. Those sources do not all have the same scope.
Give the vendor a collision scenario. For example, let an internal rule lag behind a newly effective official instruction. Ask which rule fires, who can change the precedence, how the change is approved, and whether old findings retain the rule version that produced them.
The answer should be visible in the product, not buried in an implementation consultant’s memory. Versioning also needs an effective-time model. A rule published today may govern service dates next month, while a retrospective audit may examine claims from a prior code year.
Keep suggestions separate from decisions
Software may identify a possible diagnosis code, modifier issue, or documentation gap. That output is a review prompt. It is not proof that the suggested code is supported or that the claim should be changed.
Use three explicit states:
| State | Meaning | Required actor |
|---|---|---|
| Suggested | The system found a candidate issue or code | None yet |
| Reviewed | A qualified reviewer compared the suggestion with the record and rules | Named reviewer |
| Approved | The organization authorized a defined downstream action | Named approver under local policy |
Do not allow a suggestion to become an approved correction merely because nobody answered it within a timer. Silence is not clinical or coding evidence.
Test the sample, not only the model
An audit result is shaped by the claims selected for review. A product can find many issues in a narrow high-risk pool and still tell you little about the wider population.
Ask for a sampling record that preserves:
- the eligible population and time period;
- every inclusion and exclusion rule;
- the random seed or repeatable selection method when sampling is random;
- targeted strata such as modifiers, denials, new services, outliers, or high-volume codes; and
- the denominator used for every reported rate.
Keep baseline and targeted findings separate. If the product combines them into one percentage, a buyer may mistake a risk-enriched sample for an organization-wide estimate.
OIG’s General Compliance Program Guidance describes compliance guidance as voluntary and nonbinding, while presenting infrastructure for health care compliance programs (HHS OIG). That distinction is useful in product design: a tool can support a compliance process, but its presence does not prove that the process is effective or that every finding is correct.
Watch the reviewer workflow under pressure
A polished queue can hide weak controls. Run the test with two reviewers who disagree.
The first reviewer should document a rationale and request a correction. The second should reject it based on a different rule interpretation. The software should preserve both positions, route the dispute to the right owner, prevent unauthorized closure, and show the final reason without overwriting history.
Then remove one reviewer’s access. Confirm that prior actions remain attributed to that person and that the account can no longer open protected records. Export the audit packet after the access change. If the export loses actor identity or translates it to a generic “system user,” the evidence chain is incomplete.
Demand a usable correction loop
Finding issues is only the first half of an audit program. The other half is learning what changed.
Track correction types separately: claim amendment, documentation education, rule configuration, workflow change, payer inquiry, and no-change decision. Give each an owner and due date. Re-sample the affected category later using documented criteria.
Do not let the software claim that education worked because someone opened a module. The defensible evidence is a defined follow-up sample and its reviewed outcomes.
Score the product on later reconstruction
Use a scorecard built around work your team must perform after the sale.
| Test | Pass condition |
|---|---|
| Claim reconstruction | An independent reviewer can trace source, rule, finding, decision, and closure |
| Rule currency | Versions and effective dates remain visible on old and new findings |
| Human approval | Suggestions cannot silently become final corrections |
| Sampling integrity | Population, selection logic, strata, and denominators are preserved |
| Access change | Deactivated users lose access without erasing attribution |
| Export | Structured data and readable evidence leave the platform together |
| Re-review | The system supports a documented follow-up sample and comparison |
Set pass conditions before the demo. Otherwise, a feature tour will define success after the fact.
The Patient Square boundary
Patient Square’s public US pricing describes ICD-10 suggestions as part of its clinical documentation workflow and lists EHR-ready export formats (Patient Square pricing). Those statements do not establish an autonomous coding engine, a final coding decision, automatic claim submission, payer approval, or a complete audit program.
If the documentation step is part of your evaluation, treat every suggested code as review material. Keep the signed note, current coding sources, payer rules, and qualified reviewer in the decision path.
Review the published product scope.
A medical coding audit software purchase should end with a later-reconstruction test, not a feature count. If a replacement auditor can reopen one finding, see the governing evidence, understand the disagreement, and verify the correction, the product has supported the work. If they cannot, the record did not survive its first reviewer.