---
title: 药品对码标准化方案
description: 面向药店、医院和供应链系统，说明如何通过对码能力完成药品数据标准化。
sidebar_position: 1
---


# 药品对码标准化方案

本方案面向药店、医院、供应链系统、健康平台及其他需要管理药品商品库的业务场景，重点解决药品名称、包装、条形码、批准文号和生产企业表达不统一带来的标准化问题。

## 适用场景

- 药店商品库标准化与数据治理
- 医院药品目录补全与去重
- 多来源药品库合并后的主数据整理
- 扫码识别药品并补齐标准字段
- 需要把历史药品库映射到统一药品主数据体系

## 典型业务问题

在真实业务中，药品数据通常来自 ERP、HIS、供应链系统、人工录入或第三方库，不同来源之间常见以下问题：

- 同一药品存在多种包装写法，难以唯一匹配
- 条形码、批准文号、商品名和通用名之间缺乏稳定映射关系
- 原始库字段不全，无法直接用于医保、图片、说明书等下游业务
- 人工匹配成本高，且容易出现重复、漏匹配和错匹配
- 业务方希望保留原始数据结构，但又需要拿到一套稳定的标准化标识

## 推荐方案

药品对码方案建议按「优先自动命中、再做标准化补齐、最后再做结果确认」的方式落地。

### 1. 条形码优先命中

如果业务场景天然带条形码，例如扫码购药、药盒录入或零售终端识别，建议优先调用 [基础·条形码扫码](/doc/nc.ms.drug.detail.barcode/description)。

这个接口适合做：

- 扫码后快速识别商品
- 基于 69 码直接命中药品包装
- 获取 `drug_package_id`、批准文号级别 ID、通用名级别 ID 等标准标识

### 2. 通过包装信息做标准化映射

如果没有稳定条形码，或者需要批量整理历史药品库，建议调用 [高级·药品包装提交对码](/doc/nc.ms.drug.package.mapping/description)。

推荐最少传入以下字段：

- `generic_name`
- `package`
- `company_name`
- `source`
- `source_id`

这套方式适合：

- 老旧药品库批量对码
- 医院、药店、供应链系统对历史数据做标准化整理
- 保留原始库结构的前提下，引入唯一主数据标识

### 3. 根据任务结果做落库与追踪

提交对码后，可通过返回的 `task_id` 调用 [高级·药品包装对码结果查询](/doc/nc.ms.drug.package.mapping.result/description) 获取最新状态与结果。

建议在本地保留：

- 原始药品记录 ID，例如 `source_id`
- 对码任务 ID，例如 `task_id`
- 标准包装 ID，例如 `drug_package_id`
- 对码状态，例如 `state`

这样可以支持后续重试、人工复核和结果追踪。

## 推荐调用顺序

可按下面的顺序组合接口：

1. 有条形码时先调用 [基础·条形码扫码](/doc/nc.ms.drug.detail.barcode/document)
2. 无条形码或需要批量治理时调用 [高级·药品包装提交对码](/doc/nc.ms.drug.package.mapping/document)
3. 通过 [高级·药品包装对码结果查询](/doc/nc.ms.drug.package.mapping.result/document) 获取最终状态
4. 对已命中的 `drug_package_id`、批准文号或通用名 ID，再进入「药品信息」目录查询更完整的包装详情、说明书、批准文号等扩展数据

## 交付结果

完成标准化后，通常可以得到以下几类结果：

- 每条原始药品记录对应唯一的标准包装 ID
- 同一药品的重复表达被收敛到统一主数据
- 后续图片、说明书、批准文号、通用名等字段可继续补齐
- 药品检索、推荐、风控、目录治理等下游能力可以基于统一 ID 开展

## 实施建议

- 对历史数据批处理时，建议按 `source` 区分批次，便于回溯
- `source_id` 应保持业务侧唯一，避免结果回写混乱
- 自动匹配结果建议结合 `state` 做分层处理
  - `1` 表示自动成功匹配
  - `2` 表示人工成功匹配
  - `-1` 表示自动失败
  - `-2` 表示人工失败
- 对自动失败数据，建议单独建立人工复核流程，而不是直接丢弃

## 方案边界

药品对码方案解决的是「药品标准化映射」问题，而不是一次性补齐所有下游业务字段。

如果业务目标是构建完整的药品主数据能力，建议在对码完成后继续接入「药品信息」目录下的详情、说明书和更新时间等接口。