医疗数据典型特征及架构发展方向研究

简介: 医疗及健康行业风口来临,本文从最近阿里云天池比赛对于医疗数据的特征进行分析并提出未来医疗健康产业数据架构的发展方向思路

前言

医疗健康产业目前呈高速发展状态,处在互联网对医疗行业赋能的关键阶段,由于医疗行业数据的隐私性较强,通过传统方式很难获取公开的医疗健康数据进行研究,根据阿里云天池比赛赛题设置研究及提供的脱敏数据集着手进行分析是比较理想的手段。本文的目的在于对医院的信息系统流程进行思考,结合公开数据集对于医疗健康数据特征进行分析,从而得出未来医疗健康产业数据架构模式的发展方向。

医疗健康数据特征

首先看一下天池比赛近期的两场比赛,都是针对医疗数据进行研究并进行挖掘的,采用脱敏数据,数据来源于实际病例因此参考价值较高:
image.png
image.png
分析两个比赛提供的数据集形式,可以明显感到医疗数据集的特征为数据异构,即因为医疗检测手段的关系,数据图像化比例较高,但是因为训练数据集需要根据患者其他特征包括性别、年龄、身高、体重等进行统筹分析,因此也包含了一部分结构化数据,因此医疗数据集是典型的非结构化数据和结构化数据并存的异构数据集。

常用预测算法分析

医疗数据所需要的预测结果一般为分类,由于结果的主要目的并非直接作出定性结论而更多的是为医生提供参考因此二分类(即是或不是)和多分类(分为几类)都有实际价值。
从宫颈癌风险智能诊断比赛要求结果看,初赛恶性细胞检测算法属于二分类问题,而复赛宫颈癌恶性细胞检测分类算法属于多分类问题即需要将检测结果分类成5类典型宫颈癌。
数据处理方面,需要结合训练集图像输入和医生的手工标注信息和患者特征信息,因此深度学习算法的普遍使用成为必然,由于单张CT图片和标注信息只能属于一个患者因此JSON文件被采用作为记录文件形式是非常合适的,单张CT文件对应单个JSON文件相比结构化表单能够更好的记录数据。
image.png
从数据量大小分析,数千份宫颈癌细胞学图片和对应异常鳞状上皮细胞位置标注,每张数据在20倍数字扫描仪下获取,大小300~400M。因此以训练集包含800张图片计算训练数据集大小约为273G,非结构化数据占了绝大部分。
从心电人机智能大赛比赛要求结果看,心电异常事件分类属于多分类问题即需要将检测结果分类成训练集中的异常事件种类。4万个医疗心电样本。每个样本有8个导联,分别是I,II,V1,V2,V3,V4,V5和V6。单个样本采样频率为500 HZ,长度为10秒,单位电压为4.88微伏(microvolts)。因此在检测设备输出时已经将数据结构化,相比CT图片的特征提取和数据处理并不需要采用深度学习算法,常规数据预处理手段即能满足需求。
从算法角度进行分析,针对图片进行计算需要用到深度学习算法,各类神经网络中RNN即卷积神经网络被使用频率较高,也是目前图像识别的主流算法。对两个比赛中选手公开的算法进行统计,宫颈癌风险智能诊断比赛所采用的算法几乎全部为基于神经网络的深度学习算法,差异无非是所采用的深度学习框架不同和基于神经网络衍生的算法采用不同。代表数据科学界对于未来非结构化医疗数据所采用的算法大方向上是统一的。心电人机智能大赛采用算法为机器学习分类算法,目前基于决策树的分类算法占据绝对主导地位,在决策树的基础上衍生的机器学习算法如RF即随机森林算法、GBDT算法和LIGHTLGBM算法又占了多数,LIGHTLGBM算法最普遍被使用。
从交叉验证集调参和测试集验证效果评估来说,面向癌症算法和其他如心脏异常情况算法需要关注的角度不一样,癌症因为检测结果对于病员包括家属心理冲击很大,因此对于测准率和召回率的平衡问题需要非常关注,防止算法过拟合而造成的草木皆兵情况,同时也加大了医生复核的工作量。而心脏异常算法或是其他普通生化指标数据,则过拟合的问题没有那么严重,因为数据的体量到了一定的程度根据大数定理即使过拟合也会逐步的倾向于往较为准确的趋势发展。特别对于心脏异常情况判断,高测准率极其重要,因为数据的实时性强并且随时间变化价值下降速度较快,即使过拟合而误报,能让病员或家属重视总是没有错的。

医疗数据处理架构方案

根据以上对于医疗健康数据特征、所采用的数据挖掘算法分析结果,对于医疗数据处理所用的架构方案进行研究。
医疗数据结构化和非结构化并存的特征造成需要使用CPU和GPU结合的异构计算。从医院现实条件来说,非结构化数据的来源主要为放射性检查设备等产生的图像,如CT每张图片的大小就约为350M,而生化指标包括心电指标能够以结构化数据呈现。非结构化数据的处理需要消耗大量GPU计算力,无法在现实情况下要求医院对于本地IDC机房进行大规模扩容并增加GPU集群。因此从架构上来说云-雾-边协同会是比较理想的架构方式。
1 边缘计算节点
各类检测设备附近的计算节点(包括设备自带的和医生查看结果的PC机)构成协同体系内边缘计算节点,但是现有技术条件下边缘计算的计算力相对偏弱,无法要求边缘节点进行大规模图像识别计算,因此边缘计算节点的主要任务是数据清洗并负责向雾端传送,由于医院的检查种类较多,各种报告和图像信息数据格式并不统一,因此预先在边缘端进行数据清洗有助于雾端和云端降低计算压力并帮助医院未来实现统一数据中台可能。
2 雾计算节点
医院现有本地IDC机房可以考虑作为雾计算节点,雾计算节点目前对于医疗行业尤其重要,虽然5G技术在时延上和传输速度上都满足大规模数据传输要求但是由于医院的环境较为复杂,如果边缘计算节点的数据需要直接传送到云端则在网络层会极其依赖无线通信手段,而无线通信特别是5G较高的频率在全方位全覆盖性的边缘计算节点与云端通信过程中是否会对医疗设备产生干扰和其他预料之外的问题需要在实际应用中再研究,短期内,边缘计算节点数据通过有线通信手段传送到雾计算节点是最合适的方法。
雾计算节点的现实作用非常多,如集中边缘计算节点数据和区分应用场景并进行计算,特别如果个别医院本地IDC服务器集群配置较强则可以就地对于结构化数据进行挖掘、训练模型并进行预测工作而不必传送到云端。此外从通信角度,雾端作为统一数据出口向云端无线传输数据可以最大可能避免无线信号对于医疗设备可能的干扰作用。短期5G未普及情况或者费用较高的情况下可以采用本地IDC与云端专线通信方式作为过渡手段。
在具有多个院区的医院中,不同地域的本地IDC作为雾端能够进行异地容灾建设。多个本地IDC机房在不同地域互为灾备,确保单一节点故障能够及时迁移确保业务不中断及存储数据的可用性和完整性。
3 云端
云计算平台能够很好的解决医院异构数据计算需求大但又短时间无法配置大规模GPU集群的现实情况,CT等放射性检查设施产生的高清图像文件及其他需要采用深度学习算法的数据可以统一通过雾端传输到云端进行计算,云计算弹性伸缩的优势在面对医院计算力需求随患者数量呈时间性波动的情况时也可以最大可能的减小医院异构计算成本,GPU集群的配置通过弹性伸缩在医院计算力需求大时自动扩充计算节点,而需求小时自动减小集群内虚拟机规模。

相关实践学习
基于阿里云DeepGPU实例,用AI画唯美国风少女
本实验基于阿里云DeepGPU实例,使用aiacctorch加速stable-diffusion-webui,用AI画唯美国风少女,可提升性能至高至原性能的2.6倍。
目录
相关文章
|
1月前
|
存储 SQL 关系型数据库
ClickHouse(02)ClickHouse架构设计介绍概述与ClickHouse数据分片设计
ClickHouse的核心架构包括执行过程和数据存储两部分。执行过程涉及Parser与Interpreter解析SQL,通过Column、DataType、Block、Functions和Storage模块处理数据。Column是内存中列的表示,Field处理单个值,DataType负责序列化和反序列化,Block是内存中表的子集,Block Streams处理数据流。Storage代表表,使用不同的引擎如StorageMergeTree。数据存储基于分片和副本,1个分片由多个副本组成,每个节点只能拥有1个分片。
75 0
ClickHouse(02)ClickHouse架构设计介绍概述与ClickHouse数据分片设计
|
2月前
|
缓存 安全 API
【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的API网关设计实现
公司对外开放的OpenAPI-Server服务,作为核心内部系统与外部系统之间的重要通讯枢纽,每天处理数百万次的API调用、亿级别的消息推送以及TB/PB级别的数据同步。经过多年流量的持续增长,该服务体系依然稳固可靠,展现出强大的负载能力。
55 9
【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的API网关设计实现
|
4月前
|
存储 设计模式 测试技术
了解三层架构:表示层、业务逻辑层、数据访问层
了解三层架构:表示层、业务逻辑层、数据访问层
248 0
|
1月前
|
存储 关系型数据库 测试技术
印尼医疗龙头企业Halodoc的数据平台转型之Lakehouse架构
印尼医疗龙头企业Halodoc的数据平台转型之Lakehouse架构
35 4
|
1月前
|
SQL 缓存 分布式计算
日增数据超10PB!揭秘沃尔玛Lakehouse架构选型之路
日增数据超10PB!揭秘沃尔玛Lakehouse架构选型之路
45 2
|
1月前
|
存储 SQL 机器学习/深度学习
通用数据湖仓一体架构正当时
通用数据湖仓一体架构正当时
61 2
|
2月前
|
存储 消息中间件 Java
【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的高可靠消息服务设计实现
在深入研究了 **“【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的API网关设计实现”** 设计实现后,我们意识到,尽管API网关为服务商提供了高效的数据获取手段,但实时数据的获取仍然是一个亟待解决的问题。
39 1
【亿级数据专题】「高并发架构」盘点本年度探索对外服务的百万请求量的高可靠消息服务设计实现
|
2月前
|
前端开发 JavaScript API
|
4月前
|
消息中间件 数据挖掘 Kafka
Kafka在微服务架构中的应用:实现高效通信与数据流动
微服务架构的兴起带来了分布式系统的复杂性,而Kafka作为一款强大的分布式消息系统,为微服务之间的通信和数据流动提供了理想的解决方案。本文将深入探讨Kafka在微服务架构中的应用,并通过丰富的示例代码,帮助大家更全面地理解和应用Kafka的强大功能。
|
6月前
|
弹性计算 Java 数据库连接
架构设计第七讲:数据巡检系统之daily&线上表结构自动化比对
架构设计第七讲:数据巡检系统之daily&线上表结构自动化比对