医疗行业大数据应用实例.docx
《医疗行业大数据应用实例.docx》由会员分享，可在线阅读，更多相关《医疗行业大数据应用实例.docx（17页珍藏版）》请在冰点文库上搜索。
医疗行业大数据应用实例
医疗行业大数据应用实例
大数据
医疗领域应用
演讲人:
崔浩博时间:
2014.10.13ppt
制作:
崔浩博
outline
一
、
医疗与大数据的趋势二
、医疗大数据的应用场景三、
案例分析
一
、
医疗与大数据的趋势二、医疗大数据的应用场景三、
案例分析
医疗费用在不断上升
GDP的占比非常高
10-19%
0-9%
趋势分析:
我们正处在医疗行业的一个重要转折点
%
of
population
over
age
60
30+
%
25-29%
20-24%
2050
WW
Average
Age
60+:
21%
Source:
United
Nations
“Population
Aging
2002”
全球老龄化
平均年龄60+
的人
:
目前的10%,到2050
年将到达
20%
以美国为例:
医疗大数据的价值
3千亿美元/年,相当于每年生成总
值增长0.7%
到
2020
年，医疗数据将会急剧增长到
35ZB,相当于
2009
年数据量的44
倍增长。
0
1500010000
5000
2010
2011
2012
2013
2014
2015
趋势分析:
我们正处在医疗行业的一个重要转折点
存储的增长
医疗服务产生的数据总量
（PB）
Admin
ImagingEMR
Email
File
Non
Clin
Img
Research
一
个
CT
图像
含有
大约
150MB
的
数据，
而一
个基因组序列文件大小
约
750MB
，
一
个标准的病理图则大得多，
接近
5GB
。
如果
将这些数据量乘以人口数量和平均寿命，仅一个社区医院或一个
中等规模
制药企业就可以生成和累积达数
个
TB
甚至
数
个
PB
级
的结构化和非
结构化数据。
一
、
医疗与大数据的趋势
二、医疗大数据的应用场景三、
案例
分析
医疗大数据应用场景
医疗行业产生的数据量主要来自于
PACS
影像、
B
超、病理分析等业务所产生的非结构化数据。
人体不同部位、不同专科影像
的数据文件大小不一，
PACS
网络存储和传输要采取不同策略。
面对大数据，医疗行业遇到前所未有的挑
战和机遇。
医疗行业大数据应用场景非常多，右图仅以临床操作和研发为例，展示医疗
行业大数据应用场景。
对于公共卫生部门，可以通过过覆盖全国的患者电子病历数据库，快速检测
传染病，进行全面的疫情监测，并通过集成疾病监测和响应程序，快速进行响应。
一
、
医疗与大数据的趋势
三、
案例
分析
二、医疗大数据的应用场景
临床医生的知识更新无法与急剧增长的医学知识同步。
对大批量的常规决策工作，自动化决策效率更高（
如大量的常规实验室检测和数据分析等
）
。
人有时会犯错误或失误，当然医生也不例外
（
复杂病例和常见病例都会出错
）,
使用临床决策支持系统
，可以提醒专家没在意的或没有发现到的病人信息，从而提高诊断准确性
对医学院学生，成熟专业
的临床支持
系统可能是他们学习专业知识和专家经验的方便可得的廉价的老师，同时也
是他们初入医院实习工作的非常好的助手。
临床决策支持系统的功能和作用
案例分析
基于知识库的
CDSS
大部分
CDSS
属于此类，它由三大模块组成:
知识库、推理机和通讯模块。
知识库存储着
编译好的医学知识
，推理机
则根据知识库里的规则，以及患者的资料进行自动分析。
分析的结果通过通
讯模块反馈给用户
。
例如:
MYCIN
非
基于
知识库的
CDSS
主要
是通过机器学习从已有的经验中自动攫取规则。
MYCIN
系统
MYCIN
系统是由斯坦福
（Stanford）
大学建立的对细菌感染疾病的诊断和治疗提供咨询的计算机咨询专家系统。
医生向系统输入病人信息，
MYCIN
系统对之进行诊断，并提出处方。
细菌传感疾病专家在对病情诊断和提出处方时，大致遵循下列
4
个步骤
:
确定
病人是否有重要的病菌感染需要治疗。
为此，首先要判断所发现的细菌是否
引起了疾病
。
（
2）
确定疾病可能是由哪种病菌引起的。
（
3）
判断哪些药物对抑制这种病菌可能有效
。
（
4）
根据病人的情况，选择最适合的药物。
咨询开始时，先启动咨询系统，进入人机对话状态。
在对话过程中，系统向用户提出必要的问题，进行推理。
当结束咨询时，系统自动地转入解释子系统。
解释子系统回答用户的问题，并解释推理过程。
解释时，系统显示说明为什么需要某种信息，以及如何得到某个结论。
这样做的主要目的是为了使医生容易接受系统的结论。
动态数据库中的数据表示
数据库中的数据都用如下形式的三元组描述
:
（
对象属性值）
1.“
对象”又称为上下文，它是系统要处理的实体，例如:
PERSON（
病人）
2.“
属性”又称临床参数
用于描述相应对象的特征，例如“病人”的姓名、年龄、性别。
3.“
值”是指相应属性的值，根据属性的不同类别，其值可以是一个或多
个。
MYCIN
采用上下文树
（Contexttree）来表示问题
一棵
上下文
树构成了对一个病人的完整描述。
知识库的知识表示
领域知识的
表示
领域知识用规则表示
其一般形式为:
RULE
*
**IF<前提
>THEN<
行为
>
例如对如下规则:
RULE047
如果:
（
1
）病原体的鉴别名不确定，且
（
2
）病原体来自血液，且
（
3
）病原体的染色是革兰氏阴性，且
（
4
）病原体的形态是杆状的，且
（
5
）病原体呈赭色
那么:
该病原体的鉴别名是假单胞细菌，可信度为
0.4
。
静态知识的表示（
属性特性的表示
）
从临床参数（属性）的角度来看，可认为每个临床参数都具很多种特性。
主
要特性有
:
MEMBEROF:
按所描述的对象不同迸行分类时，临床参数所属的类型名，例如
:
PRO-
PTo
VALUTYPE
:
临床参数是单值、二值还是多值。
PROMPT:
用于向用户提问一个单值或二值参数的值。
LABDATA
:
用于指出相应参数的值是否可从用户那里获得。
推理策略:
MYCIN
的咨询系统
采用逆向推理（目的驱动）过程。
在咨询开始时，首先例示上下文树中的根节点。
根节点属于
PERSON
类型的上下文。
例示包括以下3
步:
（1）
赋于这个上下文一个名称;
（2）
把这个上下文加到上下文树上去;
（3）
马上跟踪这类上下文的
MAINPROPS
表中的参数。
实例示范:
系统首先在数据库中建立一棵上下文树的根节点
并为
该根节点
指定一个名字
PATIENT-1（
病人
-1）
，其类型为
PERSON
。
PERSON
的属性为
（NAMEAGESEXREGIMEN）,
其中前三项都具
LABDATA
特性，即可通过向用户询问得到其值。
于是系统向用户提出询问。
用户输人病人的姓名、年龄及性别，并以三元组形式存入数据中。
REGIMEN
不是
LABDATA
属性，必须由系统推出。
为了得到
REGIMEN,
系统将开始推理过程。
推理时首先运用的一条规则是
RULE092
。
规则
092
IF
存在一种病菌需要处理
某些病菌虽然没有出现在目前的培养物中，但已经注意到它们需要处理
THEN
根据病菌对药物的敏感情况，编制一个可能抑制该病菌的处方表
从处方表中选择最佳的处方
ELSE
病人不必治疗
规则
092
的前提部分涉及到临床参数TREATFOR
，它是一个
NONLABDATA,因而系统调用
TREATFOR
的
UPDATEI-BY特性所指出的第一条规则
090
。
规则
090
:
IF
已知细菌的类别
存在和这种细菌的出现有关的显著的病症
THEN
肯定存在一种需要处理的细菌（
可信度
1.0）
检查它的前提是否为真，此时如果该前提所涉及到的值是可向用户询问的，
就直接询问用户
否则再找出可推出该值的规则。
如此反复进行，直到最后推出
PATIENT-1
的主要临床参数
REGIMEN
为止。
发展障碍
医学
知识的复杂性导致了系统设计时需要考虑非常多的因素，如患者的症状、体征、实验室检查数据、家族史、基因、流行病学资料、现有的医学文献等等。
而且，每年发表的临床研究数以千计，而且不少研究彼此矛盾，大量的数据导致了系统维护上存在困难。
目前成功用于诊断环节的
CDSS
常常局限于某个领域，比如，
1971
年上线使用的
Leeds
腹痛诊断系统，其诊断的正确率高达
91.8%
，而医生的诊断正确率在
79.6%
。
但这套系统仅能用于腹痛的诊断。
临床
工作的复杂性也增加了系统整合的难度。
目前大多数系统仍独立于临床工作流程，这导致了医生需要独立打开
CDSS
，然后花费时间录入患者资料，降低了工作效率。
目前整合比较成功的案例是药房系统和账单系统。
因为药房工作相对简单，
CDSS
主要解决药物相互作用问题，比较容易设计。
CDSS
经常产生大量的警告信息，很容易导致医护人员疲劳应付。
正向推理（数据驱动）
用户通过人机界面输入一批事实，推理机用这些事实，一次雨知识库中的规则前提匹配，若某规则前提全被事实满足，则规则可以被运用。
规则的结论作为新的事实存储，然后用更新过的事实再与其他规则的前提匹配，直到不再有可匹配的
规则
。
应用
Thanks
升级会员 