Case Study 2: MedClaim's Claim History Browse and Submission Workflow

Background

MedClaim's customer service representatives handle two primary tasks: looking up claim history (60% of calls) and entering new claims (30% of calls). The existing system had a single-claim inquiry screen (Chapter 29) but no way to browse a member's complete claim history or enter new claims online. Representatives had to use a batch-generated microfiche system for history and paper forms for new claim entry.

James Okafor's team needed to build two CICS transactions: CHST (Claim History Browse) and CNEW (New Claim Entry).

Part 1: The Claim History Browser (CHST)

The Problem

A typical MedClaim member accumulates 20-100 claims per year. Long-term members may have 500+ claims. The single-claim inquiry screen required knowing the exact claim number. Representatives frequently needed to answer questions like:

• "How many times did I visit Dr. Wilson this year?"
• "What was the total I paid out of pocket last quarter?"
• "Was my MRI claim approved or denied?"

These questions required browsing and filtering the claim history — far beyond what a single-record inquiry could provide.

Architecture

The team chose the TSQ-based browse/scroll pattern:

1. Representative enters Member ID and optional date range filter
2. Program queries DB2 with the filter and loads results into a TSQ
3. Browse screen shows 15 claims per page, scrollable with PF7/PF8
4. Typing 'S' next to a claim shows full detail
5. PF3 from detail returns to the browse at the previous position
6. PF3 from browse cleans up and exits

TSQ Design

Each TSQ item is 120 bytes containing the essential browse fields:

01  WS-TSQ-ITEM-DATA.
    05  WS-TSQ-CLAIM-NUM     PIC X(15).
    05  WS-TSQ-SVC-DATE      PIC X(10).
    05  WS-TSQ-PROVIDER      PIC X(30).
    05  WS-TSQ-SVC-CODE      PIC X(5).
    05  WS-TSQ-AMOUNT        PIC S9(7)V9(2) COMP-3.
    05  WS-TSQ-STATUS        PIC X(10).
    05  WS-TSQ-PAY-AMOUNT    PIC S9(7)V9(2) COMP-3.
    05  FILLER               PIC X(34).

The COMMAREA stores the browse state:

01  WS-COMMAREA.
    05  WS-CA-STATE         PIC X(1).    (S/B/D)
    05  WS-CA-TSQ-NAME      PIC X(8).
    05  WS-CA-TOTAL-ITEMS   PIC S9(4) COMP.
    05  WS-CA-TOP-ITEM      PIC S9(4) COMP.
    05  WS-CA-MEMBER-ID     PIC X(10).
    05  WS-CA-DATE-FROM     PIC X(10).
    05  WS-CA-DATE-TO       PIC X(10).
    05  WS-CA-SELECTED-CLM  PIC X(15).

Performance Challenge: The 500-Claim Load

Initial testing with members who had 300+ claims showed a noticeable delay (1.5 seconds) during the TSQ loading phase. The root cause: 300 individual WRITEQ TS operations, each requiring CICS storage management overhead.

The team optimized by loading the TSQ in blocks — constructing 10 items in working storage and writing them as a batch using a loop that minimized the number of WRITEQ TS calls per task. They also added a "Loading..." message that displayed before the load began:

EXEC CICS SEND TEXT FROM('Loading claim history...')
    LENGTH(25) ERASE END-EXEC

PERFORM 2000-LOAD-CLAIMS

IF WS-CA-TOTAL-ITEMS > 100
    MOVE 'Large history loaded. Use PF7/PF8 to scroll.'
        TO MSGO
END-IF

The final load time for 500 claims was 0.6 seconds — well within the 1-second target.

The Date Range Filter

Representatives frequently needed claims within a specific date range. Rather than loading all claims and filtering in the browse logic, the team applied the filter in the SQL cursor:

SELECT C.CLAIM_NUMBER, C.SERVICE_DATE, ...
FROM CLAIM C
JOIN PROVIDER P ON C.PROVIDER_ID = P.PROVIDER_ID
WHERE C.MEMBER_ID = :WS-MEMBER-ID
AND (:WS-DATE-FROM = '          '
     OR C.SERVICE_DATE >= :WS-DATE-FROM)
AND (:WS-DATE-TO = '          '
     OR C.SERVICE_DATE <= :WS-DATE-TO)
ORDER BY C.SERVICE_DATE DESC
FETCH FIRST 500 ROWS ONLY
WITH UR

The trick with the space-filled date comparisons allows the same cursor to work with or without date filters, avoiding the need for dynamic SQL.

Part 2: The Claim Submission Workflow (CNEW)

The Three-Screen Workflow

Screen 1 — Member Verification: - Enter Member ID - Display member name, plan, coverage level for verification - Representative confirms this is the correct member

Screen 2 — Claim Entry: - Enter: Provider ID, service code, service date, billed amount - Program validates provider exists, service code is valid, date is reasonable - Display provider name and service description for verification

Screen 3 — Confirmation: - Display complete claim summary - Show estimated payment (based on plan rules) - Enter = submit, PF3 = edit

The Async Processing Pattern

After the representative confirms the claim, the program: 1. INSERTs the claim into the CLAIM table with status 'SUBMITTED' 2. Uses START to trigger CADJ (Claim Auto-Adjudication) for immediate rules-based processing 3. Displays "Claim submitted. Number: CLM-xxxxxxx" to the representative

The auto-adjudication transaction (CADJ): 1. RETRIEVEs the claim number 2. Applies simple rules (coverage check, provider network check) 3. If rules pass cleanly, updates status to 'APPROVED' and creates a PAYMENT record 4. If rules require human review, updates status to 'PENDING REVIEW' 5. Writes an audit record to the AUDT TDQ

This async pattern means the representative sees immediate confirmation while the adjudication happens in the background — typically completing within 2 seconds.

Error Handling: What If CADJ Fails?

The team identified three failure scenarios:

1. START fails (CADJ transaction not defined): The claim is submitted with status 'SUBMITTED'. A batch sweep program runs hourly to process any claims still in 'SUBMITTED' status. The representative sees a message: "Claim submitted. Auto-adjudication unavailable — claim will be processed within 1 hour."

2. CADJ abends during processing: The claim remains in 'SUBMITTED' status. The batch sweep picks it up. CADJ's HANDLE ABEND logs the error to TDQ.

3. DB2 error during CADJ: The claim status is not changed. The batch sweep handles it.

This layered approach — real-time processing with batch backup — ensures no claim is ever lost, even if the async processing chain fails.

Results

Claim History Browser (CHST)

Claim Submission (CNEW)

Combined Impact

The two new transactions reduced average call handle time from 6.2 minutes to 3.8 minutes — a 39% improvement — and eliminated the paper claim submission process entirely.

Lessons Learned

1. The TSQ-based browse pattern scales well. Even with 500 items, load times remained under 1 second. The key was efficient SQL (WITH UR, FETCH FIRST) and minimizing TSQ write overhead.

2. Async processing with batch backup is highly resilient. The START/RETRIEVE pattern provides real-time processing when it works, and the batch sweep provides a safety net when it does not. This "belt and suspenders" approach is standard practice in production CICS environments.

3. Date range filtering in SQL beats post-filtering. Loading all claims and filtering in COBOL would have been simpler to code but slower and more memory-intensive. Applying the filter in SQL reduces the data transferred from DB2 and the TSQ storage consumed.

4. Estimated payment on the confirmation screen was highly valued. Representatives could tell members immediately: "Your estimated out-of-pocket for this visit will be $25." This feature alone reduced follow-up calls by 15%.

Discussion Questions

1. The TSQ item size is 120 bytes. With 500 items, that is 60 KB of MAIN storage per user. With 200 concurrent users of the browse transaction, how much total TSQ storage is consumed? Is this a concern?
2. Why did the team choose WITH UR for the history query? Would CS or RS be more appropriate? What risks does UR introduce?
3. The batch sweep runs hourly. If the auto-adjudication fails for all claims during a 1-hour period, approximately 2,000 claims would queue up. How would you handle this volume in the batch sweep? Would multi-row FETCH help?
4. How would you modify the browse screen to support filtering by provider or service code without reloading the TSQ? Would you need a different data structure?