大医疗数据背景下基于云架构的家庭诊断服务

1、大医疗数据背景下基于云架构的家庭诊断服务摘要：自我护理服务在我们的日常生活中正变得越来越重要，特别是在面临全球老龄化这样紧迫的情况下。大量的历史医疗记录这样的大数据使得用户进行自我护理服务成为可能，例如他们自己就可以通过类似的病人的病例来获得诊断。发展这样一种自我护理的服务就会面临很多挑战包括高并发和可扩展的的医疗记录的检索，数据分析，以及隐私的保护。在本文中，我们提出了一个基于云计算的架构来实现自我护理服务称为家庭诊断以解决上述挑战。具体而言，一个基于Lucene的分布式搜索集群被设计出来旨在支持高并发和可扩展的病历检索，数据分析和隐私保护。此外，为了加快医疗记录检索，Hadoop集群被采用

2、以存储离线数据以及构建索引。当谈及家庭诊断服务的实现，我们可以从中获得相似的历史医疗记录和疾病症状点阵，以帮助用户查明他们可能感染了哪一种疾病。最后，一个原型系统会被设计出来以及一个运行实例会被呈现以证明我们的提案的扩展性以及效率。关键词：基于云计算的架构，家庭诊断服务，医疗大数据1 介绍1.1 背景根据世界卫生组织的报告，人们在亚健康状态（SHS），也被称为“第三状态”（处于健康和生病之间），在世界人口中占75（He et al., 2013）。 在中国，处于这个状态的人群数量已经达到了9亿人（Ding et al., 2009）。有相当一部分人会密切关注他们的健康希望能获得预防性健康检查或

3、以有类似病历的病人来指导自己。而且，随着人口老龄化的成长，有些为老年人的慢性疾病监测也应在日常生活中进行。因此，为了满足“SHS”群体和人口老龄化的需求，按需自助服务应该被发展以帮助人们可以在家方便地获得疾病预防知识。(Rashidi and Cook, 2009; Cook et al., 2003; Doctor et al., 2005).另一方面，不断增加的在日常临床活动所产生的医疗和诊断数据量，使得开展医疗自助服务来满足SHS人群和老年人的要求成为可能。然而，大量的医疗数据，以及它的各种格式，造成大规模数据管理和高效的知识挖掘技术的挑战，这也被称为“大数据”的问题。(Chaudhur

4、i, 2012). 由于云计算的显着特征，如弹性计算能力，和普遍的面向服务的性质 (Shang et al., 2013; Xu et al., 2012), 云计算技术已被广泛研究，并在大数据领域使用 (Canny and Zhao, 2013; Cheng et al., 2012), 许多医疗保健服务已经迁移到云环境。更具体来说，本文提出的研究报告是为连云港卫生局建立一个基于大型研究项目的医疗信息云平台。连云港是中国江苏省的一个城市，靠近上海。卫生局是要搭建一个平台，以收集所有的医疗信息，如每个来自当地保健医师的医疗记录。（例如，医院，诊所）。通过这样做，各种医疗服务可以被制定以符合实际

5、的医疗保健需求。例如，每个病人可具有他/她的个人健康简况，由所有他/她的临床与每个临床访问相关联的记录组成。1.2 一个生动的例子我们讨论这个生动的例子是为了突出我们将要提出的问题。假设有一个名叫李某的患者，有一天生病了。并且他知道他的症状包括“高烧”和“呼吸困难”。他去医院进行诊断之前，希望通过互联网初步诊断，这样就能知道他可能患有哪种疾病。因此，他可以在事先通过医院的主页作出合适的预约。在上面的例子中，如果有一个医疗自助服务，根据李某的疾病症状提供相似的历史医疗记录这样的诊断协助，这将有助于李某做出合适的预约。此外，有相似的历史病历，李某会对他的病情更详细的了解。因此，当李某去医院进行诊断

6、时，将花费李和医生双方更少的时间做出正确的处理，从而提高诊断效率。然而问题出现了，就是如何去提供这样一种自我保健服务。具体来说，这个问题主要包含以下三点。第一点是如何根据李某的疾病症状在大规模和不断增加的医疗记录中提供实时在线医疗记录检索。另一个是如何提取有用的诊断知识来帮助李从大量检索出来的医疗记录中弄清楚可能感染了什么疾病。最后一个是如何避免在病历隐私信息曝光，因为医疗记录是隐私的、敏感的。1.3 我们的工作和贡献通过这些观察，在本文中，我们将通过以下工作来面对这些挑战。（1）在本文中我们提出了一个基于云的框架来实现一个名为家庭诊断的自我保健服务。具体来说，一个分布式基于Lucene搜索集

7、群被设计出来旨在提供高并发和可扩展的在线医疗记录检索，数据分析和隐私保护功能。为了加快病历检索，Hadoop集群被采用已进行线下数据存储和检索库。（2）更具体来说，家庭诊断服务的实现由四个步骤组成。首先,用户提交查询有关他/她的疾病信息。然后医疗记录匹配用户的疾病症状,性别和年龄在步骤2中检索。通过检索医疗记录，数据分析在步骤3进行，来计算疾病症状的点阵，揭示疾病常见症状之间的关系。最后,隐私敏感信息根据访问控制策略在医疗记录中被过滤。因此，疾病的症状点阵，以及进行过隐私处理的医疗记录被返回到用户，这为用户自己做一个初步的诊断提供了一个详细的诊断依据。1.4 本文的组织结构本文的其余部分安排如

8、下。第2节讨论的病历初步知识，以及一些关键技术，如基于云计算框架中被采用的Hadoop的计算框架和Lucene库。基于云计算架构的家庭诊断服务将在第3节介绍。第4节介绍了家庭诊断服务是如何为用户提供了诊断援助的细节。基于云计算框架的家庭诊断服务的评价将在第5部分被讨论。其中一个原型系统设计讨论和一个运行示例会被提出以证明我们的建议的可扩展性和高效率。第6节讨论了大医疗数据在工业和学术领域应用的相关工作。第7节总结全文，并讨论了今后的工作。2 初步知识在本节中，预备知识将被讨论，来介绍医疗记录和在基于云的架构中应用的一些技术。2.1 医疗记录定义1（医疗记录）从形式上看，电子病历是去网络由三元组

9、定义：EMR=（病人数据，病人简况，临床资料）(Zhang et al., 2013; Li et al., 2010)。每个元素的内容如下：（1）病人数据：患者数据包括患者的基本信息，如患者的姓名，性别，出生年月日等;（2）患者简况：患者简况通常包括病人的病史，包括疾病史，手术史，输血史，以及过敏史等等。（3）临床资料：临床数据存储详细的临床信息，包括症状集，病人投诉，现病史，诊断结果，治疗方法等，与患者的每次访问一个保健医生相关。通常情况下，在临床活动中，电子病历要么是一个XML文件由存储在网络文件系统的标签值对组成，或者存储在关系数据库中的关系记录。图1给出了XML病历的一个例子。一般来

10、说，在日常的诊断中，患者的疾病通常是由他/她的疾病的症状，以及他/她的年龄和性别确定的。另外，症状相同，同样的性别和年龄相仿的患者倾向于感染类似疾病。基于此观察，使用者在在类似的医疗记录检索需要提供疾病症状，性别和年龄，如图1三个红色圆圈所示。2.2 Hadoop：HDFS和MapReduce框架Hadoop (Ekanayake et al., 2011; Bahga and Madisetti, 2012)是一个云计算框架，用来运行内置商用硬件大型集群应用程序。Hadoop由两个主要组件组成。（1）HDFS:HDFS(Hadoop分布式文件系统)在集群中的节点的集合中存储文件。大文件分割成

11、块(默认64 MB)和每一个块可以写入多个节点(默认值是3)容错。图1 一个XML医疗记录的例子（2）MapReduce:MapReduce是并行数据处理模型,该模型由两个阶段组成:Map和Reduce。在映射阶段,从分布式系统(如HDFS)读取数据,在一组集群中的计算节点之间分区,并将节点作为一组键值对。映射任务过程的输入,你记录相互独立的和中间结果作为键-值对。中间结果存储在本地磁盘上运行的节点映射任务。当所有的映射任务完成,减少阶段开始的中间数据具有相同关键是聚合。映射任务处理输入的相互独立的记录并产生中间结果作为键值对。中间结果存储在本地磁盘上运行的节点映射任务。当所有的映射任务完成,

12、筛检阶段开始并把具有相同关键值得中间数据聚合起来。在我们的提案中,HDFS被采用到分布式存储Lucene文件和索引文件。同时,MapReduce计算框架用于离线批处理索引构建工作。2.3 Lucene:信息检索库Lucene是一个高性能，可扩展的信息检索（IR）库，并通过Apache软件基金会授权的开源项目(Ochoa and Duval, 2008; Hatcher et al., 2004). 它被广泛应用于许多搜索应用，如NetFlix, Digg, MySpace, LinkedIn等等(Apache Lucene, 2014).Lucene的核心部件是索引和搜索。索引是负责建立索引文

13、件从最初的文件转化Lucene的文件，以方便快速上网查询。实际上，Lucene的允许应用程序在几乎所有的数据源添加搜索能力，包括远程Web服务器上的网页，存储在本地的文件系统，文本文件，MS Word文档，XML网络LES，或任何其他形式，从中我们可以提取文本文件信息。另一方面，搜索是这样一个过程，根据在索引阶段建立的索引文件，在索引文件中查找单词以找到数据源。在本文中,我们采用Lucene和Hadoop实现病历家庭诊断服务的搜索。首先,医疗记录通过标准Lucene APIs转换为多个Lucene文档。然后Lucene文档被存储为块文件在Hadoop的HDFS集群。此外,为支持快速在线医疗记录

14、搜索、MapReduce任务在每个Lucene文档创建索引时被初始化。索引阶段后,索引文件也存储在Hadoop的HDFS集群。3 云计算框架下的家庭诊断服务3.1 应用场景在本文中，我们提出了一个基于云计算的框架来实现家庭诊断服务，从历史医疗记录中提取一些诊断的帮助提供给用户。更具体来说，家庭诊断服务，根据目标用户的查询，允许基于症状的病历检索。此外，为帮助用户区分检索到的病历疾病，会进行数据分析以构建疾病症状点阵。这个疾病症状点阵在用户查询的过程中会揭示具有相同症状的疾病的关系。因此，在疾病症状点阵的帮助下，目标用户很容易排除不可能的疾病而选择感兴趣的。同时,医疗记录返回给目标用户以获得更详

15、细的参考。此外,返医疗记录返回到目标用户之前，隐私信息在医疗记录会被过滤,以避免暴露医疗记录中的敏感隐私数据。我们的家庭诊断服务旨在通过相似的历史医疗记录为用户提供自我护理服务。从大规模和不断增长的医疗记录中搜索类似病历需要按需数据存储模型和弹性可扩展性以管理高峰期进入家庭诊断服务的权限。由于云计算的显着特征，如按需存储，弹性计算能力，本文提出了基于云计算框架实施家庭诊断服务。基于云计算架构概述的讨论如下。3.2 基于云计算架构的概述为了简化讨论，我们把一些术语罗列在下面的表1中。表1 基于云计算架构的关键术语 图2 基于云计算架构的家庭诊断服务如图2所示，云计算框架由两个主要的集群组成，一个

16、线下的Hadoop集群和一个在线的分布式搜索集群，它由一组四个集群和负载平衡器组成：（1）大规模数据存储和并行索引建立采用离线的Hadoop集群。简而言之,HDFS是用于存储索引文件和大量医疗记录中转换过来的Lucene文档;而MapReduce计算模型用于平行索引构建;（2）网上分布式搜索簇设计用于处理高并发和可扩展方式的用户查询。此外，四个簇以及一个负载平衡器包括在在线分布式搜索群集。相应地，（a）一种搜索由NM个搜索节点组成的节点集群被设计出来以进行病历检索。（b）由P个数据分析节点组成的数据分析集群被设计用于数据分析以建立一个疾病症状点阵。（c）由Q个访问控制节点组成的访问控制集群被采

17、用以过滤隐私信息。（d）一个负载平衡器和一个由K个调度器所组成的调度集群被用于平衡用户查询的负载。在我们的提案中，基于云计算框架的可扩展性可以通过动态添加或删除在每个集群中的节点来获得。两个集群之间的关系的分析如下。一旦完成索引构建，一个完整的索引文件就变分成N个片，此外，第i个（1 i N）的索引片被分配给在分布式搜索群集的每一行的第i个（1 i N）的搜索节点。换句话说，存储在一排搜索节点集群中的每个节点中的索引文件组成了一个完整的索引文件。此外，在搜索节点的集群的第i个（1 i N）的列中的每个节点中包含的第i个（1 i N）的索引碎片的相同副本。3.3 离线Hadoop集群在离线存储模

18、块中，有两个任务会进行，包括文档存储和索引建立。正如2.2节中所讨论的,首先，医疗记录被翻译成几个Lucene文档。然后,我们为每个Lucene文档建立索引支持快速在线病历检索。具体地说,我们使用Hadoop集群进行Lucene文档存储、并行索引构建,以及相关索引文件存储。3.3.1 分布式数据存储模型正如初步知识那一节讨论的，医疗记录是作为XML文件存储在文件系统或是RDMBs的关系记录。图3 家庭诊断服务的文档存储模型根据Lucene的性质,所有医疗记录在索引阶段之前都应该转移到由字段值对组成的Lucene文档。对XML的医疗记录,我们解析他们以建立相应的Lucene文档。对于存储在RDB

19、Ms的医疗记录,我们使用HBase作为中间件,使在多个关系数据库中的“加入”操作更高效。特别的，把相关的医疗数据转换为存储在HBase中的数据之后，我们可以应用“加入”和“删除”操作把结构化的医疗记录转换为Lucene文档。所有的Lucene文档被存储在Hadoop集群的HDFS中，如图3所示。图4 MapReduce框架下构建索引文件的流程图3.3.2 离线索引构建为了实现快速在线用户查询处理，索引文件建立时与每个Lucene文档相关联。我们采用MapReduce计算框架进行批量索引构建。图4描述了MapReduce框架来构建索引文件的流程图。首先,每个文档块被分为若干个分区,映射节点为给定

20、文档分区建立索引。根据分布式搜索集群中搜索节点的列的数量(i.e., N),每个映射节点会将索引文件分为N个部分。一旦完成映射工作，在每个映射节点上的N个碎片会重组到reduce节点，并完成合并操作。在完成合并操作后，可以获得索引文件的N个碎片，它们存储在HDFS中，如图3所示。另外，为了能够进行在线医疗数据检索，索引文件的N个碎片被分布到分布式搜索集群的搜索节点中。而且，我们建立了三种类型的索引文件来进行在线医疗数据检索，包括反向检索，概要检索和细节检索。这里，我们还是用2.1节的例子来解释每个索引文件的内容。反向索引文件。反向索引文件记录症状集和相应的医疗记录ID之间的映射关系。如图1所示

21、,症状的描述是一个字符串,由特定的分离器分离出来。在基于症状的医学检索中，这种朴实的方法是为了使每个查询中的症状集合与索引文件中的每个症状集相匹配。然而，大规模的字符串匹配在实际应用中并不是容易实现的。与（Li et al. 2010）相似，布隆过滤器的签名(Bloom,1970)和布隆过滤器索引结构被用来加快基于症状的医疗记录查询。算法1 BF签名计算算法算法1描述了如何为一组症状在医疗记录中构建一个布隆过滤器签名(BF签名)。对于图1中所示的医疗记录示例，假设m的值设置为10，并且分别有两个离散函数h1和h2。则布隆过滤器签名计算如下: (1)症状组中的症状= 发热、咳嗽、呼吸困难,其散列

22、值被计算出来。h1(热)= 5,h1(咳嗽)= 6,h1(呼吸困难)= 7。此外,h2(热)= 6,h2(咳嗽)= 2,h2(呼吸困难)= 9。(2)因此,对于h1,第一个10位向量的值是,5日,6日和7日根据散列值设置为1。类似的,第二个10位向量的值等于。（3）由于=，在医疗记录中这个症状集设置的布隆滤波器签名是。当一个用户输入一组症状，它的签名首先会由算法1生成，并且与每个医疗记录的BF签名相比较，如果=，那么可能满足用户的需求。否则将被安全的删除。受益于位操作，所有的在关于签名的计算都是非常有效的。BF索引文件是由键值对组成的，并以序列文件存储于HDFS中。每个值都包括一组CR ids

23、（临床数据的cIDs ）和将被检索的原始的症状集合的ID；然而关键是这些原始症状集合的BF签名。通过BF签名查询测试签名，大量不合格的数据将被删除。然而，在布隆过滤中被保留下来的CR id仍然不是准确的。因此我们也会存储原始的症状集以确保匹配。概要检索文件。概要文件检索记录了医疗记录的一些关键部分，用于过滤掉不相关的医疗记录。在我们的例子中，病人的性别、年龄将被记录以过滤一些记录。这些记录中患者的性别和年龄是与目标用户的查询条件所不符的。细节检索文件。细节检索文件是由每个Lucene文档中的字段值对所组成的，用于数据分析并返还给目标用户。在我们的设计中,在Lucene文档中的所有字段将被添加到

24、细节索引文件。为了进行数据分析过程，诊断结果和疾病症状字段被用于建立疾病症状点阵，以显示具有相同症状的疾病之间的关系。同时，为帮助目标用户做出更准确的判断,Lucene文档中的字段,如患者的年龄和性别,症状,诊断结果,以及所提供的治疗医师应该返回供用户参考使用。图5中罗列了Lucene文档的一些字段，它是从图1的医疗记录转换过来的。由于空间限制，我们不详细列出所有字段索引。请注意,根据Lucene索引构建的可配置特性，所有字段在Lucene可以很容易地从细节索引文件中添加或删除。图5 三种索引文件的数据结构3.4 在线分布式搜索集群3.4.1 分布式搜索集群的关键组件如图2所示，基于Lucen

25、e的在线分布式搜索集群由五个主要组件组成，分布式搜索集群= 负载平衡器,调度集群，搜索节点集群,集群数据分析,访问控制集群。在下面的讨论中,每个基本组件的责任将被展示。（1）负载平衡器负载均衡器是家庭诊断服务的一种硬件接口。在接受用户查询时,负载平衡器根据其选择规则将查询转发到一个调度程序。选择规则通常是依赖于硬件,这里不做讨论。（2）分配调度集群为了支持高并发的用户查询，一个分配调度集群是由K个调度程序组成的。每个调度程序负责搜索节点集群、数据分析集群和访问控制集群之间的协调。具体地说，从负载平衡器收到用户查询之后，一个调度程序会从搜索节点集群的每一列选择一个搜索节点执行实时的医疗记录检索。

26、当医疗记录被返回，它会合并检索结果并把合并的结果转发给数据分析集群的数据分析节点以建立疾病症状点阵。在把疾病症状点阵和医疗记录返回给目标用户之前，它会授权访问控制集群过滤检索到的医疗记录中的隐私敏感信息以保护患者的隐私。从图2中我们可以看到,每个集群包含多个节点。因此,对于每一个用户查询,节点选择算法会进行以选择合格的节点进行用户查询。节点选择算法将在3.4.2节中讨论。（3）搜索节点集群搜索节点集群是一个弹性和可扩展的搜索矩阵,由NM搜索节点组成(每个搜索节点包含索引碎片,并通过采用Lucene搜索库功能开展实时医疗记录检索)。每一行的第i个(1 i N)搜索节点包含完整的索引文件的第i个碎

27、片,如3.2节中讨论。为了实现高并发的实时医疗记录检索，M-1个搜索节点被复制到每排的每个节点。对于每次用户查询，一个搜索节点会被调度程序从每一列中选取以进行医疗记录检索。通常,N的值是由索引文件的大小和每个搜索节点的内存性能决定的,而M的值是由并发用户查询的数量决定。（4）数据分析集群通常,对于一个给定的用户的查询, 由于用户对医学知识的欠缺，这种疾病症状集合可能是不完全的。因此，检索到的相关的医疗记录可能就包含多个疾病分类。与相关的医疗记录相联系，可以提取疾病分类和疾病症状。并且用户没有提供的症状可以用来区分疾病分类。在我们的提案中，数据分析集群旨在从检索到的医疗记录中计算疾病症状的点阵。

28、关于如何计算疾病点阵的细节我们将在后续的章节讨论。（5）访问控制集群正如上述节中所讨论的,类似的医疗记录返回给目标用户作为一个更详细的家庭诊断依据。然而,医疗记录是隐私敏感的。在医疗记录返回给目标用户之前,应该进行隐私保护,保证不会曝光病人的隐私信息。为了解决这一问题，我们设计了一个访问控制策略，根据用户的角色，用户会被分为不同的用户域。而且，对于每个用户域，细节检索文件的字符串会被相应地归入静态域和动态域。动态域中的信息可以通过相应域的角色获得。而静态域中的信息是不可获取的。在我们的设计中，每个访问控制集群中的节点都会通过索引文件存储用户的权限。索引文件会记录用户ID和相关的用户域之间的关系

29、。而且，我们设计了另一个索引文件来存储用户域和与其相关的细节索引文件中的动态字符串之间的映射关系。在调度程序把结果返回给负载平衡器之前，它会根据相应地用户ID授权访问控制集群过滤掉细节索引文件中的静态域。3.4.2 节点选择算法对于每次用户查询，调度程序会从搜索节点集群中选择某些节点。调度集群和数据分析集群会执行家庭诊断服务。对于节点选择，一种朴素的方法是采用循环调度算法，这样每个节点都会轮流被选中。然而,循环调度算法的可扩展性较差,因为它不考虑每个节点的不同的服务能力。在这里，我们提出了一个合理动态节点选择算法，为每次用户查询选择合适的节点。不失一般性，搜索节点集群的节点选择将被讨论以说明动

30、态节点选择算法的合理性。在搜索节点集群,集群中的每一行搜索节点构成一个完整的索引文件,每一列的搜索节点都是相同的。因此，对于每一次用户查询，每一列只有一个搜索节点被选中来进行医疗记录查询。简而言之，调度集群有一个包含N个最小堆栈的集合，而每个最小堆栈都有M个元素（如图6所示）。而且这N个最小堆栈与搜索节点集群的N列相对应，而对于每个最小堆栈，M就是每列中的搜索节点数。这里,在第i(1 i N)个最小堆栈的第j(1 j 3时,平均延迟和I/O等待倾于稳定。同样地,当N3, CPU利用率会随着n的增加显著增加，而当N 3时趋于稳定，原因分析如下。当N3,每个搜索节点的RAM(2GB)小于索引碎片的

31、大小( 2GB)。在这种情况下,CPU利用率很小,因为它会浪费时间等待大量的I / O交换操作。因此,平均延迟远远高于N 3的情况。为了解决这个问题,我们可以添加更多的搜索节点到节点搜索集群,以提高搜索性能。然而,这并不意味着搜索节点越多,搜索节点就有更好的性能。从表5中,我们可以看到当N 3,随着每行的搜索节点的增加,CPU利用率和延迟不会改变很多。原因是RAM比索引碎片大。I/ O等待时间就会变得较小,而CPU不必等待I / O操作。因此,添加更多的搜索节点将会导致资源浪费。实际上,N的值是由索引文件的大小和每个搜索节点的内存性能决定的,正如我们在3.4.1节所讨论的。对于实时应用程序,我

32、们可以根据索引文件大小和搜索节点的RAM性能来调整搜索节点的数量。（2）相对于M值的性能表6 性能关于M的测试数据在这个测试中，N为定值3。我们会进行6次试验来评估相对于不同的M值时的可扩展性。（相应地，M为1,2,3，4,5,6）同样，有50000次查询会通过在客户端初始化的6个并发进程被连续地发送到调度节点。平均延时、CPU利用率和I / O等待时间记录,如表6所示。从表6中，从表6中,我们可以发现I/O等待时间不会随着M改变。原因是索引文件的大小是固定的1.4G 2G(RAM)和CPU不必因为I / O交换操作浪费时间。与此同时,随着M的增加,平均延时以及CPU利用率也会相应减少。此外,

33、当M 4,它导致CPU资源浪费,因为相比于增加的M延迟并不会减少太多。事实上,正如3.4.1节中提到的,M的值是由并发用户查询的数量决定的。在实际应用中,我们可以根据实际并发数调整副本的数量(即M的值),来提高搜索性能。例如,在这个测试用例中,M = 3是最优选择。根据这两个测试用例,它表明我们设计的搜索节点集群对应于不同的M和N值可以实现最优性能。此外,由于框架的可扩展性,我们可以简单地改变索引文件的大小的或改变搜索节点的RAM容量来调整搜索节点的列的数量(即N值)。同样,当并发用户查询数量改变时,我们可以调整行数(即M值)。总之,通过搜索节点集群的可扩展性,我们的云计算框架可以实际应用中达

34、到最优的性能。5.3 家庭诊断服务的一个运行示例为了更好地描述家庭诊断服务为用户提供的自我护理服务，我们在本节中会讨论一个运行示例。图10 家庭诊断服务原型系统的用户界面这里，我们继续用一个生动的例子来描述家庭诊断服务的实现。某天，李觉得自己生病了，基本症状是“呼吸困难”和“咳嗽”。他想获得一些关于他的疾病的预备知识，这样他就可以知道他应该在医院的哪一部门提前预约。具体来讲，家庭诊断服务会进行以下4个步骤：步骤1 查询提交首先,李访问家庭诊断主页(见图10),提交他的疾病信息。在这里,根据我们的医生列出的53个在日常诊断常规的疾病症状,为用户调用家庭诊断服务提供指导。关于基本信息,李选择“男性

35、”,“成年人”。对于疾病症状,选择“呼吸困难”和“咳嗽”。因此,李的查询可以这样表达，查询=(男,成人,呼吸困难、咳嗽)。步骤2 医疗记录检索提交查询以后，被调度节点选中的搜索节点将在反向索引文件和概要索引文件中进行匹配查询,以获取医疗记录的症状描述中与李的疾病症状相符的。特别的,发生在女性患者、儿童以及老年人的身上的疾病会被过滤。根据我们的检索结果,有49个医疗记录与李的查询相匹配。步骤3 数据分析通过步骤2检索到49个医疗记录之后，数据分析节点会进行数据分析来计算疾病症状点阵，这会揭示具有“呼吸困难”和“咳嗽”这两个症状的疾病之间的潜在关系。步骤4 返回结果中隐私信息的过滤此外，在每个疾病

36、分类下都有一个超链接前往相关的医疗记录。为了保护用户的隐私，根据李的访问权限，如姓名、地址这样的隐私信息会被过滤。由于本文篇幅的限制,这里我们重点讨论数据分析步骤如何建立症状点阵以及李如何使用疾病症状点阵来判断他感染了哪种疾病。5.3.1 形式内容构建表7 形式内容的运行示例首先,疾病类别和相关疾病症状从检索到的医疗记录中提取。在我们的示例中,有49个医疗记录匹配用户查询,相应地检索到7种疾病以及14种症状。交叉表是用来描述形式内容,如表7中所示。对于这7种疾病,都包含“呼吸困难”和“咳嗽”症状。在表7中,一行意味着一种疾病,一列表示一种症状。“”表示这种疾病会发生这种症状。5.3.2 形式概

37、念计算根据定义7和算法4，在我们的例子中有11种概念包括在形式内容中，每种概念都被一个圈所表示，如图11。图11 疾病症状点阵的运行示例5.3.3 疾病症状点阵计算对于这11个概念，疾病症状点阵会通过偏序关系来计算，如定义8中所示。而且图11展示的疾病症状点阵会被一个Hasse表所替代。在我们的示例中,通过疾病症状点阵,李能搞清楚检索到的医疗记录中的疾病的关系。此外,它证明了李需要其他症状来判断他可能感染的疾病。为了判断他可能感染了哪种疾病, ,李可以查看与一组症状和疾病结果相关的每个诊断路径。根据每个症状诊断路径,李很容易排除不可能的疾病。诊断路径例子在图11用红色突出显示。如果李也有胸部疼

38、痛、高烧的症状,李可能是感染了急性脓胸。此外,在我们的设计中,在疾病症状点阵中对于每个疾病,有超链接可以到相应的医疗记录。与急性脓胸相关的医疗记录为李做出正确的诊断提供一个更详细的参考。6 相关工作与比较分析随着信息技术的广泛采用,大数据在多个领域被生成,包括航空、医疗领域、和生物学等等。从大数据中挖掘有用的知识已经在学术界和工业界引起了极大关注。处理大数据的挑战主要体现于大规模数据存储和高效知识挖掘技术。由于云计算的显著特性,如弹性存储和计算能力,和无处不在的面向服务的性质,云计算技术已经被应用于大数据。例如，Xu et al. (2012)中讨论了CloudVista原型系统，来形成整个大

39、数据可视化的方法，它保留了集群结构的细节。同样，在Cheng et al. (2012)中，一组基于云架构的硬件、软件和设计模式被采用以实现低成本进行快速、大规模的数据挖掘。此外，作者在(Chandramouli et al., 2013)中提出了一个基于云架构的过程模型称为Prism来帮助数据科学家从大的探索性数据中执行渐进采样。棱镜模型可以为数据科学家提供可重复的语义和源数据。在医学领域，在日常的临床活动中会产生大量的医疗数据，这也被称为“大医疗数据”问题（Cook et al. 2003）。大医疗数据的应用也被很多工业界人士和研究人员所关注。比如健康库(HealthVault, 2014

40、; Microsoft HealthVault, 2014)从网上便利的为用户创建、管理和控制他们的个人健康数据，这使得医疗信息的存储、检索和共享更加高效。同时，在(Wang et al., 2013)中，讨论了一个面向公众的医疗信息服务平台称为PHISP。作者提到，大量的医疗保健任务可以由PHISP平台来支持，提供很多智能的个性化的服务。在(Hsu et al., 2013)中，讨论了一种老年人护理指导关于如何通过老年人学和老年医疗体系整合不同的领域与合作。而且在系统中提到了一种医疗问卷平台来帮助老年人通过问卷形式运行自我诊断。不同于这些应用，本文中我们提出了一种基于云的架构来实现家庭诊断服

41、务。通过家庭诊断服务，用户在家就可以获得便捷的诊断帮助以判断他们感染了哪一种疾病。尽管解决的问题千差万别，但是提供一种普遍的医疗服务，改善医疗服务使我们的共同目标。此外，医疗应用也在专家系统领域被广泛研究。专家系统设计是通过知识推理，主要是通过IF-THEN规则来解决复杂问题的。(Expert system, 2014) ES背后的基本理念是把完成特定任务的知识从一个人转移到一台电脑。这些知识会被存储在计算机中，当需要的时候，用户可以访问计算机来获得具体的建议。(Jackson, 1998; Shu-Hsien Liao, 2005)。在(Lee and Wang, 2011)中，一个模糊专家

42、系统被开发用于糖尿病诊断，一个5层的模糊实体和模糊推理规则被构建以对关于个人感染糖尿病的可能性作出判断。同时，这个结果被存储在糖尿病决策知识库以作为未来诊断的依据。在(Gholami et al., 2012)中，作者通过利用熟练的临床医生的知识和经验扩展了确定性的基于规则的专家系统。以处理心肺管理和ICU镇静框架。类似于在专家系统的这些工作，我们从大数据集中提取知识以帮助用户做出正确的判断。然而，我们并不是把知识作为专家经验存储在计算机系统中以备未来使用。我们的设计中所获得的知识（即疾病症状点阵）是在线和动态计算的，它提供了实时的、更客观的诊断帮助。此外，我们的疾病症状点阵并不是提供推理知识作为主要的IF-ELSE规则，而是作为一个图形化的点阵。图形化的点阵对于用户而言可以更直观的判断他们可能患有哪一种疾病。而且，隐私问题是医疗数据应用的前提，这引起了许多研究人员的注意。比如，在Li et al. (2013)中，作者提出了一个关于个人医疗数据在云计算中共享安全的新颖的框架。并且ABE计划和一个增强的MA-ABE计划被用于加密PHR数据，以确保多个