Download and run

The workbench is one HTML file with no build step, no package manager and no server. Everything — the parser, the hundred validation rules, the repair engine, the redaction layer and the search index — is inside it.

Requirements

• Any current browser: Chrome, Edge, Firefox or Safari.
• Works with no network connection. Two things degrade gracefully without one: the page falls back to system fonts, and PDF import is unavailable. Everything else — parsing, validation, repair, redaction and search — runs unchanged.
• No installation, no account, no admin rights.

One tool, two transactions

The workbench detects what you paste. A claim switches it into validation mode, headed 837P claim; a remittance switches it into denial mode, headed 835 remittance. There is no setting and no second download, because the parser, the redaction layer and the knowledge base are shared. Keeping them together also matters in practice: a denial that says the authorization was not carried on the claim is something you will want to check against the claim, in the same session.

Reading remittances

Paste an 835 and the tool switches to a denial report rather than a validation report. There is nothing to validate on a remittance, because it came from the payer — so instead it decodes every adjustment, explains what it means, marks whether it is appealable, and ranks the whole thing by dollars at stake. Press Denial remit in the editor toolbar to see it with a sample.

Reference files you supply

Two things you supply make the remittance report substantially more useful. Your contracted fee schedule, as a CSV with a procedure code column and an allowed amount column, lets it flag lines paid below contract. The CMS Procedure-to-Procedure edit file, published free and updated quarterly, lets bundling denials show the modifier indicator for the pair — which tells you whether a modifier can legitimately override the edit, or whether appending one would be inappropriate.

Download the Practitioner edit file, not the Hospital one. The same code pair can carry a different modifier indicator in each, and the practitioner set is the one that matches professional claims. If the download is a spreadsheet, save it as CSV before loading. The reader tolerates title rows above the header, tab or comma separation, and the legend text CMS embeds in the modifier column heading; if it cannot find the columns it will tell you which ones it did find.

Any other transaction type — 270, 271, 276, 277, 278, 820, 834, 997 and 999 — is refused with an explanation rather than being checked against claim rules it was never meant to satisfy. The same applies to 837 Institutional and 837 Dental, which are identified by their implementation guide and refused rather than measured against Professional rules.

Hosted or downloaded?

Both run the same code. Opening it at /tool runs it in that browser tab. Downloading it runs it from your own disk. Nothing about the privacy behaviour differs, because in both cases the code executes in your browser and no claim data is transmitted.

The hosted copy is served with a Content Security Policy that names every origin the browser is permitted to contact. You can verify it: open developer tools, watch the network tab, and paste a claim. Nothing leaves. That restriction is enforced by the browser rather than asserted by us, which is a stronger guarantee than any statement in this documentation.

The downloaded copy is the better answer when IT wants to review the code, host it internally, or run it on a machine with no internet access at all.

Is there a Mac or Windows version?

There is one file and it runs on both, because it runs in the browser rather than as a native application. The download page shows opening instructions tailored to your operating system, but the file you receive is identical either way. Verify it with the SHA-256 checksum published on the download page.

Running it

Save claim-workbench-1.3.0.html and double-click it. To share it with a team, drop it on a network share or serve it from any static path. Because there is no server component, hosting it is only file hosting.

Quickstart

The workbench opens with a valid claim already parsed, so you can read the output before pasting anything of your own. Whatever you paste is de-identified as it is read; there is no setting to check first.

The interface

The left column is your input and the right column is the report. Four tabs across the top of the left column:

Resizing the panes

The divider between the two columns can be dragged to give either side more room, anywhere between roughly a quarter and three quarters of the width. Double-click it to return to the default split. A short claim rarely needs half the screen, and the wire view often wants more than half. On narrow screens the layout stacks and the divider is hidden.

The report

The right column shows, in order: what the shield redacted, the accept or reject verdict, the interchange envelope, every validation finding, the available repairs, the claim rendered as a CMS-1500 faceplate with real box numbers, the service lines, and the hierarchical structure.

Input formats

Everything is converted to X12 before validation, so the rules only ever run against one representation.

What the harvester anchors on

• NPIs are accepted only when the check digit verifies.
• A postal code counts only when a state code sits immediately before it, so a tax id is not mistaken for a ZIP+4.
• A procedure code counts only when a charge follows it on the same line.
• Payer, submitter and control numbers are defaulted, never guessed, and are listed as defaulted in the conversion notes.

Claim JSON schema

Press Claim JSON in the editor toolbar to load this template. Key matching is deliberately loose: npi, NPI and providerNpi are equivalent, as are cpt, procedureCode and code. Dates accept 2023-08-15, 08/15/2023 or 20230815.

{
  "billingProvider": {
    "name": "GREAT LAKES CLINIC",
    "npi": "1982736450",
    "taxonomy": "207Q00000X",
    "taxId": "123456789",
    "address": {
      "line1": "123 HEALTHCARE WAY",
      "city": "SOMECITY", "state": "NJ", "zip": "088311234"
    }
  },
  "payer": { "name": "BLUE CROSS BLUE SHIELD", "id": "99999" },
  "subscriber": { "relationship": "18", "filing": "CI" },
  "patientControlNumber": "CLAIM1001",
  "placeOfService": "11",
  "frequency": "1",
  "diagnoses": ["J209"],
  "serviceLines": [
    {
      "serviceDate": "2023-08-15",
      "procedureCode": "99214",
      "modifiers": [],
      "charge": 150.00,
      "units": 1,
      "diagnosisPointers": [1]
    }
  ]
}

Subscriber name, member identifier, date of birth and the provider tax id are not read from your JSON at all. Redacted placeholders are written instead, and the editor is replaced with the redacted X12 so the identifiers do not stay on screen.

Validation rules

One hundred rules, grouped by prefix. Every finding carries its code, the element it came from, a plain explanation and, where one exists, a corrected snippet. Errors block; warnings and notes do not.

Rules worth knowing about

• PRV-006 — the billing postal code must be nine digits with no hyphen. This is the most common single cause of front-end rejections.
• BAL-001 — CLM02 must equal the sum of every SV102. Payers reject the whole claim on this, not just the offending line.
• DX-002 — BK and BF are ICD-9 qualifiers, retired for dates of service from 1 October 2015.
• ENV-010 — SE01 counts ST and SE themselves. An off-by-one produces a 999 rejection.

Repair

Repairs are split by whether the correct value can be derived from the file. That split is the whole design.

Derivable, applied on one click

Thirteen rules: segment and group recounts, control-number alignment, ISA re-padding to 106 characters, BHT element realignment, ICD-9 to ICD-10 qualifier upgrades, decimal removal from diagnosis codes, currency symbol stripping, facility code qualifier correction, whitespace trimming, and reconciling CLM02 to the sum of the service lines.

Not derivable, so the tool asks

Five fields: the billing ZIP+4, a principal diagnosis, the billing NPI when its check digit fails, and the billing taxonomy. Each renders as a labelled input with its own validation.

Every applied change is shown as a before and after diff. Repairing an already-clean claim produces no changes.

PHI shield

The shield is always on and has no setting. It runs at the tokenizer boundary, before the model builder, the validator, the search index or the payer profiler receive the segments. Redaction is positional, driven by X12 element addresses rather than by inspecting content, and no mapping table is kept, so it cannot be reversed.

Replacements preserve structure

Blanking a member identifier would trigger a false “member id empty” error, so replacements keep the shape of what they replace. Member identifiers become zeros of the same length. Dates of birth keep the year, which Safe Harbor permits, and zero the month and day, which keeps DMG02 a valid eight-digit date and keeps the service-date-against-birth-date check working. A clean claim still validates clean after redaction, which is what makes an always-on shield workable rather than merely safe.

What it does not cover

The redaction report names positions and field kinds — NM103, DMG02 — and never the values it removed.

Accepted claims

A payer’s companion guide describes intent. A claim that payer accepted is evidence. The Accepted tab turns the second into rules.

Adding one

• Drop a claim file on the tab, or press Use claim in editor when the current claim has no blocking errors.
• Identifiers are redacted on arrival, as everywhere else.
• Only structure is stored: which segments appeared, which qualifiers were used, the filing indicator, the guide version and the postal code length. No claim values are kept.

How it is used

With more than one sample for a payer, the tool keeps the intersection of always-present segments. If one accepted claim omits PRV, the taxonomy stops being reported as always required. New claims for that payer then get a Payer conformance section.

Knowledge base

The Ask tab is a local search engine over question and answer pairs, not a chatbot. There is no API key, no network call and no generated text, so every answer is something a human wrote and approved.

Loading your own content

Drop a file on the tab or paste text. The reader detects JSON, JSONL, CSV, TSV, Markdown headings, Q: and A: blocks, and plain text blocks whose first line ends in a question mark. Whichever reader finds the most pairs wins.

Why it understands plain English

Retrieval is BM25 with thirty-five domain synonym clusters, so “provider number is invalid” reaches the NPI entry and “the totals don’t add up” reaches the balancing entry. When nothing matches well, it says so rather than returning a confident wrong answer.

Questions are also generated from the errors in the claim currently loaded, so a PRV-006 finding offers “Why was my claim rejected for the billing provider ZIP code?” as a single tap.

Limits

Stated plainly, because finding these out later is expensive.

• 837 Professional only. Institutional and dental claims are flagged as the wrong implementation guide rather than validated incorrectly.
• No OCR. Scanned PDFs are refused.
• Nothing persists. Payer profiles and any loaded knowledge base are cleared on reload.
• Code lists are abbreviated. Place of service, filing indicators and diagnosis qualifiers cover the common cases. Production use needs the full licensed CPT and ICD-10-CM tables.
• Not a submission system. It tells you whether a claim would survive a clearinghouse. Sending it stays with your existing software.
• Not a substitute for a companion guide. A claim can be valid against 005010X222A1 and still be rejected by a payer that asks for more.

Questions