Case Study 2: MedClaim Multi-Format Claim Record

Background

MedClaim Health Services processes four types of insurance claims: medical, dental, vision, and pharmacy. Historically, each claim type was stored in a separate file with its own record layout. This meant four different file processing programs, four different sort jobs, and four different report generators — all doing essentially the same thing with slightly different data.

When Sarah Kim joins as business analyst, she immediately spots the redundancy. "We're maintaining four copies of the same logic," she tells James Okafor. "Every time we add a new status code or change a validation rule, we have to update four programs. Last month, someone updated medical but forgot dental, and we had denials going out with the wrong status description."

The Challenge

James must design a single unified claim record that:

  1. Stores all four claim types in one sequential file
  2. Uses REDEFINES for type-specific detail fields
  3. Maintains a common header for fields shared across all claim types
  4. Supports variable-length line items for medical claims
  5. Enables clean, type-safe processing in the PROCEDURE DIVISION

Design Process

James starts by identifying the common fields across all claim types:

  • Claim ID, member ID, provider ID
  • Service date, submission date
  • Total charge, allowed amount, paid amount, member responsibility
  • Claim status

He then catalogs the type-specific fields:

  • Medical: Diagnosis codes (ICD-10), procedure codes (CPT), place of service, facility, admission/discharge dates, line items
  • Dental: Tooth number, surface, procedure code (ADA), quadrant, orthodontic info
  • Vision: Exam type, lens type, frame info, contact lens parameters
  • Pharmacy: NDC code, drug name, quantity, days supply, DAW code, formulary tier

The detail area must be large enough for the largest variant (medical, with its variable-length line items) while padding shorter variants with FILLER.

The Solution

James designs the 500-byte record shown in Section 4.10 of this chapter. Key design choices:

  1. Type discriminator first: CLM-RECORD-TYPE is the first field in the detail area's parent group, making it easy to read and branch
  2. 88-levels for type checking: CLM-IS-MEDICAL, CLM-IS-DENTAL, etc., make the EVALUATE statement self-documenting
  3. Consistent FILLER padding: Each REDEFINES variant pads to exactly 380 bytes
  4. OCCURS DEPENDING ON for medical line items: Medical claims can have 1-10 service lines, each with its own procedure code, modifier, charge, and quantity

Processing Pattern

The unified processing program follows a clean pattern:

       PERFORM UNTIL WS-EOF
           READ CLAIM-FILE INTO CLAIM-RECORD
               AT END SET WS-EOF TO TRUE
           END-READ

           IF NOT WS-EOF
               IF NOT CLM-TYPE-VALID
                   PERFORM HANDLE-INVALID-TYPE
               ELSE
                   PERFORM VALIDATE-COMMON-FIELDS
                   IF WS-VALID
                       EVALUATE TRUE
                           WHEN CLM-IS-MEDICAL
                               PERFORM PROCESS-MEDICAL
                           WHEN CLM-IS-DENTAL
                               PERFORM PROCESS-DENTAL
                           WHEN CLM-IS-PHARMACY
                               PERFORM PROCESS-PHARMACY
                       END-EVALUATE
                   END-IF
               END-IF
           END-IF
       END-PERFORM

Results

After migrating to the unified record:

  • Code reduction: Four processing programs consolidated into one (3,200 lines instead of 8,400)
  • Defect reduction: Status code mismatches eliminated — one set of 88-levels, one validation routine
  • Performance: Single-pass processing instead of four separate file reads
  • Maintainability: New claim types (e.g., behavioral health) require only a new REDEFINES variant and EVALUATE branch

The Vision Claim Addition

Six months later, MedClaim adds behavioral health claims. Tomás Rivera notes that the FILLER in each existing variant provides room, and James adds:

           05  CLM-BEHAVIORAL REDEFINES CLM-DETAIL-AREA.
               10  CLM-BH-DIAGNOSIS       PIC X(7).
               10  CLM-BH-PROCEDURE       PIC X(7).
               10  CLM-BH-SESSION-TYPE    PIC X(2).
                   88  CLM-BH-INDIVIDUAL      VALUE 'IN'.
                   88  CLM-BH-GROUP           VALUE 'GR'.
                   88  CLM-BH-FAMILY          VALUE 'FM'.
               10  CLM-BH-SESSION-MINS    PIC 9(3) COMP.
               10  CLM-BH-PROVIDER-TYPE   PIC X(3).
               10  FILLER                 PIC X(356).

The addition requires: one new REDEFINES, one new 88-level on CLM-RECORD-TYPE (VALUE 'BH'), one new WHEN branch in the EVALUATE, and one new PERFORM paragraph. Total change: approximately 150 lines of code.

Discussion Questions

  1. What would happen if a programmer accessed CLM-MED-DIAGNOSIS without first checking that CLM-IS-MEDICAL is true? What data would they see?
  2. Why is it important that every REDEFINES variant pads to exactly the same size (380 bytes)?
  3. How does the OCCURS DEPENDING ON in the medical variant affect WRITE operations? What must be set before writing?
  4. Compare the REDEFINES approach to an alternative design where type-specific fields have unique names without REDEFINES (i.e., all fields are always present). What are the trade-offs?
  5. If MedClaim needed to support claims with more than one type (e.g., a medical claim that also includes pharmacy), how would you modify the design?