Where Do Downcoding and Returned Claims Actually Happen? — Taking Apart Receipt Checking Logic Using ORCA's Source Code and Public Documents

Front-desk takings are only a fraction of a healthcare provider’s income; the bulk of it is settled by the once-a-month receipt claim. That is why phrases such as “we got downcoded” or “a claim came back” carry so much weight on the ground — and yet, for engineers working on the systems, where and by what logic downcoding and returned claims arise is a surprisingly hard thing to see.

Part 1 of this series covered the role of the receipt computer, Part 2 covered the Nichi-Rece API, and Part 3 covered online eligibility verification. This time we take on the heart of receipt work — the logic of checking and assessment — by lining up, in order, the checkpoints a receipt has to pass through.

• The precise meaning of the terms returned claim, downcoding and re-assessment
• Checks inside the healthcare provider — the implementation of ORCA’s data check function and its check masters
• The rece-den data check performed before submission
• Checks on the claims review and payment body side — computer checks, cross-matching review and longitudinal review
• The fact that, structurally, the receipt computer side and the assessment side are both the same “rule table plus engine”

Statements about the regulatory side are based on public documents from the Payment Fund, medical associations and similar sources; statements about ORCA’s implementation are based on actually reading the officially published Nichi-Rece core 5.2-series source (the snapshot published on 1 July 2026).

Table of Contents

1. The conclusion first — a receipt passes through “four checkpoints”
2. Terminology in the shortest possible form — returned claim, downcoding, point adjustment, re-assessment
3. Checkpoint 1: reading ORCA’s data check function in the source
4. The check master as a rule table — the design of the tbl_chk family of tables
5. Input-time checks and APIs — checking does not only happen at month end
6. Checkpoint 2: the rece-den data check — inspecting the claim data
7. Checkpoints 3 and 4: computer checks, cross-matching review and longitudinal review at the claims review and payment bodies
8. Both sides are “rule table plus engine” — the engineer’s map
9. Practical points — what the system side can do to improve checking accuracy
10. Summary
11. References

1. The conclusion first — a receipt passes through “four checkpoints”

Put on a single page, the main checkpoints a receipt passes through between data entry at the healthcare provider and payment look like this.

flowchart LR
    subgraph clinic["Inside the healthcare provider"]
        NYU["Day-to-day data entry<br/>(input-time checks)"]
        DC["1. Data check function<br/>(ORCA: orca41)"]
        REC["2. Rece-den data check<br/>(inspecting the claim data)"]
        NYU --> DC --> REC
    end
    subgraph SHINSA["Claims review and payment bodies (Payment Fund / NHI Federations)"]
        CC["3. Computer checks<br/>+ cross-matching and longitudinal review"]
        JIN["4. Inspection by staff<br/>+ review committee"]
        CC --> JIN
    end
    REC -->|"Online claim submission"| CC
    JIN -->|"Assessed claim"| HOKEN["Insurer"]
    HOKEN -.-> PAY["Payment<br/>(to the provider via the review and payment body)"]
    JIN -.-> RET["Returned claim / downcoding<br/>(notified to the provider → correction and re-submission)"]

• Checkpoint 1 (checking the clinical content): the receipt computer inspects the internal consistency of the clinical content — “do the diagnosis and the drug match?”, “has anything claimable been missed?”. In ORCA this is the job of the data check function.
• Checkpoint 2 (checking the claim data): the electronic receipt to be submitted (the rece-den file) is inspected as claim data, from record format through to comment entry requirements. In ORCA this is the rece-den data check.
• Checkpoint 3 (machine assessment): the computer checks at the claims review and payment body scan the receipt mechanically against rules derived from official notices, circulars and drug package inserts, flagging suspect items. This also includes the cross-matching review, which pairs a single patient’s medical and dispensing receipts, and the longitudinal review, which compares the receipt against previous months.
• Checkpoint 4 (human assessment): staff inspect the items the machine flagged, and ultimately the review committee decides. The outcome is notified to the healthcare provider as a returned claim or as downcoding.

The essential point for an engineer to grasp is that checkpoint 1 and checkpoint 3 are performing “the same kind of inspection” from opposite sides. The provider wants to find, before submission, any claim likely to be caught in assessment; the assessment side wants to find claims that do not match the rules. As we will see, that symmetry shows up as a similarity in implementation structure — both are a rule table plus an engine.

2. Terminology in the shortest possible form — returned claim, downcoding, point adjustment, re-assessment

The shortest possible summary of the regulatory vocabulary.

The important distinction is that a returned claim means “do it again” while downcoding means “the reduction is final” — the severity is different. And the cross-matching and longitudinal reviews detect errors that cannot be found by looking at a single receipt on its own (frequency limits that span months, discrepancies between medical and dispensing claims). Their nature differs, though: matching against another organisation’s receipt (cross-matching) is impossible in principle inside a healthcare provider, whereas comparing against your own previous months (the equivalent of longitudinal review) is possible within your own data. Understanding where that line falls, the goal of checking work becomes “catch everything internally that can be caught internally”.

3. Checkpoint 1: reading ORCA’s data check function in the source

From here on we read the source. ORCA’s data check is business menu 41, corresponding in the source to the cobol/orca41/ directory and lddef/orca41.ld. The LD definition shows the structure directly.

• Screens: starting from D01 “Receipt Check Instruction”, it branches to D02 “Individual Instruction”, D03 “Check Item Setting Registration” and D04 “Error Content Confirmation” respectively, while D05 “Exception Setting List” is called from D04 (the branching is in the transition handling of ORCGD01.CBL and ORCGD04.CBL, and the screen names can be confirmed from the titles of each screen/D0x.glade).
• Engine: the body of the inspection logic sits not on the screen side but in the batch programs cobol/orcabt/ORCDTCHK000 through 011.CBL. From the screen, ORCGDSUB02.CBL launches this batch as a job (shell ID ORCBSD1), so the interactive screens and the inspection processing are kept separate.
• API: an API for launching the data check externally (ORCGDAPI01) is bound as bindapi "datacheckv3".

The API’s request definition (record/xml_data_checkv3req.db) is the most compact statement of this function’s input specification.

data_checkv3req {
    Request_Number             varchar(02);   -- 00=fetch information / 01=run check / 02=check status
    Karte_Uid                  varchar(36);   -- caller identifier (required when running; error if empty)
    Orca_Uid                   varchar(36);   -- job identifier (required for status checks; returned in the run response)
    Perform_Month              varchar(07);   -- target treatment year and month
    Start_Day / End_Day        varchar(02);   -- date range
    InOut                      varchar(01);   -- inpatient/outpatient classification
    Check_Insurance_Information { Id; }[6];   -- target insurance (up to 6)
    Check_Item_Information    { Id; }[22];    -- check item IDs (up to 22)
    Patient_Information { Patient_ID; }[100]; -- target patients (up to 100)
};

(The meanings of the Request_Number values can be confirmed from the constant definitions and branching in ORCGDAPI01.CBL, and the mandatory checks on Karte_Uid and Orca_Uid from ORCGDAPI01S01.CBL and ORCGDAPI01S02.CBL. A run (01) executes as a job, and you follow its progress with a status check (02) quoting the Orca_Uid returned in the run response — an asynchronous design.)

Note that Check_Item_Information is an array of 22 elements. The data check is not a single inspection but a set of inspections known as “check items”, and which of them run is selected at execution time. The error content confirmation screen (D04.glade) also has an exception registration facility, so individual errors can be suppressed as “do not check (this month)” or “do not check (always)” (exceptions are stored in the table tbl_chkreigai). It is the shape of a practical rule engine, one where false positives can be worked out through operation.

Incidentally, D04.glade carries sample data of “Pontal” (an antipyretic analgesic) and “gastric ulcer”, with check master classification “1 drug and diagnosis”. Even in the sample data of a screen definition, the representative use case we look at in the next section — checking that a drug matches a diagnosis — is inscribed.

4. The check master as a rule table — the design of the tbl_chk family of tables

Of the knowledge of “what is correct” that the data check relies on, the part concerning the relationship between drugs and procedures is not hard-coded in COBOL but held as data in a family of tables called the check masters. By contrast, checks concerning the basic structure of the system — consistency of insurance, symbol and number, and the actual number of treatment days — are implemented directly in the code of the batch programs (ORCDTCHK*), and the revision histories duly list code-side additions such as “support for branch-number data checking” and “support for workers’ compensation insurance number data checking”. It is a mistake to assume that maintaining the check masters changes every rule: what the rule table covers is the territory of approved indications, contraindications, combination claiming and so on. With that caveat in place, extracting the related tables from the table list (lddef/orcadb.inc) gives:

The structure of a rule can be confirmed in record/tbl_chk.db and in the COPY member cobol/copy/CPCHK.INC (whose fields carry Japanese comments). Reduced to essentials, a single rule row has this shape.

Check classification (CHKKBN) + treatment code (SRYCD) + validity period (YUKOSTYMD to YUKOEDYMD)
  -> the set of corresponding codes (CDKBN + CD), inpatient/outpatient classification, processing classification

In other words, a declarative rule stating that “for treatment code X, within period Y, one of the codes in set Z must correspond (or must not coexist)”. The kinds of rule available are enumerated on the check master report output screen (screen/X91.glade).

• Drug and diagnosis / diagnosis and drug (matching approved indications)
• Procedure and diagnosis / diagnosis and procedure
• Drug and contraindicated combination
• Contraindicated drug and diagnosis
• Combination claiming of procedures (same day / same month / same billing episode)
• Missed claims between procedures
• Claim frequency checks

What makes “drug and diagnosis” and “diagnosis and drug” interesting is that they form a pair: the former handles “if you prescribe this drug, this diagnosis must be present” (detecting a missing approved indication), the latter “if this diagnosis is present, this drug or test ought to be there” (detecting missed claims). In implementation, though, they are not two directions of a single table. Reading the report program (cobol/orca103/ORCHXLST.CBL), the former is managed in tbl_chksnd and the latter in tbl_chk005, in separate tables with separate keys, so registering one direction does not make the reverse direction work as well — worth being careful about. The validity period exists so that the rules can follow the biennial fee schedule revisions and the listing and delisting of drugs; “keeping up with regulatory change is the essence of a receipt computer”, as we saw in Part 1, runs right through the design of the rule table too.

Note that not every rule fits the single shape above. tbl_chksnd and tbl_chk005 have shapes that hold diagnosis name strings (BYOMEI) and handling for suspected diagnoses, while tbl_chktrd has a shape holding a same-day/same-month classification (DAYMONTHKBN): the rule tables themselves are normalised into different shapes according to the kind of check. “Rule table” does not mean a single schema — a point to bear in mind when reading the implementation.

5. Input-time checks and APIs — checking does not only happen at month end

The data check is a monthly batch inspection, but it is not the only checking that happens. The source also shows mechanisms that run further upstream — at the point of day-to-day data entry.

• Contraindicated combination check API: /api01rv2/contraindicationcheckv2 (handled by the program ORAPI021R4V2, “return contraindicated drug combination information”; the creation date in the header is 2016). Pass it a patient and a drug and it returns any applicable contraindicated combinations, so you can build an integration in which the electronic medical record queries Nichi-Rece at the moment the prescription is entered.
• Data check API: datacheckv3 from the previous section. Because the monthly batch can be launched without screen operation, you can set up an arrangement such as “check the current month automatically every night and produce an error list the next morning”.

There is a universal design lesson here. The closer to its source an error is caught, the cheaper it is to fix. An error found by the data check at month end means correcting a whole month’s worth at once, whereas noticing a contraindicated combination at the moment the prescription is entered takes seconds to deal with. (Note that this API looks at contraindicated combinations. Checks on correspondence relationships, such as a missing approved indication, remain the territory of the monthly data check and are not taken over at input time.) The fact that ORCA’s checking mechanism is multi-stage — “input time (API) → monthly (data check) → pre-submission (rece-den check)” — is an implementation of that principle.

6. Checkpoint 2: the rece-den data check — inspecting the claim data

Where the data check looks at the internal consistency of the clinical content, a different check waits immediately before submission: the rece-den data check. Its subject is the electronic receipt (rece-den) file, and it inspects correctness as claim data — record format, presence of mandatory records and so on.

The conditions for this check are published by the official ORCA site as a PDF under the title “Rece-den Data Check: Check Condition Specification” (in three variants: health insurance, workers’ compensation, and after-care). In other words ORCA publishes not only the content checks (whose check masters can be inspected via reports or CSV) but the condition specification for the rece-den check as a document, so you can confirm “what gets checked” against a primary source.

It would not be accurate, though, to think of the rece-den check as purely a format inspection. Looking at the source, a subprogram that checks the entry requirements for receipt comments (cobol/common/ORCSRECECOMCHK.CBL, new in 2018) and a check on the claiming history of management and guidance fees relating to online consultation fees (ORCSRECESRCHK.CBL) are implemented on the rece-den processing side, and the monthly processing Ruby script (in the repository, scripts/monthly/receden_check.rb.in — a template installed as receden_check.rb) goes as far as verifying consistency against the fee point master and the diagnosis master. (That Ruby lives alongside COBOL is another of this source tree’s charms.) Broadly the division is “data check = clinical content, rece-den check = claim data”, but the boundary is not strict, and some of the meaning-level checking is handled by the rece-den check — take that division too literally and you will misidentify where an error came from. In practice, the point is that only after passing both does a receipt become “fit to submit for assessment”.

7. Checkpoints 3 and 4: computer checks, cross-matching review and longitudinal review at the claims review and payment bodies

The submitted receipt then enters assessment at the claims review and payment body (the Payment Fund for employee-based insurance; the National Health Insurance Federations for NHI and Late-Stage Elderly Medical Care). What matters here is that some of the assessment side’s check rules are published too.

On the Payment Fund’s “Disclosure Relating to Computer Checks” page, two kinds of file are provided (both in CSV format, with coverage being widened in stages).

Note the name. The Payment Fund side also uses the term “check master”. A structure that manages rules derived from official notices and circulars separately from rules derived from package inserts maps neatly onto ORCA’s structure, where fee calculation rules live in the program and drug indications live in the check masters.

There are, however, checks that are not published. The disclosure page states explicitly that cases requiring confirmation of items entered in the remarks column, cases requiring clinical judgement, and cases concerning the indications of drugs and procedures will be considered carefully before publication. The Payment Fund also repeatedly explains that a computer check merely flags suspect items: it does not downcode mechanically, but goes through inspection by staff and a decision by the review committee. “Computer check = automatic downcoding” is not true, and people on the system side should understand that precisely.

Then there are the cross-matching review and longitudinal review mentioned in section 2. These two, which got properly under way in 2012, are not inspections of a single receipt but inspections of the relationships between receipts. Let us draw the boundary precisely. Cross-matching review (pairing a patient’s medical receipt with their dispensing receipt) has as its counterpart a receipt from another organisation, the dispensing pharmacy, so it cannot in principle be substituted for by checking inside the healthcare provider. The equivalent of longitudinal review (comparing a patient’s current month against previous months), by contrast, is possible in-house within the range of your own claim history. Managing claims that carry frequency limits rigorously, and managing the diagnoses that correspond to outpatient prescriptions, within your own data is the realistic countermeasure for reducing findings from cross-matching and longitudinal review.

8. Both sides are “rule table plus engine” — the engineer’s map

Folded onto a single page, the world of receipt checking looks like this.

The structure is isomorphic; the differences are the comprehensiveness of the rules and the scope of inspection. Three conclusions an engineer can draw from that.

1. The separation rules are data, the engine is a program was a precondition for keeping up with regulatory revisions for over twenty years. Had the rules been buried in code, every revision would have meant a full rewrite.
2. In the territory driven by the check masters (approved indications, contraindications and so on), the provider’s checking accuracy is determined less by how clever the engine is than by how well populated the rule table is (for checks implemented in code, such as insurance and actual treatment days, the program’s own coverage is precisely its detection power). ORCA’s check masters come in two lines, the supplied content (tbl_chk_master) and user-registered content (tbl_chk_user), so the design lets a provider add its own rules. The value of commercial receipt checking software, pushed to its conclusion, also lies in how well populated its proprietary rule table is.
3. Now that some of the assessment side’s rules are published, “how to take the assessment side’s published rules into your own checking” has become a new practical theme. The significance of their being provided as machine-readable published CSV should not be lost on an engineer.

9. Practical points — what the system side can do to improve checking accuracy

A summary of the points worth grasping if you work in a provider’s IT team or for an integration vendor.

1. Map the multi-stage check structure onto your operations. The three stages — input time (the contraindication API and similar), monthly (the data check), pre-submission (the rece-den check) — have different roles. If your practice is “run the data check once at month end”, there is room to make use of the two upstream stages.
2. The data check can be automated via the API. With datacheckv3 you can set up scheduled runs specifying check items and target patients. Turn it into an overnight batch plus a morning error list and you spread the month-end checking load across the days.
3. Treat exception registration as “tuning the rules”. Leave false positives in place and nobody reads the error list any more. Maintaining exceptions (tbl_chkreigai) and your own rules (tbl_chk_user) deliberately, so as to keep the signal-to-noise ratio of the error list high, is the lifeline of checking work.
4. Feed the results of returned claims and downcoding back into an analysis loop. Tally the reasons on the point adjustment notices and reflect the frequent patterns in your own check master rules and in input-time practice — that is what “growing the rule table” means, and it is the only way to narrow the perception gap with the assessment side.
5. Read the assessment side’s published material regularly. The Payment Fund’s computer check disclosure keeps being updated. In an era when the assessment side explains officially what it looks at — including its explanations of the cross-matching and longitudinal reviews — there is no excuse for not reading it.

10. Summary

• A receipt passes through a multi-stage series of checkpoints: 1. the receipt computer’s content check → 2. the rece-den data check → 3. the assessment side’s computer checks (plus cross-matching and longitudinal review) → 4. staff and the review committee. A returned claim means it comes back; downcoding means points are cut; and the cross-matching review, which pairs receipts from other organisations, cannot be substituted for inside a healthcare provider (comparison against your own previous months is possible in-house).
• ORCA’s data check is implemented as the orca41 function, and rules for approved indications, contraindications, combination claiming and so on are held as data in the check masters (basic consistency checks such as insurance and actual treatment days live in the code). You select which check items to run, suppress false positives through exception registration, and can drive it externally via the datacheckv3 API — all of which can be confirmed from the published source.
• The assessment side also publishes its rule tables — head-office checking conditions plus check masters — as CSV, so the provider side and the assessment side have the same “rule table plus engine” structure. The differences are the comprehensiveness of the rules and the scope of inspection (only the assessment side can see all organisations and all months).
• What determines checking accuracy is not the engine but how well populated the rule table is and how it is operated. Exception registration, your own rules, an analysis loop over downcoding results, and taking in the assessment side’s published rules are the practical essentials.

Upcoming instalments in this series are planned to include a “database edition” that reads ORCA’s database schema directly, and the practicalities of running diff monitoring to track the monthly source releases automatically.

11. References

• Disclosure Relating to Computer Checks — Social Insurance Medical Fee Payment Fund (CSV publication of head-office checking conditions and check masters)
• Cross-Matching Review and Longitudinal Review — Social Insurance Medical Fee Payment Fund
• Receipt checking, assessment, returned claims, downcoding, requests for re-assessment and more — Tokyo Medical Association, “Key Points of Insured Medical Practice for Private Practitioners”
• Nichi-Rece Outpatient Edition Manual (data check topics) — ORCA Project
• Rece-den Data Check: Check Condition Specification — ORCA Project
• Nichi-Rece core 5.2-series source code (snapshot published July 2026): lddef/orca41.ld / cobol/orca41/ORCGD*.CBL / cobol/copy/CPCHK.INC / record/tbl_chk*.db / record/xml_data_checkv3req.db / screen/D01.glade / screen/D04.glade / screen/X91.glade / lddef/api01rv2.ld (contraindicationcheckv2) and others — every statement about the implementation in this article is based on that snapshot

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

What is the difference between downcoding and a returned claim?

Both terms relate to the assessment carried out by the claims review and payment bodies (the Social Insurance Medical Fee Payment Fund and the National Health Insurance Federations), but they mean different things. A returned claim (henrei) is a receipt sent back to the healthcare provider; the provider can correct the entry error or eligibility error and re-submit it in a later month. Downcoding (satei) means the points on the claim are adjusted up or down as a result of the assessment (in practice almost always down), so the claimed amount falls accordingly. If you disagree with a downcoding decision, there is a procedure for requesting a re-assessment.

How many times is a receipt checked before it is submitted?

Broadly speaking, it passes through several stages of checking. Inside the healthcare provider there is the content check performed by the receipt computer (in ORCA, the data check function), and the rece-den data check, which inspects the electronic receipt file as claim data. After submission come the computer checks run by the claims review and payment bodies (checking conditions based on official notices and circulars, plus check masters based on drug package inserts), the cross-matching review that pairs a single patient's medical and dispensing receipts, and the longitudinal review that compares the claim against previous months — followed by assessment by staff members and the review committee.

How is receipt checking implemented in ORCA (Nichi-Rece)?

It is implemented as the data check function (business menu 41), and you can confirm the implementation in the published source code. The rules covering the relationship between drugs and procedures (drug versus diagnosis, procedure versus diagnosis, contraindicated drug combinations and so on) are held as data in a family of tables called the check masters, with COBOL programs interpreting them to inspect patient data — a classic "rule table plus engine" structure. Basic checks such as insurance consistency and the actual number of treatment days are implemented directly in the program code. There are also facilities for registering exceptions (do not check this particular error) and an API (datacheckv3) for launching the data check from an external system.

Are the check rules used by the claims review and payment bodies published?

Some of them are. Under the heading "Disclosure Relating to Computer Checks", the Payment Fund publishes both its head-office checking conditions, derived from official notices and circulars, and its check masters, derived from drug package inserts, as CSV files — and it keeps widening the scope in stages. The mechanisms of the cross-matching review and the longitudinal review are also explained on the official site. That said, some checks are not published, including cases that require inspection of the remarks column or that call for clinical judgement.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.