RxNorm — 标准化药物概念

美国国家医学图书馆的标准化药物命名体系。美国医疗体系中的每一种处方药、非处方药和成分都有一个 RxCUI（稳定的概念 ID）。RxNorm 将混乱的药物命名规范化："Tylenol"、"acetaminophen" 和 "APAP" 都指向同一个成分概念。免费，无需认证。

属于 Pipeworx —— 一个连接 AI 代理与 1476+ 个实时数据源的 MCP 网关。

为什么这对 AI 代理很重要

药物数据是出了名的混乱。品牌名、通用名、盐形式、剂量强度、剂型——同一种分子，几十种字符串。RxNorm 为你提供规范 ID，可用于交叉引用 FDA 数据、药物相互作用数据库、EHR 系统和临床试验。

三个核心流程：

1. 解析名称。 "Ozempic 是什么？" → rxnorm_search({name: "ozempic"}) → 按术语类型（SBD、BN、IN 等）分组的概念，附带 RxCUI。

2. 获取药物属性。 "这个 RxCUI 是什么？" → rxnorm_get_properties({rxcui}) → 成分名称、强度、剂型、品牌状态。

3. 药物相互作用——不可用。 NLM 于 2024 年 1 月停用了 RxNav 相互作用 API，且没有替代品，因此本包没有 rxnorm_interactions 工具，Pipeworx 也没有药物-药物相互作用数据源。pharma_safety_report 返回 FDA 标签自身的"药物相互作用"章节，它记录的是单一药物而非检查药物对；该文本中未出现的药物并不代表已通过安全审查。

如需结合 RxNorm + FDA + ClinicalTrials 进行完整的药物安全综合分析，请使用 [compare_entities({type: "drug", values})] 或 pharma_drug_profile 复合工具。

Related MCP server: MedData MCP Server

术语类型（TTY）——需要理解的重要概念

RxNorm 对每种药物有多个概念，处于不同的抽象层级：

对于跨数据源关联，当存在 IN（成分）RxCUI 时，始终优先使用它。不同国家的品牌药有不同的 SBD；IN 是全球通用的。resolve_entity({type: "drug"}) 按优先级顺序选择规范 RxCUI：IN > PIN > BN > SBD > 第一个可用项。

可引用 URI

pipeworx://rxnorm/concept/{rxcui}
pipeworx://rxnorm/concept/{rxcui}/interactions

RxCUI 是稳定且可共享的。

更新频率

RxNorm 每月发布更新。新药在 FDA 批准后一个月内出现；已停用的产品会被标记但保留在数据库中供历史查询。Pipeworx 以 24 小时 TTL 进行缓存。

常见陷阱

• 品牌查询只返回 SBD。 搜索 "Ozempic" 返回的是语义品牌药概念，而非成分。要得到 "semaglutide"，要么直接搜索通用名，要么对品牌 RxCUI 调用 rxnorm_related({rxcui, tty: "IN"})。后者在某些配置下目前存在 bug——参见错误恢复。

• 拼写比你想象的更重要。 "metformin hydrochloride" 和 "metformin HCl" 返回略有不同的概念集。搜索对常见缩写比较宽容，但对不太常见的缩写则要求精确。

• NDC 是不同的。 国家药品代码（NDC）是 FDA 颁发的包装级标识符，不是 RxCUI。如果你需要 NDC 用于处方配药数据，请使用 rxnorm_ndc({rxcui}) 进行桥接。

• 复方产品。 像 "Kombiglyze" 这样的药物含有 metformin + saxagliptin。搜索 "metformin" 可能会把复方产品作为最靠前的结果，这不是你在成分级分析中想要的。请筛选 SCD 或 IN，而不是直接取第一个结果。

• 已停用药物。 药物撤市后概念仍然存在。完整记录中的 obsolete 标志会告诉你该药物当前是否可用。

快速开始

添加到你的 MCP 客户端（Claude Desktop、Cursor、Windsurf 等）：

{
  "mcpServers": {
    "rxnorm": {
      "url": "https://gateway.pipeworx.io/rxnorm/mcp"
    }
  }
}

此端点实际提供什么

tools/list 位于 https://gateway.pipeworx.io/rxnorm/mcp，返回上表中的工具，以及共享的 Pipeworx 元工具——ask_pipeworx、discover_tools、search_within、remember/recall 以及其余网关级工具。因此你看到的工具数量比这个表更大：一个单包端点目前会列出大约 30 个共享工具以及该包自身的工具。连接的 initialize 响应会说明其确切范围，这是某一天最权威的答案。

这是有意为之，而非意外的多路复用。元工具的作用是让一个限定范围的连接能够回答本包未覆盖的问题——通过 ask_pipeworx，它会在整个目录中路由——而无需你添加第二个 MCP 服务器。目前没有办法在不包含这些元工具的情况下挂载一个包端点；如果额外的 schema 消耗的上下文比路由带来的价值更多，请一次性连接到完整网关，而不是连接多个包端点。

或者连接到完整的 Pipeworx 网关，直接列出每个包的工具，而不仅仅是这一个的：

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

两个 URL 都到达同一个网关和相同的 1476+ 个数据源。唯一的区别是哪个包的工具被直接列出；ask_pipeworx 从两者中的任何一个都能访问所有工具。

与 ask_pipeworx 一起使用

不必直接调用工具，你可以用纯英语提问——这在上述包端点和完整网关上都可以使用：

ask_pipeworx({ question: "your question about Rxnorm data" })

网关会选择正确的工具并自动填写参数。

更多

• 文档和指南

• pipeworx.io

许可证

MIT