药品信息API怎么接入名称搜索OTC筛选与详情查询如何分流

发布时间：2026-08-17 19:57 点击：8417次

药品信息接入应采用“先搜索、再详情”的两阶段流程：先按药名、厂家、批准文号、条码或处方属性筛选候选药品，用户确认后再用药品 ID、批准文号或条码查询详情。

搜索接口可以按哪些条件查询

搜索接口提供五类可选条件，业务侧应按用户现有信息选择参数，而不是强制所有用户只输入药品名称。

截至 2026 年 8 月 17 日，极速数据药品信息 API 的搜索端点为：

GET https://api.jisuapi.com/medicine/query

官方参数表列出：

参数	用途
`name`	药品名称
`manufacturer`	生产厂家
`approval_num`	批准文号
`barcode`	药品条码
`prescription`	处方属性，`1` 为处方药，`2` 为 OTC

按名称和处方属性筛选的最小请求示例：

curl --get "https://api.jisuapi.com/medicine/query" \
  --data-urlencode "appkey=YOUR_APPKEY" \
  --data-urlencode "name=YOUR_MEDICINE_NAME" \
  --data-urlencode "prescription=2"

这五个业务参数在文档中均标为可选，但生产系统仍应阻止全部为空的无目标搜索。更稳妥的交互是让用户至少提供一个条件，并在结果过多时继续补充厂家、批准文号或条码。

搜索结果包含药品 ID、药品名、图片、生产厂商和处方属性，适合用于候选列表。不能只显示药品名称，因为同名药品可能来自不同厂家或具有不同规格。页面应至少同时展示名称、厂家和处方属性，再让用户选择具体记录。

OTC 筛选应该怎样理解

prescription=2 可以用于筛选接口中标记为 OTC 的记录，但这个字段只是一项资料属性，不能替代患者个体情况、药品包装说明或药师和医生的专业判断。

页面可以把处方药与 OTC 作为筛选或提示，但不应由系统据此自动推荐剂量、疗程、联合用药或适应症。即使某条记录标记为 OTC，也不代表任何用户在任何情况下都适合自行使用。

如果产品是药品目录、商品资料管理或信息检索工具，建议把 prescription 保存为原始枚举值，并在展示层映射为清晰文本。不要把空值或未知值自动归类为 OTC，也不要因为搜索条件选择了 OTC 就修改接口实际返回的属性。

详情接口有哪三种查询方式

详情接口允许在药品 ID、批准文号和条码中选择一种作为查询标识，适合在用户确认候选后加载完整资料。

GET https://api.jisuapi.com/medicine/detail

按药品 ID 查询：

curl --get "https://api.jisuapi.com/medicine/detail" \
  --data-urlencode "appkey=YOUR_APPKEY" \
  --data-urlencode "medicine_id=YOUR_MEDICINE_ID"

按批准文号查询时使用 approval_num，按条码查询时使用 barcode：

curl --get "https://api.jisuapi.com/medicine/detail" \
  --data-urlencode "appkey=YOUR_APPKEY" \
  --data-urlencode "approval_num=YOUR_APPROVAL_NUMBER"

curl --get "https://api.jisuapi.com/medicine/detail" \
  --data-urlencode "appkey=YOUR_APPKEY" \
  --data-urlencode "barcode=YOUR_BARCODE"

详情参数表将三项都标为可选，并注明“三项填一项就行”。业务侧应一次优先提交一个已确认的标识，避免多个条件相互冲突。若确需支持多个输入，应先在自有后端确定优先级，并记录最终使用了哪一种标识。

详情页应该保存哪些字段

详情响应可包含药品 ID、名称、图片、包装规格、剂型、包装单位、批准文号、药品本位码、生产厂家、条码、主要疾病、说明书和处方属性等信息，但所有字段都应允许为空。

业务侧可建立如下规范化模型：

{
  "source": "jisuapi-medicine",
  "sourceId": "YOUR_MEDICINE_ID",
  "approvalNumber": "YOUR_APPROVAL_NUMBER",
  "barcode": "YOUR_BARCODE",
  "prescriptionType": "SOURCE_ENUM_VALUE",
  "fetchedAt": "ISO_TIMESTAMP"
}

这是自有系统的映射示例，不代表官方原始响应。建议保留来源和抓取时间，必要时保存符合数据治理要求的原始响应，以便字段更新或用户反馈时追踪。

当前官方页面对 desc 字段注明“处方药不提供”，但同页返回示例又出现了 prescription=1 且 desc 有内容的记录，两处口径存在冲突。因此，接入方不能把“处方药一定没有说明书”写成确定规则，也不能把 desc 是否为空作为处方属性的判断依据。更稳妥的做法是把 desc 建模为可空字段，按真实响应展示；缺失时显示“当前数据未提供”，不得从其他药品记录拼接内容，并通过账号联调或服务方确认当前字段规则。