【《基于云医疗的联合手术室调度系统模型构建分析》4000字】

基于云医疗的联合手术室调度系统模型构建分析目录TOC\o"1-3"\h\u21971基于云医疗的联合手术室调度系统模型构建分析 180531.1系统总体流程 114601.2Petri网相关预备知识 352361.1.1Petri网基本概念 3171301.1.2Petri网的数学定义 425201.1.3Petri网的性质 4222271.3联合手术室资源调度问题的Petri网模型构建 51311.3.1不考虑转诊的Petri网模型构建 5122211.3.2考虑转诊的Petri网模型构建 71.1系统总体流程本章节对云医疗背景下的联合手术室调度系统的整体运作流程进行了整体的概述，如图1.1所示。现结合实际的云医疗系统特点对本文研究的远程手术流程进行详细的描述。图1.1云医疗手术室联合调度系统工作流程（1）准备阶段首先，患者需要在云医疗平台进行预约挂号，并填写有关个人信息以及有关病情的问诊问题，系统根据患者的问诊记录对患者的病情进行分析，病情严重的患者由系统分配到综合医院进行就诊，病情较轻或中等程度的患者将被分配到普通医院接受相关的医疗服务，这一操作流程充分实现了患者的分流，有效的缓解了大医院的就诊压力等问题。（2）诊断环节在诊断环节，被分到核心医院的患者直接由核心医院的专家进行线下的诊治，根据患者的病情，以及手术室的占用情况决策该患者的手术方案以及手术时间等安排。若患者被分到普通医院，该患者需要在普通医院完成术前检查，并由普通医院的医生对其结果进行分析，若该患者需要手术，则由普通医院的医生申请远程会诊，若核心医院的医生有可用的远程问诊时间，则安排空闲的专家医生与普通医院的医生进行匹配，之后普通医院的医生将患者的检查结果传送给专家医生，专家医生对检查结果进行分析并与普通医院的医生一起确定患者是否需要转诊，若不需要转诊，则拟定手术方案和手术的实施时间。（3）转诊阶段普通医院的患者可以根据专家医生的诊断结果以及转诊意见，决定自己是否选择转诊。由于核心医院高昂的医疗费用，被分配到核心医院的患者也可以选择转诊到普通医院，由核心医院的医生到普通医院为其进行手术。另外，针对普通医院病情严重或者恶化的患者，普通医院没有能够提供手术的相关设备和医疗环境，则需将患者立即转诊到核心医院。这一环节充分考虑了患者的个人意愿以及病情程度。（4）手术环节对于核心医院的患者，核心医院的医生根据患者的病情以及手术室的排程和医生的时间安排来决定患者的手术时间。如果患者在普通医院等待手术，则需要安排给病人进行远程会诊的核心医生为其进行手术。对于转诊的患者，医生根据患者的先后顺序以及病情轻重等情况，为其安排手术。综上，从整个系统工作流程来看，在云医疗系统中，制约手术安排的关键问题之一是手术室的数量。核心医院的手术室数量不足以满足患者和医生的需求，导致专家医生在一周内有可能只被安排两台手术，由于手术室资源紧缺引起了医生的被迫空闲，这是一种对资源的变相浪费。云医疗系统实现了将普通医院的手术室资源与专家医生资源进行了整合，从根本上，有效的缓解了核心医院的手术问题，并使患者的手术等待时间和手术成本得到了显著的改善。由此，大医院也得到“减负”，小医院的医疗资源也得到了充分的利用。1.2Petri网相关预备知识1.1.1Petri网基本概念=1\*GB2⑴Petri网简介及功能Petri网是一种系统建模与分析工具，具有充分的模拟能力和丰富的分析方法。Petri网既有直观的图形表示，又可以引入许多数学方法对其性质进行分析[27]。一方面，作为一种图形工具，Petri网不仅可以利用自己强大的图形体系完成对系统结构的刻画，而且可以利用托肯的属性来描述系统的动态行为（如系统的状态变化等）；另一方面，作为一种数学工具，Petri网可以建立关联矩阵、状态方程等数学方式来描述系统的结构特征。对于一个系统来说，如果构建系统的Petri网模型，然后对这个Petri网模型进行分析，就可以揭示出被描述系统在结构和动态行为方面的许多重要信息[28-30]。=2\*GB2⑵Petri网组成元素：=1\*GB3①库所（place）：圆形节点

=2\*GB3②变迁（transition0）：方形节点（也有可能是粗实线）

=3\*GB3③有向弧（connection）：库所与变迁之间的有向弧线

=4\*GB3④托肯（token）：又称令牌，是库所中的动态对象，可以从一个库所移动到另一个库所，表示库中所拥有的资源数量。=3\*GB2⑶Petri网规则Petri网用于描述和分析系统中的控制流和信息流，尤其是有异步和并发活动的系统。如果某一个变迁的所有前驱库所都有托肯，则这个变迁满足发射条件；变迁发射时，从它所有的前驱库所里分别取出1个托肯，同时往它所有的后继库所里面分别放置1个托肯，以此类推。如果有两个或多个变迁都被允许的可能，但是一次只能发生一个变迁，由随机数确定发生的变迁。如果出现一个变迁，其输入库所的个数与输出库所的个数不相等，令牌的个数将发生变化，即就是，消耗托肯数目=前驱库所数目-后继库所数目。两个变迁争夺一个托肯的情形被称之为冲突。当发生冲突的时候，由于Petri网的时序是不确定的，因此具体哪个变迁得以发生也是不确定的。用于描述现象的Petri网也可能自然出现冲突，这表明我们对于变迁发生的条件没有完全了解。Petri是静态的，也就是说，不存在发生了一个变迁之后忽然冒出另一个变迁或者库所，从而改变Petri网结构的可能。Petri网的状态由托肯在库所的分布决定。也就是说，变迁发生完毕、下一个变迁等待发生的时候才有确定的状态，正在发生变迁的时候是没有一个确定的状态的。1.1.2Petri网的数学定义一个简单的三元组可用来表示一个Petri网N=P是库所的集合；T是变迁的集合；F=P×T三元组P,T;F被称作是一个有向网，当且仅当满足如下条件：P∪T≠∅,P∩T=∅···················································F⊆P×TdomF其中，domFcodF其中，定义(2-1)说明了变迁与库所之间不存在公共元素，但是二者也均不为空集，即这个有向网不是空白的。定义(2-2)则表达了F描述网之间关系，是一个P元素和一个T元素组成的有序数对的集合，只存在于P与T元素之间。定义(2-3)规定了有向网中不存在孤立的点。图1.2公式(2-2)的说明图1.1.3Petri网的性质Petri网具有如下性质：=1\*GB2⑴可达性如果Petri网中某个标识M0经过不断的变迁最终变成MN，则称MN=2\*GB2⑵有界性这个反映的是Petri网中的资源有限性，即托肯的数量不是无穷大的。在分析问题的过程中常假定某一节点的容量是无穷的，但在实际系统设计中，必须使网络中每个位置在任何状态下的标志数小于位置的容量，这样才能保证数据不会溢出。=3\*GB2⑶活性对于一个变迁T，在任意标识m的作用下，若存在某一变迁序列Sr，该变迁序列的激发使得此变迁使能，则称该变迁是活的。若一个Petri网的所有变迁都是活的，则称该网是活的。=1\*GB3①死变迁：若存在m，不存在从m开始的变迁序列，该变迁序列的激发使得m使能，则称该变迁是死变迁。=2\*GB3②锁死若存在m，在此状态下，无任何变迁使能，则称该Petri网包含一个锁死。1.3联合手术室资源调度问题的Petri网模型构建1.3.1不考虑转诊的Petri网模型构建根据第一章对问题的描述，以及第二章1.1节中对联合手术室整合调度系统的工作流程的介绍，在不考虑转诊的条件下，建立了手术室资源调度问题的Petri网模型，如下图所示：图1.3不考虑诊的Petri网模型图1.3中各个库所和各个变迁的含义如表1.1所示。表1.1各个变迁和库所代表的意义或内容库所和变迁意义或内容p完成云医疗病历填报申请住院的手术患者p分别表示1个核心医院和2个普通医院p表示1个核心医院和2个普通医院的诊断环节中患者位置p表示1个核心医院和2个普通医院准备实施手术的患者p表示1个核心医院和2个普通医院的手术环节中患者位置t对云平台上的患者进行分流t表示1个核心医院和2个普通医院患者诊断环节的开始t表示1个核心医院和2个普通医院患者诊断环节的结束t表示1个核心医院和2个普通医院患者手术环节的开始t表示1个核心医院和2个普通医院患者手术环节的结束r核心医院医生资源的存储位置这里，本文将分为4个模块对所构建的Petri模型进行介绍：（1）病人分配模块：病人通过云医疗平台t0（2）普通医院模块：病人进入普通医院P11（3）核心医院模块：病人进入核心医院P01（4）核心医生循环模块由于普通医院不具备能够手术的医生，因此整个系统共用核心医院的医生资源。当核心医院的病患完成术前检查后，即可由核心医生团队指派一名医生实施手术。但当普通医院有需要手术的病患后，则必须首先由团队中的某个成员完成远程会诊，之后了解病人病情及确认手术方案。当医生完成手术后都会进入待命状态，直至又有新的病人需求出现，由此便形成了一个循环。1.3.2考虑转诊的Petri网模型构建图1.4考虑转诊的Petri网模型从考虑转诊的联合手术室整合调度问题的Petri网模型可以看出，所有医院的患者在完成诊断阶段后，系统会重新分配病人，使得患者的分流工作更加合理，且综合考虑了患者的转诊意愿以及病情的严重程度。以上分别建立了不考虑转诊和考虑转诊的联合手术室整合调度问题的Petri网模型，不同于简单的线上问诊过程，云医疗联合手术室整合调度是“线上+线下”的模式，线上体现在通过远程会诊，确定手