Skip to content
Mimic Docs

Batch Processing

Batch processing executes one workflow across many input rows.

CSV schema design

Use one row per case and one column per variable. Example headers:

  • case_id
  • member_id
  • date_of_birth
  • payer_name
  • service_date

Keep values normalized before upload.

Batch workflow

  1. Upload CSV.
  2. Map each column to a workflow variable.
  3. Validate mappings on a sample row.
  4. Launch canary batch.
  5. Expand to full volume when success thresholds are met.

Operational guardrails

  • Start with 5 to 20 rows to validate field mapping.
  • Monitor completion and error rates after first 50 runs.
  • Pause rollout if error taxonomy shifts unexpectedly.
  • For Dentrix full-loop runs, use max_patients (or DENTRIX_MAX_PATIENTS) to enforce bounded canary volume before full daily rollout.

Dentrix full-loop review semantics

When running Dentrix primary-standard loops, treat these fields as required review context:

  • requested_target_date (date requested by scope/claim selection)
  • effective_target_date (date actually used for clinical-note comparison)
  • date_fallback_used (true means manual review required)
  • code_compare_status (matched, mismatch, reconstructed_from_ledger, skipped_incomplete_extraction)
  • billing_mode (llm_json_schema, deterministic_fallback, deterministic_fallback_llm_error, deterministic_fallback_llm_unparseable)
  • billing_reason (blank when billing passes; concise reason when flagged)

Validation flow is SQL-first. If SQL flags a claim only because section 24-31 appears to have no procedure codes, the run retries through Print Preview OCR before final flagging.

This keeps operator decisions aligned with RPA-first execution truth instead of inferred success from partial extraction.

Dentrix SQL runtime controls

Use these environment variables when you need explicit runtime behavior:

  • DENTRIX_SQL_SERVER, DENTRIX_SQL_USER, DENTRIX_SQL_PASSWORD: enable SQL runtime and treat SQL as preferred read path.
  • DENTRIX_SQL_ENABLE, DENTRIX_SQL_DISABLE: force SQL runtime on or off.
  • DENTRIX_SQL_PHASES: limit SQL execution to selected phases (scope, validate, ledger).

Keep mutation actions (Send to Batch, final submit) on deterministic UI automation paths.

Pilot metrics to monitor

  • Completion rate (target commonly >= 90 percent)
  • Error category distribution
  • Mean and p95 runtime
  • Support minutes per completed case
  • Cost per workflow run

Export and reconciliation

Use pilot export endpoints and jobs tables to reconcile:

  • Total submitted rows
  • Terminal run counts
  • Flagged vs completed outcomes
  • Missing outputs requiring reprocessing

Recovery strategy

If a batch fails partially:

  • Export failed rows.
  • Fix root cause in workflow or mapping.
  • Re-run only failed rows using the same batch ID convention.