救护车运维保障系统的制作方法

文档序号:16581153发布日期:2019-01-14 17:59阅读:579来源:国知局
救护车运维保障系统的制作方法

本发明涉及数字化医疗技术领域,特别涉及一种救护车运维保障系统。



背景技术:

救护车行业属于特殊行业,救护车属于特种车辆,需要对通用型载客汽车改装后,并配上医疗急救设备才能交付给医院。征对不同医院,个性化很强,有监护型、半监护型、孕妇型和胸痛型等救护车。

救护车是民生工程,中国是人口大国,老龄化日趋严重,但是各医院的救护车仍然短缺,1天24小时都在运行,表现为需求与供应的矛盾。一但救护车在运送病人中或是在行驶过程中(车上没有病人的情况)遇到交通事故,或是坏了,需要快速维修救护车,以保障医院能快速投放救护车进行急救的能力。如果车上有病人还需要医院快速派新车运输病人。救护车销售商或是医院还需要随时查看救护车维修的状态,跟踪进展。

目前,救护车的运维保障系统只是提供电话预约维修功能,无法满足上述需求。



技术实现要素:

本发明提出一种救护车运维保障系统,解决现有技术的救护车运维保障系统无法满足上述需求的问题。

本发明的一种救护车运维保障系统,包括:中心服务器、维修点客户端、医院客户端和车载客户端,所述中心服务器连接所述维修点客户端、医院客户端和车载客户端,所述中心服务器存储有车辆基本信息、驾驶员信息、医院信息及各区域4s维修点信息;

所述车载客户端用于在车辆运行途中发生故障时,发送包含车上是否有病人的故障信息至中心服务器,所述中心服务器采集车载客户端的gps信息已定位车辆位置,通过定位查询最近的4s维修点,将故障车的车辆基本信息、故障信息及gps信息发送至最近的4s维修点,并将该最近的4s维修点地址发送至车载客户端,同时将车辆信息及gps信息发送至该车所属医院的医院客户端;

所述维修点客户端用于实时将救护车的维修进度上传至中心服务器;

所述医院客户端用于实时查询救护车的维修进度,且在车辆发送故障且车上有病人时,根据gps信息重新安排救护车达到故障地点。

其中,所述车载客户端,包括:

odb连接模块,用于连接车辆的odb接口,获取包括里程、油耗和gps信息,检测车内电子设备的异常信息,采集车辆发生碰撞和翻车的数据;

存储模块,用于存储车辆基本信息,以建立车辆与车载客户端一一对应的绑定关系;

一键呼叫模块,用于在发生故障时一键呼叫与中心服务器连接的坐席,通过语音将车辆基本信息和故障信息传输至所述坐席,用于使坐席将车辆基本信息和故障信息录入中心服务器,所述故障信息包括:所述里程、油耗和gps信息、电子设备的异常信息、车上是否有病人及车辆发生碰撞和翻车的数据。

其中,所述维修点客户端在收到故障车的车辆基本信息及故障信息后,创建维修记录表,所述维修记录表表项包括:保修编号、车牌号、保修时间、司机电话、所属医院、维修状态、处理流程节点及处理人。

其中,所述中心服务器还用于在收到维修进度的更新后,及时将更新后的维修进度推送至医院客户端。

本发明的救护车运维保障系统实现了从故障、选择维修点到维修的一体化服务,故障时能够就近选择维修点,车上有病人也能快速通知所属医院重新派车,而且经销商和医院均可实时监控故障车辆的维修情况。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。

图1为本发明的一种救护车运维保障系统结构示意图。

具体实施方式

下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。

本实施例的一种救护车运维保障系统如图1所示,包括:中心服务器1、维修点客户端3、医院客户端4和车载客户端2,中心服务器1连接维修点客户端3、医院客户端4和车载客户端2。中心服务器1存储有车辆基本信息、驾驶员信息、医院信息及各区域4s维修点信息。其中车辆基本信息包括:车架号、车牌号、类型(如:有监护型、半监护型、孕妇型和胸痛型)和所属医院等,驾驶员信息包括:姓名、联系方式及所属医院,医院信息包括:医院名称和地址,4s维修点信息包括:维修点名称、地址及负责人电话等。中心服务器1将以上信息存储在数据库中,进行数字化管理。

车载客户端2用于在车辆运行途中发生故障时,发送包含车上是否有病人的故障信息至中心服务器1,中心服务器1采集车载客户端2的gps信息已定位车辆位置,通过定位查询最近的4s维修点,将故障车的车辆基本信息、故障信息及gps信息发送至最近的4s维修点,并将该最近的4s维修点地址发送至车载客户端2,可根据故障信息判断出故障的救护车是否能继续行驶,如果车辆能继续行驶则可自行开车到最近的4s维修点,若不能,最近的4s维修点派拖车达到gps信息指定地点。同时将车辆信息及gps信息发送至该车所属医院的医院客户端4。

维修点客户端3用于实时将救护车的维修进度上传至中心服务器1,便于车辆经销商和医院实时查询车辆的维修情况。

医院客户端4用于实时查询救护车的维修进度,且在车辆发送故障且车上有病人时,根据gps信息重新安排救护车达到故障地点。医务人员登录中心服务器1后可以查阅救护车修理的进展,有多少车辆处于维修状态,并查看车辆的gps位置信息,为管理决策提给依据,助力院前单位聚焦核心事务。

维修点客户端3和医院客户端4软件采用b/s架构,公有云计算部署方式,可以使用了阿里云的短信api接口传输信息,车载客户端2采用安卓机的gpsapi接口实现。

本实施例中,车载客户端2,包括:

odb连接模块,用于连接车辆的odb接口,获取包括里程、油耗和gps信息,检测车内电子设备的异常信息,采集车辆发生碰撞和翻车的数据。

存储模块,用于存储车辆基本信息,以建立车辆与车载客户端一一对应的绑定关系。

一键呼叫模块,用于在发生故障时一键呼叫与中心服务器1连接的坐席,通过语音将车辆基本信息和故障信息传输至所述坐席,用于使坐席将车辆基本信息和故障信息录入中心服务器,所述故障信息包括:所述里程、油耗和gps信息、电子设备的异常信息、车上是否有病人及车辆发生碰撞和翻车的数据。

具体地,车载客户端2在软件上以app形式呈现,硬件上采用obd设备插入汽车内obd接口上,obd设备是标准的车况检测物联网设备,设备内有sim卡,设置好系统服务端的公网ip地址,通过api接口系统就能采集到obd数据。obd数据包括里程,油耗,gps定位,并检测车内电子设备的异常情况,车上安装有三轴陀螺仪,能采集到车辆发生碰撞和翻车的数据。把数据关联到销售商对应的车架号内,作为一个子数据库存在。车载安卓屏,安装“救护车保障系统“app,含有车辆设置功能,在设置里绑定好对应救护车的车架号和安桌屏里sim卡的号码。app里含有一键救援电话按钮,当车子发生事故时,救援电话与销售商的售后座席号码连接,并可急时接通电话。

本实施例中,维修点客户端3在收到故障车的车辆基本信息及故障信息后,创建维修记录表,维修记录表表项包括:保修编号、车牌号、保修时间、司机电话、所属医院、维修状态(维修中或维修完成)、处理流程节点及处理人,维修记录以表格的形式便于后期查询。若处理流程节点发生变化时表示维修进度的变化,每发生一次变化将该表项上传至中心服务器1。

本实施例中,中心服务器1还用于在收到维修进度的更新后,及时将更新后的维修进度推送至医院客户端4。避免医院客户端4查询不及时,而导致救护车不够用的问题。

以上所述仅为本发明的较佳实施例,并不用以限制本发明,凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1