保險人編號的8碼在說什麼 ── 從收費電腦的實作解讀法別編號・都道府縣編號・驗證編號

印在保險證(如今是My Number保險證的資格資訊畫面)上的保險人編號。這是診療報酬明細書申報中必然會出現的8碼(有時是6碼)數字，但知道「這個編號其實可以讀懂」這件事的工程師，恐怕意外地不多。開頭2碼就能看出所加入的制度，接下來2碼能看出保險人所在的都道府縣，末尾1碼甚至可以用來驗算──也就是說，保險人編號並非單純的連號，而是具有結構的編碼。

ORCA系列的第4篇，在此前預告過的診療報酬明細書點檢話題之前，先作為一期番外篇，單獨解剖這個保險人編號。本文將涉及以下4點。

• 保險人編號的結構 ── 法別編號・都道府縣編號・保險人別編號・驗證編號
• 驗證編號(check digit)的手工計算，以及ORCA的COBOL實作
• 唯有舊・政府管掌健康保險(現・協會健保)是「4碼」的歷史特例
• 該特例的痕跡，至今仍留存在2026年公開的ORCA原始碼中

制度層面的記述，以厚生勞動省的《保險人編號、公費負擔者編號、公費負擔醫療受給者編號並及醫療機構代碼及藥局代碼設定要領》(以下稱「設定要領」)為一手資料；實作層面則與前幾篇文章相同，基於實際閱讀官方公開的日レセ本體5.2系原始碼(2026年7月公開快照)後確認的結果。

目標讀者，以及本文使用的4個用語

本文設想的讀者，是開發或串接醫療機構相關系統(收費電腦・電子病歷・掛號與請款相關業務應用程式)的工程師，以及負責醫療資料匯入工作的資訊系統負責人。本文不預設診療報酬明細書申報方面的實務知識。只要掌握下面這4個詞就能讀懂，即便沒有讀過本系列前3篇，本文也能獨立成立。

收費電腦與電子病歷的關係，以及ORCA的整體樣貌，已在系列第1篇中說明。

目錄

1. 先講結論 ── 保險人編號由「制度+地區+連號+驗算」構成
2. 法別編號 ── 開頭2碼就能看出制度
3. 都道府縣編號與保險人別編號 ── 能看出具體是哪個保險人
4. 驗證編號 ── 手工計算模數10權重2-1方式
5. 例外的故事 ── 舊政管健保的保險人編號曾是「4碼」
6. 保險人編號「無法說明的事」
7. ORCA是如何實作的 ── 兩個主檔與碼數的分支
8. 給處理編號系統開發者的實務要點
9. 總結
10. 參考資料

1. 先講結論 ── 保險人編號由「制度+地區+連號+驗算」構成

設定要領第1條對保險人編號做出了如下規定。

不過，本則中還寫有一項例外。唯有國民健康保險(不含退休人員醫療)沒有法別編號，由都道府縣編號2碼+保險人別編號3碼+驗證編號1碼共計6碼構成。如果保險證上的保險人編號是6碼，光憑這一點就能知道「這是市町村國保或國保組合」。

直接借用設定要領中所舉的例子，06130488這個保險人編號可以這樣解讀。

06  13  048  8
│   │   │    └ 驗證編號(第4章會進行驗算)
│   │   └ 保險人別編號: 東京的組合中的第048號
│   └ 都道府縣編號: 13 = 東京
└ 法別編號: 06 = 組合管掌健康保險

也就是說，「東京都內的某家健康保險組合」，不用查主檔、僅憑編號本身就能知道到這一步。以下各章將依序看每個組成部分。

2. 法別編號 ── 開頭2碼就能看出制度

法別編號由設定要領別表1(1)「法別編號及制度略稱表」規定。以下摘錄主要的醫療保險制度。

解讀時有3個實務要點。

1. 診療報酬明細書的提交對象因此而異。 被雇用者保險(01〜34、63、72〜75)的診療報酬明細書要提交給社會保險診療報酬支付基金，國民健康保險(6碼以及法別67)與後期高齡者醫療(39)則要提交給國民健康保險團體聯合會。也就是說，診療報酬明細書申報世界裡「社保」「國保」這種區分方式，只要看保險人編號開頭就能機械式地判斷出來。
2. 明明屬於國保系統，卻有8碼的編號。 國保的退休人員醫療(67)雖然屬於國保制度，卻例外地帶有法別編號、是8碼。若把實作簡化為「6碼=國保、8碼=社保」，就會在這裡踩坑。
3. 並非1個保險人對應1個編號。 正如別表1的注記所述，63、72〜75是為特例退休被保險人設置的法別編號。同一個健康保險組合，可能同時持有多個保險人編號──面向一般被保險人的06號，以及面向特例退休被保險人的63號。

此外，還有一種與之十分相似的8碼編號，叫公費負擔者編號(生活保護的12、精神通院醫療的21等)。其結構也同樣是「法別2碼+都道府縣2碼+實施機構3碼+驗證1碼」，與前者極為相似，但這與醫療保險的保險人編號是不同的獨立體系。診療報酬明細書上也為其準備了單獨的記載欄。關於兩者混淆的注意事項，將在第6章中再作說明。

3. 都道府縣編號與保險人別編號 ── 能看出具體是哪個保險人

第3〜4碼的都道府縣編號，由設定要領別表2規定為01(北海道)〜47(沖繩)。其排列順序與一般常用的都道府縣代碼(JIS)相同，東京是13，大阪是27。判定基準是保險人的所在地，因此即使是有全國性人事調動的公司，只要其健康保險組合的所在地在東京，編號就會是13。

第5〜7碼的保險人別編號，是在同一制度・同一都道府縣範圍內，按保險人逐一分配的號碼。通知中也明確寫明了由誰來決定這個號碼──依現行規定，協會健保依都道府縣支部由厚生勞動省保險局設定，組合健保依健康保險組合由地方厚生(支)局設定，國保依市町村・國保組合由都道府縣設定，後期高齡者醫療由後期高齡者醫療廣域聯合會設定，共濟組合則由各主管機關設定(昭和51年制定之初，設定者原為社會保險廳長官或都道府縣知事，隨著行政組織的改組，已陸續移交給現行機構)。

也就是說，保險人編號並非在全國範圍內統一採號，而是在「制度×都道府縣」這一框架之內分散採號的編碼。單獨取出連號部分本身沒有意義，只有與法別編號・都道府縣編號組合在一起，才能唯一指定某個保險人。這一點，與後文將會看到的ORCA主檔設計(保險人主檔的鍵正是保險人編號本身)也是互相吻合的。

順帶一提，協會健保作為法人只有全國健康保險協會這一個整體，但保險人編號卻是依都道府縣支部分別分配的(平成20年9月18日廳保險發第0918001號)。這正是一個很好的例子，說明「保險人編號所識別的單位」與「作為法人的保險人」有時並不一致。

4. 驗證編號 ── 手工計算模數10權重2-1方式

末尾1碼驗證編號的計算方式，同樣以步驟的形式寫在設定要領中。

1. 對除驗證編號以外的各碼數字，以末位為起點依序乘以2和1
2. 求各乘積之和。若某個乘積為2碼，則取其個位數與十位數之和
3. 用10減去「上述總和的個位數」，所得結果即為驗證編號。若個位數恰為0，驗證編號也取0

這就是所謂的模數10權重2-1方式(M10W21)。用第1章的06130488來驗算一次。驗算對象是去掉驗證編號後的7碼0613048，權重以最右端的8為起點，依序賦予2、1、2、1……

總和為 0+6+2+3+0+4+7 = 22。個位數是2，所以驗證編號為 10 - 2 = 8，與06130488末尾的8一致(僅當個位數為0時，驗證編號才同樣取0)。

順帶一提，這個計算其實與信用卡卡號等所用的檢查數字演算法──Luhn演算法──本質上是相同的。Luhn演算法通常被描述為「從右端起每隔一碼將數字乘以2，若乘積超過9則減去9，再把所有數字相加，使總和成為10的倍數來決定末位」，但由於乘積最大也只有18，「減去9」與「把2碼數字拆成1碼分別相加」這兩種做法的結果是相同的。即便不熟悉M10W21這個名稱，只要寫過Luhn演算法，應該也能看出這是同一段程式碼。

寫成程式碼只需幾行。

def check_digit(code: str) -> int:
    """從去掉驗證編號後的保險人編號數字串中求出check digit"""
    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

由於醫療領域的業務應用程式多半以C#或COBOL撰寫，這裡也附上C#版本(在.NET Framework 4.x與.NET 8上都能原樣通過的語法範圍內)。

// 從去掉驗證編號後的數字串中求出check digit
public static int CheckDigit(string code)
{
    int total = 0;
    for (int i = 0; i < code.Length; i++)
    {
        // 以右端為起點，依序乘以 2,1,2,1… 的權重
        int digit = code[code.Length - 1 - i] - '0';
        if (digit < 0 || digit > 9)
        {
            throw new ArgumentException("包含非數字字元", nameof(code));
        }
        int n = digit * ((i % 2 == 0) ? 2 : 1);
        total += n / 10 + n % 10;   // 乘積為2碼時，拆成1碼數字分別相加
    }
    return (10 - total % 10) % 10;
}

// 對保險人編號(6碼的國保 / 8碼)的末位數字進行驗算。
// 舊政管的4碼編號沒有驗證編號，因此不在本函式的適用範圍內(第5章)
public static bool IsValidInsurerNumber(string number)
{
    if (string.IsNullOrEmpty(number)) { return false; }
    if (number.Length != 6 && number.Length != 8) { return false; }

    // 先檢查全部碼位。若只檢查末尾1碼，中間碼位混入非數字字元的
    // 輸入就會一路傳到CheckDigit，回傳的不是false而是ArgumentException。
    // 既然要經受OCR、條碼、手動輸入的考驗，這裡就應該徹底以bool回傳
    foreach (char c in number)
    {
        if (c < '0' || c > '9') { return false; }
    }

    int check = number[number.Length - 1] - '0';
    return CheckDigit(number.Substring(0, number.Length - 1)) == check;
}

// CheckDigit("0613048") == 8 / IsValidInsurerNumber("06130488") == true

這裡有一個實作上的陷阱。權重「2,1,2,1……」被定義為以右端為起點。實際上，若只看保險人編號，驗算對象的碼數是7碼(8碼編號)或5碼(6碼的國保)，都是奇數，所以即使從左端開始乘以2,1,2,1……，分配結果也會一樣(因為在奇數長度下，權重的排列本身左右對稱)。真正危險的是把這套邏輯原樣挪用到偶數碼編號上的那一刻。比方說公費負擔醫療的受給者編號，由受給者區分6碼+驗證編號1碼構成，驗算對象是6碼、偶數。以左端為起點寫成的實作，在這裡全部碼位的權重就會錯開一位，回傳一個不同的值。這個問題惡劣的地方在於──如果只用保險人編號做測試，永遠也不會發現。

有意思的是，ORCA的原始碼中恰好留有這個陷阱的痕跡。負責統一承擔check digit計算與驗證的共用子程式cobol/common/ORCSCHKDGT.CBL(元件名稱「チェックデジット算出(チェック)」，即「check digit計算(檢查)」)，是一個不限於保險人編號、可接收最多20碼數字編號的通用常式，但其修改履歷中寫著這樣一條。

*  程式修改履歴
* Maj/Min/Rev  修改者       日期      內容
*  01.00.01    MCC-太田     01/04/17  將算式的運算方式改為從右端開始

在2000年12月新建之後4個月，即2001年4月，加入了一條「將算式的運算方式改為從右端開始」的修改──閱讀被註解掉但仍留存的舊程式碼可以看出，初版是從左端開始依序乘以權重的。如前所述，奇數碼的保險人編號即便以左端為起點，結果也會碰巧一致，因此這個錯誤只有在驗證偶數碼編號時才會浮現。修改後的程式碼，把數字串右端的索引取為IDY，一邊遞減IDY一邊以右端為起點乘以權重，乘積為2碼時就拆分為WRK-CD2-1 + WRK-CD2-2相加，最後回傳10 - (總和 mod 10)，是與設定要領所述步驟完全一致的實作。25年前修改履歷中的這一行，至今依然可以原樣當作一條注意事項來用──「check digit要以右端為起點來寫。光靠奇數碼的測試可不能安心」。

5. 例外的故事 ── 舊政管健保的保險人編號曾是「4碼」

以上是原則。而保險人編號，還存在著歷史上最大的一項例外。設定要領第1條第7款中這樣寫道。

關於政府管掌健康保險(不含日僱特例被保險人保險)保險人編號的特例 政府管掌健康保險(……)的保險人編號，在當分之間，不論上述第1項及第3項，均以都道府縣編號2碼及保險人(市町村)別編號2碼組合而成的4碼號碼作為保險人編號，此時的都道府縣編號，依社會保險事務所所在地的都道府縣，採用別表3所定的號碼。

協會健保的前身──政府管掌健康保險(政管健保)，是中小企業員工所加入、依加入人數計為國內最大級的制度。這一最大制度的保險人編號，卻是

1. 不是8碼而是4碼(沒有法別編號，甚至也沒有驗證編號)
2. 都道府縣編號用的不是通常的別表2，而是專用的別表3
3. 保險人明明只有國家這一個，編號卻是依社會保險事務所逐一分配的

這三重特例。別表3的號碼與通常表相比幾乎毫無相似之處。

這項特例以「當分之間」的名義持續了數十年，直到2008年10月1日全國健康保險協會(協會健保)成立才終於解除。在現行的要領(昭和51年通知的現行版)中，協會健保的保險人編號已規定為依都道府縣支部制定的8碼號碼(前述・廳保險發第0918001號)。法別編號則與政管時代相同，仍是01。

ORCA原始碼中殘留的「政管」痕跡

制度層面這件事在2008年就已經結束，但收費電腦仍要持續處理舊資料。在2026年公開的ORCA 5.2系原始碼中，政管4碼時代的痕跡如今依然「在役」地留存著。

其一：以碼數推測制度的分支。 患者登記的保險輸入檢核子程式cobol/orca12/ORCSP03A.CBL，先將輸入的保險人編號碼數限定為4、6、8三者之一(否則報錯)，再針對保險人主檔中尚未登記的編號，從碼數推測制度(ORCA內部的「保險編號」)。

*        依法別編輯
EVALUATE    WRK-MOJ-MAX
    WHEN    4
*                政府管掌
        MOVE    "001"           TO  WRK-HKNJA-HKNNUM
    WHEN    6
*                國保
        MOVE    "060"           TO  WRK-HKNJA-HKNNUM
    WHEN    8
*            其他
        PERFORM 1003-HKNNUM-HBTNUM-SEC
END-EVALUATE

若為4碼則判定為政府管掌(內部代碼001)，6碼則為國保(060)，8碼則以開頭2碼的法別編號去查主檔。 第1〜3章所見的編號體系知識，就這樣原樣變成了COBOL裡的分支處理。而由於4碼的政管編號沒有驗證編號，緊接其後的模數10檢查也只在「碼數大於4」時才會執行。這項特例，甚至波及到了驗算邏輯本身。

其二：政管與協會的轉換。 資料遷移・匯入端也有對應處理。在患者保險資訊匯入批次cobol/orcabt/ORCVTPTHKNINF.CBL中，有這樣一段。

*    針對協會健保的處理
IF      PTHKN-HKNNUM        =   "001"
*        政管情況下若保險人編號為8碼，則判定為協會
    IF      WRK-LEN             =   8
        MOVE    "009"           TO  PTHKN-HKNNUM
    END-IF
END-IF

也就是「以政管(001)的身分傳入，但保險人編號若為8碼，則改判為協會健保(009)」的處理。在內部實作上，舊・政管與現・協會健保是作為兩個不同的「保險編號」共存的，碼數正是區分新舊的線索。在診療報酬明細書彙總端的cobol/orcabt/ORCBG014.CBL中，001與009被歸入同一分類，並附有「政管會變更為協會」的註解。

其三：顯示名稱的改寫。 最具代表性的，是保險名稱編輯共用常式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

協會健保成立日20081001被嵌入程式碼作為常數，只要診療日在此之後，制度簡稱中所含的「政管」字樣就會被替換為「協会」。主檔上的名稱仍保持舊貌，只是依診療日切換顯示──也就是說，對2008年9月30日以前的診療而言，至今仍會顯示為「政管」。制度的歷史，就這樣靠一行字串替換程式碼，在執行時被重現出來。

6. 保險人編號「無法說明的事」

前面一直在追問「能知道到什麼程度」，這裡也劃出邊界線來。以下是保險人編號無法說明的事情。

• 無法鎖定具體個人。 保險人編號所指向的，只到保險人(這個單位)為止。個人的識別，由保險證上的記號・號碼(以及線上資格確認個人單位化後新增的2碼枝號)來負責。在上一篇看到的線上資格確認中，查詢條件同樣是「保險人編號+記號・號碼+枝號」這一組合。
• 無法決定自付比例。 法別編號能看出制度，但窗口自付比例會因年齡、所得區分而變化。「因為是39所以自付1成」這類想當然的判斷是大忌，自付比例應依資格確認的結果(高齡受給者證・限度額認定資訊等)來判定。
• 看不出保險人的名稱・聯絡方式。 從編號能知道「東京的組合健保048號」，但那具體是哪個組合，只有與保險人主檔核對後才能得知。編號體系提供的只是一個檢索鍵。
• 與公費負擔者編號是完全不同的世界。 生活保護(法別12)、自立支援醫療(21)等8碼號碼屬於公費負擔者編號，其編號是在與保險人編號的法別編號表不同的另一張表上採號的。由於兩者同樣是「8碼・法別2碼+都道府縣2碼+3碼+驗證1碼」的結構，若只看格式就將二者混為一談，會釀成事故。診療報酬明細書上，保險與公費也是分開的兩欄。

7. ORCA是如何實作的 ── 兩個主檔與碼數的分支

以下整理第5章所見分支背後、ORCA圍繞保險人編號的資料設計。登場的主檔主要有兩個。

保險編號主檔tbl_hknnum是「制度」這一層。制度由3碼的內部代碼「保險編號」(001=政管、009=協會健保、060=國保、039=後期高齡者……)來標識。不過實際的主鍵並非保險編號單獨一項，而是包含醫療機構編號・適用起始日期・區分(HOSPNUM, HKNNUM, TEKSTYMD, PAYKBN)在內的複合鍵，如此一來，同一制度的記錄就能依適用期間疊加為多個「世代」保存──即使負擔比例等屬性因制度改定而變化，也能依期間正確取用。定義(record/tbl_hknnum.db)中除了法別編號HBTNUM、制度名稱SEIDONAME/簡稱TANSEIDONAME外，還排列著本人・家屬×住院・門診各自的負擔比例與上限金額等欄位。值得注意的是3個檢查區分欄位。

• HBTNUMCHKKBN ── 法別編號檢查區分
• KENSNUMCHKKBN ── (負擔者編號的)驗證編號檢查區分
• JKYSKENSNUMCHKKBN ── 受給者編號的驗證編號檢查區分

也就是說，是否對編號進行檢查，被做成了依制度而異的主檔設定。實際讀一下公費輸入檢核子程式cobol/orca12/ORCSP03B.CBL就會發現，負擔者編號的模數10檢查只在KENSNUMCHKKBN = "1"時才執行，而受給者編號在區分為"3"時，會被當作警告而非錯誤處理(確認後可以放行)。公費的受給者編號在不同自治體間混雜著有・無驗證編號的不同體系，因此才需要能透過資料來調整檢查強度。這種不把驗證邏輯直接寫死在程式碼裡、而是交由主檔配置的設計，可以說是這套收費電腦25年來應對制度多樣性所累積的智慧。

保險人主檔tbl_hknjainf是「保險人」這一層。其鍵是醫療機構編號+保險人編號本身，保存著保險人名稱・郵遞區號・地址・電話號碼・保險證上的記號，以及所屬的制度(保險編號)(record/tbl_hknjainf.db)。第5章ORCSP03A.CBL的處理順序，正是以這個兩層結構為前提。

1. 若保險人編號的碼數不是4、6、8之一，立即報錯
2. 先檢索保險人主檔(tbl_hknjainf)。若已登記，名稱・地址・給付比例・制度均已確定
3. 若未登記，僅在碼數超過4碼時，以模數10進行驗算(呼叫ORCSCHKDGT)
4. 從碼數與法別編號推測制度(4碼→政管，6碼→國保，8碼→以法別編號檢索tbl_hknnum)

也就是說，「能從編號體系推導出的內容」只是未登記時的備援方案，真正準確的答案始終以主檔為準，這是一種優先順序關係。第6章「從編號無法得知名稱」這一局限，在實作層面的答案，正是這套兩段式設計。

順帶一提，保存保險人編號的欄位HKNJANUM被定義為PIC X(08)──也就是8碼的字串，而非數值型別，並被650個以上的COBOL原始碼檔案所參照。開頭為0的編號(如法別01〜07等)若以數值型別保存，開頭的0就會遺失──下一章會提到這個注意事項，而型別的選擇從一開始就避開了這個問題。

8. 給處理編號系統開發者的實務要點

以下整理在設計・實作處理保險人編號(以及同類型的公費負擔者編號)的系統時應注意的要點。

1. 用字串保存，不要用數值保存。 法別01〜07號段的編號開頭是0。經過Excel一趟，開頭的0掉落變成7碼，是醫療資料串接中的經典事故。CSV匯入端，應設計成能偵測「碼數不足的編號」並予以拒絕或警告。
2. 假定碼數只有4、6、8這3種。 現行的新增資料是6碼(國保)和8碼，但過去資料中可能存在舊政管的4碼編號(第5章)。ORCA至今仍接受4碼輸入，正是出於對這段歷史的顧慮。若輕率地做「固定8碼・補零」這種正規化處理，就會在與舊資料或其他系統核對時產生不一致。
3. check digit驗證只對「可以驗證的編號」進行。 M10W21的驗算能力很強，但舊政管4碼編號沒有驗證編號，公費的受給者編號中也存在沒有驗證編號的體系。像ORCA那樣把「該對哪種編號做驗證」交給主檔設定、並區分使用警告與錯誤，是更貼近實戰的做法。
4. 依法別編號的分支要做成主檔驅動。 若要用法別編號來判斷提交對象(支付基金/國保連)等，請不要把「法別編號→制度」的對應表直接寫死在程式碼裡，而應保存在主檔(資料表)中。法別編號有著隨制度改革不斷新增的歷史，今後也可能繼續增加。
5. 不要把保險人編號和公費負擔者編號放進同一欄。 兩者結構相同，但體系不同(第6章)。建議在資料模型上也把它們設為不同的欄位，並在核對鍵中包含「編號種類」這項資訊。
6. 即便到了線上資格確認的時代，保險人編號依然在役。 隨著向My Number保險證遷移，需要留意記號・號碼的場景會減少，但在線上資格確認的查詢・回應XML中，InsurerNumber(保險人編號)依然健在，診療報酬明細書的申報對象判定也仍以保險人編號為基礎。請不要把它當成「遲早會消失的編號」，而應假定它會作為資格資訊的核心鍵長期存在來進行設計。

9. 總結

• 保險人編號是法別編號2碼+都道府縣編號2碼+保險人別編號3碼+驗證編號1碼共計8碼(僅國保為不含法別的6碼)。開頭2碼可知制度與申報對象(支付基金/國保連)，接下來2碼可知保險人所在的都道府縣。
• 末位的驗證編號採用模數10權重2-1方式。權重以右端為起點，在奇數碼的保險人編號上，即便誤以左端為起點實作也會碰巧一致，但一旦挪用到偶數碼的編號(如公費的受給者編號)上就會失效。ORCA的共用子程式ORCSCHKDGT.CBL留有2001年「將算式的運算方式改為從右端開始」的修改履歷。
• 最大的例外是舊・政府管掌健康保險。以「當分之間」的名義運行了數十年、使用專用的都道府縣編號表的4碼號碼(既無法別編號也無驗證編號)，直到2008年10月協會健保成立才改為8碼化。
• ORCA的原始碼中，「4碼→推定為政管」的分支、「8碼則改判為協會健保」的匯入處理、「診療日在2008年10月1日以後就把顯示名稱中的『政管』替換為『協会』」的處理──這項特例的痕跡，作為2026年仍在使用的現役程式碼留存至今。
• 從編號能知道的，只到保險人這個單位為止。個人・自付比例・保險人名稱都無法得知。以「制度主檔+保險人主檔」的兩層結構來保存資料，把基於編號體系的推測僅作為未登記時的備援方案──這正是ORCA的做法，也可以應用到一般的編號處理系統中。

系列下一篇，將依照最初的預告，介紹診療報酬明細書的點檢・審定邏輯。醫療機構內部的資料檢核，與審查支付機構端的電腦檢核各自關注什麼，同樣會基於原始碼與公開資料進行拆解。

10. 參考資料

• 保險人編號、公費負擔者編號、公費負擔醫療受給者編號並及醫療機構代碼及藥局代碼設定要領(厚生勞動省・平成20年3月版 別添2 PDF) ── 正文中關於結構・驗證編號計算步驟・法別編號表(別表1)・都道府縣編號表(別表2)・政管特例(第1條第7款)及專用編號表(別表3)的引用來源
• 關於保險人編號等的設定(昭和51年8月7日廳保發第34號・保發第45號，現行版) ── 將協會健保的保險人編號規定為依都道府縣支部分配的號碼(平成20年9月18日廳保險發第0918001號)的現行規定
• 關於保險人編號 - 協會健保(全國健康保險協會) ── 依都道府縣支部劃分的現行保險人編號一覽
• 日レセ本體5.2系原始碼(2026年7月公開快照) 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.db 等 ── 正文中關於實作・修改履歷・資料表定義的記述，皆基於這一快照

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

保險人編號可以鎖定個人嗎？

無法。保險人編號能識別的，只到「是哪個保險人(協會健保○○支部、○○健康保險組合、○○市的國保等)」為止。個人的識別是由保險證上的記號・號碼(包含線上資格確認個人單位化後新增的2碼枝號)負責，這與保險人編號是不同的項目。

為什麼有的保險證保險人編號是6碼，有的是8碼？

這是因為只有國民健康保險(不含退休人員醫療)被規定為不帶法別編號的6碼(都道府縣編號2碼+保險人別編號3碼+驗證編號1碼)。被雇用者保險(協會健保・組合健保・共濟等)、後期高齡者醫療，以及國保的退休人員醫療(法別67)，則是在開頭加上法別編號2碼而成的8碼。

保險人編號最後1碼是什麼數字？

是驗證編號(check digit)。除末位外的各碼，從右端起依序乘以2、1、2、1……，若乘積為2碼則拆成兩個1碼數字相加，將所得總和的個位數用10減去(個位數為0時驗證編號也為0)，得到的結果就是驗證編號。這就是所謂的模數10權重2-1方式，輸入錯誤中的大部分都能靠這1碼檢測出來。

早期的協會健保(政府管掌健康保險)保險人編號是4碼，這是真的嗎？

是真的。厚生勞動省的設定要領中明確寫有這樣一條特例：「政府管掌健康保險的保險人編號，在當分之間(過渡期間內)，以都道府縣編號2碼+保險人別編號2碼共計4碼構成」。而且都道府縣編號用的還是與通常表不同的專用表(東京=21、大阪=41等)。隨著2008年10月協會健保成立，該編號已切換為按都道府縣支部劃分的8碼編號。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。