LumeSage · 医疗 AI 数据工程 · 患者级多模态

医疗 AI 多模态数据如何按患者组织?从病历文件夹到可追溯的纵向数据资产

将病历、检验、影像与病理放进同一患者包,不只是目录整理。关键在稳定关联、临床时间线、原文证据链和可复核验收,让每个模型输入都能回到它的来源。

患者级多模态数据包:统一患者索引连接就诊、文书、检验、DICOM 与病理,并保留来源和质控状态。
图 1|患者包的核心不是目录树,而是患者、就诊、临床事件和原始证据之间可验证的关系。

为什么“按患者归拢”会改变数据的算法价值

医疗人工智能的训练样本经常以文件交付:一个 PDF、一张影像、一张结构化表格,分别看都能打开,合在一起却未必知道是否来自同一患者、同一次住院或同一临床阶段。对模型来说,这不是小小的整理瑕疵,而是样本定义本身不成立。若模型输入中的 CT 属于另一位患者,或出院诊断与病程记录无法对应,模型可能学到错误关联,评测指标也就失去解释基础。

患者级数据包把“样本”从孤立文件重新定义为一个带有边界的临床对象:患者身份使用稳定的去标识化键;患者之下有多次就诊或住院;每次就诊再关联病程文书、检查、检验、医嘱、影像序列和病理证据。这样一来,训练团队能明确样本是患者级、就诊级、检查级还是单文档级,并据此避免同一人的数据跨训练集和测试集泄漏。

附件提出把结构化 CSV、PDF 文书、DICOM 和病理挂到同一患者 ID 下,并要求每例患者包检查跨模态完整性。这个方向对应算法工程中的实体解析与数据血缘:一个患者键需要连接多个临床实体,但并不意味着每种资料都必然存在。正确的数据模型应区分“没有发生”“临床上不适用”“未采集”“采集但未交付”“关联失败”和“质量不合格”,而不是把缺失都写成空值。

把患者包建成规范数据模型,而非压平的总表

可落地的模型通常包含五类核心实体。第一类是 Patient:使用项目范围内的伪名化标识,不直接保存真实身份字段。第二类是 Encounter:描述门诊、住院、急诊或随访事件,记录起止时间、机构、科室与就诊类型。第三类是 ClinicalEvent:表示病程、诊断、检验、影像检查、手术、用药或出院等事件。第四类是 Artifact:指向源 PDF、DICOM Study/Series、病理报告或切片。第五类是 Assertion:记录由原文抽取或人工标注得到的字段、结论、证据位置、审核状态和版本。

这些实体之间应使用明确关系,而不是仅依赖文件名。患者可有多个就诊;就诊可关联多份文书和多次检查;一份影像报告可以描述一个检查,检查又包含多个 DICOM series;病理报告可能关联一个或多个标本、取材部位及切片。对于需要联结的报告、结构化字段和影像,关系表应记录关联键、匹配方法、置信度、时间窗口、人工复核状态和异常原因。没有可靠依据时,应保留“待核验”,不能为了凑完整率而强行匹配。

字段的语义也需要规范。日期至少要分清事件发生时间、采集时间、报告签发时间、文书记录时间、文书修订时间和进入数据平台的时间。数值需要保存原值、单位、参考区间、异常标志以及标准化值;诊断应保留原文、编码体系、编码版本和映射依据。药物医嘱可以保留原始药名、剂量、频次、途径和执行状态;ATC 代码等标准编码是辅助映射,不应覆盖临床原文。统一数据模型的目标是可计算与可回查同时成立。

原文、结构化字段和多模态文件如何形成证据链

如果只留下结构化结果,后续审核者很难判断字段是原始记录、规则抽取、模型预测还是人工补录。每个关键字段应能回到来源:文件标识、文档类型、页码或文本片段、原始字段路径、抽取方法、标注人角色、审核时间和数据版本。对影像报告,可以把报告中的结论与检查日期、模态、部位、Study/Series 标识连接;对病理结果,需要连接病理报告、标本信息和对应切片。证据链让下游训练集可以追溯错误,而不是只能发现错误存在。

附件对文书提出可提取文本层、患者与就诊对应、出院记录必需等要求。这些检查实际上覆盖两条不同质量轴:一条是机器可读性,另一条是临床闭环性。PDF 可复制文字不代表文字抽取无错;应抽检表格顺序、脚注、单位、分页和扫描混排。出院记录存在也不等于病程完整;应验证它与入院诊断、住院过程及出院转归在同一就诊范围内。对关键指标,要比对结构化字段和原文证据,估计抽取准确率和遗漏率。

同一个“诊断”在入院、病程修正、手术记录、病理报告和出院总结中可能逐步变化。将其压成一个最终诊断,会抹去模型研究中重要的时间与不确定性信息。更稳妥的做法是保留带时间的诊断陈述、作者角色、原文依据与状态,并将“临床工作诊断”“修正诊断”“术后诊断”“病理诊断”和“出院诊断”明确区分。模型可以按任务选择某个时间截点之前可用的特征,同时避免在预测任务中偷看后来才产生的信息。

DICOM 与病理不能被简化成几张代表图

影像是带有采集上下文的序列数据,不是若干 JPEG 的集合。对于 CT 或 MR,检查记录、Study、Series、Instance 的层级、方向、像素间距、层厚、重建核、对比剂阶段和图像数量都会影响算法输入。附件强调完整序列、同一患者多次检查及术前术后影像应保留。工程上还要检查系列是否完整、重复实例、缺层、方向和几何信息是否一致,并将报告中的检查日期及部位与 DICOM 元数据核对。若训练目标确实只需要精选关键图像,也应把选择策略和母序列关系记录下来。

病理同样有多层级:病理号、标本、组织块、切片、数字化全切片图像(WSI)、局部 patch 和报告结论不能混为一个文件。切片图像的扫描倍率、像素尺寸、染色类型、扫描仪、组织覆盖率和伪影都影响可用性。报告中的大体、镜下、免疫组化和分期字段各有语义;癌症病例的 TNM/AJCC 分期需要记录版本和来源。术后病理与术前影像或临床诊断可能一致,也可能不一致;后者是重要的标签差异,应作为可研究现象保留,而不是当成数据错误直接删除。

DICOM 去标识化也不等于删除一个 PatientName 字段。DICOM PS3.15 描述了属性级保密配置文件,但实际流程还需考虑 UID 及引用关系、私有属性、自由文本、像素内烧录文字、文件前导区以及与其他资料组合后的再识别风险。根据任务保留某些必要时间或年龄特征时,应采用受控、最小化、可审计的方案,并由数据治理和隐私责任方评估。患者键可以用于内部关联,但映射表须与研究数据隔离、严格授权,不能将伪名化误称为匿名。

从数据验收走向模型可用性验证

患者包验收至少包含四层。结构层检查目录、文件格式和必需实体是否存在;关联层检查患者、就诊、检查、报告和影像是否连接正确;内容层抽查字段、文本层、影像完整性和临床文书证据;治理层核对授权范围、去标识化、访问控制和保留期限。附件中的“同一 ID 下核对 CSV/PDF/影像/病理、核对时间戳与原文、检查高难度样本比例”的思路可以改写成可重复运行的验收规则,并将失败条目输出成可定位的差异清单。

技术验收通过仍不等于模型性能可用。模型任务要另行定义目标人群、索引时点、预测窗口、标签来源、阳性定义、排除条件和临床使用场景。训练、验证、测试应以患者为单位划分;若同一患者有多个就诊、多个影像序列或多张切片,必须作为一个整体隔离。样本构成、医院、时间、设备、科室和病例复杂度都会影响外部泛化,不能靠扩大文件量消除分布偏移。

最终的目标是让数据在模型生命周期里可复用、可审计、可重新解释。采购交付时定义的字段与关联规则,应能映射到数据卡、训练集版本、评测集、错误分析和后续修订记录。若某个字段从原文抽取升级为人工双审,或某个影像序列经过新的去标识化流程,要保留版本差异以及对既有评测的影响。患者包并不是一个永远固定的 ZIP 文件,而是围绕临床实体、来源证据、权限和质量状态构成的数据产品。

朗慧可以在哪些环节提供可验证的支持

医疗 AI 项目通常需要把采购规格翻译成数据接口、样本定义和验收逻辑。朗慧可围绕项目授权与约定范围,协助梳理数据字典、患者级关联规则、源文件和结构化字段的对应关系、医学标注规范、抽样质控方案及模型评测设计。具体交付内容、数据来源、规模、学科覆盖和质量指标必须以项目合同、数据卡和双方确认的验收方案为准;本文不代表对任何特定样本现货或交付结果的承诺。

一个可执行的启动方式是先选取经授权的代表性样本完成小规模 POC:验证字段映射、患者和就诊联结、时间对齐、DICOM/病理读取、脱敏边界、标注一致性及验收报告。POC 不只看“打开成功”,还应记录失败类别、修正成本和无法覆盖的样本边界,再决定是否扩展。对医疗数据,清晰披露缺失与不确定性,通常比给出一个看似漂亮的总分更有工程价值。

患者包建设还需要处理身份键的生命周期。项目内部 ID 应由受控流程生成,避免直接使用身份证号、手机号、病案号等可识别编号;跨来源匹配宜采用经批准的确定性或概率性规则,并保存匹配依据和冲突状态。概率匹配不应只输出一个最终 ID,还应提供阈值、候选数量和人工复核情况。若患者无法可靠匹配,宁可保留为未链接样本,也不要因“患者包必须完整”而错误合并。不同项目之间是否允许同一伪名键复用,应由授权范围和治理制度决定。

从工程上看,数据质量最好在采集、加工、交付和训练前分别设门。源端检查文件完整、权限和格式;加工端检查解析、字段映射、关系建立和去标识化;交付端检查 manifest、文件校验和抽样结果;训练前再检查目标任务、标签、患者切分和数据版本。质量规则需要有严重等级:例如患者错配、可识别信息暴露应阻断交付;少量非关键字段缺失可在披露后接受;模态缺失则要判断是否超出任务合同约定。只给一个“合格率”会掩盖不同错误的风险差异。

数据库设计应兼顾保留原文和算法使用。对原始数据采取只读保存并进行校验和;解析结果以派生表存储,记录解析器版本和运行时间;修订后的字段通过新版本覆盖逻辑而非无痕改写。对每个患者包生成机器可读清单,列出预期实体、实际实体、源文件哈希、关联结果、质控状态与异常代码。若临床专家纠正了诊断映射,也保留原始映射和修订理由,以便复现实验。敏感原始文件的访问日志与训练数据访问权限应分开管理。

患者包还应明确“最小可用样本”和“扩展样本”的差别。对某些 NLP 任务,一份可追溯的病程文书已经足够;对纵向预测,患者需至少有明确的索引时点、观察窗和结局;对影像病理关联,可能要求手术、影像、标本和病理诊断均能可靠连接。若把所有病例都按同一套完整包标准筛选,容易丢弃可用于单模态任务的高质量资料;反过来把不完整包混进多模态训练,也会使模型的模态缺失机制不透明。数据目录可以提供“核心必需”“条件必需”和“可选扩展”三层规则,并按任务筛选。

质量指标应覆盖精确性、完整性、一致性、及时性、唯一性和可追溯性,而非仅以缺失率表示。比如患者 ID 的完整率可能是 100%,但若跨院错误合并,精确性仍然很差;DICOM 文件都能读取,但患者与报告匹配错误,一致性仍不合格;PDF 有文本层,但关键表格顺序被抽取错,内容质量仍不足。对每个指标要说明分母、抽样框、通过定义和置信区间,并把关键错误的风险等级单独呈现。这样采购方、数据供应方和模型团队才能围绕同一事实讨论整改。

每个数据包还需要清晰的生命周期状态,例如待接收、解析中、待审核、可用于指定任务、限制使用、已撤回或到期销毁。状态变化应保留时间、操作角色和依据,避免旧版本文件在新版本获批后仍被训练系统读取。若数据用途发生变化,例如从字段抽取转向模型预训练或跨机构评估,应重新确认原授权是否覆盖该用途。数据访问策略可按角色区分原始文书、脱敏影像、结构化数据和派生标签,并在项目结束后执行约定的归档或删除。患者级关联使多模态研究更有价值,也提高了组合识别风险,因此需要将关联能力和访问权限一起纳入治理,而不是只在导出时做一次脱敏。

跨团队交接时,患者包规格还应提供明确的目录示例、字段数据类型、允许值、编码版本、空值规则和异常样例。比如“检查时间”究竟指预约、扫描还是报告签发,应在字段说明中写明;“影像阳性”应说明依据报告结论还是人工复核。结构化表格要包含稳定的字段 ID,便于多轮交付时识别字段改名或语义漂移。对关键字段可提供验证脚本和预期输出,使采购、标注、算法和质控团队都能使用同一份规则。若接收方发现数据异常,应通过病例级问题单回报文件、字段、原文证据和影响任务,形成可追踪的修复闭环。

作者信息也属于临床语境。经授权并完成必要去标识化后,可保留作者角色、职称与科室等非直接身份属性,用于区分住院医师记录、上级医师查房、专科会诊和术者文书;姓名与证件号码则按项目规则移除。若把所有作者统一替换为“医生”,不仅降低了来源可追溯性,也使研究者无法分析不同文书类型和签署角色的语义差异。对药品和非药品医嘱,患者包应保留原始医嘱名称、通用名、剂量、频次、途径、执行时间及状态;ATC 等标准码可作为映射字段,并记录映射依据,不能用标准代码覆盖原始医嘱。

方法边界与数据来源

本文依据用户提供的医疗数据字段与复购需求文件归纳数据工程和队列设计要点,并结合公开的同行评议研究、技术标准与监管/报告指南进行讨论。附件中的字段、筛选门槛和数量均为需求规格示例,不证明数据已采购、已交付或已通过模型验证。文中算法和流程用于科研与工程设计讨论,不构成医疗诊断或治疗建议。具体项目须以授权、数据卡、合同和伦理/合规审查为准。

参考文献与技术标准

  1. Longitudinal alignments and syntheses of multimodal clinical data for personalized medicine with the PULSE framework, Nature Computational Science (2026)
  2. Digital Imaging and Communications in Medicine (DICOM), PS3.15 Security and System Management Profiles
  3. WHO Europe: Governance for health data
  4. FDA / IMDRF: Good Machine Learning Practice for Medical Device Development

需要把数据需求转成可核对的样本定义、质量规则与交付流程?可与 LumeSage 团队讨论项目边界。

填写需求表单

联系朗慧团队

如需讨论本文涉及的数据结构、质量控制、医学标注或模型评测,可通过电话、邮箱或下方表单联系。请勿发送可识别患者身份的信息。具体项目范围以正式文件为准。

电话
+86 150 1040 0907
邮箱
date@lumesage.com
商务微信
朗慧商务联系人微信二维码
扫码添加商务联系人

请勿在表单中提交患者姓名、身份证号、联系方式、原始病历或其他可识别个人的信息。

提交即表示您同意北京朗慧科技有限公司为回复本询盘处理您填写的联系信息。 隐私政策 · 合规说明