What Do the Eight Digits of an Insurer Number Tell You? — Law-Type Numbers, Prefecture Numbers and Check Digits Read from a Receipt Computer's Implementation
· Go Komura · Medical IT, ORCA, Insurer Number, Receipt Computer, Medical Fee Claims, Medical Office Administration
The insurer number printed on a health insurance card (nowadays, on the eligibility information screen of a My Number health insurance card). It is the eight-digit (sometimes six-digit) number that always turns up in receipt claims — but surprisingly few engineers know that “this number can actually be read”. The first two digits tell you which scheme the person belongs to, the next two tell you which prefecture the insurer is in, and the last digit lets you verify the whole thing. In other words, an insurer number is not just a serial number but a code with structure.
The fourth article in the ORCA series sets aside the receipt checking topic we had trailed and dissects the insurer number as a standalone side piece. We cover four things.
- The composition of an insurer number — law-type number, prefecture number, per-insurer number, check digit
- Calculating the check digit by hand, and ORCA’s COBOL implementation of it
- The historical special provision under which only the old Government-Managed Health Insurance (now Kyokai Kenpo) had “four digits”
- The traces of that special provision still alive in the ORCA source published in 2026
For the regulatory side the primary source is the Ministry of Health, Labour and Welfare’s “Guidelines for Setting Insurer Numbers, Public-Funding Payer Numbers, Recipient Numbers for Publicly Funded Medical Care, Healthcare Provider Codes and Pharmacy Codes” (hereafter “the setting guidelines”); for the implementation side, as in the previous instalments, the statements are based on actually reading the officially published Nichi-Rece core 5.2-series source (the snapshot published July 2026).
Table of Contents
- The conclusion first — an insurer number is “scheme + region + serial + checksum”
- The law-type number — the first two digits tell you the scheme
- The prefecture number and the per-insurer number — down to which insurer it is
- The check digit — working modulus 10 weight 2-1 by hand
- The exception — the old Government-Managed Health Insurance had “four digits”
- What an insurer number does not tell you
- How ORCA implements it — two masters and a branch on digit count
- Practical points for those building systems that handle these numbers
- Summary
- References
1. The conclusion first — an insurer number is “scheme + region + serial + checksum”
Article 1 of the setting guidelines defines the insurer number as follows.
| Position | Digits | Name | Meaning |
|---|---|---|---|
| Digits 1–2 | 2 | Law-type number | The medical insurance scheme (Kyokai Kenpo, society-managed health insurance, Late-Stage Elderly Medical Care…) |
| Digits 3–4 | 2 | Prefecture number | The prefecture where the insurer is located |
| Digits 5–7 | 3 | Per-insurer number | The number of the individual insurer within that scheme and prefecture |
| Digit 8 | 1 | Check number | Check digit (modulus 10 weight 2-1) |
There is, however, an exception written into the main rule itself. National Health Insurance (excluding Retiree Medical Care) alone has no law-type number, giving six digits in total: 2-digit prefecture number + 3-digit per-insurer number + 1-digit check digit. If the insurer number on a card is six digits, that alone tells you it is either municipal NHI or an NHI association.
Taking the example given in the setting guidelines as it stands, the insurer number 06130488 reads like this.
06 13 048 8
│ │ │ └ Check digit (we verify it in section 4)
│ │ └ Per-insurer number: society no. 048 within Tokyo
│ └ Prefecture number: 13 = Tokyo
└ Law-type number: 06 = society-managed health insurance
So the number alone, without consulting any master, gets you as far as “one of the health insurance societies located in Tokyo”. The sections that follow look at each component in turn.
2. The law-type number — the first two digits tell you the scheme
Law-type numbers are defined in Appendix Table 1(1) of the setting guidelines, “Table of Law-Type Numbers and Scheme Abbreviations”. Here is an extract of the main medical insurance schemes.
| Law-type number | Scheme | Abbreviation |
|---|---|---|
| 01 | Kyokai Kenpo (health insurance managed by the Japan Health Insurance Association; formerly Government-Managed Health Insurance) | (協) |
| 02 | Seafarers’ Insurance | (船) |
| 03 / 04 | Insurance for day-labourer special-case insured persons (general medical care / special medical benefits) | (日) |
| 06 | Society-managed health insurance | (組) |
| 07 | Medical benefits for Self-Defence Force personnel and others | (自) |
| 31–34 | Mutual aid associations (national public servants / local public servants and others / police / public schools and private school promotion) | (共) |
| 39 | Late-Stage Elderly Medical Care | (高) |
| 63, 72–75 | Special-case retirees (specified health insurance societies / the various specified mutual aid associations) | (退) |
| 67 | Retiree Medical Care under the National Health Insurance Act | — |
| (none, 6 digits) | National Health Insurance (excluding Retiree Medical Care) | — |
There are three practical points to reading them.
- They determine where the receipt goes. Receipts for employee-based insurance (01–34, 63, 72–75) are submitted to the Social Insurance Medical Fee Payment Fund; those for National Health Insurance (six digits, and law-type 67) and Late-Stage Elderly Medical Care (39) go to the National Health Insurance Federations. The distinction the claiming world calls “shaho” versus “kokuho” can be determined mechanically just by looking at the start of the insurer number.
- Some NHI-family numbers are eight digits. NHI Retiree Medical Care (67) is exceptionally an eight-digit number with a law-type number despite being part of the NHI scheme. Simplify this to “6 digits = NHI, 8 digits = employee insurance” in your implementation and this is where you fall through.
- One insurer does not mean one number. As the notes to Appendix Table 1 state, 63 and 72–75 are law-type numbers for special-case retiree insured persons. The same health insurance society can hold several insurer numbers — an 06 number for its ordinary insured persons and a 63 number for its special-case retirees.
There is also a very similar eight-digit number, the public-funding payer number (12 for Public Assistance, 21 for outpatient psychiatric care, and so on). Its composition — 2-digit law type + 2-digit prefecture + 3-digit implementing body + 1-digit check — looks identical, but it is a separate code system from the medical insurance insurer number. Receipts even have separate entry columns for them. We return to the risk of confusing the two in section 6.
3. The prefecture number and the per-insurer number — down to which insurer it is
The prefecture number in digits 3–4 is defined in Appendix Table 2 of the setting guidelines, running from 01 (Hokkaido) to 47 (Okinawa). The ordering is the same as the commonly used JIS prefecture codes: Tokyo is 13 and Osaka is 27. The criterion is where the insurer is located, so even for a company with nationwide transfers, if its health insurance society is based in Tokyo the number is 13.
The per-insurer number in digits 5–7 is the number assigned to each insurer within that scheme and prefecture. Who assigns it is set out in the circulars as well: under the current provisions, Kyokai Kenpo numbers are set per prefectural branch by MHLW’s Health Insurance Bureau; society-managed health insurance numbers per society by the Regional Bureaus of Health and Welfare; NHI numbers per municipality or NHI association by the prefecture; Late-Stage Elderly Medical Care numbers by the Late-Stage Elderly Medical Care wide-area unions; and mutual aid association numbers by each supervising ministry. (When the system was established in 1976 the assigning authorities were the Director-General of the Social Insurance Agency and prefectural governors, but these have passed to the present bodies as administrative organisations were reorganised.)
In other words, insurer numbers are not assigned centrally across the country but assigned in a distributed way within the frame of “scheme × prefecture”. The serial portion alone means nothing; only paired with the law-type number and prefecture number does it point uniquely to an insurer. This is consistent with ORCA’s master design, which we look at later (the key of the insurer master being the insurer number itself).
Incidentally, although Kyokai Kenpo is a single legal entity — the Japan Health Insurance Association — its insurer numbers are assigned per prefectural branch (Agency Insurance Notification No. 0918001 of 18 September 2008). It is a good example of how “the unit an insurer number identifies” and “the insurer as a legal entity” do not always coincide.
4. The check digit — working modulus 10 weight 2-1 by hand
The setting guidelines also give the procedure for calculating the final check number.
- Multiply each digit except the check digit by 2 and 1 in turn, starting from the last digit
- Sum the products; where a product has two digits, use the sum of its first and second digits
- The check digit is the difference between 10 and the last digit of the sum from step 2 — except that where that last digit is 0, the check digit is 0
This is the scheme known as modulus 10 weight 2-1 (M10W21). Let us verify it against 06130488 from section 1.
Digit: 0 6 1 3 0 4 8
Weight: 2 1 2 1 2 1 2 <- 2,1,2,1… starting from the right-hand end (8)
Product: 0 6 2 3 0 4 16
Sum: 0 + 6 + 2 + 3 + 0 + 4 + (1+6) = 22
Check digit: 10 - 2 = 8 ✓ (matches the final 8)
In code it is a few lines.
def check_digit(code: str) -> int:
"""Compute the check digit from the digits of an insurer number, excluding the check digit itself"""
total = 0
for i, ch in enumerate(reversed(code)):
n = int(ch) * (2 if i % 2 == 0 else 1)
total += n // 10 + n % 10
return (10 - total % 10) % 10
assert check_digit("0613048") == 8
Here is one implementation trap. The “2,1,2,1…” weighting is defined as starting from the right-hand end. As it happens, for insurer numbers specifically, the digit string being checked is seven digits (for an 8-digit number) or five (for a 6-digit NHI number) — both odd — so multiplying 2,1,2,1… from the left-hand end assigns exactly the same weights (with an odd length the weight sequence is symmetric). The danger comes the moment you reuse that routine on a number with an even digit count. For example, the recipient number for publicly funded medical care is a 6-digit recipient classification plus a 1-digit check digit — six digits under check, an even number. An implementation written from the left-hand end will have every weight shifted by one and will return a different value. The nastiness of it is that testing only with insurer numbers can never reveal it.
Amusingly, the ORCA source carries the traces of exactly this trap. The common subprogram that handles all check digit calculation and verification, cobol/common/ORCSCHKDGT.CBL (component name “check digit calculation (check)”), is a general-purpose routine that accepts numbers of up to 20 digits rather than insurer numbers specifically — and its revision history reads:
* Program revision history
* Maj/Min/Rev Modified by Date Content
* 01.00.01 MCC-Ota 01/04/17 Perform the arithmetic starting from the right-hand end
Four months after it was newly created in December 2000, in April 2001, a modification went in reading “perform the arithmetic starting from the right-hand end” — and reading the old code left behind commented out, you can see that the first version multiplied the weights starting from the left. As noted above, for odd-length insurer numbers the left-hand start happens to produce the same result, so the error only surfaces once you verify an even-length number. The corrected code takes the index of the right-hand end of the digit string in IDY, decrements IDY while applying the weights from the right, decomposes any two-digit product as WRK-CD2-1 + WRK-CD2-2 and sums them, and finally returns 10 - (sum mod 10) — the procedure of the setting guidelines exactly. A single line of revision history from twenty-five years ago still serves as a note to self: write check digits from the right-hand end, and do not let odd-length tests reassure you.
5. The exception — the old Government-Managed Health Insurance had “four digits”
Everything so far is the general rule. And insurer numbers had one historically enormous exception. Article 1, paragraph 7 of the setting guidelines says:
Special provision concerning the insurer number for Government-Managed Health Insurance (excluding insurance for day-labourer special-case insured persons) Notwithstanding paragraphs 1 and 3 above, the insurer number for Government-Managed Health Insurance (…) shall, for the time being, be the four-digit number formed by combining a 2-digit prefecture number and a 2-digit per-insurer (per-municipality) number, and the prefecture number in this case shall be the number set out in Appendix Table 3 for each prefecture in which the social insurance office is located.
Government-Managed Health Insurance (“seikan kenpo”), the predecessor of Kyokai Kenpo, was the scheme covering employees of small and medium-sized enterprises — among the largest in the country by membership. And the insurer number of that largest scheme was:
- Four digits rather than eight (no law-type number, and no check digit either)
- A prefecture number taken not from the usual Appendix Table 2 but from a dedicated Appendix Table 3
- Numbered per social insurance office, even though the insurer was a single body (the state)
— a triple exception. The numbers in Appendix Table 3 look nothing like those in the ordinary table.
| Prefecture | Ordinary prefecture number (Appendix Table 2) | Government-Managed only (Appendix Table 3) |
|---|---|---|
| Tokyo | 13 | 21 |
| Kanagawa | 14 | 31 |
| Aichi | 23 | 51 |
| Osaka | 27 | 41 |
| Fukuoka | 40 | 75 |
| Okinawa | 47 | 82 |
This special provision remained “for the time being” for several decades, and was only resolved when the Japan Health Insurance Association (Kyokai Kenpo) launched on 1 October 2008. Under the current guidelines (the current version of the 1976 circular), Kyokai Kenpo insurer numbers are eight-digit numbers assigned per prefectural branch (per the Agency Insurance Notification No. 0918001 cited above). The law-type number is 01, the same as in the Government-Managed era.
Traces of “seikan” left in ORCA’s source
The story ended in regulatory terms in 2008, but a receipt computer keeps handling old data. The ORCA 5.2-series source published in 2026 still carries live traces of the 4-digit Government-Managed era.
Trace 1: inferring the scheme from the digit count. The insurance input check subprogram used in patient registration, cobol/orca12/ORCSP03A.CBL, restricts the entered insurer number to 4, 6 or 8 digits (anything else is an error) and then, for numbers not registered in the insurer master, infers the scheme (ORCA’s internal “insurance number”) from the digit count.
* Edit based on the law type
EVALUATE WRK-MOJ-MAX
WHEN 4
* Government-Managed
MOVE "001" TO WRK-HKNJA-HKNNUM
WHEN 6
* National Health Insurance
MOVE "060" TO WRK-HKNJA-HKNNUM
WHEN 8
* Other
PERFORM 1003-HKNNUM-HBTNUM-SEC
END-EVALUATE
Four digits means Government-Managed (internal code 001); six means NHI (060); eight means look up the master by the leading 2-digit law-type number. The knowledge of the numbering system from sections 1–3 has become a COBOL branch, just like that. And because 4-digit Government-Managed numbers have no check digit, the modulus 10 check immediately before it only runs “when the digit count is greater than 4”. The special provision reaches all the way into the verification logic.
Trace 2: translating Government-Managed into Kyokai. There is handling on the data migration and import side too. The batch that imports patient insurance information, cobol/orcabt/ORCVTPTHKNINF.CBL, contains:
* Kyokai Kenpo support
IF PTHKN-HKNNUM = "001"
* If it came in as Government-Managed but the insurer number is 8 digits, treat it as Kyokai
IF WRK-LEN = 8
MOVE "009" TO PTHKN-HKNNUM
END-IF
END-IF
— that is, “if it arrived as Government-Managed (001) but the insurer number is eight digits, reinterpret it as Kyokai Kenpo (009)”. Internally, the old Government-Managed scheme and the current Kyokai Kenpo coexist as different insurance numbers, and the digit count is the clue that tells old from new. On the receipt aggregation side, cobol/orcabt/ORCBG014.CBL bundles 001 and 009 into the same classification, with a comment reading “Government-Managed is changing to Kyokai”.
Trace 3: rewriting the display name. The crowning example is the common routine for editing insurance names, cobol/common/ORCSHKNMEI.CBL.
01 CONST-H201001 PIC X(08) VALUE "20081001".
...
IF ( ORCSHKNMEI-SRYYMD >= CONST-H201001 )
AND ( COMB-HKNNUM = "001" )
INSPECT COMB-SYU-TANSEIDONAME
REPLACING ALL "政管" BY "協会"
END-IF
The Kyokai Kenpo launch date 20081001 is embedded as a constant, and if the treatment date is on or after it, the string “政管” (Government-Managed) in the scheme’s short name is replaced with “協会” (Kyokai). The name in the master stays as it was, and only the display is switched according to the treatment date — so treatment dated on or before 30 September 2008 still displays as “政管” today. The history of the scheme is reproduced at runtime by a single string replacement.
6. What an insurer number does not tell you
Having chased “how much can you tell”, let us also draw the boundary: the things an insurer number cannot tell you.
- You cannot identify an individual. An insurer number points only as far as the insurer (as a unit). Identifying an individual is the job of the symbol and number on the insurance card (and the two-digit branch number added when online eligibility verification moved to per-individual identification). In online eligibility verification, which we looked at last time, the query conditions were the combination of insurer number + symbol and number + branch number.
- It does not determine the co-payment rate. The law-type number tells you the scheme, but the amount payable at the front desk varies with age and income bracket. Shortcuts such as “39, so it’s 10%” are off limits; the co-payment rate is determined from the eligibility verification result (elderly recipient certificate, out-of-pocket limit certification information and so on).
- The insurer’s name and contact details do not come out of it. The number gets you as far as “society no. 048 among Tokyo’s society-managed health insurance”, but which society that is only becomes clear once you reconcile against the insurer master. The numbering system merely hands you a search key.
- Public-funding payer numbers are a different world. The eight-digit numbers for Public Assistance (law-type 12), Services and Supports for Persons with Disabilities medical care (21) and the like are public-funding payer numbers, assigned from a different table than the insurer number law-type table. Because the structure is identical — “8 digits: 2-digit law type + 2-digit prefecture + 3 digits + 1-digit check” — treating them as the same thing on the basis of format alone leads to accidents. On a receipt too, insurance and public funding have separate columns.
7. How ORCA implements it — two masters and a branch on digit count
Let us lay out the data design around insurer numbers in ORCA that sits behind the branch we saw in section 5. There are broadly two masters involved.
The insurance number master tbl_hknnum is the “scheme” layer. Schemes are identified by a 3-digit internal code, the “insurance number” (001 = Government-Managed, 009 = Kyokai Kenpo, 060 = NHI, 039 = Late-Stage Elderly…). The actual primary key, though, is not the insurance number alone but a composite key including the healthcare provider number, application start date and classification (HOSPNUM, HKNNUM, TEKSTYMD, PAYKBN), a structure that lets records for the same scheme be stacked as generations by applicable period — so when attributes such as co-payment rates change with a regulatory revision, they can be resolved by period. The definition (record/tbl_hknnum.db) contains the law-type number HBTNUM, the scheme name SEIDONAME and short name TANSEIDONAME, along with fields for co-payment rates and ceilings for each combination of principal/dependant × inpatient/outpatient. What is notable is the three check classifications.
HBTNUMCHKKBN— law-type number check classificationKENSNUMCHKKBN— check digit check classification (for the payer number)JKYSKENSNUMCHKKBN— check digit check classification for the recipient number
In other words, whether or not to apply number checking is a master setting per scheme. Indeed, reading the public-funding input check subprogram cobol/orca12/ORCSP03B.CBL, the modulus 10 check on the payer number only runs when KENSNUMCHKKBN = "1", and for the recipient number, classification "3" means it is treated as a warning rather than an error (you can confirm it and proceed). Recipient numbers for publicly funded care include systems without check digits that vary by local authority, so the strength of the check is made adjustable through data. This design — pushing validation out into the masters rather than writing it directly into the code — can fairly be called the wisdom of a receipt computer that has lived with regulatory diversity for twenty-five years.
The insurer master tbl_hknjainf is the “insurer” layer. Its key is the healthcare provider number plus the insurer number itself, and it holds the insurer’s name, postcode, address, telephone number, the insurance card symbol, and the scheme (insurance number) it belongs to (record/tbl_hknjainf.db). The processing order in ORCSP03A.CBL from section 5 presupposes this two-layer structure.
- If the insurer number’s digit count is anything other than 4, 6 or 8, error out immediately
- First search the insurer master (
tbl_hknjainf). If it is registered, the name, address, benefit rate and scheme are all settled - If it is not registered, verify with modulus 10 — but only for more than four digits (calling
ORCSCHKDGT) - Infer the scheme from the digit count and law-type number (4 digits → Government-Managed, 6 → NHI, 8 → search
tbl_hknnumby law-type number)
So “what can be derived from the numbering system” is the fallback for the unregistered case, and the priority is that the master is authoritative. This two-stage arrangement is the implementation’s answer to the limitation from section 6 that “the number does not tell you the name”.
Incidentally, the field that holds the insurer number, HKNJANUM, is PIC X(08) — defined not as a numeric type but as an 8-character string — and is referenced from over 650 COBOL sources. The choice of type sidesteps from the outset the caution in the next section: hold a number beginning with 0 (law types 01–07 and so on) as a numeric and the leading zero drops off.
8. Practical points for those building systems that handle these numbers
A summary of the key points when designing and implementing a system that handles insurer numbers (and the identically shaped public-funding payer numbers).
- Hold them as strings, not numbers. Numbers in the law-type 01–07 range start with 0. Losing the leading zero and ending up with seven digits the moment the data passes through Excel is a classic problem in medical data integration. On the CSV import side, design for detecting and rejecting — or warning about — “numbers with too few digits”.
- Assume three possible digit counts: 4, 6 and 8. Current new data is six digits (NHI) or eight, but historical data may contain the old 4-digit Government-Managed numbers (section 5). ORCA still accepting four digits is a concession to that history. Casually normalising everything to “8 digits, zero-padded” will cause mismatches when reconciling old data or data from other systems.
- Only apply check digit verification to numbers that have one. The M10W21 verification is powerful, but the old 4-digit Government-Managed numbers have no check digit, and some recipient number systems for publicly funded care have none either. The practical approach is ORCA’s: push “which numbers get verified” out into master settings, and distinguish warnings from errors.
- Make branching on the law-type number master-driven. If you use the law-type number to decide where a claim goes (Payment Fund or NHI Federation) or similar, do not hard-code the law-type-to-scheme mapping — hold it in a master table. Law-type numbers have a history of being added as the regulations change, and more may yet appear.
- Do not put insurer numbers and public-funding payer numbers in the same column. Identical structure, different code systems (section 6). Keep them as separate fields in the data model too, and include “the kind of number” in any reconciliation key.
- Insurer numbers are still current in the online eligibility era. The move to My Number health insurance cards means fewer occasions on which anyone thinks about symbols and numbers, but
InsurerNumber(the insurer number) is alive and well in the online eligibility query and response XML, and determining where a receipt is submitted is still insurer-number-based. Design on the assumption that it is not a number that will quietly disappear but one that will remain as a core key of eligibility information.
9. Summary
- An insurer number is 8 digits: a 2-digit law-type number + 2-digit prefecture number + 3-digit per-insurer number + 1-digit check digit (NHI alone has six digits with no law type). The first two digits tell you the scheme and where the claim goes (Payment Fund or NHI Federation); the next two tell you the insurer’s prefecture.
- The final check digit uses modulus 10 weight 2-1. The weights start from the right-hand end; with odd-length insurer numbers a left-hand-start misimplementation coincidentally agrees, but reuse it on an even-length number (such as a recipient number for publicly funded care) and it breaks. ORCA’s common subprogram
ORCSCHKDGT.CBLstill carries the 2001 revision history entry “perform the arithmetic starting from the right-hand end”. - The biggest exception was the old Government-Managed Health Insurance. It ran for decades “for the time being” on four digits using a dedicated prefecture number table (no law-type number and no check digit), and only became eight digits when Kyokai Kenpo launched in October 2008.
- ORCA’s source still carries the traces of that special provision as live code in 2026: a branch inferring Government-Managed from four digits, import handling that reinterprets eight digits as Kyokai Kenpo, and processing that replaces “政管” with “協会” in the display name when the treatment date is on or after 1 October 2008.
- What a number tells you stops at the unit of the insurer. The individual, the co-payment rate and the insurer’s name are not in there. Holding the implementation in two layers — scheme master plus insurer master — and confining inference from the numbering system to the unregistered-case fallback is the ORCA way, and it generalises to any system that handles structured numbers.
The next instalment in this series will, as originally trailed, cover the logic of receipt checking and assessment. We take apart what the data check inside the healthcare provider and the computer checks on the claims review and payment body side are each looking at, again using the source and public documents.
10. References
- Guidelines for Setting Insurer Numbers, Public-Funding Payer Numbers, Recipient Numbers for Publicly Funded Medical Care, Healthcare Provider Codes and Pharmacy Codes (MHLW, March 2008 version, Attachment 2, PDF) — the source for the composition described here, the check digit calculation procedure, the law-type number table (Appendix Table 1), the prefecture number table (Appendix Table 2), and the Government-Managed special provision (Article 1, paragraph 7) with its dedicated number table (Appendix Table 3)
- On the setting of insurer numbers and related matters (Agency Insurance Notification No. 34 / Insurance Bureau Notification No. 45 of 7 August 1976, current version) — the current provision making Kyokai Kenpo insurer numbers per-prefectural-branch numbers (Agency Insurance Notification No. 0918001 of 18 September 2008)
- About insurer numbers — Kyokai Kenpo (Japan Health Insurance Association) — the list of current insurer numbers by prefectural branch
- Nichi-Rece core 5.2-series source code (snapshot published July 2026):
cobol/common/ORCSCHKDGT.CBL/cobol/orca12/ORCSP03A.CBL/cobol/orca12/ORCSP03B.CBL/cobol/common/ORCSHKNMEI.CBL/cobol/orcabt/ORCVTPTHKNINF.CBL/cobol/orcabt/ORCBG014.CBL/record/tbl_hknnum.db/record/tbl_hknjainf.dband others — every statement about the implementation, revision histories and table definitions in this article is based on that snapshot
Related Articles
Recent articles sharing the same tags. Deepen your understanding with closely related topics.
Where Do Downcoding and Returned Claims Actually Happen? — Taking Apart Receipt Checking Logic Using ORCA's Source Code and Public Documents
Where do downcoding and returned claims actually happen? From ORCA's data check function and its check masters, through the rece-den data...
What Does the Electronic Prescription Change in a Receipt Computer? — Reading ORCA's Electronic Prescription Support in the Source Code
What does a receipt computer actually need in order to support electronic prescriptions? From the table design in ORCA (Nichi-Rece) that ...
What Happens When You Tap a My Number Health Insurance Card — Reading Online Eligibility Verification and Its Integration with the Medical Billing System from ORCA's Source Code
From tapping a My Number health insurance card to insurance eligibility landing in the medical billing system, explained through the end-...
Grasping the Whole Nichi-Rece API from the Source Code — Reading ORCA's Published Source (with a Mapping Table of All 137 Endpoints)
Grasping the whole picture of the Nichi-Rece API from the published source code of ORCA (the JMA Standard Receipt Software). Covers a map...
ORCA (Nichi-Rece) Is Not an Electronic Medical Record System — Medical Billing Systems and Healthcare IT Architecture from an Engineer's Perspective
ORCA (Nichi-Rece) is not an electronic medical record system — it is a medical billing system. From an engineer's perspective, this artic...
Related Topics
These topic pages place the article in a broader service and decision context.
Windows Technical Topics
Topic hub for KomuraSoft LLC's Windows development, investigation, and legacy-asset articles.
Where This Topic Connects
This article connects naturally to the following service pages.
Technical Consulting & Design Review
Designing business code systems such as insurer numbers and public-funding payer numbers, and settling on a validation policy for them, is a standard subject for technical consulting and design review on business systems — not only medical ones.
Windows App Development
Reception and claiming applications that include insurer number input validation and master reconciliation usually run on Windows machines inside a clinic or an office, which falls within Windows application development.
Frequently Asked Questions
Common questions about the topic of this article.
- Can you identify an individual from an insurer number?
- No. All an insurer number identifies is which insurer it is (a particular Kyokai Kenpo prefectural branch, a particular health insurance society, the National Health Insurance scheme of a particular municipality, and so on). Identifying the individual is the job of the symbol and number on the insurance card (including the two-digit branch number added when online eligibility verification moved to per-individual identification), which is a separate field from the insurer number.
- Why do some insurance cards have a 6-digit insurer number and others 8 digits?
- Because National Health Insurance (excluding Retiree Medical Care) alone is defined as having no law-type number, giving six digits (2-digit prefecture number + 3-digit per-insurer number + 1-digit check digit). Employee-based insurance (Kyokai Kenpo, society-managed health insurance, mutual aid associations and so on), Late-Stage Elderly Medical Care, and NHI Retiree Medical Care (law-type 67) all carry a 2-digit law-type number at the front, giving eight digits.
- What is the last digit of an insurer number?
- It is the check number (check digit). Each digit except the last is multiplied by 2, 1, 2, 1… starting from the right-hand end; where a product has two digits it is split into its individual digits and those are summed; and the check digit is 10 minus the last digit of that total (or 0 if that last digit is 0). This is the modulus 10 weight 2-1 scheme, and this single digit catches most input errors.
- Is it true that the old Kyokai Kenpo (Government-Managed Health Insurance) insurer numbers were only four digits?
- It is. The Ministry of Health, Labour and Welfare's setting guidelines contained an explicit special provision: "the insurer number for Government-Managed Health Insurance shall, for the time being, be the four digits formed by a 2-digit prefecture number plus a 2-digit per-insurer number". What is more, the prefecture number came from a dedicated table separate from the usual one (Tokyo = 21, Osaka = 41, and so on). With the launch of Kyokai Kenpo in October 2008, these were switched to eight-digit numbers assigned per prefectural branch.
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.
Public links