上一篇文章基于医院信息化发展比较好的前提下对在线余额退款的功能需求分析及流程设计等做了阐述，但有些医院信息科接口配合度可能没那么好，他们通常对外只提供标准的余额查询接口以及余额退款接口，这种情况余额退款的功能该怎么设计呢？

巧妇难为无米之炊，作为产品经理要学会绝地求生，找到适合当前环境的最佳解决方案。

继之前我手头完成了一家医院的余额退款功能后，领导又给我另一家医院的余额退款需求让我来接。我们一开始都以为他们的打法应该是一样的，原型交互什么的都可以直接copy。但当我把需求流程梳理出来后，项目经理对我说这家医院提供的只有余额查询及余额退款的标准接口，其他的能力都是小程序自己来处理，另外有一点不一样的是，这家医院的统一支付平台是用我们自研的那一套。

也就是说，医院只提供患者的余额查询及余额退款接口，像多少钱可退、发起申请退款以及余额退款状态等都由小程序自己来设计。这个时候就很考验产品经理如何利用有限的资源将功能设计出来并且还可用了。

下面我将从需求分析、业务流程分析、功能及原型设计以及总结说明来展开对这个需求的拆解。

一、需求分析

在线退款的旨在解决用户线下退款难跑腿多的问题，只要患者就诊完后就能离院在手机便可操作金额退款。

上一篇文章也说过，关于余额退款涉及的角色有小程序或微信公众号、医院HIS系统、统一支付平台。在这家医院中，我们同时承担小程序、统一支付平台角色。

从业务角度考虑，余额退款中的余额有两类：

第一类是通过小程序在线充值的预交金剩余的金额，因为是微信充值这部分钱可以原路退回；

第二类是通过线下自助机或窗口充值的预交金剩余的金额，该部分钱不能原路退回需要线下打款。

这家医院目前提出的是原路退回的业务，银行卡打款退款的场景在本文不做考虑。

所以为了满足这一目标，我们要做的是功能要满足以下几点：

1）患者的账户余额是正确的，不能与实际不符，这个可以通过调his余额查询接口解决，只要医院提供的接口不出错，小程序就不会出错；

2）患者要知道自己有多少余额可退；

3）患者可以通过小程序直接线上操作退款申请，提交后等待金额原路退回至微信账户。

4）患者可以看到自己提交的退款申请记录以及退款状态。

我在设计这个功能的时候，是结合患者的充值记录一起去设计的，也即通过查询到的余额与患者所有的充值记录金额进行对比并倒叙分配，患者可以基于看到的充值记录进行操作退款。

故涉及的功能点如下：

• 患者及患者家属移动端需求
• 支持查询当前患者的院内账户余额
• 支持查看当前患者的可退余额
• 支持患者在已经分配到的充值记录上提交申请退款
• 支持查看患者提交的退款申请记录及退款状态
• 对账平台支持查看该笔交易记录以及成功与否，如果异常支持特殊处理，保证用户最终能收到钱款

二、业务流程分析

针对余额退款的业务流程设计如下：

1）用户点击余额退款申请入口（小程序或公众号菜单或院内展码），小程序将请求院内his系统余额查询接口，接口返回账户总余额；

2）小程序查到账户总余额后，再与该患者的线上充值记录的金额一一对比并分配可退余额（倒叙）直到分配完并将分配到的充值记录显示在余额退款的页面，支持患者在每条充值记录上点击申请退款；

3）点击申请退款时先请求his退款接口进行业务退款（扣除院内的账户余额），his会将退款结果回调给小程序，当小程序获取到退款成功后再调统一支付平台的退款接口将金额原路退回。

4）用户点击查询退款明细查看退款记录及状态。

三、功能及原型设计

1. 账户余额查询及可退余额计算

用户进入余额退款页面后，需要通过接口查询到账户余额，小程序需要将账户余额和充值记录倒叙对比并全额分配，用户可查看可退的充值记录并点击申请退款。可退余额计算规则为：

账户余额按充值记录倒叙的方式进行分配可退余额，每条充值记录的可退余额最大不能超过充值金额，可退金额为0的充值记录不展示，可退金额大于0的充值记录，可支持退款操作，退款后金额原路退回，如：

1）当查询到账户余额110元，线上充值记录最近的两条金额总和大于110，则最近的一条充值记录可退余额为70，第二条充值记录的退款余额为110-70=40元；

2）当查询到账户余额为100元，线上充值记录金额总和小于100，则倒叙分配所有充值记录全部满额分配，还有剩下的账户余额为线上不可退金额。

2. 申请退款提交及状态显示

点击申请退款后，显示的退款详情页面的状态读取HIS接口回调的状态（没有去统一支付平台平台查），分为三种情况：

1）回调结果为退款成功，his的账户余额扣款成功，但钱不一定立即到账，页面显示退款成功，预计到款时间2-3天；

2）回调结果为退款失败，小程序不与统一支付平台请求，流程结束，his账户不发生扣款，支持重新操作退款申请；

3）回调结果未知（异常），小程序不与统一支付平台请求，流程结束，页面支持刷新重新请求接口（是否扣款未知）。

四、总结说明

设计同一个功能，可能会有不一样的实现方法，要根据医院提供的接口来考量。产品经理在需求调研的时候可以先设计一套最省事儿的方案给到医院问医院是否能配合调整接口，如果不行我们再用B方案。