Use case
Use case3 min readBy The Data Workers Team

Risk adjustment data, run by agents

Encounter submissions and RAF calculations depend on claims and chart data that are resent, restated and remapped, and errors surface in reconciliation reports. Here is how Data Workers runs it instead.

Key takeaways

  • •The problem today. Encounter submissions and RAF calculations depend on claims and chart data that are resent, restated and remapped, and errors surface in reconciliation reports.
  • •What changes. Agents verify every encounter and claims load, catch resends and code changes, and hold anything that changes submitted data for a named approver.
  • •What stays with your people. Changes to submitted encounter data: payments depend on them.
  • •The result. Encounter data is right before it is submitted.

The problem today

Encounter submissions and RAF calculations depend on claims and chart data that are resent, restated and remapped, and errors surface in reconciliation reports.

What changes with Data Workers

Agents verify every encounter and claims load, catch resends and code changes, and hold anything that changes submitted data for a named approver.

The workflow: Data Ingestion agent (get_connector_status) → Schema Evolution agent (detect_schema_change) → Quality Monitoring agent (run_quality_check) → Autonomous Data-Conductor (request_governance_review).
Fig. 1:The workflow: Data Ingestion agent (get_connector_status) → Schema Evolution agent (detect_schema_change) → Quality Monitoring agent (run_quality_check) → Autonomous Data-Conductor (request_governance_review).

The workflow, step by step

  1. 1.The Data Ingestion agent calls get_connector_status and detects resent and restated files.
  2. 2.The Schema Evolution agent calls detect_schema_change and maps code-set and layout changes.
  3. 3.The Quality Monitoring agent calls run_quality_check and reconciles encounters to claims.
  4. 4.The Autonomous Data-Conductor calls request_governance_review and holds submission changes at L2.

The impact metrics we move

  • •Resend handled: from about a week to ~1 h
  • •Code-set update rolled out: from about 2 weeks to 1 day
  • •Encounter reconciliation: from about a week to under 1 h
Time to complete, current practice (black) vs. with Data Workers (green). Illustrative.
Fig. 2:Time to complete, current practice (black) vs. with Data Workers (green). Illustrative.

What goes on autopilot

  • •Resends and restatements are detected on arrival, so nothing is submitted twice.
  • •Encounters reconcile to claims daily, so rejections are rare.

Where your people stay in charge

Changes to submitted encounter data always go to a named approver, because payments depend on them. Everything starts at L1, observing only, and autonomy rises only on evidence.

The pilot

  • •Scope. Resend detection and encounter reconciliation at L2.
  • •First week. Agents run at L1, observing only, and show the fixes they would have made, with receipts.
  • •By week two. The routine work above runs on its own; anything sensitive stays with a named approver.
  • •At day 30. We review the impact metrics against your baseline:
  • •Resend handled: from about a week to ~1 h
  • •Code-set update rolled out: from about 2 weeks to 1 day
  • •Encounter reconciliation: from about a week to under 1 h
  • •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.