Case Study 25.2: MedClaim's OO Evaluation

Background

MedClaim Health Services processes 500,000 insurance claims per month through their MEDCLAIM-PROC system. James Okafor, the team lead, was tasked with modernizing the claim adjudication module, which had grown to 45,000 lines of procedural COBOL across 12 programs. The system was becoming difficult to modify: each new regulation change (and healthcare regulations change frequently) required touching 6-8 programs.

Sarah Kim, the business analyst, suggested exploring OO COBOL after reading about GlobalBank's proof-of-concept.

The Domain Analysis

Sarah mapped the claim types to a potential class hierarchy:

Claim (base)
├── MedicalClaim
│   ├── InpatientClaim (hospital stays)
│   └── OutpatientClaim (doctor visits, lab work)
├── DentalClaim
├── VisionClaim
└── PharmacyClaim

Each claim type had: - Common data: claim ID, member ID, provider ID, service date, billed amount, status - Type-specific data: inpatient claims had admission/discharge dates and room charges; pharmacy claims had NDC codes and quantities; dental claims had tooth numbers and surface codes - Type-specific adjudication rules: each type checked different benefit limits, applied different copays, and had different maximum allowable amounts

The OO hierarchy was a natural fit. Each claim type's adjudication logic could be encapsulated in an overridden Adjudicate method.

The Constraints

James conducted a technical assessment and identified critical constraints:

  1. Compiler: MedClaim ran IBM Enterprise COBOL 5.2 on z/OS. This version had limited OO support — no FACTORY section, no interfaces, limited inheritance.
  2. Team skills: James's team of six COBOL developers had zero OO experience. Training estimates: 3-4 weeks per developer, plus 2-3 months of reduced productivity during the learning curve.
  3. Timeline: A major regulatory change (new ICD-11 codes) required the adjudication module to be updated within 8 months.
  4. Risk tolerance: MedClaim processed healthcare claims affecting real patients. A system failure could delay claim payments to hospitals and doctors.

The Decision

James chose not to adopt OO COBOL. Instead, he restructured the procedural code using OO thinking:

Encapsulation: Each claim type's adjudication logic was isolated into its own program (CLM-ADJ-MED, CLM-ADJ-DEN, CLM-ADJ-VIS, CLM-ADJ-RX). A dispatcher program (CLM-ADJ-DISPATCH) examined the claim type and CALLed the appropriate adjudication program.

Polymorphism via CALL: The dispatcher used EVALUATE to route claims, functionally equivalent to method dispatch:

       EVALUATE CLM-TYPE
           WHEN 'MED' CALL 'CLM-ADJ-MED' USING CLM-RECORD
           WHEN 'DEN' CALL 'CLM-ADJ-DEN' USING CLM-RECORD
           WHEN 'VIS' CALL 'CLM-ADJ-VIS' USING CLM-RECORD
           WHEN 'PHR' CALL 'CLM-ADJ-RX'  USING CLM-RECORD
           WHEN OTHER MOVE 'BADTYPE' TO CLM-ERROR
       END-EVALUATE

Interface contracts: James defined standard copybooks that served as interface contracts — every adjudication program accepted the same parameter layout and returned the same result layout.

Outcome

The restructured system was delivered in 5 months — 3 months ahead of the regulatory deadline. When the ICD-11 code change arrived, it required modifications to only CLM-ADJ-MED (medical claims) rather than 8 programs. James estimated the restructuring saved 60% of the effort that would have been needed under the old monolithic design.

Lessons Learned

  1. OO design principles are language-independent. Encapsulation, single responsibility, and polymorphism can be approximated in procedural COBOL through disciplined program structure.
  2. Compiler limitations are a hard constraint. No amount of good design overcomes a compiler that cannot compile your code.
  3. Skills availability matters more than technical elegance. The team could maintain the procedural restructuring from day one. An OO version would have required months of ramp-up.
  4. The 80/20 rule applies. The procedural restructuring captured roughly 80% of OO's organizational benefits at 20% of the adoption cost.

Discussion Questions

  1. James achieved "OO thinking in procedural code." What specific benefits of true OO COBOL did he sacrifice? When would those benefits become significant enough to justify the adoption cost?
  2. If MedClaim's compiler were upgraded to Micro Focus Visual COBOL (full OO support), would that change James's decision? What other factors would need to change?
  3. Compare the dispatcher pattern (EVALUATE + CALL) to true polymorphism. What happens when you need to add a new claim type in each approach?
  4. Sarah Kim suggested that even without OO COBOL, the class hierarchy diagram was valuable as a design document. Do you agree? How would you document a procedural system using OO concepts?