ReprocessChangedConfigurations

Overview

ReprocessChangedConfigurationsTask identifies visits and accounts affected by configuration changes and queues them for reprocessing. When configurations like AutoSendLetterConfig, Bundle, AutoBenefitsRule, or InsuranceMap are modified, this task ensures all associated visits and accounts are flagged for recalculation.

Use this task when: You need to propagate configuration changes (pricing rules, insurance mappings, auto-send settings, etc.) to existing visits or accounts that were processed using the old configuration.

Don't use this task when:

• Processing new visits/accounts (they will use current configurations automatically)
• Making configuration changes that should not affect historical data
• You need immediate reprocessing (this task only queues items; subsequent tasks consume the queue)

Parameters

Execution Flow

flowchart TD
    A[Start ReprocessChangedConfigurations] --> B{ReprocessVisits = true?}
    B -->|Yes| C[Process AutoSendLetterConfigs]
    B -->|No| D{ReprocessAccounts = true?}

    C --> E[Process Bundles]
    E --> F[Process AutoBenefitsRules]
    F --> G[Process InsuranceMaps for Visits]

    G --> D

    D -->|Yes| H[Truncate AccountsToReprocess table]
    H --> I[Process InsuranceMaps for Accounts]
    I --> J[Populate AccountsToReprocess]

    D -->|No| K[End]
    J --> K

    style C fill:#e1f5ff
    style E fill:#e1f5ff
    style F fill:#e1f5ff
    style G fill:#e1f5ff
    style H fill:#ffe1e1
    style I fill:#e1f5ff
    style J fill:#fff4e1

Processing Algorithm

The task uses a two-phase approach for each configuration type:

Visit Reprocessing (when ReprocessVisits = true)

For each configuration type (AutoSend, Bundle, AutoBenefits, InsuranceMap):

1. Identify Changed Configs: Query configs where NeedsReprocessing = true flag is set
2. Turn Off Flags: Clear the NeedsReprocessing flag on identified configs
3. Find Affected Visits: Query visits associated with each changed config
4. Filter by Schedule: Only queue visits with ScheduledTime > CurrentDateTime (future visits only)
5. Create Queue Items: Add entries to VisitReprocessQueueItem table with visit key and config key
6. Delete Duplicates: Remove existing queue items for the same config before adding new ones

Account Reprocessing (when ReprocessAccounts = true)

For InsuranceMap configurations only:

1. Truncate Queue: Clear the entire AccountsToReprocess table
2. Identify Changed Maps: Query InsuranceMaps where ReprocessFlag indicates account reprocessing needed
3. Adjust Flags: Update ReprocessFlag (e.g., ReprocessVisitsAndAccounts → ReprocessVisits, ReprocessAccounts → None)
4. Find Affected Accounts: Query accounts using the source insurance IDs from changed maps
5. Populate Queue: Insert affected accounts into AccountsToReprocess table

Example Execution

Scenario: Modified an InsuranceMap for "Blue Cross PPO" that affects 500 visits and 200 accounts:

1. ReprocessVisits = true:
   - Find InsuranceMap with NeedsReprocessing flag
   - Clear the flag
   - Query 500 visits associated with "Blue Cross PPO"
   - Filter to 300 future visits (200 are past)
   - Add 300 entries to VisitReprocessQueueItem

2. ReprocessAccounts = true:
   - Truncate AccountsToReprocess (removes all existing rows)
   - Find InsuranceMap with ReprocessFlag = ReprocessAccounts
   - Adjust flag to None
   - Query 200 accounts with "Blue Cross PPO" as source insurance
   - Insert 200 accounts into AccountsToReprocess

Usage Examples

Example 1: Reprocess visits after changing auto-send letter configurations

var task = new ReprocessChangedConfigurationsTask
{
    ReprocessVisits = true,
    ReprocessAccounts = false
    // Only queue visits; accounts are not affected by auto-send changes
};

Example 2: Reprocess accounts after insurance mapping changes

var task = new ReprocessChangedConfigurationsTask
{
    ReprocessVisits = false,
    ReprocessAccounts = true
    // Only queue accounts affected by insurance map changes
};

Example 3: Reprocess both visits and accounts after insurance map updates

var task = new ReprocessChangedConfigurationsTask
{
    ReprocessVisits = true,
    ReprocessAccounts = true
    // Common scenario: InsuranceMap changes affect both visits and accounts
};

Example 4: Part of a larger pipeline

// Step 1: User modifies Bundle configuration in UI
// (System sets NeedsReprocessing = true on the Bundle entity)

// Step 2: Scheduled job runs this task
var queueTask = new ReprocessChangedConfigurationsTask
{
    ReprocessVisits = true,
    ReprocessAccounts = false
};
// Result: Affected visits are added to VisitReprocessQueueItem

// Step 3: VisitLoader consumes VisitReprocessQueueItem
// (Subsequent scheduled job processes the queue and recalculates visits)

Related Tasks Comparison

Key Differentiators:

• ReprocessChangedConfigurations is configuration-change-driven (automatic flagging when configs change)
• ProcessAccountData tasks are criteria-driven (facility, insurance, date range)
• ReprocessChangedConfigurations uses a two-step process (queue → consume), while Process tasks execute immediately
• Only ReprocessChangedConfigurations automatically tracks which configurations changed

Performance Considerations

Database Impact

• Tables Read:
  • Configuration tables: AutoSendLetterConfig, Bundle, AutoBenefitsRule, InsuranceMap
  • Data tables: Visit, Account
• Tables Written:
  • VisitReprocessQueueItem (inserts; deletes before insert)
  • AccountsToReprocess (truncated, then bulk insert)
  • Configuration tables (flag updates)
• Query Patterns:
  • Config queries: Simple WHERE clauses filtering by flags
  • Visit/Account queries: Joins on configuration keys (indexed lookups)
  • Visit filter: Date comparison to exclude past visits
• Bulk Operations:
  • Uses bulk inserts for queue items
  • Truncate operation for AccountsToReprocess (fast)

Optimization Tips