事件驱动型急诊流程管理系统和方法与流程

本发明总体上涉及医院内的患者流程管理，更特别地，涉及一种事件驱动型急诊流程管理系统和方法，其可以有效地引导和管理急诊患者在医院内的检查流程，从而确保急诊患者能够得到及时有效的诊治。

背景技术：

当急诊患者到达医院时，必须得到及时并且有效的诊断和治疗，尤其是对于胸痛、卒中、休克、昏迷、创伤等危重急诊患者而言，需要尽快进行各项检查以确认病情并且采取相应的救治措施，否则可能会付出生命的代价。以急性卒中为例，急救期间每节约1分钟意味着3.5天的额外健康寿命。

然而，患者或家属要面临的第一个问题就是拿着一大堆单据去做各项检查，该做什么检查，在什么地方做，还剩下什么检查没有做都是头疼的问题。责任医生和护士由于要负责多个患者，一般也不可能带领患者去完成各项检查。此外，在医院内一般都有很多患者在排队等候进行检查，谁也不知道哪个患者是不是急诊，尤其是危重急诊，是不是需要被特殊对待，如等电梯、检查排队等方面就没有办法优先安排。因此，急诊患者可能会耗费过长时间来完成各项检查，造成对诊断和治疗的严重延误。中国AMI(Acute Myocardial Infarction，急性心肌梗塞)规范化救治项目结果表明，急性心肌梗塞接受溶栓的患者从进入医院大门开始到实施溶栓的平均时间为83分钟，远远超过了指南要求的30分钟；而接受急诊介入治疗的患者平均入门-球囊扩张时间为112分钟，也远远超过了指南中90分钟的基本要求。

另外，当患者在医院内各部门处进行各项检查时，责任医生和护士可能会失去与该患者的联络，不能及时掌握患者在医院内的检查动态，如哪些检查做完了，哪些还没有做，还需要多长时间完成检查，有没有超时等，从而无法掌握患者的当前状况并且在需要时及时介入，也无法根据患者的动态来分配后续的人力物力资源。还有一个问题是，医院的各种检查设备，比如十二导联心电检查仪器、CT、X光机等，可能都有自己的时间管理，多个设备的时间不能统一，事后在分析检查流程时就无法形成正确的时间轴。

不恰当的患者流向也是造成医院运行效率低下、患者候诊时间较长的原因之一。美国医院协会(American Hospital Association)指出，避免医院患者拥堵的主要措施是提升信息的交互以及加强信息的可视性。目前，患者流向管理(Patient Flow Management Solutions)这一细分领域主要有两个解决方案：实时定位系统(Real Time Locating System，RTLS)和事件驱动解决方案(Event Driven Solutions)，前者应用较广泛，而后者应用较少。实时定位系统主要是随时定位患者在医院中的位置，把患者作为医疗信息管理中的一个资源进行统一的调度和管理。这种方法可以比较好地解决医生和护士对患者动态信息的把握，但是也存在一些问题。例如，患者不同于诸如仪器设备之类的资源，尤其是急诊患者，没法提前准确预测其下一步会发生什么。此外，这些解决方案的大部分功能设置都是服务于医院管理者以及医务人员的，没有真正做到以患者为中心(patient-centric approach)的流程管理和信息采集。此外，实时定位采集的数据比较多，大部分数据并不会被医生关注，而且需要在医院内部署大量的硬件设备，实施维护成本过高。

因此，需要一种服务于患者，尤其是急诊患者的流程管理系统和方法，其能够有效提高急诊患者的诊治效率，同时易于部署，并且不需要高昂的成本。

技术实现要素：

本发明一方面提供一种事件驱动型急诊流程管理系统，其包括部署在移动终端上的客户端模块，所述移动终端可用于供患者在执行检查时携带使用。所述客户端模块包括：患者信息管理单元，用于接收患者信息，所述患者信息包括一个或多个检查事件；事件管理单元，用于基于所述一个或多个检查事件生成检查事件列表，并且管理每个检查事件的执行状态；以及时间管理单元，用于监视患者执行每项检查事件的时间，以及执行所述检查事件列表所用的总时长。

在一实施例中，所述事件管理单元还包括事件排序单元，用于基于预定标准对所述检查事件列表中的一个或多个检查事件进行排序。

在一实施例中，所述预定标准包括以下标准中的至少一种：检查地点离患者当前位置的距离；以及检查项目的当前等候人数。检查项目的当前等候人数是指具有比当前患者更高优先级的候检患者的人数，所述优先级根据患者病情的紧急程度来确定。

在一实施例中，所述事件管理单元还用于提供每项检查事件的位置信息，所述位置信息包括地址信息和地图信息中的至少一种。

在一实施例中，管理每个检查事件的执行状态包括：响应于检查医师的操作，将检查事件标记为已完成状态。

在一实施例中，所述时间管理单元还用于当患者执行所述检查事件列表所用的总时长超过规定时间时，发出提示信号。

在一实施例中，所述客户端模块还包括：定位单元，用于确定所述移动终端的当前位置；以及呼叫单元，用于向外发出呼叫或者应答从外界传入的呼叫。

在一实施例中，所述事件驱动型急诊流程管理系统还包括服务器端模块，所述服务器端模块包括：患者信息采集单元，用于采集患者信息并且将所述患者信息发送给所述客户端模块，所述患者信息包括患者要进行的一个或多个检查事件；以及移动终端管理单元，用于在患者携带所述移动终端执行各项检查时，监视和管理所述移动终端。

在一实施例中，所述移动终端管理单元包括：时间管理单元，用于监视患者携带所述移动终端执行各项检查所用的时间；事件管理单元，用于监视所述检查事件列表中的检查事件的执行进展。

在一实施例中，所述时间管理单元还用于向所述移动终端授时以使二者的时钟保持一致。

在一实施例中，所述移动终端管理单元还包括：重置单元，用于对所述移动终端执行重置操作。

在一实施例中，所述移动终端管理单元还包括：位置管理单元，用于确定所述移动终端的位置；以及呼叫单元，用于呼叫所述移动终端或者应答来自所述移动终端的呼叫。

在一实施例中，所述服务器端模块还包括：数据库单元，用于储存用于所述事件驱动型急诊流程管理系统的数据。

本发明另一方面提供一种事件驱动型急诊流程管理方法，包括：在移动终端侧接收患者信息，所述患者信息包括患者要执行的一个或多个检查事件；生成包括所述一个或多个检查事件的检查事件列表，以便于所述患者根据所述检查事件列表来执行所述一个或多个检查事件；根据所述患者对所述一个或多个检查事件的执行情况来更新所述一个或多个检查事件的执行状态；以及将所述一个或多个检查事件的执行状态发送到服务器侧以便于监视和管理所述患者的检查事件执行进展。

在一实施例中，所述方法还包括以下步骤中的一个或多个：在服务器侧和/或移动终端侧监视所述患者携带所述移动终端执行所述一个或多个检查事件所用的总时长；在移动终端侧监视患者完成每项检查事件的时间点；以及使所述移动终端的时钟与所述服务器的时钟同步。

在一实施例中，所述方法还包括：当所述总时长超过预定时间时，则发出提示信号。

在一实施例中，所述方法还包括：响应于患者对所述移动终端的操作，向所述患者提供关于检查事件的信息。关于检查事件的信息包括如下信息中的一种或多种：检查事件的地址信息；检查事件的地图信息；以及检查事件的结果信息。

在一实施例中，所述方法还包括：基于预定标准对所述检查事件列表中的一个或多个检查事件进行排序。所述预定标准包括以下标准中的至少一种：检查地点离患者当前位置的距离；以及检查项目的当前等候人数。检查项目的当前等候人数是指具有比当前患者更高优先级的候检患者的人数，所述优先级根据患者病情的紧急程度来确定。

在一实施例中，所述方法还包括：在移动终端侧发起向所述服务器侧的呼叫或者应答来自服务器侧的呼叫。

在一实施例中，所述方法还包括：在服务器侧采集所述患者信息，并且将所采集的患者信息发送到移动终端侧。

本发明另一方面提供一种移动终端装置，包括：输入单元，用于接收用户输入；显示器，用于向用户显示信息；通信单元，用于与外界进行通信；以及处理器，配置为运行存储器中的计算机程序指令以执行上述方法。

本发明另一方面提供一种计算机程序产品，包括计算机程序指令，所述计算机程序指令在由处理器运行时使所述处理器执行上述方法。

附图说明

图1是示出可实施根据本发明一实施例的事件驱动型急诊流程管理系统和方法的医院内网络系统的拓扑图。

图2是示出根据本发明一实施例的事件驱动型急诊流程管理系统的服务器端模块的功能框图。

图3是示出根据本发明一实施例的事件驱动型急诊流程管理系统的客户端模块的功能框图。

图4是示出根据本发明一实施例的在服务器侧执行的事件驱动型急诊流程管理方法的流程图。

图5是示出根据本发明一实施例的在客户端侧执行的事件驱动型急诊流程管理方法的流程图。

图6是示出根据本发明一实施例的患者信息采集界面的示意图。

图7是示出根据本发明一实施例的患者管理界面的示意图。

图8A和8B是示出根据本发明一实施例的移动终端的主显示界面的示意图，其中图8A示出移动终端初始化时的界面，图8B示出执行了若干检查事件时的界面。

图9A和9B是根据本发明一实施例的移动终端上显示检查事件相关信息的界面的示意图，其中图9A示出检查事件执行之前的界面，图9B示出检查事件执行之后的界面。

图10是示出根据本发明一实施例的移动终端的结构框图。

具体实施方式

下面将参照附图来描述本发明的示例性实施例。

图1是示出可实施根据本发明一实施例的事件驱动型急诊流程管理系统和方法的医院内网络系统10的拓扑图。如图1所示，医院内网络系统10可包括第一服务器11、第二服务器12、固定终端13和移动终端14，它们可以通过网络15彼此通信连接。

第一服务器11可以是用于运行医院信息管理系统(HIS)的服务器。医院信息管理系统一般可涵盖医院的所有业务过程，包含医院的各种信息，例如财务信息、物资信息、患者信息、医护人员信息等。通常使用的医院信息管理系统可包括例如但不限于门诊管理模块、住院管理模块、药房管理模块、药库管理模块、查询模块、电子处方模块、物资管理模块、媒体管理模块等。

第二服务器12可以是用于实施根据本发明一实施例的事件驱动型急诊流程管理系统的服务器端程序的服务器，该服务器端程序将在后面进一步详细描述。在一些实施例中，第二服务器12可以和第一服务器11是同一服务器，也就是说，根据本发明一实施例的事件驱动型急诊流程管理系统的服务器端程序可以和医院信息管理系统(HIS)实施在同一服务器上。当然，二者也可以是单独的服务器，如图1所示的那样。

固定终端13可以是位于医院内各个部门处的终端，例如位于分诊台处由护士操作，位于医生桌面由医生操作，以及位于药房、库房、财务室等处由其他工作人员操作等。在一些实施例中，至少一些固定终端13，例如但不限于位于各个科室的分诊台处以及位于医生桌面处的固定终端13，可以用于实施根据本发明的事件驱动型急诊流程管理系统的一部分。

移动终端14可以是分配给急诊患者手持移动的便携终端，并且其可以运行根据本发明的事件驱动型急诊流程管理系统的客户端程序，如后面将详细描述的那样。移动终端14可以通过网络15连接到其他设备，例如第一服务器11、第二服务器12和固定终端13，并且移动终端14还可以通过例如有线或无线连接方式，诸如蓝牙、USB连接等，直接连接到固定终端13。

网络15可以是局域网，也可以是广域网例如因特网。此外，网络15可以包括有线网络，也包括无线网络，例如包括布设在医院内的若干Wi-Fi接入点，从而实现对医院内患者可能移动到的地方的覆盖。当患者手持移动终端14在医院内移动时，移动终端14仍可以连接到网络15，进而连接到其他设备。

应理解，虽然上面描述了可用于实施根据本发明的事件驱动型急诊流程管理系统的医院内网络系统10的典型拓扑结构，但是该网络系统10也可以有许多变化。例如，有些医院的网络系统10可以没有医院信息管理系统(HIS)，从而没有第一服务器11；有些医院的网络系统10可以将医院信息管理系统(HIS)和根据本发明的事件驱动型急诊流程管理系统运行于同一服务器上，即第一服务器11和第二服务器12是同一服务器。或者，固定终端13之一和第二服务器12可以是同一设备，其用于运行根据本发明的事件驱动型急诊流程管理系统的服务器端程序。此外，一些或全部固定终端13可以被移动终端代替，例如可以被平板设备或其他便携式电子设备代替，这些平板设备或其他便携式电子设备可以执行相同甚至更多的功能。将理解，这些变化都不影响本发明的实施。换言之，根据本发明的事件驱动型急诊流程管理系统可以实施在这些医院内网络系统10的任一种上。

下面将描述根据本发明的事件驱动型急诊流程管理系统和方法的一些示例性实施例。本发明的事件驱动型急诊流程管理系统可包括服务器端模块和客户端模块，其中服务器端模块可以部署在前述第二服务器12和固定终端13上，客户端模块可以部署在移动终端14上。但是将理解，服务器端模块的一些功能也可以实施在客户端模块中，或者客户端模块的一些功能也可以实施在服务器端模块中，这些变化应被本发明的范围所涵盖。

图2示出根据本发明一实施例的事件驱动型急诊流程管理系统的服务器端模块100的功能框图，图3示出根据本发明一实施例的事件驱动型急诊流程管理系统的客户端模块200的功能框图。应理解，这些功能框图可以通过软件来实现，也可以通过硬件或硬件与软件的组合来实现。当通过软件来实现时，可以利用各种编程语言来实现各个功能块，例如但不限于各种web编程语言例如HTML、HTML5、PHP等，以及其他编程语言例如Jave、Jave Script、C语言、C#、C++等。软件实施的平台可以是例如但不限于windows、linux、iOS、安卓等。本领域技术人员还将理解的是，图2和图3描绘的功能框中每个都可以组合或者分离成子框以实施下面描述的本发明的原理。因此，这里的描述可以支持这里描述的功能框的任何可能的组合或分离或者进一步定义。

如图2所示，服务器端模块100可包括数据库单元110，其用于维护本发明的急诊流程管理系统所需的各种数据。例如，数据库单元110可包括医护人员数据库单元112，其包括在医院内工作的并且能够操作急诊流程管理系统的医生、护士等职员的姓名、编号、密码、权限等信息。数据库单元110还可包括检查项目数据库单元114，其包括与医院提供的各种检查项目相关的信息，例如检查项目名称、位置(可以是文本和/或地图)等信息。数据库单元110还可以包括例如移动终端数据库单元116，其包括本发明的急诊流程管理系统所采用的移动终端的信息，包括移动终端的名称、编号、使用记录等信息。可以理解，数据库单元110还可以包括这里未示出的其他数据库，例如患者数据库等，以支持后面描述的本发明的急诊流程管理系统的运行。

在一些实施例中，数据库单元110可以将上述数据存储于本地，例如第二服务器12中(见图1)。在另一些实施例中，数据库单元110亦可以连接到医院信息管理系统(HIS)(例如运行于图1所示的第一服务器11中)以获取至少一些数据，例如医护人员数据、检查项目数据等，并且可以定期更新这些数据。

服务器端模块100还可包括患者信息采集单元120。当急诊患者进入医院时，急诊科的接诊医生和护士可以采集患者的相关信息。这里，患者信息不仅包括患者的人身信息，例如姓名、性别、年龄等，还可以包括患者的疾病信息，例如由接诊医生确定的患者病症和危险程度信息、患者需要进行的检查项目信息等，这将在后面进一步详细描述。

患者信息采集单元120所采集的患者信息可通过客户端接口单元140发送到相关的移动终端，并且用这些信息来初始化该移动终端，从而实现该患者与该移动终端的绑定。然后，患者可以携带该移动终端，并且在该移动终端上显示的信息的帮助下执行各项检查事件，这将在后面更详细地描述。

服务器端模块100还可包括移动终端管理单元130，其可以在患者携带移动终端在医院内执行各项检查事件期间，通过客户端接口单元140保持与移动终端的通信，并且执行对移动终端的各项管理功能。例如，管理单元130可包括时间管理单元131、事件管理单元132、位置管理单元133、呼叫单元134和重置单元135。

时间管理单元131可以对移动终端执行各种时间管理。例如，对于某些急诊患者，要求其在规定时间内完成各项检查，因此当用患者信息初始化移动终端时，时间管理单元131就可以对移动终端的使用时间进行计时。当移动终端的使用时间超过规定时间时，时间管理单元131可以发出提示或警报信息，以提醒接诊医生或护士的注意，并且在必要时采取适当的介入措施。此外，时间管理单元131可以对移动终端进行授时操作，使得各个移动终端上的时钟与服务器端的时钟保持一致。

事件管理单元132可以管理移动终端上的事件，例如取得移动终端上的事件列表及其执行情况，必要时还可以对事件列表中的检查事件进行调整，例如增加新的检查项目，或者删除检查项目等。

位置管理单元133可以管理各个移动终端的位置。在一些实施例中，位置管理单元133可以从各个移动终端接收其位置信息。例如，当患者携带移动终端在医院内进行各项检查时，移动终端通过无线网络例如Wi-Fi连接到院内网络(例如图1所示的网络15)，此时通过Wi-Fi接入点即可确定患者的大致位置，或者通过多个Wi-Fi接入点检测到的移动终端的信号强弱来确定患者的更精确的位置。或者，移动终端可以根据检查事件的执行情况，确定其位置。例如，如后面参照图9A描述的那样，当完成某项检查事件时，可以确定移动终端在该时刻位于该检查点处。然后，移动终端可以将其位置信息发送给服务器端模块。

呼叫单元134可以呼叫各个移动终端。例如当接诊医生或护士需要联系正在进行各项检查的患者时，可以通过呼叫移动终端来进行。呼叫可以是语音呼叫，也可以是视频呼叫。

当患者完成了检查任务，返回到接诊医生和护士处时，可以归还移动终端。此时，接诊医生或护士可以重置移动终端以供下一次使用。重置时，移动终端上的各种数据可以作为移动终端使用记录而被存储到数据库单元110中。

上面描述了服务器端模块100的各种示例功能，应理解，在另一些实施例中，服务器端模块100也可以根据实际需要而具有更多或者更少的功能。下面将参照图3来描述客户端模块200的各项功能。

如前所述，接诊医生或护士会采集患者的各种信息，并且将这些信息发送到移动终端以初始化移动终端。如图3所示，移动终端上的客户端模块200则可通过服务器接口单元250来接收这些信息，并且通过下面描述的各个单元来管理这些信息。

如图3所示，客户端模块200可包括患者信息管理单元210，患者信息管理单元210可以接收来自服务器端模块100的患者信息，如在图6所示的界面中采集的信息，并用其来初始化移动终端的相关参数。这些信息可以显示在移动终端的主界面上，以便于随时通过其来识别患者。

客户端模块200还可包括时间管理单元220，其在接收到来自服务器端模块100的患者信息时就开始计时，以监视患者持移动终端执行检查事件的时间。如果该时间超出了规定时间，则还可以向患者发出提醒。在患者持移动终端执行检查任务期间，时间管理单元220还可以监视各个事件的执行时间。此外，时间管理单元220可以从服务器端模块100取得时间，以使二者的时间保持一致。

客户端模块200中的事件管理单元230可以对来自服务器端模块100的患者信息中的检查事件数据进行管理。例如，在接收到检查事件数据时，生成检查事件列表，并且管理各个检查事件的执行情况。例如，当患者完成某项检查后，可以在医生或护士的操作下，将该事件标识为已完成状态。在一些实施例中，事件管理单元230还可以连接到医院信息管理系统(HIS)，以获取所完成的检查事件的检查结果，从而患者可以方便地在移动终端上查看。

在一些实施例中，事件管理单元230还可以包括事件排序单元232，其可以按照一定的标准对检查事件列表中的各个检查事件进行排序。例如，当在急诊室由接诊护士完成对移动终端的初始化后，事件排序单元232可以按照检查地点由近到远的顺序对各个事件排序，从而患者可以按照该顺序方便地完成各项检查，节省时间。在另一些实施例中，事件管理单元230还可以连接到医院信息管理系统(HIS)以获得各个检查处的当前等候人数，事件排序单元232可以根据检查人数来对各个事件进行排序，以引导患者到等候人数较少的检查点完成某项检查。这样，就患者个人而言，可以优化其检查顺序，缩短等候时间；就医院整体而言，可以优化患者流向，改善各个检查部门的负载均衡，从而提高运营效率。

应理解的是，手持终端设备进行检查的患者都是病情严重且紧急程度较高的患者，因此具有较高的优先级。例如当患者手持移动终端来到一处检查点时，如果没有其他手持移动终端的患者，则应优先为该患者执行检查；如果有其他也持移动终端的患者，则应比较二者之间的优先级来判断检查顺序。优先级可以根据患者的病症、危险程度、年龄等因素来考虑，并且可以编码在例如急诊号中。当有多个相同优先级的患者时，则可以根据先来后到的顺序确定检查顺序。因此，当事件管理单元230从医院信息管理系统(HIS)获取某检查点的当前等候人数时，可以只考虑具有相同或更高优先级的候检患者。

当患者手持移动设备进行各项检查时，事件排序单元232可以根据患者的位置、或者各个检查点的等候人数信息来动态更新检查顺序。此外，患者也可以不按照所排列的顺序进行检查，而是可以按任意顺序进行检查。事件排序单元232可以将已完成的检查事件排列在前，未完成的排列在后，以便于患者方便地观看。

此外，客户端模块200还可以包括定位单元240和呼叫单元250。在一些实施例中，定位单元240可以基于例如Wi-Fi信号来确定移动终端的当前位置。在另一些实施例中，定位单元240也可以基于检查事件的执行情况来确定移动终端的当前位置。例如，当执行完一项检查事件，并且检查医生操作移动终端以将该检查事件标记为已完成时(如后面参照图9A描述的那样)，定位单元240可以确定在该时刻移动终端位于该检查点处。此外，定位单元240还可以包括有医院的地图信息，该信息可以用于供事件排序单元230按地点远近为各个检查事件排序，如前面描述的那样。呼叫单元250可以用于应答服务器端模块100的呼叫。在一些实施例中，呼叫单元250也可以用于发起对服务器端模块100的呼叫，以联络接诊医生或护士，从而在整个检查过程中医患之间都可以保持畅通的沟通渠道。

上面简要描述了根据本发明一些实施例的事件驱动型急诊流程管理系统的各个模块的功能，下面将参照附图来描述可利用这些模块实施的急诊流程管理方法。图4示出了服务器侧实施的方法300的流程图，图5示出了客户端侧实施的方法400的流程图。

如图4所示，方法300示于步骤S301，例如患者抵达医院急诊室就诊。当接诊医生和护士判断该患者病情紧急，需要使用移动终端来执行多项检测时，则进行步骤S302的患者信息采集步骤，这可以利用例如图2所示的患者信息采集单元120来执行。图6示出了患者信息采集页面的示例，其可以运行于例如急诊室的固定或移动终端13(见图1)上。如图6所示，患者信息采集页面可以采集患者的姓名、性别、年龄、病案号、急诊号等基本信息，还可以设置接诊医生(包括护士)，接诊医生可以显示为头像，也可以直接显示姓名。在该页面上，还可以选择患者的病症。应理解，移动终端仅用于需要在预定时间内完成检查事项的急诊患者，因此只用于少量危急病症，例如胸痛、卒中、休克、昏迷和创伤患者等。针对每种病症，还可以选择其危险等级。危险等级可以分为例如五个等级，从低到高依次是低、谨慎、较高、高和严重。图6的示例是用于危险等级为高的胸痛患者。针对该患者，可以选择需要执行的一个或多个检查项目。在患者信息采集页面中，还可以选择要用于该患者的移动终端设备，例如在图6的示例中选择了“1号终端”。图6的页面中的许多信息，例如接诊医生、终端设备、检查项目等，都可以从服务器端模块100的数据库单元110中选择，如前面参照图1描述的那样。

虽然未示出，但是在图6的患者信息采集页面中，还可以采集其他所需的患者信息。例如，接诊医生或护士可以设置患者完成检查的规定时间，或者该时间也可以根据患者的病症和危险等级而由患者信息采集模块120自动生成。当由患者信息采集模块120自动生成该时间时，还可以考虑其他因素，例如所选择的检查项目等。

当接诊医生或护士完成了患者信息采集时，可以点击页面上的“开始计时”按钮，此时执行方法300的步骤S303，服务器端模块100将患者信息发送到所选定的1号移动终端上运行的客户端模块200，并且用患者信息来初始化1号终端，从而完成该患者与1号终端的绑定。同时，时间管理单元131可以开始对1号终端进行计时。时间管理单元131还可以对移动终端上的时间进行设置或校准，以使得移动终端与服务器的时间保持一致。

然后，急诊患者可以携带移动终端开始执行接诊医生指定的各项检查事件。此时，服务器端可以通过移动终端管理单元130来保持对移动终端的监视和管理，如步骤S304所示，例如监视移动终端的事件执行进展，并且在需要时接诊医生或护士可以直接介入检查执行过程。图7示出了服务器端的管理界面的示例。如图7所示，管理界面显示了各个用户的基本信息，例如姓名、病症、危险程度等。此外，管理界面还显示了各个用户的检查用时，其可以由例如时间管理单元131给出。检查用时可以以倒计时的方式给出，当患者用完了规定检查时间时，则时间变为负值，表示该患者已经超时。此时，时间管理单元131可以发出提示信号，例如使显示的时间的颜色变红以引起护士的注意，或者显示超时图标、发出提示音等。当然，检查用时也可以以正计时的方式给出，当其超出规定值时，则时间管理单元131发出超时提醒信号。

此外，事件管理单元132可以监视各个检查事件的执行情况。如图7的管理界面所示，可以列出检查事件列表，用特定符号(例如勾符号)区分开已完成的检查事件和尚未完成的检查事件，并且示出检查事件列表的执行进度，例如“4/5”表示已经完成了总共5项检查事件中的4项，亦可用百分数表示事件执行进度。

虽然图7的界面未示出，但是还可以利用例如位置管理单元133来监视移动终端的位置。例如，如前所述，位置管理单元133可以从各个移动终端接收其位置信息。当在图7所示的界面点击相应用户的头像符号时，可以弹出医院的楼座和/或楼层的地图界面，显示移动终端在地图中的位置。或者，也可以用文字信息来显示移动终端在医院内的位置。

此外，当发现患者的检查过程已经超时或者快要超时时，接诊医生或护士还可以通过呼叫单元134来联系患者。如图7所示，接诊医生或护士可以通过点击管理界面上患者前面的扬声器图标来呼叫该患者，图7示出了正在呼叫第一个患者的例子。

当患者手持移动终端完成了所有检查项目之后，可以返回到接诊医生或护士处。此时，如步骤S305所示，护士可以利用重置单元135将该患者使用过的移动终端重置，恢复成空白状态，以供下一次使用。重置时，重置单元135可以将移动终端上的相关数据，例如各个检查事件的执行时间、执行医师、甚至检查结果等信息储存到数据库单元110中，以供以后查询。然后，方法300结束，如步骤S306所示。

下面参照图5描述客户端侧实施的方法400。如图5所示，方法400始于步骤S401。在步骤S402，客户端模块可通过患者信息管理单元210接收来自服务器端模块的患者信息，例如前面参照图6描述的那些患者信息，并且还可以利用这些信息来初始化移动终端，从而完成该移动终端与该患者之间的绑定。其中，初始化移动终端可包括由患者信息管理单元210设置患者身份信息，由时间管理单元220开始计时，并且时间管理单元220可以在此时执行与服务器的时间同步。此外，初始化移动终端的步骤还可包括由事件管理单元230生成检查事件列表。

然后在步骤S403，事件管理单元230中包括的事件排序单元232可以对检查事件列表中的各项检查事件进行排序，以确定优选的先后检查顺序。例如，在一实施例中，事件排序单元232可以基于检查地点离患者当前位置的远近来进行排序，距离近的检查项目排列在前。或者，在另一实施例中，事件排序单元232可以基于从HIS获得的各个检查项目的当前等候人数来进行排序，等候人数少的检查项目排列在前。当然，事件排序单元232也可以根据其他策略来进行排序，例如某些检查项目需要尽快进行，某些检查项目对于该疾病的诊断比较重要，等等。

图8A示出初始化和事件排序步骤执行完毕之后，移动终端的显示界面。如图8A所示，该界面上显示了患者的一些基本信息，包括急诊号，其是患者在就诊期间的身份标识，并且还显示了与急诊号对应的条码，便于在各个检查点录入患者信息，例如只要一扫条码即可录入患者信息。此外，该界面还示出了时间，如前所述，其可以是倒计时，也可以是正计时。该界面还示出了所生成的检查事件清单，其已经按照一定的顺序排列，和检查任务执行进度条，其表明检查事件的完成进展。虽然未示出，但是该界面还可以显示一些其他信息，例如提示用户如何使用该移动终端的提示信息等。

然后，患者可以手持该移动终端，到各个检查地点进行检查，如步骤S404所示。应理解，移动终端本身就代表较高的紧急程度或优先级，当各个检查点的医师看到手持该移动终端的患者时，会优先为其进行检查。但是当某个检查点同时有多个手持移动终端的患者在候检时，则需要比较这多个患者之间的紧急程度或优先级。如前所述，患者的紧急程度或优先级可以编码在急诊号中，而图8A所示的移动终端的主显示界面可以根据患者的紧急程度或优先级而具有不同的背景颜色。例如，当患者具有最高的优先级时，背景颜色可以为紫色，次之则为红色，再次之则为黄色，最低优先级则为绿色，等等。在另一些实施例中，主界面的背景颜色也可以根据患者所剩时间来改变颜色，当患者剩余时间越短，即患者应在越短的时间内完成检查，则背景颜色越深。

移动终端可提供关于各项检查的具体信息。例如，当在图8A所示的界面上点击尚未完成的检查事件时，可以弹出图9A所示的界面，其示出了检查事件相关的信息，例如名称、地点和地图等，以便于患者进行各项检查。应理解，检查事件的地点和地图可以由事件管理单元230从服务器端模块100的数据库单元110获得，或者直接从医院信息管理系统HIS获得。图9A的界面还可以显示从HIS获取的该检查项目的当前等候人数和预计等候时间等信息。当患者执行完该检查项目时，完成该检查的医师可以在该界面上输入其姓名或编号以及密码，并点击完成按钮，则事件管理单元230可以将该检查事件的状态标记为已完成，并且时间管理单元220可以记录事件完成时间。在另一些实施例中，医师也可以通过语音来操作来将事件标记为已完成，而医师的声纹信息可用作密码。当患者再点击该事件时，则弹出图9B所示的界面，其显示该事件的完成医师的姓名，以及完成时间，并且在一些实施例中，还可显示从HIS获得的检查结果信息，从而方便患者进行查看。

当患者完成了若干检查事件时，则移动终端的主界面从图8A所示的界面变化为图8B所示的界面。在图8B所示的界面中，已经完成了的检查事件被排列在前，并且用特殊标记(图8B中为勾符号)示出，未完成的检查事件排列在后。事件排序单元232可以重复地对未完成的事件进行排序，以持续向患者推荐最优检查顺序。应理解，患者也可以不按照排列顺序进行检查，而是可以根据自己的意愿来进行检查。

在患者持移动终端进行各项检查期间，如步骤S405所示，移动终端还将检查事件执行情况的数据更新至服务器端的数据库单元110，从而服务器端可以随时掌握客户端的事件执行进展。例如，如前面参照图7描述的那样，移动终端管理单元130可以从数据库单元110获得相关数据，并且将执行进展以及其他信息显示在图7所示的管理界面上，以便于接诊医生或护士方便地查看。

在检查期间，患者可能需要一些外界帮助，这可以通过呼叫步骤S406来执行。例如，患者或其家属可以执行紧急情况呼叫，或者呼叫轮椅等。呼叫步骤可以通过点击触摸屏上显示的相应呼叫按钮来执行，或者可以通过按压移动终端上的相应物理按钮来执行。

当患者完成了所有检查项目时，方法400结束，如步骤S407所示。此时，患者可以携带移动终端返回至接诊医生或护士处，并且归还移动终端。接诊医生或护士可以执行图4所示的方法300的步骤S305以重置移动终端。

图10示出根据本发明一示例性实施例的移动终端装置500的结构框图。如图10所示，移动终端500可包括处理器510、键盘520、触摸屏显示器530、存储器540、通信单元550、扬声器560和麦克风570，它们通过总线系统580彼此连接。

处理器510可以是通用处理器，例如中央处理单元CPU，也可以是专门设计的处理器或控制器，其可以运行计算机程序指令以执行前面描述的方法300以及其他操作。计算机程序指令可存储在存储器540中。存储器540可以是任何类型的非易失性存储器，诸如磁盘、闪存等。除了存储计算机程序之外，存储器540还可以存储执行前述方法所需的患者相关数据和/或医院相关数据等。

键盘520可包括各种按键，包括但不限于电源按键、音量按键、以及其他按键。例如，可以包括一个或多个呼叫按键，以便于患者在需要时快捷地进行各种呼叫，例如紧急情况呼叫、呼叫轮椅、或者呼叫医生护士等。为了执行呼叫功能，移动终端500还包括有扬声器560和麦克风570。

触摸屏显示器530兼具输入和输出功能，其可以接收用户的各种操作，以及向用户显示各种信息，如前面参照图6至图9B所描述的那样。应理解，前面描述的一些功能，例如呼叫，可以通过单独的按键来进行，也可以通过触摸屏显示器530来执行。当通过触摸屏显示器530来执行时，相应的物理按键可以被省略。

除了上述系统和方法以外，本申请的实施例还可以是计算机程序产品，其包括计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本说明书描述的根据本申请各种实施例的急诊流程管理方法中的各个步骤。

所述计算机程序产品可以以一种或多种程序设计语言的任意组合来编写用于执行本申请实施例操作的程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如Java、JavaScript、C#、C++等，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。程序运行平台可以包括Windows、Linux、安卓、iOS、Symbian等。

此外，本申请的实施例还可以是计算机可读存储介质，其上存储有计算机程序指令，所述计算机程序指令在被处理器运行时使得所述处理器执行本说明书描述的根据本申请各种实施例的急诊流程管理方法中的各个步骤。

所述计算机可读存储介质可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以包括但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

上面描述了本发明的一些示例性实施例，但是应理解，在本申请的教导下，本领域技术人员可以进行形式和细节上的各种变化。例如，本领域技术人员可以根据需要而为本发明的事件驱动型急诊流程管理方法增加许多其他功能模块。此外，本发明的系统和方法不仅可用于医院急诊接诊部门的流程管理，还可以应用到例如ICU患者流程管理、住院患者流程管理等其他方面。

如上所述，本发明的事件驱动型急诊流程管理系统和方法实现了以患者为中心的、并且以为患者建立的检查列表为主线的检查过程，其至少具有如下优点。

第一，移动终端本身作为紧急情况的显著标志，其可以使急诊患者能被容易地识别并且得到优先处理，从而避免了向其他患者或医生说明情况所需的时间。

第二，移动终端可以为患者生成检查事件列表，并且还能显示各项检查的相关信息，例如地点等，从而便于患者快速完成各项检查。移动终端还可以连接到医院的HIS以获得检查结果，以便于患者查看。

第三，移动终端可以为患者提供优化的检查顺序，例如按照距离远近、等候人数的多少等来优化，可以改善患者流向，节省患者平均花费的检查时间，提高医院的运营效率。

第四，接诊医生或护士可以通过移动终端来方便地实现对各个急诊患者的管理，可以随时掌握各个患者的当前位置和检查进展，在需要时通过呼叫等方式来介入检查过程。而且，当某些患者的检查超过规定时间时，还可以向接诊医生或护士发出警报信息，避免因繁忙而导致遗忘了该患者。

第五，由于各个移动终端的时间与服务器保持一致，因此可以确保各项检查在时间上的一致性，从而可以便于执行信息的整合分析。

第六，本发明的系统能够容易地布设。该系统可以利用医院现有的网络系统来进行，在硬件上增加的设备很少，因此不会产生高昂的成本。

第七，本发明的系统和方法可以独立实施，不依赖于现有的医院信息管理系统，或者也可以连接或整合到现有的医院信息管理系统中。因此，该系统可以适应于各种医院信息管理状况。

本发明还具有其他优点和特征，其可以从前面对示例性实施例的描述而显见。以上结合具体实施例描述了本申请的基本原理，但是，需要指出的是，在本申请中提及的优点、优势、效果等仅是示例而非限制，不能认为这些优点、优势、效果等是本申请的各个实施例必须具备的。另外，上述公开的具体细节仅是为了示例的作用和便于理解的作用，而非限制，上述细节并不限制本申请为必须采用上述具体的细节来实现。

本申请中涉及的器件、装置、设备、系统的方框图仅作为例示性的例子并且不意图要求或暗示必须按照方框图示出的方式进行连接、布置、配置。如本领域技术人员将认识到的，可以按任意方式连接、布置、配置这些器件、装置、设备、系统。诸如“包括”、“包含”、“具有”等等的词语是开放性词汇，指“包括但不限于”，且可与其互换使用。这里所使用的词汇“或”和“和”指词汇“和/或”，且可与其互换使用，除非上下文明确指示不是如此。这里所使用的词汇“诸如”指词组“诸如但不限于”，且可与其互换使用。

还需要指出的是，在本申请的设备和方法中，各部件或各步骤是可以分解和/或重新组合的。这些分解和/或重新组合应视为本申请的等效方案。

虽然上面按照一定的顺序描述了方法中的各个步骤，但是应理解，这些步骤也可以按照不同的顺序进行，或者多个步骤可以同时进行。或者在一些实施例中，某些步骤可以一直持续地进行。本发明的方法涵盖所有这些不同的执行顺序。

提供所公开的方面的以上描述以使本领域的任何技术人员能够做出或者使用本申请。对这些方面的各种修改对于本领域技术人员而言是非常显而易见的，并且在此定义的一般原理可以应用于其他方面而不脱离本申请的范围。因此，本申请不意图被限制到在此示出的方面，而是按照与在此公开的原理和新颖的特征一致的最宽范围。

为了例示和描述的目的已经给出了以上描述。此外，此描述不意图将本申请的实施例限制到在此公开的形式。尽管以上已经讨论了多个示例方面和实施例，但是本领域技术人员将认识到其某些变型、修改、改变、添加和子组合。本发明的范围由所附权利要求及其等价物定义。