企业官网建设流程全解析

药品集中采购这个领域，外行看热闹，内行看门道。很多人第一次接触各省的药品集采平台，以为就是几个网页、几份公告，随手翻翻就完了。真要做分析、做比价、做趋势判断的时候才发现，这些平台的数据结构千差万别，字段命名五花八门，更新节奏各不相同，想把它们捏成一个能用的分析数据库，远比想象中麻烦。我这两年陆陆续续搭过几套面向地方集采的分析库，踩过的坑足够写一本小册子。这篇就把"各省药品集中采购平台-地方药品集采分析数据库"这件事拆开讲透，从为什么要自建、数据怎么摸、结构怎么设计，到清洗规则、更新机制和实际分析场景，尽量把能复现的东西都写出来。不管你是做医药数据分析的新手，还是已经有一版半成品想重构的老手，应该都能从里面找到能直接抄的部分。

1. 为什么地方集采数据值得单独建一个分析库

1.1 省级平台和国家级平台不是一回事

很多人下意识觉得，药品集采看国家级平台就够了。实际做过项目的人都知道，国家级平台更多承担的是规则发布、目录汇总和结果公示的职能，而真正落到"某省某市某医疗机构买了什么、什么价、什么量"这种颗粒度，绝大多数信息沉淀在省级甚至地市级的采购平台上。各省平台独立建设、独立运营，数据口径、披露频率、字段定义几乎没有统一标准。你要做跨省比价，光靠国家级平台的汇总表根本不够，必须回到省级平台去抓原始数据。

这就带来一个很现实的问题：省级平台的数据是"活的"，今天挂网价调整了，明天某个品规撤网了，后天又新增了一批带量采购的中选结果。如果只是临时去网页上看一眼，你看到的永远是切片，做不了时间序列分析，也没法回溯某个价格是什么时候变的。自建分析库的核心价值，就是把这些分散、动态、口径不一的数据固化下来，形成可查询、可对比、可追溯的结构化资产。

1.2 分析需求决定了库的形态

在动手之前，得先想清楚这个库到底要回答什么问题。根据我接触过的实际场景，地方集采分析库通常要支撑几类需求：跨省同一通用名下药品的价格对比、某个品种在各省的集采覆盖情况、中选企业与未中选企业的价格梯度、带量采购执行前后的价格变化趋势、以及按治疗领域或剂型做的结构性分析。这些需求对数据的要求完全不同——比价要求通用名、剂型、规格、转换比高度标准化；趋势分析要求有时间戳和版本记录；结构性分析要求有分类编码和标签体系。

所以这个库不能是简单的"网页数据搬运"，而要在采集层之上做一层标准化建模。我的经验是，先把分析场景列全，再倒推需要哪些字段、哪些维度表、哪些历史快照，最后才去设计采集和清洗流程。顺序反了，后面一定返工。

1.3 自建库和现成数据源的取舍

市面上确实有一些商业数据服务提供集采数据，但普遍存在两个问题：一是覆盖不全，往往只覆盖几个大省或者只覆盖带量采购部分，普通挂网采购的数据缺失；二是更新滞后，商业库的更新节奏受制于其采集能力，遇到平台改版就容易断档。对于要做深度分析或者长期跟踪的团队，自建库虽然前期投入大，但数据主权在自己手里，字段可以按需扩展，历史版本可以自己控制，长期看反而更划算。当然，如果只是做一次性的行业研究，买现成数据也未尝不可，这就看具体投入产出的权衡了。

2. 各省平台的数据形态摸底与采集策略

2.1 先摸清平台类型，再谈采集方式

省级药品集采平台大致可以分成几类：一类是独立建设的省级采购平台，页面结构相对规整，有明确的药品目录、价格公示、交易记录等栏目；一类是依托省级公共资源交易平台建设的子站点，入口深、栏目多，数据往往藏在多层跳转之后；还有一类是直接对接医保信息平台的查询入口，数据以查询结果页的形式呈现，翻页和筛选逻辑比较特殊。不同类型的平台，采集策略完全不同。

我一般会先做一轮"平台画像"：记录每个平台的域名结构、栏目路径、列表页的分页方式（是URL参数翻页还是POST请求）、详情页的字段布局、是否有反爬限制（比如请求频率限制、验证码、动态加载）。这一步看起来繁琐，但能避免后面大量返工。举个实际例子，有的平台列表页用的是前端渲染，直接请求HTML拿不到数据，必须分析其背后的数据接口；有的平台详情页字段是图片形式展示的，那就得考虑OCR或者干脆放弃该字段。这些判断都得在画像阶段完成。

2.2 列表页与详情页的字段映射

采集的核心是把列表页和详情页的字段对应起来。列表页通常提供药品名称、规格、剂型、生产企业、挂网价格等概要信息，详情页则可能有批准文号、医保分类、质量层次、执行日期等更细的字段。我的做法是先人工抽样二三十条，把列表页和详情页的字段逐一对照，画一张字段映射表，明确哪些字段列表页就有、哪些必须进详情页、哪些字段在不同平台叫法不同但含义一致。

这里有个容易被忽略的点：同一平台不同栏目的字段口径可能都不一样。比如"挂网价"和"中标价"在某些平台是分开的两个字段，在另一些平台则混用；"规格"有的平台写"0.25g×24片"，有的写"0.25g"，转换比单独一列。这些差异必须在映射阶段就记录下来，形成一份"平台字段字典"，后面清洗时直接查字典，效率高很多。

2.3 采集频率与增量策略

集采数据不是每天都有大变化，但也不能几个月才采一次。我的经验是按平台的数据更新规律来定频率：挂网价格公示类栏目通常按月或按季度更新，可以低频采集；带量采购中选结果公示是事件驱动的，公示期集中，需要在那段时间提高频率；交易记录类数据如果平台提供，更新较频繁，可以按周采集。关键是建立"增量识别"机制——通过对比本次采集和上次采集的记录指纹（比如药品编码加执行日期的组合哈希），只处理新增和变更的记录，避免全量重采带来的资源浪费和重复清洗。

增量策略还要考虑"撤网"和"价格调整"这两种特殊变更。撤网意味着某条记录从有效集合中移除，价格调整意味着同一药品出现新价格。这两种情况如果只做简单的新增去重，很容易漏掉。我的处理方式是给每条记录维护一个状态字段和版本号，撤网记录标记为失效但不删除，价格调整则新增一条版本记录并关联到同一药品主键，这样历史轨迹就完整保留了。

3. 分析库的表结构设计与标准化建模

3.1 主数据表与事实表的分层

一个能长期用的集采分析库，我建议至少分成三层：原始层、标准层、分析层。原始层保留采集到的原始记录，字段名和平台保持一致，不做任何加工，作用是溯源和重采校验；标准层做字段统一、编码映射、去重合并，是真正可查询的核心；分析层则是面向具体分析场景的宽表或汇总表，比如"省级药品价格对比宽表""品种集采覆盖汇总表"。

标准层里最关键的是主数据表和事实表的拆分。主数据表存药品的稳定属性——通用名、剂型、规格、转换比、生产企业、批准文号，用一个稳定的药品主键标识；事实表存动态属性——某省某时间的挂网价、中选价、采购量、执行日期，通过药品主键关联。这样拆分的好处是，药品属性变了（比如企业更名）只改主数据，价格变了只加事实记录，互不干扰。

3.2 药品主键的设计难点

药品主键设计是这个库最考验功力的地方。理想情况下，一个通用名加剂型加规格加转换比加生产企业，应该能唯一确定一个药品。但现实是，各省平台的命名极不统一：通用名有简称和全称混用，剂型有"片剂"和"素片"混用，规格有"0.25g"和"250mg"混用，生产企业有"某某药业"和"某某药业股份有限公司"混用。如果直接拿原始字段拼主键，同一个药品在不同省会被当成不同实体，比价就无从谈起。

我的处理办法是建一套标准化字典：通用名做同义词归并，剂型做标准剂型映射，规格统一换算成最小计量单位（比如都换算成mg），生产企业做名称规范化（去掉"股份""有限"等后缀再匹配）。标准化之后生成一个"标准药品编码"，作为跨省比对的锚点。这套字典需要持续维护，遇到新出现的命名就补充映射规则，属于典型的"越用越准"的基础设施。

3.3 维度表与标签体系

除了药品主数据，还需要几类维度表来支撑分析：地区维度（省、市）、时间维度（年月、集采批次）、企业维度（生产企业、投标企业）、分类维度（医保分类、治疗领域、剂型大类）。这些维度表看起来是配角，但直接决定了分析层能不能灵活切片。比如治疗领域标签，如果只靠通用名关键词匹配，准确率有限，最好结合医保分类编码和人工校验，形成一张可维护的药品-治疗领域映射表。

标签体系我建议做成可扩展的键值结构，而不是固定几列。因为分析需求会变，今天要按剂型分析，明天可能要按是否独家品种分析，后天又要按是否通过一致性评价分析。用标签表存储，新增标签只是加数据不改表结构，灵活性高很多。

4. 数据清洗中最容易翻车的几个环节

4.1 规格与转换比的解析陷阱

规格解析是清洗环节的重灾区。看似简单的"0.25g×24片"，实际藏着不少坑：有的平台用"×"，有的用"*"，有的用"X"；有的把转换比写在规格里，有的单独一列；有的复方制剂规格写成"每片含A 0.1g与B 0.2g"，根本无法用简单正则拆解。我吃过最大的亏是早期用一条正则通吃所有平台，结果复方制剂和特殊剂型全部解析失败，价格比对的基数全错了。

后来改成"分平台正则加兜底人工"的策略：每个平台维护一套解析规则，规则覆盖不了的记录打上"待人工"标记，进入人工校验队列。同时把解析结果和原始字符串都存下来，方便回溯。转换比尤其要小心，它直接决定单剂量价格的计算，算错了整个比价结论都是错的。我的做法是转换比解析后做一次合理性校验，比如片剂转换比一般在个位数到百位数之间，超出范围就报警。

4.2 价格字段的口径统一

价格字段的坑在于口径。同样是"价格"，可能是挂网价、中标价、中选价、医保支付标准、最高零售限价，含义完全不同。有的平台一个页面列好几个价格字段，有的平台只给一个笼统的"价格"。如果不区分口径直接混在一起算均价，结论毫无意义。

我的处理是给价格事实表加一个"价格类型"字段，采集时根据栏目和字段名判断类型，判断不了的标记为"未分类"单独存放。分析时严格按价格类型过滤，绝不跨类型聚合。另外要注意价格的单位，有的平台按盒计价，有的按最小制剂单位计价，必须结合转换比统一到"元/最小制剂单位"才能横向比较。

4.3 重复记录与版本冲突

重复记录在跨平台合并时特别常见。同一个药品可能在一个平台的不同栏目重复出现（比如既在挂网目录又在交易记录里），也可能因为采集时间不同产生多条记录。简单的按全字段去重会误删有效记录，因为价格调整后其他字段可能完全一样。我的做法是用"药品主键加价格类型加执行日期"作为业务唯一键，同一业务键下保留最新采集时间的一条，同时把历史版本存入版本表。这样既避免了重复，又保留了变更轨迹。

版本冲突则出现在同一业务键下出现不同价格的情况，通常是平台数据本身有误或者采集时点正好赶上数据更新。遇到这种情况不要急着覆盖，先标记冲突，人工核对平台原始页面后再决定保留哪条。我见过因为自动覆盖导致价格错乱的案例，后面排查花的时间远超人工核对。

5. 更新机制与数据质量监控

5.1 定时任务与变更告警

分析库建好只是开始，能不能持续可用取决于更新机制。我的做法是把采集、清洗、入库串成定时任务链，每个环节有独立的日志和失败重试。采集环节重点监控"记录数突变"——如果某次采集记录数比上次少了百分之几十，很可能是平台改版或者采集规则失效，必须告警。清洗环节重点监控"解析失败率"，失败率超过阈值就暂停入库，避免脏数据污染标准层。

变更告警还要覆盖"关键字段变更"，比如某药品的挂网价突然大幅变动、某企业名称整体变更、某栏目突然消失。这些变更未必是错误，但需要人工确认，确认后再放行。我一般会在告警里附上变更前后的对比，方便快速判断。

5.2 数据质量指标与巡检

光有告警不够，还得有一套数据质量指标做定期巡检。我常用的指标包括：各平台记录覆盖率（实际入库数除以平台公示数）、字段完整率（关键字段非空比例）、标准化成功率（能映射到标准药品编码的比例）、价格合理性通过率（价格在合理区间内的比例）、重复率。这些指标按周或按月出报表，趋势异常就深挖原因。

巡检还要做"抽样回查"，随机抽若干条入库记录，回到平台原始页面核对字段是否一致。这一步很枯燥但很必要，因为自动化校验只能发现格式问题，发现不了语义错误。我遇到过平台把两个字段的列顺序调换导致价格和规格错位的情况，自动化校验完全无感，全靠抽样回查发现。

5.3 平台改版的应对预案

省级平台改版是常态，改版往往意味着采集规则失效。应对预案的核心是"快速发现加快速修复"。快速发现靠前面说的记录数突变告警；快速修复靠采集规则的可配置化——把选择器、字段映射、分页逻辑都做成配置项，改版时只改配置不改代码。我还会给每个平台保留一份"最近可用配置"的快照，改版后先回滚到快照确认能跑通，再逐步适配新结构，避免手忙脚乱。

6. 这个库能支撑哪些实际分析场景

6.1 跨省价格对比与异常识别

库建好之后最直接的应用就是跨省比价。拿同一个标准药品编码，横向拉出各省的最新挂网价或中选价，一眼就能看出价格梯度。实际用下来，跨省价差往往比想象中大，同一通用名同规格的药品，不同省之间差几倍的情况并不罕见。这时候就要结合集采批次、质量层次、是否独家品种等因素去解释差异，而不是简单下"某省价格高"的结论。

异常识别是比价的延伸。设定一个合理价差区间，超出区间的记录自动标记，再人工核查是数据错误还是真实的政策差异。这个机制在数据质量巡检里也用得上，属于一举两得。

6.2 品种集采覆盖与趋势跟踪

按品种维度看集采覆盖情况，能回答"某个药在多少省已经集采、以什么形式集采、中选价什么水平"这类问题。结合时间维度，还能看某个品种从挂网采购到带量采购的价格演变轨迹。做趋势分析时一定要注意口径一致，挂网价和中选价不能混在一条趋势线里，否则曲线会莫名其妙地跳变。

6.3 企业与治疗领域的结构性分析

企业维度可以看某企业在各省的中选品种数和价格策略，治疗领域维度可以看某类疾病的用药集采进度和价格降幅分布。这类结构性分析对行业研究很有价值，但前提是标签体系做得够细。我的经验是先把治疗领域标签做扎实，再谈结构性分析，否则切出来的结果经不起推敲。

7. 几个我踩过之后才明白的经验

第一个经验是关于"慢就是快"。早期我总想着一口气把所有平台全接进来，结果每个平台都只做了半吊子，字段映射不全、清洗规则粗糙，后面返工的成本远高于一个一个平台做扎实。后来改成"接一个、通一个、稳一个"的节奏，虽然前期看起来慢，但整体进度反而更快，数据质量也稳。

第二个经验是关于"原始数据永远别丢"。标准层的数据经过清洗和映射，看起来干净，但一旦映射规则出错，没有原始数据就无法回溯修正。我现在的做法是原始层永久保留，标准层可以随时从原始层重算，这样规则迭代就没有后顾之忧。

第三个经验是关于"人工校验不可省"。自动化能解决百分之八九十的问题，但剩下的百分之十往往是最关键的边界情况。给人工校验留出通道和队列，比追求百分之百自动化更现实。我见过太多项目因为迷信全自动，最后在几个特殊剂型上栽跟头。

第四个经验是关于"文档和字典要跟着数据走"。平台字段字典、标准化映射规则、清洗规则说明，这些东西如果不及时更新，过几个月连自己都看不懂当初为什么这么设计。我现在强制要求每次规则变更都同步更新文档，哪怕只是改一个映射，也要留痕。

最后分享一个小的实操技巧：在标准层之上做一个"数据血缘"视图，记录每条标准记录来自哪个平台、哪次采集、经过哪些清洗规则。排查问题时顺着血缘往回查，比大海捞针高效得多。这个视图不用做得很复杂，一张关联表加几个查询就够用，但省下的排查时间非常可观。