来源：DataFunTalk

本文约8000字，建议阅读10+分钟 
本文将从数据、算法、知识3个层面带来阿里在医疗NLP领域的工作、遇到的问题以及相应的思考。

[ 导读 ]NLP技术在智慧医疗领域有着越来越多的应用场景，本文将从数据、算法、知识3个层面带来阿里在医疗NLP领域的工作、遇到的问题以及相应的思考。主要内容包括：① 阿里医疗业务介绍；② NLP赋能医疗行业；③ 医疗+NLP（医疗NLP本质是什么）；④ 中文医疗信息处理标准数据集。

01 阿里医疗业务介绍

医疗AI（即深度学习技术）在医疗领域的应用场景包括：

• 医学影像（国内较为成功的医疗AI公司基本都是医学影像方向）；
• 文本信息抽取和疾病预测（我们今天分享的重点）；
• 病患语音识别和机器翻译（三甲医院医生用话筒讲话，然后ASR语音识别转录成电子病历的内容，通常用到RNN或Seq2Seq的技术实现）；
• 体征监测和疾病风险评估（应用场景包括慢病评估，健康管理等）；
• 新药研发（新冠疫情之后逐渐兴起，目前该领域较为火爆）
• 手术机器人（交叉学科，一般会涉及到增强学习技术）。

阿里巴巴在医疗健康赛道有较多布局：

• 阿里云：面向B端，主要服务于公卫领域如医院、卫健委等智慧医疗的应用场景。
• 阿里健康：可分为两部分，包括电商售药和互联网在线问诊，其中线上问诊涉及到的自动问答技术与NLP强相关。
• 蚂蚁保险：在智能理赔过程中，患者上传病历或收据，经OCR识别、文本信息抽取后被用于服务核保核赔预测模型。
• 夸克浏览器：面向医疗的垂直搜索。
• 达摩院：两个团队在做医疗AI的业务。①NLP团队：主要负责NLP原子技术能力，服务于阿里集团内的一些业务方、以及阿里云的生态合作伙伴。②华先胜博士所负责的城市大脑团队：主要负责医学影像，根据影像图片做辅助诊疗。
• 天池：天池大赛的定位是针对人工智能技术尚未成熟的行业，先通过来源于真实场景的数据集把问题提出来，然后征募选手来做比赛方案，相当于做一个先期的技术验证。天池开放了很多行业稀缺的数据集，尤其是医疗行业。

讲者今天的分享主要介绍了在达摩院和在阿里云天池团队所做的医疗NLP工作。

02 NLP赋能医疗行业

NLP处理医疗行业数据时，首先要分析数据的特点，其次选择适合这批数据的模型，或者做一些模型改良。

医疗数据包括：

• 电子病历数据：是讲者处理较多的数据，特点是数据的非标准化和多样性。
• 药品说明书，检查报告单和体检报告：这3类数据比较规范。
• 在线问诊，论坛问答：数据质量较差，其特点是口语多，噪音大。患者就诊过程中涉及较多不相关信息，医生的工作主要负责识别、总结有效信息，然后我们再应用NLP去做后续的分析处理。
• 医学教科书、科研文献：数据比较规范。我们应用NLP技术把文本类内容解析出来。

电子病历数据的主要应用场景是电子病历质检。电子病历质检指的是根据各个省市卫建委发布的电子病历书写规范对医生书写的电子病历进行质检，其中浙江省的电子病历书写规范比较领先，大概有240多项检测点。传统的做法是医院设置专门的质检科，由质检科医生将每份病历按照质检点进行人工检查，因此存在效率低、查全率低的痛点。阿里云智能电子病历质检就是帮助医院质检科解决这个痛点的产品。举个例子，在上图这份病历中我们检测到两个不合规的点。

• 一致性矛盾：患者一开始疼痛的部位是“右”上腹，后来经过治疗“左”上腹疼痛缓解。我们的产品准确的捕捉到患者初始症状出现的部位以及治疗改善的部位不一致。
• 诊断依据不充分：住院病历中的初步诊断写的是胆囊结石，但是下一步诊疗计划里却出现了腹部B超，可见该患者尚不能明确诊断为胆囊结石。如果临床高度怀疑胆囊结石，初步诊断可写“腹痛待查，胆囊结石？”，而不能只写“胆囊结石”。我们的产品准确的捕捉了诊断依据的不充分。

电子病历是一种半结构化的文本，章节标题可以认为是结构化的信息，而医生书写的文字是无结构化的信息。针对第一个检测点，我们需要运用NLP对这种半结构化的信息进行文本结构化，同时对术语进行归一化。而针对第二个检测点，我们需要构建医学知识图谱。

阿里云智能电子病历质检的核心模块儿是医疗实体、属性的联合抽取，医学文本的实体识别有如下3种特点：

• 实体属性：如当前疾病是现病史（现在发生的）还是既往史（过去就有的），症状是阳性（肯定）还是阴性（否定）。传统的方法是使用关系抽取模型，但我们的产品为了追求效率没有用关系抽取的方式，而是用了下图中的模型。
• 嵌套：如图中的症状中就包含了身体部位，医学文本中有大量嵌套类型的实体存在。
• 非连续：在药品说明书中大量存在。

攻坚上述产品核心内容过程中，我们的工作成果有以下4个：

① 基于实体属性构建模型：

我们选择了一个非常朴素自然的idea，即span-based模型（邱锡鹏老师团队最近推出的unified model可以把所有的情况cover掉，感兴趣的可以去了解一下）。该模型采用BERT作为语义建模模型，取一个start位置，再取一个end位置去形成一个span，如图中W1-W2或W3-W6就是1个span。我们通过枚举所有的span去学习span的表示，模型的特点是可以天然的解决嵌套实体类型，接下来再对span表示去做分类，采用MLP或其他的分类方法进行实体类别判断。

属性判断是在此基础上再多一个分支判断，这样一个非常简单的联合学习的框架就是span-based backbone模型，其最下面一层是embedding 层（线上的话我们会应用预训练模型），上面一层是文本表示层，再上面一层是分类层。这里先抛出了一个问题，枚举span会导致模型的复杂度为O（N^2），与传统模型相比其复杂度较高，那么如果想将其用于线上的话，应该怎么处理？

讲者的答案是要对这个模型做改良（2020年讲者将其工作成果发表在AAAI上）。如上图所示，改良span-based模型的motivation是增强span的表示。这里主要借鉴了MRC的思路，即把start及end形成一个span的概率设计进来，我们通过计算“start的概率”ⅹ“end的概率”ⅹ“span表示的概率”进行最终的判断。

这个模型的benefit是在推理阶段进行加速，通过为“start的概率”和“end的概率”设定阈值（高于阈值将被预测，而低于阈值会被剥离掉），将模型复杂度由O（n^2）降为O（mⅹN）。m表示句子里的实体个数，N表示句子token的长度，这样在线上应用的话，效率还是非常高的。图中的表格是AAAI20的实验结果，之后我们又不断探索其他模型，在某些数据集上结果已经超过了这个实验结果。

② 基于嵌套实体构建模型：

我们针对医学嵌套实体的特点开展了很多研究的工作，上图是我们发表在AAAI2021的一个工作。我们将嵌套 NER识别问题看作是经典的句法成分分析（constituent parsing）问题， 根据嵌套实体的特点将其视为部分观察(partial observed)到的树，进行选区解析，并使用部分观察到的 TreeCRF 对其进行建模。具体来说，将所有标记的实体span视为选区树中的观察节点（黑点），将其他跨度视为潜在节点（白点）。该模型其中的一个优点是，实现了一种统一的方式来联合建模观察到的和潜在的节点。而另外一个优点是，在进行选区分析时，通过Batchfied将模型复杂度从O（n^3）降为O（nⅹlogn）。

③ 医学术语归一化：

是医疗行业领域里面非常重要、非常核心的任务，这是因为同一种诊断、手术、药品、检查、化验、症状可能有多达几十到上百种不同的写法。比如，诊断“上感”，也可以称为“上呼吸道感染”，ICD编码是J06.903。诊断“胆囊结石”=”结石性胆囊炎”=“胆囊结石伴胆囊炎” ，ICD编码是K80.002。药品“氟哌酸”=“诺氟沙星”，国药准字H10910059。能把这个问题解决好，是一个非常有挑战的工作。

为了实现医学术语归一化，我们分两步进行。如上图所示，第一步Retrieval，从词典里面通过BM25算法筛选候选词；第二步ReRank，通过预训练语言模型（PTLM，指的是Pre-trained Language Model）如Bert进行排序，其中mention就是要归一化的原词，而concept则是我们这边筛出来一些候选词，然后进行打分，分数比较高的将作为备选方案。

医学术语归一化的技术在我们的业务场景里面用的还是比较多的。第一种是跟大家生活息息相关的医保或商保的核算，其主要根据ICD编码进行DRGs付费及核算。第二种是数据治理，例如不同医院间的数据互联互通。第三种是医学科研统计，如医生要筛选“2型糖尿病”的患者来做队列，“II型糖尿病”也要被识别成同一个术语。

④ 合理用药判断：

是PTLM应用的另一个场景。例如尽管开塞露的药品说明书的适应症只有便秘，但医生给诊断是肠梗阻的患者使用开塞露也是合理的。这是因为虽然医生的诊断与药品说明书字面上不match，但肠梗阻实际上会导致便秘，所以经过推理医生用药是合理的，而这个推理过程用到的就是医学知识。

另外合理用药还涉及到用法及剂量的合理，如诊断为“成人不能进食”的患者需要鼻饲给药，儿童用药需要根据体重计算剂量，还有药物需要首剂负荷用药。因此我们现在的工作是将说明书等原始文本，用文本生成的方法转化成逻辑表达式(logic expression)，如决策树等。因为实验结果目前在投稿阶段，所以本文就先不展示模型了。此外讲者提出一个问题，医学知识图谱是医学知识最基础的一种知识表示方式，而一个全面和专业的医学知识库需要融合多种知识表示方式，那么如何用一个新的结构来表示医学知识库呢?

03 医疗+NLP（医疗NLP本质是什么）

医疗NLP的本质是医疗，如果把NLP比做锤子的话，那么医疗领域相关问题就是钉子，我们要做的就是拿着锤子找钉子。我们前期做的一些尝试工作就靠近医学本质（偏临床一些），包括医学临床试验结果预测模型的建立以及融入知识的医学预训练语言模型的建立。

医学临床试验结果预测模型的建立：

受疫情的启发，我们做了一个比较有意义的工作，即研发医学临床试验结果预测模型。临床试验是循证医学的一个重要组成部分，主要目的是验证某种干预手段（手术、化疗、放疗或药物）是否有效。临床试验首先需要召集很多志愿者或患者，然后做对照试验，最后统计得出结果，整个试验过程比较漫长。设计有缺陷或者难以成功的临床试验占用了宝贵的病人资源及珍贵的时间，可能会使亟待实施的临床试验因招募不到足够的患者或时间的紧缺而被迫终止。

所以，研究者如果在临床试验方案设计阶段就就预测出临床试验的结果，并优先进行成功概率较高的临床试验是非常有意义的工作。举个例子，美国吉利德科学公司研发的针对MERS和SARS的药品瑞德西韦曾被科学家们认为是对抗新冠病毒最有希望的药物，这是因为MERS、SARS和新冠病毒同属冠状病毒科且在埃博拉（另一种冠状病毒）感染患者的紧急治疗中也积累了有效的临床结果，这为新冠疫情筛选新药提供了方向。科学家的这种思考是根据既往的研究经验和医学知识得出的，这使得在临床试验开展前评估临床试验所研究问题的可行性成为可能。

NLP可以基于科学家们的研究经验以及现有的医学知识来辅助地预测临床试验的结果，从而大大提高临床试验实施的效率，由此我们抽象出一个问题，即BPICO。B是Background（研究背景，如研究经验、医学知识），P是Population(或者Patient，代表试验组人群，如新冠患者)，I是Intervention（干预手段，如瑞德西韦），C是Comparison（对照组，如安慰剂），O是Outcome（需要观测的试验指标，如血氧饱和度）。总的来说，就是首先给出background，然后给定患者，最后比较治疗方案相对于对照方案的观测指标是上升/下降/不变，上升代表有效，下降或不变代表无效。

我们的工作是把上述问题BPICO转化成语言模型，即基于大规模隐式临床证据预训练的模型EBM-Net（隐式证据指的是含有“than”,“greater”,“lower”的试验结果），如下图所示。Pubmed等数据库的文献里面会有临床试验，我们把其中有对比关系的句子（比如说含有“greater”的句子）抽取出来，并把中间的比较词mask掉，向构建好的模型输入给定的两组数据（一个是对照组，一个是试验组），然后推断它们之间被mask的关系。

接下来，我们进一步改进了上述模型。我们对调了偏序关系，lower变成greater，greater变成lower，即先用正序的隐式证据预测其结果，再用反序的隐式证据预测相反的结果。这样一来，加入反序的例子将有利于模型学到治疗组和对照组之间的比较，而不是语言模型里的共现关系，使得模型更健壮。

总得来说，当我们固定了想要研究的疾病人群（P）和观察指标（O）后，可以固定以现有的标准治疗为对照（C），遍历每种可能的新型治疗方式（I）以及其相关的背景介绍（B），用模型预测其成功的概率，优先选取所有可能的治疗方式中成功概率高的做临床试验。上述工作成果被EMNLP2020录取，其实际的应用场景可进一步扩展到新药研发及老药新用。

融入知识的医学训练语言模型的建立：

区别于通用文本，医学文本有独特的术语和风格；并且医学领域中已经构建了含有大量医学实体和知识。基于这两点，该工作首先在英文领域里进行了尝试，提出了KeBioLM来增强医学预训练模型。KeBioLM利用医学论文数据库PubMed作为训练语料，通过SciSpaCy将自由文本与UMLS知识图谱中的医学实体知识相结合。KeBioLM含有两个Transformers层：第一个层用于从文本中提取医学实体并学习实体表示；第二个层用于融合文本和实体的信息来增强文本表示，如图所示。

尽管上述模型在英文领域有效果，但在中文领域里效果反而下降，主要原因可能是中文医学知识库未成体系，所以如何构建中文医学知识库是需要进一步探讨的。

04 中文医疗信息处理标准数据集

在中文医疗信息处理标准数据集相关工作中，讲者简要介绍了3个方面。

医疗行业缺乏标准数据集，目前公开的中文医疗数据集主要有3个来源，即CCKS/CHIP会议组织的学术评测任务， 竞赛类医疗数据集（如天池大赛）和部分医学论文数据集。同时，中文医疗NLP暂无多任务评测基准榜单，业界已有的GLUE/SuperGLUE/CLUE（中文领域）以及BLURB（微软开发的医疗榜单）均推动了领域技术的快速发展。在此背景下，由天池平台联合中国中文信息学会医疗健康与生物信息处理专业委员会在合法开放共享的理念下发起了中文医疗信息处理挑战榜CBLUE榜单（Chinese Biomedical Language Understanding Evaluation Benchmark），榜单任务包括医学信息抽取、医学问答、医学文本分类和医学术语归一化等，目的是推动中文医学NLP技术和社区的发展。榜单上线后比较受关注，截止7月底，已收到400多组打榜申请，并且150多队伍成功提交了打榜结果，打榜队伍涵盖了产学研界的知名机构。

CBLUE地址：

https://tianchi.aliyun.com/specials/promotion/2021chinesemedicalnlpleaderboardchallenge

天池数据集：

天池平台在举办天池大赛的同时，我们也开放了很多数据集。天池数据集的定位是做专业的科研数据集平台。和竞品相比天池数据集的特点是涵盖了上百个行业稀缺数据集。部分行业如电商、金融、物流的数据集均来源于真实的脱敏过的阿里真实业务场景， 比如天池团队与这次会议主持人林俊旸老师就联合开放了一个多模态理解与生成的评测榜单MUGE(Multimodal Understanding and Generation Evaluation Benchmark), 这些数据集/挑战榜开放的目的是促进相关领域技术的研究发展。

MUGE地址：

https://tianchi.aliyun.com/specials/promotion/mugemultimodalunderstandingandgenerationevaluation

05 问答环节

Q：医疗数据一般是在内网文件当中，达摩院是怎么解决数据的问题？

A：首先医疗数据我们是拿不到的，虽然我们和医院合作了很多模型，但数据的归属权属于医院，数据都是基于内网去展开的。一般我们会找一些类似的语料（维基百科、论坛）来做模拟，也在尝试一些保护数据安全的技术方案如联邦学习来做模型改进。

Q：医疗NLP的标注需要比较强的专业知识，达摩院的标注是如何开展的？

A：我们跟天猫精灵团队合作，他们的标注平台对接了很多标注专家，有医学生、护士，还有一些真正的医生，我们数据标注基本还是以专家为主。算法人员也会参与到标注里面去。举个例子，医生从专业知识角度来标注的话，会将一个很长的句子标注成一个症状或者一个诊断，但对于模型来说其实非常不友好，所以我们进行标注的时候，一般都是算法人员和专家一块来把关的。以保证标注的准确度和专业度，还要保证模型上线落地的效果。

Q：CBLUE后续还会引入哪一些任务类型？

A：CBLUE是我们和CHIP（China Health Information Procesing Conference）学会共建的。2.0版计划在今年11月份推出。2.0会拓宽任务类型（如增加NLG类型任务）和增加任务数，大概会扩展到15到16个评测任务。提到生成类数据集，在医学领域里生成技术的应用还是有的，但为什么生成技术这块儿没有太多标准化的数据，原因主要还是在生成的评估指标。虽然生成的是通顺的，也符合语法逻辑的，但它其实不符合医学常识的，后续需要医学NLP社区来共同解决这个问题。

Q：CBLUE存在标注不全，从模型的角度上如何改进？

A：首先医学领域的标注是非常困难的，不同标注专家对同一份标注规范会有不同的理解，很难保证完美的一致性。

CBLUE榜单在上线前，我们基本上是会检查过一次的，除了把有些特别明显的错误挑出，还有把一些不太健康的语料，如来源于夸克搜素的语料（搜索是千奇百怪的）剔除掉。数据质量是一个需要长期优化的问题。

在榜单上线后，我们也收集打榜选手的反馈，比如大家觉得有一些漏标的情况。我们也跟及时反馈给每个数据的提供单位，来保持紧密合作的关系。在2.0发布的时候，我们也会更新现有数据集中有缺陷的标注。数据集质量的提升是一个长期的工作。

CBLUE的上线，我们和CHIP学会做了非常多的努力，期待能结合社区的力量一起把CBLUE建设的更好。

Q：CBLUE能否推进开放一些脱敏的病历数据集？

A：国家的法律法规规定病历数据属于患者个人，医院和医生都没有权利去使用这个数据，所以直接开放脱敏病历是不太可行的。

Q：是否考虑做多模态的榜单？

A：是有这个规划的，但不会放到CBLUE榜单里面，而会新起一个榜单。

Q：术语标准化怎么做？

A：我们目前是在中文领域上去做术语归一化的。它是一个框架。第一步的话就是粗排即检索。我们有标准词库，一般来说是ICD词典。从词典里选出TOP10或TOP20的候选词。第二步做精排即rerank，mention就是归一化的原词，而concept是候选词，每一个候选词都会经过Bert打分，按照置信度排序选出TOP3。

Q：术语归一化在做rerank的时候大概用了多少数据来做训练？

A：每一种类型的话都不一样。诊断方面是4,000多条诊断的数据，而手术方面是参照CHIP数据集的标注规范，我们自己标注了近三万条。每一类术语归一都分别训练单独的模型。检查化验这两个是比较麻烦的，因为国家没有标准规范，一般来说电子病历厂商（如东软、卫宁）是有一个标准库的，我们第一步就是基于一些中心的三甲医院，去建检查检验库的标准词典。

Q：数据治理在解决映射问题的时候是怎么去解决数据标注的问题的？

A：术语归一化中我们一般是给出top3的结果，然后让医生、审核人员或数据治理人员去做要判断。数据标注时如果有编码规范表（ICD词典）的话，其实相对来说还是比较好标注的。ICD编码表的特点是分段的，有一级二级三级这样的类目的。

我们比较期望能直接映射到最下面层级的类目上的，但如果实在是搞不定的话，或实在判断不了的话，可以往二级或者再上一级目录上去做标注。整体来说在ICD上的标注，经专家测评后的准确率相对来说是比较高的。检查化验其实没有统一的标准规范的，一般来说的话都是基于一个区域去建标准规范。如果我们基于一些区域即一些中心的三甲医院来制定标准的话，那么在区域里面它的认可度还是比较高的。

Q：近百种类别的细粒度，实体识别就有没有什么比较好的方法？

A：我们做了20几种实体，和9种属性，可能还没有达到上百种。分享一下我们上线的效果，在电子病历文书类型上，最终F1得分在70到80之间。在一些学术数据集上（CCKS，4类实体类型），用我们这个模型的话，大概是已经上到91了。讲者的建议是，第一点根据你的业务场景去做，你是不是真的要去标这么多类型，类似我们病历质检的简单的情景需求，可能实际上都不需要30多种实体。

我们这30多种实体类型其实服务了很多的业务场景，包括病历质检、 DRGS、健康档案。百度相应的竞品的实体类型差不多是50多种。第二点这种细粒度怎么去做。先找一些中心实体，再用一些后处理或者规则的手段，挖一些更细粒度的实体。我们在上模型前有预处理阶段，模型走完以后，还要加一些后续的规则，上线后还有一些人工干预的机制等。这是一个体系，不是仅用模型就可以的。

Q：实体属性的话都是转化成这种嵌套NER，没有做关系抽取吗？

A：是的。没有考虑关系抽取的模型是因为考虑到关系抽取的在线复杂度会比较高。我们是统一到一个框架上的，它满足我们业务需求的同时也顺带把其他实体给解决掉了。我们这个框架在线上运行效率相对来说是比较可观的。

Q：病历抽取信息的时候有没有用阅读理解的方法？性能是怎么样的？

A：MRC的方法中，李纪为老师在去年ACL上的一个工作达到了一个比较好的SOTA。我们其实做过调研，我们做研究的时候也对比过李老师的工作，但实际上线的时候是没有这样去用。主要考虑的因素是性能，因为医院机器是比较弱的，一般都是两核4G的或者四核8G的机器，且两核4G的比较多一些。所以最终的话，虽然我们研究过MRC，但是并没有把它上线。

Q：术语标准化里边的症状有没有相应的标准，前期出牌具体怎么做的，有没有用一些规则？

A：症状这块其实是没有标准的。我们现在是这样解决症状的，第一步先看它是否在ICD表里面，如果有就把它并入疾病里，如果没有就定义为症状。我们基于历史经验已经积累了一些症状的词汇，但同时我们针对各专科也继续进行专科症状词汇的积累。症状这方面的词汇我们内部在用，没有公开。

今天的分享就到这里，谢谢大家。

分享嘉宾：

编辑：黄继彦

校对：汪雨晴