医疗陪护预约小程序系统 成都小火数智公司
医疗陪护预约小程序系统 成都小火数智公司 我们在做一个医疗陪护预约小程序的时候,客户找过来的时候说他那边陪护工的管理太乱了。医院里病人多陪护需求大,家属临时找人要么靠熟人介绍要么去病房门口蹲守。陪护工的资质没人审核,价格也不透明。有的陪护工接了单临时爽约,家属在手术室外面干着急。他们想通过一个系统把陪护工的信息登记清楚,把预约流程线上化。我们公司花了几天时间
医疗陪护预约小程序系统 成都小火数智公司
我们在做一个医疗陪护预约小程序的时候,客户找过来的时候说他那边陪护工的管理太乱了。医院里病人多陪护需求大,家属临时找人要么靠熟人介绍要么去病房门口蹲守。陪护工的资质没人审核,价格也不透明。有的陪护工接了单临时爽约,家属在手术室外面干着急。他们想通过一个系统把陪护工的信息登记清楚,把预约流程线上化。我们公司花了几天时间跟他们沟通业务流程,把陪护工的实名认证资格审核以及排班机制都理顺了。
这个项目我们做的是微信小程序,陪护工端和家属端分开。家属那边打开就能看到附近可预约的陪护工名单,每个人有照片有资质证书扫描件还有服务评分。陪护工端能看到自己的排班表,什么时候有空档哪些时间段已经接单。系统还设计了签到签退功能,陪护工到医院后扫码打卡,家属那边能看到陪护工已经到岗。还有满意度评价环节,每个订单完成后家属可以打分写评语。这些数据积累起来,陪护工的信用评级就出来了。
我们母公司做过很多类似的生活服务类项目。比如我们母公司开发过的上门服务预约师傅匹配H5,那个项目也是类似的逻辑但场景更复杂。那个H5对接了几百个维修师傅,用户下单后系统根据距离和评价自动匹配最近的师傅。还有我们母公司做的医疗陪护预约服务H5,那个项目里我们处理了陪护工时薪计算和加班费的逻辑,还有陪护工和病人之间的适配规则。像有些病人需要方言陪护,有些需要懂特定疾病的护理知识,我们都做成了筛选条件。这些经验直接用到医疗陪护预约小程序里,陪护工和家属的匹配逻辑两天就写完了。
医疗陪护预约小程序里有一些细节我们反复改过。比如陪护工的资质审核环节,我们开始只设计成上传照片。但客户说有的陪护工拿别人的证来认证。后来我们改成活体检测加上身份证OCR识别,现在打开小程序陪护工要对着摄像头眨眨眼摇摇头。系统自动比对身份证照片和实时人脸。家属下单之前能看到认证状态,已通过人脸核验的字样会显示在陪护工头像旁边。还有订单退款机制,陪护工爽约的话系统自动触发全额退款。家属那边退款流程全程自助,不需要联系客服人工操作。
我们在技术选型上用过Java搭配Vue做管理后台,小程序前端用的uni-app。这套方案在我们母公司项目里跑了五六年了。像我们母公司开发的电工培训接单小程序也是用同样的技术栈,那个小程序里用户预约电工上门服务,师傅端接单签到和评价打分。医疗陪护预约的订单管理系统可以直接复用电工培训那边的订单流转逻辑,只需要在陪护工资质校验环节多加几层校验。代码复用了大概百分之三十,剩下的改动主要集中在陪护工排班算法和医院病房定位功能上。
整个开发周期从需求确认到上线花了三周。第一周梳理陪护工注册流程和家属端的预约界面。第二周把签到签退和评价功能做出来,同时连通支付接口。第三周我们做了两轮内测,客户那边找了五十个陪护工和一百个家属做压力测试。测试过程中发现陪护工同时接多个订单的冲突问题,我们紧急加了时间戳检测防止时间重叠。上线首周跑了四百多单,系统没有出过崩溃情况。家属反馈最大的感受是陪护工迟到的情况变少了,因为签到打卡记录会同步给医院护理部。
我们公司在做这类系统的时候跟其他开发公司不太一样的地方在于,我们不会把项目转包给第三方团队。我们自己的开发设计师测试人员都在成都总部办公。医疗陪护预约小程序的UI设计改了三版,第一版客户觉得色彩太冷不像医疗场景,第二版加了暖色调的住院部图标,第三版把字号调大了方便老年人操作。测试人员蹲在医院陪护中心现场测试了七天,发现护士站那边的WiFi信号太弱加载地图定位会卡。我们临时加了缓存机制,陪护工签到时哪怕网络差也能离线记录GPS坐标,等网络恢复再上传。
客户那边原本预算有限想做个极简版本,后来看到我们母公司案例里那些生活服务类的功能设计,主动要求增加陪护工保险购买入口和电子合同签署功能。保险入口嵌在陪护工注册流程里,陪护工可以按天购买意外险。电子合同用的是小程序内的标准模板,家属和陪护工在线签署具有法律效力。这些功能的开发时间只多了两天,因为保险接口和电子签章服务我们母公司之前在其他项目里已经对接过。像我们母公司开发的农资物资B2B供应小程序里就有类似的合同签署模块,那个项目里供方和需方签的采购合同还能加盖电子公章。
医疗陪护预约小程序上线三个月后,客户发来数据说明反馈。陪护工注册人数达到三百人,家属端累计使用次数超过五千次。订单取消率从之前的百分之三十降到了百分之八。陪护工接单后被动放鸽子的情况几乎绝迹。客户说之前做过的那些管理系统和预约平台项目确实靠谱。我们母公司做过连锁瑜伽馆小程序和瑜伽课程预约学员分销小程序,那些项目里教练排课和会员预约的逻辑跟陪护预约有相似之处。还有医疗陪护预约服务H5的研发经验直接带动了这个小程序的质量提升。客户后来想把系统推广到周边两家医院,又找我们做了多院区版本。多院区版本里陪护工可以跨院区接单,但需要单独申请各院区的上岗资格。我们帮他们配置了按院区显示陪护工列表的规则,每个院区看到的陪护工名单不一样。
我们公司做软件定制开发有自己的流程,需求讨论阶段我们就会把原型图做出来。医疗陪护预约小程序的原型图客户看了当场改了两个地方,陪护工列表页的筛选条件从按距离排序改成熟练度排序,订单详情页增加了联系护士站的快捷按钮。开发过程中每完成一个模块我们就会发测试链接给客户,不用等到全部做完才验收。头几天客户反馈陪护工上传资质证书时照片太模糊看不清,我们在上传组件里加了分辨率检测和自动裁剪功能。第二天就更新了版本。这种迭代速度客户比较满意,说之前找的外包公司改个小功能都要排到下个月。我们之所以能快速响应,是因为我们团队就在同一个办公室里改代码,测试合发版都能当天完成。
医疗陪护预约小程序交付的时候我们把源代码和部署文档一起给了客户。代码里变量命名和注释都是用中文写的,客户那边的技术说读起来很轻松。我们提供了两轮操作培训,第一轮教陪护工怎么注册接单和签到,第二轮教医院管理方查看数据统计和导出报表。系统还预留了接口方便以后对接医院内部系统。比如后续可以对接医院HIS系统同步病人信息,或者对接护工管理平台做数据互通。我们母公司做过医院一体机系统的对接,那种场景下设备和系统的串联经验用得上。客户说我再想加个AI陪护方案推荐功能,我们回复说那需要再做一个智能匹配模块,可以根据病人病史和陪护时长推荐陪护工,现有后端框架已经支持扩展。这个功能目前在开发排期中。