简介：医疗场景80%以上是非结构化数据、多源异构还散落在不同系统里。作为医疗云架构师，复盘一次影像+病历双库合并踩过的3个坑。

最近在帮一家三甲医院重排影像数据底座，被两个数据并存的"断层"卡了很久。作为医疗云原生架构师，今天不聊架构图，聊聊这次真实踩过的3个坑——它们也解释了为什么医院的数据孤岛总是"各说各话"。

一、先分清"数据长什么样"，再谈"数据放哪" 坑在第一步：医院的数据从来不是一块铁板。一份CT影像（DICOM）是二进制流，一份病理报告是几页文本，一份检验单是结构化字段，还有基因测序这类时序/空间数据。我把它们一股脑按"存下来再说"处理，结果是要OLTP又要向量检索时全瘫了。 教训：先做"数据形态体检"，把关系型、文档、向量、时序分开规划，别追求一个大库装下所有。

二、别把"能读出来"当成"能对齐" 坑在联调：影像、病历、结算来自不同系统，同一个患者在不同库里ID都对不上，更别说"主诉"和"诊断"这种字段语义。前期图省事用模糊匹配，上线一查错配率吓人。 教训：主键统一、字典对齐要前置，先做"三本账"（项目/设备/目录）再谈上云，这个钱不能省。

三、AI检索的"幻觉"源头，一半是数据没治理 坑在最后：模型明明接了库，答出来却张冠李戴。查到最后是向量库里的原文没做清洗、去重、血缘标注，模型把旧版本当成了新结论。 教训：数据治理要当一等公民——清洗、血缘、版本回滚做扎实，AI才是"工具"而不是"甩锅对象"。

可实操的3条建议（能直接拿去对项目）：

1. 项目启动先交付"数据形态地图"（哪些是结构化、哪些非结构化、存哪），再排技术选型。

1. 主数据对齐（患者/设备/收费项目）越早做越好，晚做成本翻倍。

1. AI检索类功能，上线前必过"血缘+版本"回归测试，防一本正经地胡说。