保险人编号的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方式(M10W21)，输入错误中的大部分都能靠这1位数字检测出来。

以前的协会健保(政府管掌健康保险)保险人编号是4位，这是真的吗？

是真的。厚生劳动省的设定要领中明确写有这样一条特例：「政府管掌健康保险的保险人编号，在当分之间(过渡期间内)，以都道府县编号2位+保险人别编号2位共计4位构成」。而且都道府县编号用的还是与通常表不同的专用表(东京=21、大阪=41等)。随着2008年10月协会健保的成立，该编号已切换为按都道府县支部划分的8位编号。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。