急救场景下的志愿者调度与AED就近匹配

急救场景下的志愿者调度与AED就近匹配——120急救通的设计思路一、问题的起点黄金4分钟心脏骤停后每延迟1分钟存活率下降7%-10%。医学上公认的黄金抢救时间是4分钟。而现实是城市中120救护车平均到达时间超过10分钟郊区更长。专业急救资源有限但大多数情况下患者身边就有人——路人、邻居、同事。他们缺的不是善意而是两样东西知道该怎么做知识手边有能用的设备AED这就是120急救通想解决的问题当急救事件发生时如何用最快的速度把最近的志愿者和最近的AED送到患者身边。核心就一个字位置。二、整体思路系统有三个关键角色求助者拨打120或通过App一键呼救的人调度员急救中心的调度员负责接警和指挥志愿者经过培训的急救志愿者随时响应附近求助流程很直接求助者报警 → 调度员接警 → 系统推荐附近志愿者AED → 调度员确认下发 → 志愿者出发施救调度员是中枢系统是辅助。我们不追求全自动调度而是人机协同——系统给出推荐方案调度员做最终决定。三、志愿者调度基于地理位置的实时匹配3.1 志愿者位置怎么来志愿者打开App后系统定期上报位置信息。这里有一个平衡上报太频繁耗电太频繁不准。我们的设想是状态上报频率说明后台待命每5分钟低功耗有附近报警每30秒系统触发高频模式接受任务后每10秒实时追踪直到到达现场定位方式采用GPS为主、Wi-Fi和基站辅助。室内场景下GPS信号差Wi-Fi指纹定位可以补位但精度会下降到10-30米。这在急救场景下可以接受——调度员电话沟通时志愿者说我在XX小区门口比精确坐标更实用。3.2 附近的人怎么查求助者位置确定后系统需要快速找到他周围的在线志愿者。技术选型上Redis GEO是最直接的方案。Redis的GEOADD存储位置GEORADIUS或GEOSEARCH查询指定半径内的点。# 存储志愿者位置 GEOADD volunteers 116.397128 39.916527 volunteer_001 # 查询求助者位置3km范围内的在线志愿者按距离排序 GEOSEARCH volunteers FROMMEMBER patient_001 BYRADIUS 3 km ASC COUNT 10为什么不用PostGIS可以但在附近的人这种高频、低复杂度的查询场景下Redis GEO的响应速度更快亚毫秒级足以应对。PostGIS更适合复杂的地理空间分析比如路径规划、区域划分这里用不到。3.3 搜索半径怎么定这是关键。半径太小可能圈不到志愿者半径太大推荐列表里出现5km外的人调度员无法判断。设想方案是自适应半径基础半径3km根据志愿者密度动态调整如果3km内志愿者数量 3自动扩大到5km上限10km。超过10km志愿者步行/骑车赶过去的意义就不大了不如等救护车密度数据可以基于历史统计得出比如按城市区域维护一张志愿者密度表定期更新。3.4 调度员工作台调度员的屏幕上是一张地图同时展示三类标记 求助者位置固定 在线志愿者实时移动 AED设备点位静态数据状态报警进来后系统自动推荐方案比如建议派遣志愿者 张XX距患者320m预计3分钟到达附近有AED距志愿者150m距患者200m建议顺路取用。调度员看到推荐点击确认任务下发到志愿者手机。整个过程控制在30秒以内。四、AED就近匹配一个三节点路径问题4.1 AED数据从哪来AED自动体外除颤器在公共场所的部署越来越广泛——机场、地铁、商场、学校、社区。但问题是这些AED的位置数据分散在各个管理方手里没有一个统一的实时数据库。我们的设想接入各地AED管理平台的开放数据如果有众包标注志愿者发现新安装的AED可以拍照上传位置与当地红十字会、卫健委合作获取官方数据数据字段包括经纬度、所在地址描述、放置位置如XX商场一楼服务台旁、状态可用/维修中/已取走。4.2 匹配策略有了志愿者位置和AED位置核心问题变成如何让志愿者最快拿到AED并到达患者身边这不是简单的找最近的AED。因为我们要优化的不是志愿者到AED的距离或AED到患者的距离而是**志愿者→AED→患者的总时间**。举个例子患者 P 在位置 (0,0) 志愿者 A 在 (300, 0)距患者300m附近没有AED 志愿者 B 在 (500, 200)距患者538m但距他50m处有一台AED AED 在 (500, 250)如果只看谁离患者近选A。但A没有AED空手赶到现场意义有限。选B的话B先走50m拿到AED再走538m到患者身边总路径588m。在心脏骤停场景下有AED的588m比没AED的300m价值大得多。所以匹配策略分两种策略一先找志愿者再提示AED找到最近的志愿者查这个志愿者附近有没有AED如果有任务里附带请顺路取AED如果没有志愿者空手前往优点逻辑简单调度员容易理解缺点可能错过更优方案比如稍远一点但能拿到AED的志愿者策略二综合评分推荐对每个候选志愿者计算一个综合得分得分 α × (1/志愿者到患者距离) β × (1/志愿者到最近AED的距离) γ × (是否有急救资质)α、β、γ是权重可以根据实际情况调整。比如心脏骤停场景下AED权重拉高创伤场景下距离权重拉高。系统按得分排序推荐Top 3给调度员选择。策略二更合理但实现更复杂。我们的设想是先上策略一验证跑通后再迭代到策略二。4.3 AED状态同步AED被志愿者取走后状态要立即从可用变为已取走避免第二个志愿者也被指引到同一台AED。这看起来简单但在实际操作中有延迟志愿者扫码取走AED → App上报状态 → 服务端更新 → 其他志愿者看到这个链路正常情况下几秒钟但网络不好的时候可能十几秒我们的设想是状态更新走WebSocket长连接取AED时本地先标记同时异步上报。其他志愿者端在查询时如果发现某台AED在最近几分钟内被查过/被指派过加一个可能不可用的提示。五、几个还没有答案的问题写到这里必须承认有些问题我们还没想清楚志愿者意愿接了任务不来怎么办志愿者可能犹豫、害怕、临时有事。这不是技术问题是运营问题。一些平台的做法是响应率高的志愿者获得更高权重长期不响应的逐渐降低优先级。AED数据维护谁来保证点位准确、状态实时AED今天在明天可能被挪走、报修、丢失。没有持续的维护机制数据很快就会失真。法律风险《民法典》第184条好人法规定因自愿实施紧急救助行为造成受助人损害的救助人不承担民事责任。但在实际操作中志愿者施救万一出了问题平台是否需要承担连带责任这需要法律团队的参与。农村场景志愿者密度低、AED几乎没有。在这种场景下系统能做的很有限。也许更好的方式是培训村里的卫生员而不是依赖志愿者调度。六、回到本质急救调度系统的本质不是什么高深的技术问题而是用位置换时间。Redis GEO查附近的人几毫秒路径规划算最优路线几十毫秒。技术上没有任何难点。真正的难点在技术之外志愿者生态怎么建AED数据怎么维护调度员的工作流怎么设计才不增加负担这些问题不解决系统就是个空壳。技术人容易犯的错是拿着方案找问题觉得技术很酷但忽视了业务的真实阻力。这个项目还在设想阶段我们也在不断修正自己的思路。先跑起来再跑快。