老D侃械系列，转载请注明
00:17，注册系统弹出一行字 “请补充最小销售单元 DI。”周工盯着屏幕，仓库里刚刚扫过的六码标签还在发绿光。所有人都说：码能扫，数据库也传了，怎么偏偏卡在最后十分钟？
一场本来准备庆功的加班
晚上十一点四十七分，项目群里连续冒出三张照片：小盒能扫，十盒中箱能扫，外箱也能扫。小林把扫码枪举得像刚拿到奥运火炬：“三层包装，全绿。”供应链同事已经问明天是不是能按计划发货。周工没有说话，他在等最后一个页面——注册管理系统。
系统：最小销售单元 DI：未匹配。
小林：它明明就在小盒上！昨天还往 UDI 数据库上传了。
周工：这就像快递单能被扫描，不等于收件地址写对了。先别和系统讲道理，它没有耳朵。
会议室安静了两秒。扫码枪还在桌上闪着绿灯，像一个过早宣布胜利的裁判。
第一坑：能扫出来，只说明“码能被读”
UDI 最容易被误会成“做一个二维码”。其实二维码只是信息的载体，像快递单上的条码；它解决的是“怎么读”。真正的 UDI 管理，还要回答“读到以后，这到底是哪一个产品、哪一层包装、对应哪套受控资料”。
项目组回查后发现，小盒标签上的 DI 是新版本；数据库里留的却是旧型号的 DI。扫码枪当然不介意，它只管把字符念出来。系统也不介意，它只看字符能不能和该有的产品身份对上。两边都很敬业，夹在中间的项目组只好加班。
第二坑：小盒、十盒、外箱，不是一个“包装皮肤”
大家又打开包装资料。小林指着外箱说：“里面装的还是同一个产品啊。”周工把白板笔帽拔开：“里面的人没变，不代表住址没变。”
最小销售单元、组合包装、运输包装，分别承担不同识别任务。装量、包装层级或关键识别特征变了，就要按企业采用的编码规则评估 DI 是否需要变化。不能只因为“盒里还是那个产品”，就让不同包装共用一张身份证。
他们终于找到第二个问题：小盒资料写的是“一盒 1 件”，中箱台账却沿用了“10 件/箱”的老描述，而实物已经改成“12件/箱”。它们像一户人家在户口簿、快递地址和物业登记上各写各的地址。平时没人敲门，出事时全都解释不清。
第三坑：上传数据库，不等于完成注册系统提交
这是最像“已经交了作业，老师却说没收到”的一步。UDI数据库上传，是把产品相关信息提供给数据库；而在适用实施要求的注册、延续注册或变更申报场景，还应按当次申报要求，在注册管理系统中提交相应的最小销售单元 DI 等信息。两个动作有关，但不是一个提交按钮。
法规同事：数据库里有，不代表申报表里就会自动长出来。
小林：那我们之前是在给两个系统分别喂饭？
周工：对，而且它们饭量不同，菜单也不同。
这一次，项目组并没有怪谁手慢。他们把“内部建码、标签赋码、数据库上传、注册系统提交”四个动作拆开，才看见原来每一步的责任人、输入资料和完成证据都不一样。
把一串码翻译成人话：DI 和 PI 到底管什么
· DI（产品标识）更像产品的身份证号：它帮助确认产品、型号规格及包装层级。不同包装层级或配置，不能想当然共用同一个DI。
· PI（生产标识）更像这一批货的行程单：可承载批号、序列号、生产日期、失效日期等生产相关信息。具体采用哪些内容，应结合产品追溯要求和编码规则。
· 码的载体负责“被扫到”；数据记录负责“被查明白”。把两件事混在一起，项目就很容易在绿灯中翻车。
最后救项目的，不是再开一次会，而是一张“总身份证表”
凌晨一点，周工没有再让大家各自翻 Excel。他新建了一张主数据表，只留一条产品身份主线：产品名称、型号规格、最小销售单元、各包装层级及装量、DI、标签版本、数据库记录、注册/备案与申报信息。每一项都标明来源、版本、责任人和变更日期。
· 先画包装树：从最小销售单元往外，逐层写清“装什么、装多少、用什么 DI”。
· 再做三方回查：拿实物扫码结果、UDI 数据库记录和注册/申报资料逐项对照，不靠记忆对号。
· 最后设变更闸门：型号、包装装量、标签版本或产品身份信息一变，先评估DI、数据库和申报资料是否要同步更新。
第二天早上，扫码枪终于不再背锅
他们补齐了最小销售单元的对应关系，纠正了旧型号记录，完成了必要的数据更新和申报资料核对。小林再次拿起扫码枪，还是熟悉的绿灯。只是这一次，没人喊“过了”。周工说：“先查一遍它在系统里叫什么。”
这篇真正想说的 UDI 的难点从来不是生成一串码，而是让标签、包装、数据库和注册申报里的同一个产品，始终说同一种语言。码能扫只是开场；数据对得上，才算收场。
结语：2027年6月1日起生产的全部第二类医疗器械（包括体外诊断试剂）和全部第一类体外诊断试剂应当具有医疗器械唯一标识，你们都准备好了吗？