在病疫学中一种为了模式发现在的图理论方法。

图理论方法在疫学的模式发现中的应用。

主要内容：

1.构造二部图，表示风险因素和个体之间的联系。

2.找出二部图的模式，反应具有相同风险因素的一群体，并为每个模式量化其风险和

意义

3.把在第二步中找出的模式，按照偏序关系构成格。

4.进行分析。

1.构造二部图，表示风险因素和个体之间的联系。

　　　个体对应着其相应的特征，把个体作为一个结点集(叫terminal nodes:t-node)，把这些个体对应的特征作为一个结点集(叫sources nodes:s-node)。如果s-node是t-node的一个特征，我们用一条边连接起，结果就成一个二部图。在这个图中，只有两类结点：t-node 和s-node；

并且同类型的结点之间是没有边相连接的。

　　　几个相关的概念：

　　　Clique：完全图(略)

      Biclique：完全二部图　：在第一结点集中的任一结点都与第二个结点集合的所有结点存在一条边连接。

　　　最大完全二部图：在一个二部图中，如果没有一个比这更大的完全二部子图，那么这个完全二部子图即是最大完全二部子图。

　　　在该文章中，找出所有的最大完全二部图是最感兴趣的。这是因为最大完全二部图表示存在一群个体共享相同的特征。同时，当特征的结点数增多时，共享相同特征的个体就会减少。由每一个特征集都能生成一个最大完全二部图。所有的特征集生成的最大完全二部图之间满足偏序关系，因此，由这些集合和它们之间的关系可以构成格。

几个因素：

为了量化模式的相关的自变量，文章给出了２×２的表如图所示：

A,b,c,d这四种变量代表的个体数，a,c是已经表现出了模式，而b,d只是有这个趋向。

Odds ratio：OR = (a.d)/(b.c)；当OR>1时，模式是一种病例模式；当OR<时模式有利保护。当OR=1时，模式和因变量没有联系。

阳性似然比：

注意到这个表中，当行和列固定后，唯一的自由度就是内部变量a.

当a=a0，且OR(a0)>1时，得到满足OR>=OR(a0)的表的概率是P-value；

2.找出模式。求最大完全二部图

构造一个二部图：Ｇ＝｛Ｓ，Ｔ，Ｅ｝，而现在的目标是找出最大完全二部图书

Ｂ＝｛Sb,Tb,Eb｝且Sb≤S；Tb≤T；Eb≤E。

文章里面给出了两类集合操作：C(s)={{s},T(s)} 其中s是s-二部图中的结点，T(s)是对应的t结点。现在有C(s1)={{s1},T(s1)}；C(s２)={{s２},T(s２)}，那么

Ｃ(S1US2)=[(S1US2),T(S1)∩T(S2)]

对于C(T)={S(T),T}相例似也有：C(T1UT2)=[S(T1)∩S(T2),(T1UT2)];

扩展集：X(S)={s|T(S)＜T(X(S))}；即：T(S)∩T(X(S))=T(S)。

通过扩展集找出最大二部子图。其流程图如下：

程序首先从构建二部图开始，另外建一张表映射表把原始的数据值转换为作为s-node的离散的，绝对的特征值t-node从原始记录标示中得到。

然后程序开始在case 图中搜索最大完全二部图。并得到相关的2×2表中变量的值。

每个找到的二部图都赋给相对应的品质因数，并检查用户定义的约束条件。品质因数包括p-value,OR，也可从2×2表中得到相关的约束条件。根据约束条件，输出或是进入扩展队列以循环扩充。在循环队列中，由品质因数确定候选二部图的优先级，品质因数好的被优先出队列进行扩展。

这个循环一直重复，直到候选队列为空为止，这是输出文件中包含了最大完全二部图的s-集合，t-集合，2×2表及相关的统计信息。

程序在搜索新的可接受的候选二部图时，候选队列顶部的候选二部图出列进行集合扩充。选中的二部图与其对应的邻接集进行集合操作产生新的集合，如果新二部图遇到约束条件时且在已经存在的二部图集中没有副本，则输出该二部图及相关信息，也添加到优先候选队列中参与循环。

3.构造格。　　

当前面的程序终止后，在输出文件中包含了所有的最大完全二部图以及相对应的信息。包括2×2表信息。把每个最大完全二部图做为一个用户个体，由这些个体之间和它们之间的偏序关系构建成一个格。

给两个最大完全二部图C1(S1,T1)和C2(S2,T2)，S1<S2当且仅当T1>T2,如果S1>S2当且仅当T1<T2，这种关系我们就可以构造一个模式格。这些最大完全二部图在模式格中就成了一个结点。模式格的图示如下：

4.进行结果分析（略）。

临床基因信息学应用层的基础结构。

主要内容：

1介绍HL7**CG标准.通过这个标准能够把病人的临床信息，结合当前的科学知识和特殊病人的基因数联系起来。核心是“encapsulate and bubble-up”工作流。

２.介绍CGL7，描述CGL7在几个原始用例中的实现。

主要创新点：

构建了一个从隐性到显性的关系层，也就是将人的基因数据和临床诊断数据联系起来。“encapsulate and bubble-up”工作流在CGL7中的应用是亮点。

1.HL7**CG标准

1.1HL7(略)

1.2 The HL7 CG 标准

1.3 The “encapsulate and bubble-up” workflow

    Encapsulate阶段 把原始数据按照一定的格式用生物信息标记语言(BSML)进行封装成HL7 CG消息，这里的格式是已经提前预定义好的。

。 bubble-up阶段：在这个阶段是一个不断的重复的过程：在各种面向染色体组的决策支持应用程序中解析被封装的原始基因数据，并标记出对临床诊断，病人治序，医学研究有意义的部分。

Bubble-up 与总结或评注的区别：临床染色体组数据是很难总结的，这是因为：在这个领域的很多的知识还是未知的，bubble-up是一个不断的挖掘新信息的过程，直到找到临床诊断和基因之间的孙系。注释和评论是bubble-up过程的结果。

Encapsulate and bubble-up workflow在特定的时期对特定的病人的原始的诊断和治序数据能不断的筛选，尽可能的找出有效数据，以便以后能够再次解析。

1.4CGL7中使用模式

HL7 Clinical genomics specifications中的核心模式是：GeneticLocus模式（基因位模式）。包括序列，表式和蛋白质数据。在基因模式中，用分析复杂生物信息学的标记语言描述（满足HL7设计规则的）相关信息，为Encapsulate and bubble-up workflow提供数据信息。GeneticLoci是基因位的集合（GeneticLocus）。GeneticLocus和GeneticLoci是HL7 Clinical genomics中的组织类型用例演绎过来的。GeneticLoci模式用于描述单模标本，GeneticLocus模式适合于描述等位基因。

2. 介绍CGL7，描述CGL7在几个原始用例中的实现。

CGL7是用用Web服务技术标准实现的，允许CGL7快速集成各种不同的客户应用程序。由于，HL7 Clinical genomics数据量非常大，尤其是encapsulated的数据，所在为了避免数据的来回传输，许多CGL7的用例中采用了多步处理过程，如Encapsulation和两种不同的Bubble-up策略在ＣＧＬ７中的应用（见文章图４）。

文章描述的CGL７API用法结构图见文章图6。　

这个图的流程：把XML实例导入到解析器，解析器结合消息说明（在HL7消息交换格式中）解析导入进来的消息，把解析出的有效的内容送入内存中，进行相关处理，同样串化器也结合消息说明正确的串行内存中的对象到XML中。

ＨL7 API还为保存HL7 XML 实例到关系数据库中提供了支持。

主要内容：

1.简要介绍HL7

2.介绍两种主要的数据模型ER和EAV

3.结合ER和EAV的混合模型：ER-and-EAV.

4.新模型在CG系统中的应用。
 

1.简要介绍HL7（略）

2.两种数据模型ER和EAV。

 ER模型就是我们所熟悉的关系模型不做介绍。

 EAV模型是一个三元组模型：实体，属性，属性值。如：病人，街道地址，123Chestuat Street,。在每个EAV模型表中，每一行存储一个三元组。

 ER和EAV模型的比较：

(1)EAV设计和管理方便容易，ER设计比较的复杂且开销也较高。

(2)在ER中查询比在EAV中简单。

(3)在EAV中增加实体的新属性时，不需改变数据库的设计，而ER做不到。

用EAV模型存储医学临床数据是很有吸引力的，因为每增加一个数据不需要更改数据库的设计。

3.混合模型ER-and-EAV实现HL7 RIM的数据模型。

3.1HL7 RIM模型：HL7 信息参考模型。

   HL7 RIM 实际上是一个ER模型，专门针对临床医学相关数据的特点而提出来的。HL7 RIM有6个基类：Act，Entity，Role，RoleLink，Participation，ActRelationship，所有的RIM类是用ER方法建模得到的。每个RIM类可被看作一个ER实体。为了维持RIM中类之间的关系，很自然的在表中引用了外键。

3.2建模HL7 RIM的遗传性。

Single table per class hierarchy:父类和子尖的对象存储同一表内，表中包含了所有的尽可能遗传属性。方法简单，但效率不高。

Tables that do not contain inherited attributes:一类一表且不包括继承的属性。方法比较复杂，效率高，不过添加，更新和查询也很复杂。

Tables that contain inherited attributes:一类一表，且包括继承属性，这是在HL7 RIM模型中用到的最多的方法。

3.3 Hybrid（ER-and-EAV）方法建模观察类

   结合ER和EAV各自的优势来建模观察类。在这个方法中，一张表只存储具有相同数据类型的属性值；同时引用外键指向其父类。也就是不同类型的属性值用不同的表存放。

3.4HL7 RIM数据类型建模

   Multiple columns in the class table：由多个部分组成的数据类型，每一部分作为单独的列项。

   A separate table for the data type and a foreign key in the class table:把所有的数据类型放在一张表中，同时引入外键指向存放有对应的数据表。

   A separate table that includes a foreign key in the data type table: 把所有的数据类型放在一张表中，同时外键指向拥有者数据表。

3.5 要考虑到的Health-care相关数据。

稀疏数据，大量的说明性数据，非可加变量，属性集的快速膨胀，非标示数据，源数据与派生数据的区分，实时数据等等。根据这些数据的特点设计出基于RIM的物理数据模型并讨论了在存储临床医学数据时的优势。

4.CG产品介绍

   CG构架见文章Figure 3.CG面向消息的构架，支持几种消自己标准。

HCN ：Heath-care collaborative NetWork。主要收集Heath-care 信息（标准的信息格式）。主要特点能集成HL7 2.x的信息，作为一条基于RIM CDA（Clinical Doccument Architecture）信息。

HL7 CDA Builder:建立CDA和其它标准的HL7信息并使格式保持一致。

UDIP:是一个扩展平台，应用于非标示病人信息。

DPE：发送适当的数据到解析器，以便将解析器的信息地导入到相关的数据库。

CGAM：存储当前的Health-care信息，便于用来分析和报告。

　　Web服务堆栈

　　使用HTTP通信协议，我们可以从因特网上的一个地方向另一个地方发送消息。通过网络发送的消息可以使用XML结构化，XML协议定义这条消息的格式和语义。SOAP（简单对象访问协议）是定义如何从不同环境中的对象调用函数。使用SOAP，就能够整合不同的操作系统、对象模型和编程语言，使简化整合不同种类的业务处理过程成为可能。

　　HTTP、XML和SOAP可以看做是Web服务的核心层。这些层定义了Web服务之间交互的方法和途径。这三个协议已经被W3C（World Wide Web联盟）接受做为标准。

　　WSDL协议（Web服务描述语言）描述如何与一个Web服务通讯。在WSDL定义中，允许不同类型的通讯（绑定）。它可以用来开发Web服务，同时也可以用来赚钱。为了实现这个目的，我们需要一个Web服务门户，我们可以在那里发布我们的Web服务，其他的人也能在那里找到它并使用它。这就需要使用UDDI（Universal Description, Discovery and Integration，统一描述、发现和整合规范）。


（图1、Web 服务体系结构堆栈）

　　Web服务技术通常可以分为三个关键组成部分：描述堆栈(Description Stack)、发现堆栈（Discovery Stack）和线堆栈(Wire Stack)。描述堆栈处理描述Web服务的各种技术，以便促进B2B关系中的业务处理模型和工作流程结构的通用性。发现堆栈处理那些供目录、发现和审查服务使用的技术。线堆栈由为Web服务运行期引擎提供信息流的技术组成。

　　Web服务的结构单元

　　Web服务基于开放的因特网标准，它的结构单元是SOAP、WSDL和UDDI。

　　SOAP

　　SOAP是序列化调用位于远程系统上的服务所需信息的标准方法，这些信息可以使用一种远程系统能够读懂的格式通过网络发送到远程系统，而不必关心远程系统运行于何种平台或者使用何种语言编写。SOAP以XML格式提供了一个简单、轻量的用于在分散或分布环境中交换结构化和类型信息的机制。SOAP本身并没有定义任何应用程序语义，如编程模型或特定语义的实现；实际上它通过提供一个有标准组件的包模型和在模块中编码数据的机制，定义了一个简单的表示应用程序语义的机制。这使SOAP可用于联合各种现有的网络协议和格式，包括HTTP、SMTP和MIME，并可被用于消息传递到RPC的各种系统。

　　SOAP解决了通过防火墙传送往返于远程应用程序的消息的问题。除了通过某些预先设定的作为特定用途的端口，防火墙通常禁止通过其它端口进行远程通讯。这就出现了一个问题，大部分分布式协议不使用分配的端口，而是动态地选择端口。微软SOAP技术实现的解决方案是通过HTTP的80端口传送对远程进程的调用。这个远程调用使用XML定义消息请求或响应的格式，把调用附加到HTTP协议的顶部。这个技术的优点之一就是降低通过防火墙传送消息的复杂性。但是80端口通常还用来作为Web通信之用，所以可能会降低其效率。
SOAP可以用来解决因特网应用程序的交互性问题。你可以使用一种平台无关性方式在远程（或本地）服务器上访问对象和服务。现在的互联网世界由不同的操作系统、不同的防火墙、不同的产生远程过程调用的方法和平台组成。为了跨因特网交互，客户机和服务器都需要了解彼此的安全类型和信任、服务部署模式和实现细节以及平台语言。使用SOAP，这种平台特定性的混乱局面就会结束。基于已被业界广泛接受的HTTP标准和XML标准，SOAP也可与其竞争对象RPC技术连通，并提供用于任何操作系统、程序语言和平台的轻量级消息格式。

　　在SOAP体系结构有四个主要的部分：

　　　SOAP信封（envelope），用于描述消息内容和处理方法。
　
　　　SOAP编码规则：定义了一个编码机制用于交换应用程序定义的数据类型的实例。

　　　SOAP RPC表示，定义了一个用于表示远程过程调用和响应的约定。

　　　SOAP绑定，定义了一个使用底层传输协议来完成在结点间交换SOAP信封的约定。

　　简单的说，SOAP提供了使用完全独立于平台的访问服务、对象和服务器的技术。通过SOAP，你将能够查询服务、调用服务、与服务通讯并处理服务，而不用去关心远程系统的位置、所在的操作系统或平台到底是什么样的。

　　SOAP本身提供了与Web服务交换信息的方法，但是它没有提供查找Web服务消息的方法。而且它还不提供查找Web服务或与之交涉的方法。

　　WSDL

　　Web服务描述语言（WSDL）和SOAP一起构成了Web服务的核心结构单元。WSDL基于XML格式，用来描述Web服务。它描述了Web服务可以执行的操作以及Web服务可以发送或接收的消息格式。WSDL文档可以看成是客户端和服务器之间的一个协约。使用WSDL工具，你可以自动处理这个过程，几乎不用手工编写代码就能够让应用程序整合新的服务。因此WSDL是Web服务体系结构的基础，因为它提供了一个通用语言，用来描述服务和整合这些服务的平台。

　　虽然大部分WSDL文档使用RPC风格的要求/应答语句对，但是WSDL也支持单向的消息。WSDL支持四种SOAP消息操作：

　　　单向 (One-way)：端点接收消息。

　　　请求响应 (Request-response)：端点接收消息，然后发送相关消息。

　　　要求响应 (Solicit-response)：端点发送消息，然后接收相关消息。

　　　通知 (Notification)：端点发送消息。

　　UDDI

　　UDDI（统一描述、发现和整合）建了一个平台独立、开放的框架，通过因特网来描述服务，发现业务，并且整合业务服务。它是一套基于Web的、分布式的、为Web服务提供的信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的Web服务注册以使得别的企业能够发现的访问协议的实现标准。

　　通过使用UDDI的发现服务，企业可以单独注册那些希望被别的企业发现的自身提供的Web服务。企业可以通过UDDI商业注册中心的Web界面，或是使用实现了"UDDI Programmer's API标准"所描述的编程接口的工具，来将信息加入到UDDI的商业注册中心。UDDI商业注册中心在逻辑上是集中的，在物理上是分布式的，由多个根节点组成，相互之间按一定规则进行数据同步。当一个企业在UDDI商业注册中心的一个实例中实施注册后，其注册信息会被自动复制到其它UDDI根节点，于是就能被任何希望发现这些Web服务的人所发现。
      
           (原地址)