CN112842711B - 急救车、急救车参数的处理方法及系统 - Google Patents

Abstract

本申请提供一种急救车、急救车参数的处理方法及系统，包括：实时监测急救车车内药品的第一浓度值，并实时更新急救车的消毒状态列表；若第一浓度值达到第一预设值，则开始计时，得到计时时长；若计时时长达到预设时长，则控制急救车的车门和车窗开启，并实时监测急救车车内药品的第二浓度值；若第二浓度值小于第二预设值，则将急救车加入到预设的可调度急救车列表中。本发明以药品浓度作为判断依据，能够减少消毒时间，避免药品浓度已达标而急救车依旧处于不可用的状态，从而保证调度中心能够及时调度急救车，提高急救车的调度效率。

Description

急救车、急救车参数的处理方法及系统

技术领域

本申请涉及计算机技术领域，具体而言，涉及一种急救车、急救车参数的处理方法及系统。

背景技术

目前，在发生重大伤亡事故时，及时采取正确有效的抢救措施至关重要，其中处于功能状态的急救车是保证抢救成功的基础。通常情况下，医院配备有多辆急救车，以便于应对部分急救车消毒而处于不可用状态的情况。

急救车消毒时，需要将消毒药品喷洒在车内空间，并密闭车门一段时间后敞开车门通风一段时间。但是若车内的药品浓度已经达到标准值，仍然按照规定时间进行密闭消杀或者敞开通风，会使得急救车一直处于不可用状态的情况，从而无法有效调度急救车工作，造成急救车资源的浪费。

发明内容

本申请实施例的目的在于提供一种急救车、急救车参数的处理方法及系统，旨在解决急救车调度效率低的问题。

第一方面，本申请实施例提供了一种急救车参数的处理方法，包括：

实时监测急救车车内药品的第一浓度值，并实时更新急救车的消毒状态列表；

若第一浓度值达到第一预设值，则开始计时，得到计时时长；

若计时时长达到预设时长，则控制急救车的车门和车窗开启，并实时监测急救车车内药品的第二浓度值；

若第二浓度值小于第二预设值，则将急救车加入到预设的可调度急救车列表中。

在本实施例中，通过实时监测急救车车内药品的第一浓度值，并实时更新急救车的消毒状态列表，从而使得用户能够及时了解到车内药品浓度，避免药品浓度不够进行消毒；若第一浓度值达到第一预设值，则开始计时，得到计时时长，若计时时长达到预设时长，则控制急救车的车门和车窗开启，保证药品能够杀死车内的病菌；实时监测急救车车内药品的第二浓度值，若第二浓度值小于第二预设值，则将急救车加入到预设的可调度急救车列表中，以药品浓度作为判断依据，减少消毒时间，避免药品浓度已达标而急救车依旧处于不可用的状态，从而保证调度中心能够及时调度急救车，提高急救车的调度效率。

进一步地，实时监测急救车车内药品的第一浓度值，并实时更新急救车的消毒状态列表之前，还包括：

获取急救车的急救车参数的初始值，急救车参数包括急救车的车牌号、消毒开始时间、消毒结束时间、消毒状态、药品浓度值、计时时长、消毒人员和/或消毒类型；

根据预设的急救车参数，生成消毒状态列表。

在上述实现过程中，由于目前消毒过程需要消毒人员在纸质文件记录消毒过程，所以在翻阅纸质文件存在交叉感染的风险。因此本实施例生成消毒状态列表，一方面能够根据实时监测结果实时更新消毒状态列表，以使用户及时了解急救车内部的最新状态，另一方面能够保证消毒人员的人身安全。

进一步地，若第一浓度值达到第一预设值，则开始计时，得到计时时长之前，还包括：

识别药品对应的药品类型；

基于药品类型与标准值的预设对应关系表，确定标准值，标准值包括第一预设值、预设时长和/或第二预设值。

在上述实现过程中，由于不同消毒场景下，消毒药品存在差异，对应的消毒标准也存在差异，所以本实施例通过检测药品类型，以采用药品类型对应的消毒标准进行消毒，实现消毒过程高度自动化。

进一步地，若计时时长达到预设时长，则控制急救车的车门和车窗开启，并实时监测急救车车内药品的第二浓度值之前，还包括：

检测是否接收到急救车的车门和/或车窗的开启指令；

若接收到开启指令，则播放警报语音信息，警报语音信息用于提示用户是否确认开启车门和/或车窗；

在警报语音信息播放结束后的预设时间段内，再次检测是否接收到急救车的车门和/或车窗的开启指令；

若再次接收到开启，则开启车门和/或车窗。

在上述实现过程中，由于在消毒过程中，存在用户误入急救车内因药品浓度过高而导致人身伤害的情况，所以本实施例通过警报语音信息，避免用户误入急救车，同时为了应对必须进入急救车内的其他紧急情况，所以通过在播放警报语音信息的一段时间内，再次检测开启指令，以使用户能够再次输入开启指令开启车门或车窗。

进一步地，若第二浓度值小于第二预设值，则将急救车加入到预设的可调度急救车列表中，包括：

若第二浓度值小于第二预设值，则检测第二浓度值达到第二预设值时的持续时长；

若持续时长大于预设持续时长，则将急救车加入到预设的可调度急救车列表中。

在上述实现过程中，由于目前采用的通风一段时间，该时间长度能够保证药品浓度值降低至标准值，但是该时间长度较长，而本实施例采用的是药品浓度值作为判断依据，监测药品浓度值时由于空气传播，可能监测到药品瞬时浓度低值，但车内的实际药品浓度值较高的情况，因此，本实施例通过药品浓度值低于标准值的持续时长，进一步验证车内的实际药品浓度值是否达到标准值，从而保证消毒过程的安全性。

进一步地，实时更新急救车的消毒状态列表，包括：

按照更新时间的时间顺序，将最新的第一浓度值、计时时长和/或第二浓度值记录到消毒状态列表中。

在上述实现过程中，将最新的药品浓度值等参数更新消毒状态列表，从而使用户及时了解车内的消毒状态。

第二方面，本申请实施例提供了一种急救车参数的处理系统，包括：

监测模块，用于实时监测急救车车内药品的第一浓度值，并实时更新急救车的消毒状态列表；

计时模块，用于若第一浓度值达到第一预设值，则开始计时，得到计时时长；

控制模块，用于若计时时长达到预设时长，则控制急救车的车门和车窗开启，并实时监测急救车车内药品的第二浓度值；

加入模块，用于若第二浓度值小于第二预设值，则将急救车加入到预设的可调度急救车列表中。

进一步地，加入模块，包括：

检测单元，用于若第二浓度值小于第二预设值，则检测第二浓度值达到第二预设值时的持续时长；

加入单元，用于若持续时长大于预设持续时长，则将急救车加入到预设的可调度急救车列表中。

第三方面，本申请实施例提供了一种急救车，急救车上设有计算机设备，计算机设备包括存储器及处理器，存储器用于存储计算机程序，处理器运行计算机程序以使急救车实现第一方面的急救车参数的处理方法。

第四方面，本申请实施例提供了一种计算机可读存储介质，其存储有计算机程序，计算机程序被处理器执行时实现如第一方面的急救车参数的处理方法。

可以理解的是，第二方面至第四方面的有益效果可以参见上述第一方面的相关描述，在此不再赘述。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请一实施例提供的急救车参数的处理方法的流程示意图；

图2为本申请另一实施例提供的急救车参数的处理方法的流程示意图；

图3为本申请实施例提供的急救车参数的处理系统的结构示意图；

图4为本申请实施例提供的计算机设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

如背景技术相关记载，在急救车消毒过程中，若车内的药品浓度已经达到标准值，仍然按照规定时间进行密闭消杀或者敞开通风，会使得急救车一直处于不可用状态的情况，从而无法有效调度急救车工作，造成急救车资源的浪费。

针对上述现有技术中的问题，本申请提供了一种急救车参数的处理方法，通过实时监测急救车车内药品的第一浓度值，并实时更新急救车的消毒状态列表，从而使得用户能够及时了解到车内药品浓度，避免药品浓度不够进行消毒；若第一浓度值达到第一预设值，则开始计时，得到计时时长，若计时时长达到预设时长，则控制急救车的车门和车窗开启，保证药品能够杀死车内的病菌；实时监测急救车车内药品的第二浓度值，若第二浓度值小于第二预设值，则将急救车加入到预设的可调度急救车列表中，以药品浓度作为判断依据，减少消毒时间，避免药品浓度已达标而急救车依旧处于不可用的状态，从而保证调度中心能够及时调度急救车，提高急救车的调度效率。

另外，本申请还提供一种急救车，该急救车上设有计算机设备，以及包括但不限于药品浓度监测传感器、计时器、车门控制装置和车窗控制装置等急救车组件，计算机设备能够控制上述急救车组件工作，以使急救车实现上述急救车参数的处理方法。

参见图1，图1示出了本申请实施例提供的一种急救车参数的处理方法的实现流程图。本申请实施例中下述的急救车参数的处理方法可应用于急救车，急救车上设有计算机设备，计算机设备包括但不限于智能手机、平板电脑、桌上型计算机、超级计算机、个人数字助理和物理服务器等计算机设备。本申请实施例的急救车参数的处理方法，包括步骤S101至S104，详述如下：

步骤S101，实时监测急救车车内药品的第一浓度值，并实时更新急救车的消毒状态列表。

在本实施例中，通过急救车车内的药品浓度传感器监测药品的第一浓度值，药品可以酒精、过氧乙酸和双氧水等消毒药品。消毒状态列表用于该急救车的消毒状态，可以将急救车内的计算机设备与云端系统通信连接，以使用户能够通过云端系统查看该消毒状态列表。

可选地，实时更新急救车的消毒状态列表，包括：按照更新时间的时间顺序，将最新的第一浓度值、计时时长和/或第二浓度值记录到消毒状态列表中。

在上述实现过程中，将最新的药品浓度值等参数更新消毒状态列表，从而使用户及时了解车内的消毒状态。可以理解的是，在消毒过程中，可以将计算机设备得到任何监测结果均记录在消毒状态列表。例如，在密封车门消毒时，监测到有人开启车门，则可以将开启车门的时刻以及是否开启成功的状态记录在消毒状态列表，以便于用户查看消毒过程中的任何状态。

步骤S102，若第一浓度值达到第一预设值，则开始计时，得到计时时长。

在本实施例中，第一预设值为药品消毒浓度标准值，每种药品对应一个第一预设值，例如，过氧乙酸的第一预设值为5％(空气含量)。可以理解的是，由于监测第一药品浓度时，车门车窗已经封闭，所以车内空气流通性较差，一旦监测到第一浓度值达到第一预设值，则视为车内整体的第一浓度值达到第一预设值，并控制计时器开始计时，以及更新该过程中的消毒状态列表。

步骤S103，若计时时长达到预设时长，则控制急救车的车门和车窗开启，并实时监测急救车车内药品的第二浓度值。

在本实施例中，预设时长为药品消毒时长标准值，每种药品对应一个预设时长。可以理解的是，不同药品对应的预设时长可以相同，也可以不同。例如，过氧乙酸的消毒预设时长为1小时，过氧化氢的消毒预设时长为30分钟，具体可参见中国颁发的《消毒管理办法》，对此不作限定。

当计时时长达到预设时长时，说明以车内已消毒完成，所以计算机设备控制车门开启装置开启车门，以及控制车窗开启装置开启车窗，使得急救车通风，以使车内药品浓度降低至第二预设值。

可选地，若第二浓度值小于第二预设值，则将急救车加入到预设的可调度急救车列表中，包括：若第二浓度值小于第二预设值，则检测第二浓度值达到第二预设值时的持续时长；若持续时长大于预设持续时长，则将急救车加入到预设的可调度急救车列表中。

在上述实现过程中，由于目前方法采用通风时间作为判断依据，该时间长度能够保证药品浓度值降低至标准值，但是该时间长度较长，而本实施例采用的是药品浓度值作为判断依据，监测药品浓度值时由于空气传播，可能监测到药品瞬时浓度低值，但车内的实际药品浓度值较高的情况，因此，本实施例通过药品浓度值低于标准值的持续时长，进一步验证车内的实际药品浓度值是否达到标准值，从而保证消毒过程的安全性。

步骤S104，若第二浓度值小于第二预设值，则将急救车加入到预设的可调度急救车列表中。

在本实施例中，急救车的计算机设备与云端系统通信连接，以将可调用急救车列表发送至医院急救车调度中心和医院急救中心，使得医生和护士能够在出急救车时快速了解到可调度的急救车。

在图1所示实施例的基础上，图2示出了本申请提供的另一种急救车参数的处理方法的流程示意图。可以理解的是，与图1实施例相同步骤，在此不再赘述。

如图2所示，在步骤S101之前，还包括步骤S201至S202，具体如下：

步骤S201，获取急救车的急救车参数的初始值，急救车参数包括急救车的车牌号、消毒开始时间、消毒结束时间、消毒状态、药品浓度值、计时时长、消毒人员和/或消毒类型；

步骤S202，根据预设的急救车参数，生成消毒状态列表。

在上述实现过程中，初始值可以为空值或者0值，例如此时还无法得知消毒结束时间，所以将消毒结束时间的初始值视为空值或0值。由于目前消毒过程需要消毒人员在纸质文件记录消毒过程，所以在翻阅纸质文件存在交叉感染的风险。因此本实施例生成消毒状态列表，一方面能够根据实时监测结果实时更新消毒状态列表，以使用户及时了解急救车内部的最新状态，另一方面能够保证消毒人员的人身安全。

如图2所示，在步骤S102之前，还包括步骤S203至S204，具体如下：

步骤S203，识别药品对应的药品类型；

步骤S204，基于药品类型与标准值的预设对应关系表，确定标准值，标准值包括第一预设值、预设时长和/或第二预设值。

在上述实现过程中，可以根据常用消毒药品，在车内安装用于识别对应消毒药品的药品传感器。预设对应关系表记录不同药品与标准值之间的对应关系表，其可以根据不同药品的标准值进行预设。由于不同消毒场景下，消毒药品存在差异，对应的消毒标准也存在差异，所以本实施例通过检测药品类型，以采用药品类型对应的消毒标准进行消毒，实现消毒过程高度自动化。

如图2所示，在步骤S103之前，还包括步骤S205至步骤S208，具体如下：

步骤S205，检测是否接收到急救车的车门和/或车窗的开启指令；

步骤S206，若接收到开启指令，则播放警报语音信息，警报语音信息用于提示用户是否确认开启车门和/或车窗；

步骤S207，在警报语音信息播放结束后的预设时间段内，再次检测是否接收到急救车的车门和/或车窗的开启指令；

步骤S208，若再次接收到开启，则开启车门和/或车窗。

在上述实现过程中，开启指令可以是远程遥控器发出的开启指令，也可以是车门把手开启而触发的开启指令，还可以是语音开启指令等。警报语音信息提示用户“当前急救车正处于消毒状态，请确认是否开启车门或车窗”。由于在消毒过程中，存在用户误入急救车内因药品浓度过高而导致人身伤害的情况，所以本实施例通过警报语音信息，避免用户误入急救车，同时为了应对必须进入急救车内的其他紧急情况，所以通过在播放警报语音信息的一段时间内，再次检测开启指令，以使用户能够再次输入开启指令开启车门或车窗。

为了执行上述方法实施对应的方法，以实现相应的功能和技术效果，下面提供一种急救车参数的处理系统。参见图3，图3是本申请实施例提供的一种急救车参数的处理系统的结构框图。本实施例中该系统包括的各模块用于执行图1或图2对应的实施例中的各步骤，具体参见图1和图2以及图1和图2所对应的实施例中的相关描述。为了便于说明，仅示出了与本实施例相关的部分，本申请实施例提供的急救车参数的处理系统，包括：

监测模块301，用于实时监测急救车车内药品的第一浓度值，并实时更新急救车的消毒状态列表；

计时模块302，用于若第一浓度值达到第一预设值，则开始计时，得到计时时长；

控制模块303，用于若计时时长达到预设时长，则控制急救车的车门和车窗开启，并实时监测急救车车内药品的第二浓度值；

加入模块304，用于若第二浓度值小于第二预设值，则将急救车加入到预设的可调度急救车列表中。

进一步地，上述系统还包括：

获取模块，用于获取急救车的急救车参数的初始值，急救车参数包括急救车的车牌号、消毒开始时间、消毒结束时间、消毒状态、药品浓度值、计时时长、消毒人员和/或消毒类型；

生成模块，用于根据预设的急救车参数，生成消毒状态列表。

进一步地，上述系统还包括：

识别模块，用于识别第一浓度值对应的药品类型；

确定模块，用于基于药品类型与标准值的预设对应关系表，确定标准值，标准值包括第一预设值、预设时长和/或第二预设值。

进一步地，上述系统还包括：

检测模块，用于检测是否接收到急救车的车门和/或车窗的开启指令，还用于在警报语音信息播放结束后的预设时间段内，再次检测是否接收到急救车的车门和/或车窗的开启指令；

播放模块，用于若接收到开启指令，则播放警报语音信息，警报语音信息用于提示用户是否确认开启车门和/或车窗；

开启模块，用于若再次接收到开启，则开启车门和/或车窗。

进一步地，加入模块304，包括：

检测单元，用于若第二浓度值小于第二预设值，则检测第二浓度值达到第二预设值时的持续时长；

加入单元，用于若持续时长大于预设持续时长，则将急救车加入到预设的可调度急救车列表中。

进一步地，上述系统还包括：

记录模块，用于按照更新时间的时间顺序，将最新的第一浓度值、计时时长和/或第二浓度值记录到消毒状态列表中。

上述的急救车参数的处理系统可实施上述方法实施例的急救车参数的处理方法。上述方法实施例中的可选项也适用于本实施例，这里不再详述。本申请实施例的其余内容可参照上述方法实施例的内容，在本实施例中，不再进行赘述。

图4为本申请一实施例提供的计算机设备的结构示意图。如图4所示，该实施例的计算机设备4包括：至少一个处理器40(图4中仅示出一个)处理器、存储器41以及存储在所述存储器41中并可在所述至少一个处理器40上运行的计算机程序42，所述处理器40执行所述计算机程序42时实现上述任意方法实施例中的步骤。

所述计算机设备4可以是智能手机、平板电脑、桌上型计算机、超级计算机、个人数字助理、物理服务器等计算设备。该计算机设备可包括但不仅限于处理器40、存储器41。本领域技术人员可以理解，图4仅仅是计算机设备4的举例，并不构成对计算机设备4的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如还可以包括输入输出设备、网络接入设备等。

所称处理器40可以是中央处理单元(Central Processing Unit，CPU)，该处理器40还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

所述存储器41在一些实施例中可以是所述计算机设备4的内部存储单元，例如计算机设备4的硬盘或内存。所述存储器41在另一些实施例中也可以是所述计算机设备4的外部存储设备，例如所述计算机设备4上配备的插接式硬盘，智能存储卡(Smart Media Card,SMC)，安全数字(Secure Digital,SD)卡，闪存卡(Flash Card)等。进一步地，所述存储器41还可以既包括所述计算机设备4的内部存储单元也包括外部存储设备。所述存储器41用于存储操作系统、应用程序、引导装载程序(BootLoader)、数据以及其他程序等，例如所述计算机程序的程序代码等。所述存储器41还可以用于暂时地存储已经输出或者将要输出的数据。

另外，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述任意方法实施例中的步骤。

本申请实施例提供了一种计算机程序产品，当计算机程序产品在计算机设备上运行时，使得计算机设备执行时实现可实现上述各个方法实施例中的步骤。

在本申请所提供的几个实施例中，应该理解到，所揭露的系统和方法，也可以通过其它的方式实现。以上所描述的系统实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

以上所述，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应所述以权利要求的保护范围为准。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (8)

1.一种急救车参数的处理方法，其特征在于，包括：

实时监测急救车车内药品的第一浓度值，并实时更新所述急救车的消毒状态列表；

若所述第一浓度值达到第一预设值，则开始计时，得到计时时长；

若所述计时时长达到预设时长，则控制所述急救车的车门和车窗开启，并实时监测所述急救车车内所述药品的第二浓度值；

若所述第二浓度值小于第二预设值，则将所述急救车加入到预设的可调度急救车列表中；

其中，所述若所述第二浓度值小于第二预设值，则将所述急救车加入到预设的可调度急救车列表中，包括：

若所述第二浓度值小于第二预设值，则检测所述第二浓度值达到所述第二预设值时的持续时长；

若所述持续时长大于预设持续时长，则将所述急救车加入到预设的可调度急救车列表中。

2.根据权利要求1所述的急救车参数的处理方法，其特征在于，所述实时监测急救车车内药品的第一浓度值，并实时更新所述急救车的消毒状态列表之前，还包括：

获取所述急救车的急救车参数的初始值，所述急救车参数包括所述急救车的车牌号、消毒开始时间、消毒结束时间、消毒状态、药品浓度值、计时时长、消毒人员和/或消毒类型；

根据预设的急救车参数，生成所述消毒状态列表。

3.根据权利要求1所述的急救车参数的处理方法，其特征在于，所述若所述第一浓度值达到第一预设值，则开始计时，得到计时时长之前，还包括：

识别所述药品对应的药品类型；

基于所述药品类型与标准值的预设对应关系表，确定所述标准值，所述标准值包括所述第一预设值、所述预设时长和/或所述第二预设值。

4.根据权利要求1所述的急救车参数的处理方法，其特征在于，所述若所述计时时长达到预设时长，则控制所述急救车的车门和车窗开启，并实时监测所述急救车车内所述药品的第二浓度值之前，还包括：

检测是否接收到所述急救车的车门和/或车窗的开启指令；

若接收到所述开启指令，则播放警报语音信息，所述警报语音信息用于提示用户是否确认开启所述车门和/或所述车窗；

在所述警报语音信息播放结束后的预设时间段内，再次检测是否接收到所述急救车的车门和/或车窗的开启指令；

若再次接收到所述开启，则开启所述车门和/或所述车窗。

5.根据权利要求1所述的急救车参数的处理方法，其特征在于，所述实时更新所述急救车的消毒状态列表，包括：

按照更新时间的时间顺序，将最新的所述第一浓度值、计时时长和/或第二浓度值记录到所述消毒状态列表中。

6.一种急救车参数的处理系统，其特征在于，包括：

监测模块，用于实时监测急救车车内药品的第一浓度值，并实时更新所述急救车的消毒状态列表；

计时模块，用于若所述第一浓度值达到第一预设值，则开始计时，得到计时时长；

控制模块，用于若所述计时时长达到预设时长，则控制所述急救车的车门和车窗开启，并实时监测所述急救车车内所述药品的第二浓度值；

加入模块，用于若所述第二浓度值小于第二预设值，则将所述急救车加入到预设的可调度急救车列表中；

其中，所述加入模块，包括：

检测单元，用于若所述第二浓度值小于第二预设值，则检测所述第二浓度值达到所述第二预设值时的持续时长；

加入单元，用于若所述持续时长大于预设持续时长，则将所述急救车加入到预设的可调度急救车列表中。

7.一种急救车，其特征在于，所述急救车上设有计算机设备，所述计算机设备包括存储器及处理器，所述存储器用于存储计算机程序，所述处理器运行所述计算机程序以使所述急救车实现根据权利要求1至5中任一项所述的急救车参数的处理方法。

8.一种计算机可读存储介质，其特征在于，其存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至5中任一项所述的急救车参数的处理方法。

Images