Skip to main content

Fix validation issues

Outcome

Charges sitting at NEEDS_FIX are diagnosed, fixed (upstream where possible, in-app where necessary), re-validated, and they advance to VALIDATED ready for billing.

Prerequisites

ScopeWhat it lets you do
billing.charge.readView the worklist
billing.charge.writeEdit a charge inline
billing.charge.revalidateRe-run the validator without editing

The validator's job

The platform's validation pipeline runs after mapping. Its rule set is configured per tenant; common rules:

Rule kindExample
member_matchThe MRN on the inbound resolves to exactly one member.
coverage_requiredThe member has active coverage on the DOS.
auth_requiredA program-flagged service has an active authorization.
service_taxonomyThe procedure code is mapped to a recognized service.
unit_rangeUnits fall within the procedure's MUE band.
place_of_servicePOS is allowed for this procedure.
provider_credentialThe rendering provider has the credential the program demands.

A failing rule writes an issue on the charge with three fields:

FieldWhat it tells you
codeThe rule that failed (e.g. auth_required).
messageOne-line explanation.
fieldThe data field at fault, when known.

The fix flow

Common patterns and the fix

IssuePatternFix
member_matchThe inbound MRN doesn't match a memberSearch for the member (Member detail); attach via Resolve member.
coverage_requiredMember exists, but coverage is null on DOSRefresh eligibility — see 2.4. If still null, member is uncovered; tag for clinical review.
auth_requiredNo auth covers this DOS / unitsAttach an existing auth or request a new one — see 2.5.
unit_rangeUnits exceed MUEConfirm the units the EMR sent. Often a unit-of-measure mismatch (per-15-min vs per-hour). Edit if confident.
service_taxonomyProcedure code unknownLikely a stale code-set version; route to admin to refresh /admin/code-sets.
provider_credentialRendering provider missing credentialProvider record needs the credential added (Tenant Manual → Members & Providers).

Steps

  1. Filter to NEEDS_FIX. Open /charges?status=NEEDS_FIX. Sort by oldest first.

  2. Open a row. The inline drawer's Issues section lists every failing rule with the field at fault.

  3. Decide where the truth lives:

    • Upstream wrong → log a ticket with the EMR / source team; re- ingest will overwrite.
    • Mapping wrong → tag mapping-suspect; admin owns the mapping.
    • Eligibility / auth → use the dedicated chapters (2.4, 2.5).
    • Honest in-app correction → click Edit and change the field. See 2.6.
  4. Re-validate. Click Re-validate. If issues clear the charge flips to VALIDATED; if they don't the new issue list points to what's still wrong.

Bulk re-validate

Selecting many NEEDS_FIX rows and clicking Bulk re-validate re-runs the validator without editing — useful after:

  • A code-set refresh.
  • An admin updates a validation rule (e.g. raises an MUE).
  • Eligibility cache refreshes for a payer.

The platform processes them with the same rule set; you don't have to walk one-by-one.

Validation

CheckExpected
Editing a field clears the related issueYes after re-validate.
Re-validate is idempotentYes — multiple runs don't compound state.
Bulk re-validate emits one audit row per chargeYes; visible on each charge's history.
Tags persist across re-validationYes.

Troubleshooting

SymptomCauseFix
Re-validate doesn't clear an issueUnderlying data still fails the ruleRe-read the issue; the field hint usually points at the right place.
Edit field is read-onlyEither you lack billing.charge.write or the charge is BILLEDReverse the claim first.
New issue appears after editA rule we didn't fail before now fails (e.g. you changed the procedure code and tripped service_taxonomy)Re-read; the new issue is real.
Charge keeps flipping back to NEEDS_FIXUpstream re-ingestion overwrites your fixCoordinate with EMR team; either change at source or hold the charge while you bill.

Where to next