Case Study 11.2: MedClaim's Multi-Provider Claim Intake

Background

MedClaim Health Services receives electronic claim submissions from over 600 healthcare providers. Each provider submits a sequential batch file containing their claims for the period. These files arrive via secure file transfer throughout the day, and the nightly batch processes all files received before the 5 PM cutoff.

The Variety Problem

Provider files vary in almost every dimension:

James Okafor's CLM-INTAKE program must handle all of these variations while maintaining a single standardized output format for downstream programs (CLM-ADJUD, CLM-PAY, RPT-PROVIDER).

The Architecture

Provider Configuration Table

Rather than writing a separate intake program for each provider, James uses a configuration-driven approach. A VSAM KSDS file (PROVIDER-CONFIG) contains one record per provider describing their file format:

Provider  RecFmt  RecLen  HasHdr  HasTrl  DateFmt   AmtFmt
--------  ------  ------  ------  ------  --------  ------
PRV-0001  F       500     Y       Y       YYYYMMDD  COMP3
PRV-0002  V       200-800 Y       N       MMDDYYYY  DISPLAY
PRV-0003  F       300     N       N       YYMMDD    DISPLAY
...

The Processing Flow

For each provider file received today:
  1. Look up provider in PROVIDER-CONFIG
  2. OPEN the provider's input file
  3. If provider has header: read and validate header
  4. For each detail record:
     a. Apply provider-specific field mapping
     b. Convert date format to YYYYMMDD
     c. Convert amount format to COMP-3
     d. Validate against standard rules (Chapter 10)
     e. Write to standardized CLAIM-STAGING file
  5. If provider has trailer: validate control totals
  6. CLOSE the provider's input file
  7. Write processing statistics to INTAKE-LOG

The Field Mapping Challenge

Different providers place fields in different positions within the record. The configuration includes a field map:

       01  WS-FIELD-MAP.
           05  WS-MAP-CLM-ID-START   PIC 9(04).
           05  WS-MAP-CLM-ID-LEN     PIC 9(02).
           05  WS-MAP-MBR-ID-START   PIC 9(04).
           05  WS-MAP-MBR-ID-LEN     PIC 9(02).
           05  WS-MAP-PROV-NPI-START PIC 9(04).
           05  WS-MAP-PROV-NPI-LEN   PIC 9(02).
           05  WS-MAP-AMOUNT-START   PIC 9(04).
           05  WS-MAP-AMOUNT-LEN     PIC 9(02).
           05  WS-MAP-DATE-START     PIC 9(04).
           05  WS-MAP-DATE-LEN       PIC 9(02).

James uses reference modification to extract fields based on the map:

       4100-EXTRACT-FIELDS.
           MOVE WS-RAW-RECORD(WS-MAP-CLM-ID-START:
                              WS-MAP-CLM-ID-LEN)
               TO WS-STD-CLM-ID

           MOVE WS-RAW-RECORD(WS-MAP-MBR-ID-START:
                              WS-MAP-MBR-ID-LEN)
               TO WS-STD-MBR-ID

           MOVE WS-RAW-RECORD(WS-MAP-AMOUNT-START:
                              WS-MAP-AMOUNT-LEN)
               TO WS-RAW-AMOUNT

           MOVE WS-RAW-RECORD(WS-MAP-DATE-START:
                              WS-MAP-DATE-LEN)
               TO WS-RAW-DATE.

The Date Conversion Problem

With three different date formats, James wrote a conversion routine:

       5000-CONVERT-DATE.
           EVALUATE WS-PROV-DATE-FORMAT
               WHEN 'YYYYMMDD'
                   MOVE WS-RAW-DATE TO WS-STD-DATE
               WHEN 'MMDDYYYY'
                   STRING WS-RAW-DATE(5:4)
                          WS-RAW-DATE(1:2)
                          WS-RAW-DATE(3:2)
                          DELIMITED BY SIZE
                     INTO WS-STD-DATE
                   END-STRING
               WHEN 'YYMMDD'
                   IF WS-RAW-DATE(1:2) > '50'
                       STRING '19' WS-RAW-DATE
                              DELIMITED BY SIZE
                         INTO WS-STD-DATE
                       END-STRING
                   ELSE
                       STRING '20' WS-RAW-DATE
                              DELIMITED BY SIZE
                         INTO WS-STD-DATE
                       END-STRING
                   END-IF
               WHEN OTHER
                   MOVE 'UNKNOWN DATE FORMAT' TO WS-ERR-MSG
                   PERFORM 9800-LOG-ERROR
           END-EVALUATE.

The Production Incident: Provider #2891

In January 2024, Provider #2891 (a regional hospital chain) changed their billing software without notifying MedClaim. The new software:

1. Changed the record length from 500 to 600 bytes
2. Added new fields in the previously unused portion of the record
3. Changed the date format from YYYYMMDD to YYYY-MM-DD (with dashes)

How the Defenses Responded

First defense — FD record length mismatch: The OPEN succeeded, but the first READ returned FILE STATUS '04' (record length does not match FD). James's status checking caught this:

           WHEN '04'
               DISPLAY 'WARNING: Record length mismatch'
               DISPLAY '  Provider: ' WS-CURRENT-PROV-ID
               DISPLAY '  Expected: ' WS-PROV-REC-LENGTH
               ADD 1 TO WS-WARNING-COUNT

Second defense — date validation failed: The date "2024-01-15" (with dashes) is not a valid YYYYMMDD numeric date. The NUMERIC test caught it.

Third defense — consecutive error circuit breaker: After 10 records with invalid dates, the circuit breaker tripped:

*** CIRCUIT BREAKER TRIPPED ***
10 CONSECUTIVE VALIDATION FAILURES
PROVIDER: PRV-2891
COMMON ERROR: SERVICE DATE NOT NUMERIC
RECOMMENDATION: VERIFY PROVIDER FILE FORMAT

Result: Zero corrupted claims reached CLAIM-MASTER. The operations team contacted Provider #2891, updated the PROVIDER-CONFIG to handle the new format, and reprocessed the file. Total disruption: 45 minutes.

Without the Defenses

If the defenses had not been in place, the date fields would have been accepted as-is (they happened to be the right number of bytes). Downstream, CLM-ADJUD would have attempted arithmetic on the date fields (to calculate claim age), causing a S0C7 ABEND and corrupting any claims processed before the ABEND.

Statistics

Circuit breaker trips are investigated and resolved within 2 hours on average. Before the configuration-driven approach, provider format changes required a code change, testing, and deployment — typically a 2-week turnaround.

Lessons Learned

1. Configuration over code. A single program driven by provider-specific configuration is far more maintainable than hundreds of provider-specific programs.

2. Sequential files are a universal interchange format. Despite all the variation, every provider can produce a sequential file. The challenge is in the content, not the container.

3. Reference modification enables dynamic field extraction. By storing field positions in a configuration record, the same code handles any record layout.

4. Date format conversion is a perpetual challenge. Three formats today will become five formats tomorrow. Design for extensibility.

5. Defensive layers compound. The FILE STATUS warning, the NUMERIC check, and the circuit breaker each caught a different aspect of the Provider #2891 incident. Together, they provided complete protection.

Discussion Questions

1. The configuration-driven approach puts the field mapping in data rather than code. What are the trade-offs? When would you prefer to write separate code for each provider?

2. The date conversion uses a "pivot year" of 50 for two-digit years (50-99 = 1900s, 00-49 = 2000s). Is this a good approach? What will happen in 2050?

3. How would you test CLM-INTAKE's ability to handle a new provider format without affecting production processing?

4. If MedClaim wanted to move from nightly batch to near-real-time claim processing, which aspects of this architecture would need to change, and which could remain?