背景介绍
实现意义
框架搭建
详细实现
背景介绍
医护“上门”自古有之，大夫拎着药箱到患者家中进行服务。随着社会的发展，医护上门服务被重新定义及再次细化，我们今天要说的上门护理就是其中一个极其重要的分支。
上门护理，顾名思义就是医护工作人员上门给患者进行护理工作，包含会阴护理、母婴护理、PICC护理等，主要服务对象就是高龄或者行动不便但又需要进行护理服务的患者。
随着互联网医疗的发展，互联网+上门护理服务也越来越普及，现在市面上也有很多专做上门护理业务的公司和APP，比如医护到家。
之前我自己就做过一版完整的上门护理，当时后端架构设计都已经完成，但因为某些原因停滞一直未完成上线，再后来在2020年底我司决定与第三方公司合作，只在我司患者使用的APP上接入上门护理的入口，其他工作均由第三方公司完成，相当于患者端我们只需要提供一个入口，后面的页面全部是第三方的H5页面，护士端我们不涉及。
虽然我自己做的上门护理并未上线，但由于之前做了详细的调研，并且研发那边也已经完成了研发，所以上门护理的构建上是没有问题的，这篇博客也就不算是纸上谈兵了。
实现意义
患者想要获得护理服务，有两种方式，一种是去医院获得护理服务，一种是让护理人员到家里来进行服务，这两种方式的服务场地、收费方式均有不同。
对于高龄或者行动不便的患者来说，上门护理服务大大解决了其不便出门的问题，对于子女来说也是省时省力。对于生活水平较高，宁愿多花点钱也不愿意去医院排队的患者来说，大大提升了护理体验，节省了其在路上及医院奔波的时间。
对于医院来说，开展上门护理业务有助于缓解医院门诊压力，提升医院口碑，提升医院收入。
对于护士来说，最大的好处就是能够提升个人收入，但优势与风险并存，相比于在医院提供服务，上门的风险相对来说会更高一些。
对于公司来说，上门护理是一个能够盈利的重要业务，相比于线上问诊业务统一的定价（统一挂号费）来说，上门护理价格制定更加灵活，可操作性很强，这也是为什么现在有公司上门护理业务作为主营业务能够活下去的原因。
框架搭建
（一）调研
在进行框架搭建之前，首先需要对上门护理进行线上、线下的调研。
线上调研主要调研同类型APP是如何做的，有哪些需要注意的点并对一些重点进行分析。患者端一般我们正常注册认证就能够进行使用了，护士端则需要护士证件，最好找一下现有的资源帮忙认证一下，全流程跑通看一下，这样调研也能够深入一些。我在这里选取的调研对象主要是医护到家，也挑选了其他APP进行简单对比，在这里不再多说。
线下调研主要是对医院护理部进行的调研，业务肯定是基于一家医院上线试运行的，所以一定要结合实际，不能凭想象做一个用不了的东西。如果公司与多家医院都有合作，在有条件的情况下可以多进行一些调研，这样考虑的更周全，做出来的东西也会更通用。线下调研一个是护理部线下的基础流程，另一个是开展这项业务护理部这边的一些意愿和要求，最后就是需要跟护理部谈妥分账对账等。
完成调研之后，最好将自己的调研结果汇总输出一个调研文档，这样比较有利于理清思路，也便于他人查阅。
（二）角色分析
为什么要进行角色分析？进行角色分析的目的是进一步明确上门护理业务的参与者及他们的使命，这样有利于帮助我们抽象出具体的模块。上门护理的角色其实在前面实现意义里面提到过，在这里我们来再进行一次剖析。主要角色分为三个，如下图所示：
① 患者
患者是消费者，是业务的发起者。患者需要下单，并在护士上门之后与护士共同完成订单。
② 护士
护士是服务提供者，是业务的完成者。护士在接了患者的订单后，
③ 平台/医院
护理业务的管理者，可以不参与具体订单执行，但需要管理护理项目、监督护理订单。
在对角色分析完之后，我们对需要做哪些端、哪些模块、大体流程心里都有了一个概念和预期，这个时候可以简单画一个流程图来说明一下大致业务走向。
（三）确立产品的实现端、实现方式
根据上面的调研结果、角色分析，再结合我司的具体情况，明确下来需要实现的端和每个端以什么方式来进行实现。因为我们主要是做互联网医院的，涉及到的业务比较多，所以像上门护理这种可以独立成一个APP的业务在我们的APP里也只是作为一个比较大的功能来做的。
患者使用患者端APP实现；护士使用医护端APP实现；
医院和平台的管理主要使用web管理平台实现，考虑到医院工作人员平时在工作当中可能不方便使用电脑，所以将审核这一块放在了小程序上，方便医院工作人员操作。实际上我们给医院运营人员的许多功能都是放在了小程序上，就是为了方便运营人员在医院能够使用手机随时随地的为患者解决问题。
（四）各个端基础模块及流程搭建
在这一步中，可以使用框图，也可以使用思维导图来列出来。
① 患者端
患者端主要为两个大的模块，一个是患者用来下上门护理订单的模块，一个是下单后订单的管理模块。
② 护士端
护士端主要分为三个模块，护士擅长模块、接单模块和个人订单模块。护士擅长模块是智能推荐的基础。接单模块是护士自主在订单池里面去进行接单，而个人订单模块则分为两个部分，一部分是被指定需要处理的订单，另一部分是自主接的需要处理的订单。
③ 管理端
管理端根据实际情况决定以什么形态呈现，比如在这里我们计划的是小程序和管理平台都会做，但是最终结合工作量和实际使用效果进行评估，将订单审核模块和订单管理模块放在了小程序上实现，护理项目管理模块和业务流程参数模块则放在了管理平台（web）上实现。
（五）全流程详细梳理
实际上，在进行第三步和第四步之前，我们的脑子里面已经大体勾勒一个大致流程了，要不然也不能梳理出第三步和第四步的东西出来，只不过第三步跟第四步走完之后，上门护理的全流程更清晰了，现在也能够将其详细的梳理出来了。
一般在此时我会使用泳道图来进行梳理，明确每个角色、每个端需要做的事情和整体流程是如何进行串联的。
在这里贴出图的一部分进行演示说明。详细的流程就不在此进行说明了，有兴趣的同学可以根据前面列出的东西自己梳理出来一个详细流程，这样有助于理解，印象也会更加深刻。
详细实现
前面我们已经将上门护理业务整个进行了一遍梳理，接下来就是根据整理出来的流程进行实现。在这一部分，我会贴出一些原型截图，也会对我觉得需要注意的地方进行说明。接下来我们按照端来挨个讲解。
（一）患者端
① 功能入口
功能入口一般放在APP首页，同时也会根据业务需要放在其他业务里面进行导流。
在这里给一个建议，首页功能区可以做成可配置的，同时可以加上黑白名单等逻辑，这样方便上新功能的时候进行内测，也比较有利于进行后期维护。
② 服务条款
服务条款可以放在点击功能入口之后的第一个页面，也可以放在下单的那个页面上。
③ 护理类别、护理项目
每一个护理类别下面都会有一些护理项目，比如母婴护理类别下面会包含 保胎针护理、会阴护理、新生儿护理等。
每一个护理项目包含显示图标、显示名称、价格、服务说明、温馨提示等关键因素。
护理类别、护理项目包含的所有关键因素在管理端的护理项目管理里面均可以进行配置。
④ 提交项目、选择服务时间
如果规则为一次只能选择一个护理项目，那么在护理项目详情里面直接点击提交即可，提交后开始选择上门服务的时间。一次只能选择一个护理项目相对来说处理逻辑比较简单，但为了满足患者一次下单实现多项护理的需求，我们引入了购物车的概念。
购物车的好处在于，一次有多项护理需求的人只需要进行一次下单，交通费用等都只需要支付一次即可。
但加了购物车之后的复杂之处在于，首先是服务费用怎么收取（收一项还是收多项），其次是护理时间怎么决定（每个护理都有自己的服务时间排班，不同护理服务之间存在差异），最后是怎么派单的问题（每个护士的擅长并不相同，上门护士需要），这些问题都需要考虑清楚才能够做购物车，将购物车里面的东西一次性进行下单。
④ 护理基本资料
在下单之前，需要填写基础的护理资料，以便于订单审核及护士接单。
⑤ 订单状态流转
下单后支付，支付金额包含的收费类别由具体的业务情况决定，支付完成后生成待审核的订单，由于涉及审核流程，所以订单的状态较为复杂，如下图所示：
（二）管理端
小程序：小程序上主要完成订单审核、分配及跟踪工作。
① 审核
护士/管理人员进行订单审核的时候，可以做两个操作：
Ⅰ 接单。接单表示会继续处理该订单
Ⅱ 拒单。拒单标识订单审核失败，该订单将不会被继续处理，患者的订单费用会原路全额进行退回。
② 派单
在接单之后，可以选择将订单派给具体的护士，也可以选择将订单放入订单池，由护士自由进行接单。指定给护士的订单，护士有权进行退单，退单后需要重新进行分配。
③ 订单状态流转
Web管理端：web管理端主要做的是护理项目配置及业务流程参数配置。
① 护理项目配置
在护理类别下面配置护理项目。
② 业务流程参数
字典、业务流程参数等均在管理端进行配置，这里要注意的是，要想业务通用性更高一些，那么能配置的尽量采用配置的方式实现，不要写死，这样将该业务流程应用于不同的客户上去，能够以最小的改动实现客户需要。
（三）护士端
① 功能入口
功能入口同患者端一样，通常放在APP首页的功能区。
② 接单
护士接单分为两种，一种是指派给自己的订单，护士可以选择接单/退单，另一种是订单池里面的订单，护士可以根据自己的实际情况进行接单。
③ 接单池
为了给护士更好的接单体验，可以让护士设置自己的个人擅长，接单池列表就根据护士擅长、距离等要素进行个性化推荐。
④ 上门服务
为了对服务过程完整记录，在服务开始前、服务中、服务后都应当留存一些凭证，文字、图片及位置等信息。
⑤ 完成订单
护士完成订单分为两种情况，一种是所有费用在患者下单时都已经明确计算好了，耗材收费按照一个合理的点进行收费，那么不需要再计算整个过程中是否有多使用耗材的情况，直接完成订单即可。
另一种情况是在患者下单的时候我们只收取了基础耗材费用，具体耗材使用情况根据上门服务后的情况进行结算，这个时候护士需要计算耗材的额外情况，决定是否需要患者补交费用。这种情况建议在患者下单的时候收取一定的押金费用，多退少补会更方便一些。
⑥ 安全问题
医护、患者的安全问题一直都是上门护理业务当中需要重点考虑的，尤其是顺风车事件等为我们敲响了一个警钟，我们可以从以下方面做一些能够保障医护及患者安全的措施。
Ⅰ 为用户购买保险
Ⅱ 支持服务过程中便捷报警
Ⅲ 支持全程进行录音、录像
Ⅳ 支持对订单全程跟踪，服务时间异常的订单自动报警
⑦ 订单状态流转
以下为护士端的订单状态流转：
到这里，上门护理就基本上讲完了，在这个里面，我们讲的还是比较粗糙，只有自己从头到尾的做一遍，才知道里面到底有多少门道，这个业务是我做过的最复杂的业务之一。
写在最后：这个业务成为了我最难忘的项目之一，除了其本身比较庞杂之外，还因为其历程较为坎坷，用现实教会了我：以变化的心态拥抱世界，以乐观的态度看待问题。即使做了这么久的东西没法上线，但我们通过与第三方合作的方式还是解决了这个问题，这就可以了，我们最终还是达成了目标。问题不重要，解决了问题达成了目的才是最重要的！
