← 返回蜂巢洞察

在你们解决数据问题之前,医疗领域的人工智能技术是无法正常运行的。

为临床环境开发人工智能其实比看起来要困难得多。这不仅仅意味着需要选择一个合适的模型或调整正确的参数。 当工程师们进入医院这个生态系统时,他们会很快发现:那些在其他行业中被他们广泛使用的工具,在这里往往无法正常使用。临床数据杂乱无章、极其敏感,而且分散在许多不同的系统中。妥善处理这些数据并非可有可无,而是整个系统能否正常运行的基础。 临床数据有多种形式。其中一部分是结构化的数据,比如存储在表格中的实验室检测结果;另一部分则是非结构化数据,比如医生手写的病历被扫描成PDF文件。所有这些数据都受到严格的隐私保护规定的约束,而且每一条数据都可能直接影响患者的诊疗效果。 与电子商务或广告领域不同,在这些

为临床环境开发人工智能其实比看起来要困难得多。这不仅仅意味着需要选择一个合适的模型或调整正确的参数。

当工程师们进入医院这个生态系统时,他们会很快发现:那些在其他行业中被他们广泛使用的工具,在这里往往无法正常使用。临床数据杂乱无章、极其敏感,而且分散在许多不同的系统中。妥善处理这些数据并非可有可无,而是整个系统能否正常运行的基础。

临床数据有多种形式。其中一部分是结构化的数据,比如存储在表格中的实验室检测结果;另一部分则是非结构化数据,比如医生手写的病历被扫描成PDF文件。所有这些数据都受到严格的隐私保护规定的约束,而且每一条数据都可能直接影响患者的诊疗效果。

与电子商务或广告领域不同,在这些领域中,一个有缺陷的模型最多只会导致经济损失;而在临床医疗领域,一个有问题的人工智能系统却可能会危及患者的健康。正因如此,在编写任何一行模型代码之前,重新审视自己的数据处理流程才是最重要的事情。

在本文中,我们将探讨为什么标准的数据处理流程在医院环境中会遇到各种问题,数据质量对模型性能的影响究竟比架构设计重要多少,以及工程师与临床医生之间的差距是如何导致实际应用中出现故障的。我们还会分析同时处理临床文本、图像和遥测数据所带来的挑战,以及如何构建能够在数据格式、患者群体或文档管理方式发生变化时依然保持稳定性的系统。

我们将涵盖以下内容:

为什么标准的数据处理流程在医院环境中会失效

大多数软件数据处理流程都是为了保证系统的稳定性而设计的。它们期望输入的数据具有清晰的结构且可预测。

然而医院的环境却完全相反。一份患者的病历信息可能会同时涉及到电子健康记录系统、放射科档案系统、床边监测设备、实验室信息系统,以及多页手写的临床笔记。

如果你正在探索这个领域,Research.com网站对医疗健康领域人工智能硕士课程的比较分析是一个很有用的起点,它能帮助你了解这份工作需要哪些跨学科技能。虽然这只是一份职业指南,并非任何监管标准,但它确实展示了这个领域的广泛性。

在医院系统中流动的数据本质上就是不一致的。不同的实验室会对同一项检测使用不同的名称。虽然有像LOINC这样的标准来解决这个问题,但要将所有这些数据进行匹配确实需要付出巨大的努力。在一家医院中被整齐编码的记录,在另一家医院可能就会以自由文本的形式出现。而且这些记录往往还存在缺失部分——有时某项检测根本就没有被安排进行;有时患者也会错过预约时间。

当工程师试图对临床数据应用标准的提取、转换和加载流程时,总是会遇到三个反复出现的问题。

首先,各种数据的格式彼此完全不同。医生的文字记录、DICOM医学影像以及连续的生命体征数据流,都需要不同的预处理步骤,而单一的关系型查询无法同时处理这三种类型的数据。

其次,数据采集的时间并不固定。临床观察数据是在护理过程中实时收集的,并非按照固定的时间表进行采集,因此这些数据的记录中会存在间隔缺失的情况,这些问题需要谨慎处理,而不能简单地补全遗漏的数据。

第三,相关术语也在不断变化。ICD-10、SNOMED CT和LOINC等标准都会定期更新,因此不能为了使旧数据符合新标准就直接覆盖它们。这些数据需要进行版本管理,并且要仔细地进行映射处理,以确保它们原有的含义能够得到保留。

要想可靠地解决这些问题,就必须使用那些具备版本识别功能、并且足够灵活的数据处理流程,这样才能适应多种不同的源系统结构,而不仅仅是一种固定的数据模型。

数据质量比模型选择更为重要

在临床人工智能领域,模型仅仅只是整个系统中的一个组成部分。训练数据的质量、它对目标人群的代表性、标签的分配方式,以及这些数据在临床上的实际意义,这些因素共同决定了模型在实际应用中是否能够发挥作用。如果一个大型模型是在有偏差或不完整的 数据集上训练出来的,那么它在实际应用中也会重复出现这些问题。

正因如此,这个领域正在从以模型为中心的发展方向转向以数据为中心的方向。支撑现代人工智能发展的Transformer架构在语言理解方面确实取得了巨大的突破,但仅仅拥有更好的架构并不能解决标签错误、人口统计信息缺失,或者训练数据无法反映模型实际会遇到的患者情况这些问题。

对于高风险的临床应用来说,数据绝对不能被当作静态输入来处理,而必须在整个系统生命周期内对其进行持续的管理。

如何现代化临床数据处理

有三种做法对解决这些问题非常有帮助。

首先,在适合的情况下,应使用像HL7 FHIR这样的医疗互操作性标准。FHIR为跨系统交换健康数据提供了一种标准化的方式。

然而,它本身并不能解决术语映射或数据质量的问题,这些仍然需要专门的工程技术来进行处理。

其次,需要建立与实际使用目的相匹配的隐私保护及数据去标识化流程。并非所有数据在进入训练环境之前都需要删除其中的所有受保护的健康信息。根据美国的HIPAA隐私法规,某些情况下可以使用或披露受保护的健康信息,包括用于一些研究目的。

当需要进行数据去标识化处理时,HIPAA规定了两种方法:专家评估与安全港机制。自动化自然语言处理技术可以帮助识别文本中的标识信息,但仅依靠基于规则的自然语言处理系统并不能确保符合HIPAA法规的要求。

第三,需要确认你的训练数据是否真正代表了你试图服务的患者群体。一个庞大的数据集并不一定具有代表性。因此,需要关注数据中的缺失情况、不同地区之间的差异、测量方法的一致性,以及关键亚组在数据中的分布情况。

工程师与临床医生之间的差距

临床人工智能的应用仅靠技术本身是远远不够的。临床环境决定了模型的应用范围:模型应该预测什么、何时进行预测、谁会使用这些预测结果,以及他们会如何利用这些信息。一个技术上非常先进的模型,如果不符合临床工作流程,那么它根本就不会被实际使用。

医疗记录中的数字不仅仅是数字而已,它们代表着在繁忙的医院环境中,人们在特定时间压力下测得的数据。忽视这一背景,就会导致那些在理论上看似可行、但在实践中却会失败的模式。

多项研究都表明,临床医生的接受程度以及模型与实际工作流程的契合度,是阻碍人工智能在医疗领域应用的最主要因素。因此,从项目一开始就应让目标用户参与设计和评估过程,而不仅仅是在最后阶段让他们进行签字确认。

人工智能代理正在承担越来越多的临床行政任务。这就使得人工审核机制变得更为重要,而不是可有可无。模型输出的结果需要在工作流程中的适当环节由人类进行核查,这不仅仅是一种形式上的要求,而是一层真正的安全保障。

在这个问题上很容易犯一些细微的错误。比如,某个团队开发了一个用于预测患者再次住院风险的强大模型,但该模型使用的诊断代码是在患者出院后才会最终确定的。因此,在模型应该提供预测结果的阶段,这些代码还不存在,从而导致模型无法实时运行。

这种现象就是“时间泄漏”,只有当你仔细思考数据在临床工作流程中实际何时能够被获取时,才能发现这种问题。

三个值得了解的运营方面的要点

临床记录中的数据缺失往往是有原因的,并非随机发生的。医疗资源的获取渠道不同、文档记录的习惯各异、护理方式也有所不同,这些因素都会影响哪些数据会被记录下来,哪些数据会丢失。

NIST人工智能风险管理框架为管理人工智能相关风险提供了指导建议,包括如何应对偏见问题,但它并没有规定医疗领域的开发者应该如何判断数据记录的完整性。

在真实案例稀缺的情况下,合成数据能够帮助解决相关问题。但使用合成数据时必须谨慎。在将合成样本用于训练之前,相关团队应先评估其临床合理性、是否存在潜在的偏差放大现象,以及这些生成的数据是否能够保留有意义的医学关联。合成数据绝不能替代真实的患者记录。

最后,让临床领域的专家参与数据的标注工作、需求分析以及可用性测试,并非可有可无的附加措施。这是确保模型输入与输出结果符合临床实际需求的必要步骤。

同时处理多种类型的数据

医疗人工智能系统往往需要同时处理各种截然不同类型的数据。CT或MRI检查所需的数据处理流程,与医生记录或ICU实时监测数据所采用的处理方式是完全不同的——这些数据格式本身就不适用于相同的处理逻辑。

在构建用于医学图像处理的流程时,工程师们需要先处理DICOM元数据、像素间距、图像方向、亮度表示方式以及空间对齐问题。正确的预处理步骤取决于具体的成像类型及所要完成的任务。

医生记录中的文本也属于一种特殊类型的数据。临床自然语言处理技术需要能够理解其中的否定表达、“无发热”之类的表述、缩写词、专用术语,以及时间相关的参考信息——而这些通常是通用语言模型难以准确理解的。

随着智能体人工智能开始处理更为复杂的多步骤临床工作流程,相关系统也需要能够在所有这些数据类型之间保持上下文的一致性,而而不能孤立地处理每一类数据。如果预处理或数据协调工作不到位,就会严重影响模型的性能,有时甚至会导致输入数据与模型完全不兼容。

构建经得起时间考验的系统

在医疗人工智能领域,安全性、隐私保护、数据质量以及合规性要求绝不是事后才考虑的因素,它们是系统设计的基本要素。而且这些要求会因地区法规、数据类型以及系统的具体功能而有所不同,并非所有医疗人工智能产品都受到相同的监管规定。

每个系统都应详细记录数据的来源、软件版本以及模型版本信息。这样的记录有助于保证实验结果的可重复性、便于问题排查,同时也能满足各种合规性要求。虽然并非所有的预测结果都需要进行加密处理,但至少需要足够的信息来追踪结果的生成过程。

医疗人工智能领域的可扩展性不仅意味着能够应对高并发量的请求,还意味着要考察当患者群体发生变化、文档记录方式改变,或者医院更换了实验室设备或影像扫描仪时,模型性能是否依然稳定。

这些变化会影响到模型的输入数据。在系统正式采用新的配置方案之前,必须对这些变化进行检测、评估和测试。那些受到监管的、基于人工智能技术的医疗设备也可能需要遵守正式的变化控制要求,因此这又增加了需要考虑的因素。

通用型的人工智能应用可以根据成本或任务类型动态地在不同模型之间分配工作。临床系统也可以借鉴类似的思路,但它们所需的验证机制、管理流程以及安全控制措施,远远超出了普通软件系统的需求。

为实现更好的治理而采取的工程措施

从一开始就建立针对数据变化及模型性能漂移的监控机制。要跟踪模型输入数据、患者群体、数据采集系统以及文档编制流程等方面的变化。一旦发现任何变化,就必须立即调查这些变化是否会影响模型的性能。合适的监控阈值应该根据系统的风险等级及其预期用途来确定,而不是采用一刀切的标准。

必须维护可审计的数据来源记录及数据完整性控制机制。要详细记录数据的来源、处理过程、访问者信息,以及系统对这些数据进行了哪些操作。在某些架构中,加密技术确实可以帮助实现这些目标,但并不是所有涉及HIPAA法规的记录都必须要使用加密技术。

从项目一开始,就要设计明确的人工监管机制。当临床医生需要审核人工智能系统的推荐结果时,界面必须能够清晰地展示这些推荐结果的依据、其局限性以及所使用的信息来源。正确的异常处理流程或升级机制,应该根据系统具体的功能及其所受的监管要求来制定——而这些因素是无法在项目后期才添加进去的。

真正的工作始于数据

大多数致力于开发医疗领域人工智能技术的团队,都会将大部分精力投入到模型构建上:包括系统架构的设计、训练流程的优化、评估指标的选择等等。这些确实非常重要,但它们并不是导致大多数临床人工智能项目失败的根本原因。

项目之所以会失败,是因为人们从未真正理解过所使用的数据。数据记录中存在许多漏洞,但却没有人去调查这些问题;数据的标签是由不了解临床背景的人来标注的;训练数据集也无法反映系统最终将服务的患者群体……而等到这些问题被发现时,模型往往已经建好了。

要成功开发出实用的临床人工智能系统,就必须把数据问题视为最核心的工程挑战,而不仅仅是一个预处理步骤。这意味着需要构建能够处理复杂、多模态且不断变化的数据输入的系统;这意味着必须尽早与临床医生合作,而不是等到项目后期才进行沟通;更重要的是,必须在出现问题之前就建立完善的管理机制、监控体系以及人工监管机制。

临床环境对系统的要求极为严格,风险也极高。但那些首先重视数据基础建设的团队,最终才能开发出真正能够获得临床医生信任并得到实际应用的系统。

希望您喜欢这篇文章。您可以通过在LinkedIn上与我建立联系。

因此,

相关文章

技术实践

如何在Kubernetes环境中诊断并解决AI推理过程中的延迟问题

现在是星期四,大约两点二十分。两周前,你们的团队推出了一款内部辅助工具。测试效果还不错,以至于财务部门的某个人询问这种工具是否能够阅读合同文件。消息很快传开了,今天,所有人第一次同时使用这款工具。 支持渠道收到了同样的投诉,但这些投诉是以六种不同的方式表达的。是系统出现故障了吗?我的设备只是一直在循环加载中……今天早上它还能正常工作啊。有人发了一张显示加载指示器的截图,但没有附上任何说明文字,看来他们觉得这样挺有意思的。 于是你打开了控制面板。 所有节点都已准备就绪,容器也在运行中,CPU使用率仅为20%。没有发生重启现象,也没有进入崩溃循环状态,也没有任何警报被触发。根据Kubernetes

阅读全文
技术实践

如何使用Next.js、Supabase以及TypeSafe Jev来构建一个用于筛选人工智能相关简历的工具

每当我们发布一份工程招聘启事时,一周内就会收到300到400份简历。仔细阅读每一份简历大约需要两分钟的时间。因此,仅仅为了处理一个职位空缺,我们在开始任何面试之前就已经要花费11个小时来处理这些简历了。 但实际上,并没有人会真的去阅读每一份简历。相反,人力资源部门会进行快速的筛选工作。他们会快速浏览应聘者的职位名称、工作经验年限以及所掌握的技术框架,然后在大约15秒的时间内,将简历分为“需要进一步查看”和“可能不符合要求”两类。当他们看到第40份简历时,他们对这份简历的关注程度就已经远远低于对第4份简历时的关注了。 我们的目标就是取代这种快速筛选的过程,而不是放弃阅读简历这一环节。当阅读简历确

阅读全文
技术实践

Python工作者在Cloudflare上已进入稳定运行阶段,但仍存在关于“冷启动”现象以及上游维护相关问题的疑问。

Cloudflare已经正式推出了基于PEP 783标准开发的Python Workers功能,这些功能是通过Workers connect API来实现的,同时也利用了操作系统中的socket系统调用。不过,该公告并未提供任何关于性能的数据。后来,一位urllib3项目的维护者质疑:究竟是谁在为这些上游开发工作提供支持?而Wasmer的创始人则要求提供有关“冷启动时间”的数据,他引用了Cloudflare之前发布的信息,称冷启动时间约为1.027秒。 作者:Steef-Jan Wiggers

阅读全文
技术实践

报告主题:现实世界中的自适应推荐系统:推理机制、评估方法与系统设计

Mallika Rao指出,自适应推荐系统的真正复杂性并不在于其模型架构本身。她阐述了实时反馈机制、数据检索的新鲜度保障、多阶段协调流程以及端到端的延迟控制措施,这些因素如何使系统能够在延迟、成本和可观测性等现实操作限制条件下,在生产环境中持续学习并不断发展。 作者:Mallika Rao

阅读全文