The Same Claim, a Different Payout From Each Desk

In one line

Coverage adjudication is a calculation that cuts the billed amount down through the deductible, coinsurance rate, per-claim cap, and annual cap in a set order, and that order, the rounding, and "what unit you count by" change the result.

Why this was needed

On the surface, calculating a claim payment is a few multiplications and subtractions. But once you get into the field, you see almost every time two systems calculating the same claim differently. The claims review system and the accounting system differ, and the payment clerk's spreadsheet differs again. All three were built by reading the policy terms, yet the results differ.

The cause is usually that the policy terms are written in words and do not state the order. In the sentence "pay 80% of the amount after deducting the deductible, with a limit of 300,000 won per occurrence and 3,000,000 won per year," the sentence does not decide whether the deductible is subtracted first or the 80% is multiplied first, whether the 300,000 won cap is checked before or after multiplying, or whether the deductible is per claim or per accident. Each team builds it with its own interpretation, and that interpretation hides scattered through the code.

This mismatch does not show up as an error. Both systems terminate normally, and nothing is left in the logs. What shows up is customer inquiries and closing differences. So what an FDE does when rebuilding this adjudication is to pull the rules out into data and to leave, for each claim, which rule cut how much. Before the adjudication is right, it must be explainable.

How it works

The adjudicator takes one claim and cuts the amount down in turn. The order this lab uses is the following — this is this lab's assumption, and the policy terms of a real product differ by product. The basic framework of an insurance contract is in Part IV (Insurance) of the Commercial Act, but figures such as the deductible and caps are set by the policy terms, not the law.

청구액
 ├─ 1. 자기부담금(공제액)   사고 하나에 한 번   → 남은 금액
 ├─ 2. 공동부담률           비율로 깎음        → 남은 금액
 ├─ 3. 건당 한도            이 청구의 상한     → 남은 금액
 └─ 4. 연간 한도            남은 연간 여유     → 지급액

Why does the order change the result? Say the claim is 1,000,000 won, the deductible is 300,000 won, and the coinsurance is 20%. If you deduct first, (100 - 30) × 0.8 = 56 (in units of 10,000 won), that is 560,000 won. If you apply coinsurance first, 100 × 0.8 - 30 = 50 (in units of 10,000 won), that is 500,000 won. There is a difference of 60,000 won, and this difference is multiplied by the number of claims. The heart of the problem is that both results can claim to be "per the policy terms."

What unit you count by also changes it. If the deductible is per claim, a person who filed outpatient, medication, and tests separately for the same accident pays the deductible three times. If it is per accident, once. The annual cap is the same: depending on whether it is the "year by accident date" or the "year by filing date," the adjudication of a year-end claim splits.

The waiting period is the distance between the contract date and the accident date. Accidents that happen within a set period after the contract starts are not covered. A common mistake here is measuring by the filing date rather than the accident date. The accident happened after the period but payment is refused because the filing was late, or the reverse. Date calculation begins with string comparison and is sure to go wrong, so in Python you handle it with date.fromisoformat and timedelta of datetime, and if you must handle it inside SQL, you use SQLite's date functions.

Rounding is a policy. Multiplying by the coinsurance rate leaves fractions below the won unit. Python's built-in round() rounds exactly-half values to the even side (banker's rounding). The default rounding mode of the decimal module is also ROUND_HALF_EVEN. If the policy terms say round half up, you must specify ROUND_HALF_UP, and the difference is one won per case, but across hundreds of thousands of cases it shows up at closing. More important is that when two systems use different modes, the differences scatter randomly and the cause becomes hard to find.

What it looks like in the field

First, the rule figures are hard-coded in the code. Lines like if plan == "BASIC": deductible = 20000 are scattered across several files, and every time a product is added you have to fix all the files. If you pull the rules out into a table, adding a product becomes one line of data, and above all you can reproduce past adjudications with the table as it was then.

Second, there is only the adjudication result and no basis. If only the payable amount of 120,000 won is stored, nobody can answer when the customer asks "why 120,000 won?" If you leave the amount each rule cut as an array, that itself becomes the customer notice and the expected value of the regression test. That is why the lab's adjudicator produces steps.

Third, looking at the cumulative cap only per claim. The annual cap depends on how much the earlier claims of that policy used. If you calculate looking at just one claim, you pay beyond the cap, or a different result comes out if the order changes. Adjudication must be processed in a set order (usually the filing date), and you must also decide that a late-arriving claim does not reverse an earlier adjudication.

Fourth, there is only one denial reason. There are claims that are both an accident within the waiting period and an excluded item. If you leave only one reason, the customer explains one thing and is denied again. Leave the reasons as a list.

What really matters in practice

• Pin the order down in a document and make the code read in that order. The order must show in the shape of the code, not in a comment.
• Rule figures in a table, calculation in code. Even if products increase, the code must stay as it is.
• Leave the adjudication basis for each claim. If you match only the total, you will never know where it went off.
• Write the rounding mode and the reference year for the cap as policy. If you do not decide, two systems give different answers, and the difference does not look like an error.

What you will do in the next lab

You build a synthetic policy terms table and 141 claims yourself and see in numbers how much two application orders spread the total. Then you build the adjudicator, which applies the deductible, coinsurance, and per-claim cap in order, denies by waiting period and exclusion, makes multiple claims of the same accident share the deductible, and exhausts the annual cap. The grader actually runs your adjudicator each time with different policy figures and checks the payable amount and the adjudication basis, including the rounding of exactly-half values.