从“全人肉模式”到“有点智能”，在“两慢病基层用药管理系统”的落地之路上，各种角色都在给你挖坑，而你必须逐一踩过去才能成功。
其他
钱霁新专栏 | “两慢病基层用药管理系统”是如何落地的？
（1）产品背景：基层医院的两慢病目录无法满足部分患者的用药需求，导致本应该稳定在社区卫生服务站（也即“村站”）配药的这部分患者被迫去大医院排队配药。
（2）一句话需求：通过数据赋能，让这些患者能够在基层医院配到他们需要长期去大医院配的药。
（3）配套政策：对长期在外配药的两慢病患者，在社区卫生服务站登记后，允许扩展基层用药目录，将他们所需药物纳入采购，保证专人专用。药品不局限于两慢病相关，只要符合患者长期用药需求的，均可纳入。
（4）已具备的条件：本地区所有医疗数据已经抽取并汇聚。
有政策有数据，需求目的也很清晰，看起来是不是挺简单的一个事？其实不然，且看如何拆解：
1. 识别角色
这里服务的对象是患者（C端），提供服务的是基层社区卫生服务站的家庭医生（D端），由于基层卫生体系是“社区卫生服务中心-社区卫生服务站”的架构，因此承担药品管理进销存任务的是中心药库（也是D端）。
2. 拆解角色任务
患者做什么：签约登记→下次社区卫生服务站配药。
医生做什么：签约登记患者信息→确认患者长期用药信息→维护进系统→药物到站后，下次给患者配药。
药库做什么：确认要进多少药→进药→入库→送到社区卫生服务站→下一轮进药（循环）。
系统做什么：计算什么时候该进什么药了、药到了提醒患者取药。
不懂医疗的产品经理大概也能画出以上这些内容，然而下面的工作才是核心。
场景拆解
1. 如何找到这些在大医院配药的患者？
如前文所述，整个区域的医疗健康数据已经有了，那么可以定义这些患者的标签：（1）高血压、糖尿病等慢病患者；（2）稳定规律在大医院配药。
再细化一层筛查方法：如果通过“诊断”去找，会发现两慢病相关诊断非常的多，且每家医院还扩展了自己的编码，其中还有一些高危重症并不符合“稳定规律”的用药特点，因此，从诊断入手并不是一个好的办法。
但两慢病常用药品是可以聚类的，通过对药品数据的治理聚类，就可以得到一个用药合集。然后定义“稳定规律”这个词，可认为在用药合集内的相同药品，在2个用药周期内连续使用的，就可以算是规律用药了。由于大医院不具备长处方开立条件，因此最长配药周期为1个月。所以我们在最终具体执行时，将任务定义为寻找60天内在大医院配过用药合集里药物的患者，通过建立数据模型，很快就可以找到符合条件的人群，再通过基层卫生体系的网格地址，将这些患者定位到所在社区，形成“待服务人员清单”，然后通过短信或者C端站内信的方式触达C端在线签约，也可以让社区卫生服务站的家庭医生看到名单后，通过电话联系患者来签约。
其实，这个模型还是简单处理了，没有考虑到在基层配两慢病用药，但在大医院配其他长期用药的患者。不过出于试点的考虑，我们首先满足那些在大医院长期配两慢病药品的患者。
2. 签约场景衍生的功能需求
签约有2条路径：患者自主在线签约、家庭医生通知后现场签约。但从筛查出的人员清单来看，这一人群的年龄平均在65岁以上，对智能手机的使用普遍存在障碍。再考虑到试点阶段先由医生选择部分患者加入的方式会更为稳妥，因此我们决定优先启用家庭医生电话通知触达、患者现场签约的方式进行。
当患者接到通知并抵达社区服务站后，家庭医生需要当面核对其长期服用的药品，这时医生需要能够看到患者在区域内所有机构的配药信息，因此需要系统提供“用药记录查询”。
由于基层存在“一人参保、全家配药”的情况，此时需要考虑防止有人钻政策漏洞，确保登记的是患者本人使用的药品；同时，如果患者此前是在药店、区域外医院配药，系统无法通过数据获取配药记录，所以通知签约时都让患者带上了药盒，如果在区域外配药的还需要带上能够证明是自己使用药品的发票、病历等信息，这些纸质信息将用于拍照上传备案。因此，又产生了“拍照上传用药照片”的功能需求。
医生需要在系统中登记患者的常用药品，包含药品的通用名（商品名）、厂家、规格、用法、用量、单次配药量等信息，并且通过以上信息计算出患者的用药天数，从而判断什么时候应该进药。登记完患者就可以回家，坐等下次到社区服务站配药了。“开药”这个动作属于在HIS中的操作，“两慢病基层用药管理系统”并不需要涉及。
3. 药库备药场景
当社区卫生服务站登记完患者的用药信息后，社区卫生服务中心药库首先要了解到底需要哪些药，哪些是药库本来就有的，哪些是需要额外进货的。因此，我们需要将药品目录区分为“中心目录”和“增补目录”，并且在进药的时候也要区分相关药品。中心目录的药品，药库可以根据站点实际库存进行参考调整；增补目录的药品就是专人专用了，入库后全部拨给对应的社区卫生服务站即可。
至于“什么时间进药”，通过和药库沟通，一开始我们比较理想地设计了一周一次：周一拉清单并发给进货商，大约周三能到货，最晚周四就能送达社区卫生服务站，通知患者取药的短信时间，我们也默认设置了周四的上午10点。
至于“什么时候让药品进入待备药列表”，考虑到患者一般会在药品快吃完的5天前左右来配药（来早了医生也不给配，因为医保会扣款），加上备药周期4天，我们最初设置了当患者上次配药后用药天数<10天时，药品进入备药单。当然这个设置在后面落地过程中也经历了很大的变化。
功能设计
有了场景拆解，基本上拆解出了功能清单，功能菜单也就自然浮出水面。
患者管理：分为待签约人员、已签约人员，还有个异常场景的退出人员。其中待签约人员可以根据社区卫生服务站为单位，导出Excel表格，方便家庭医生打电话联系患者。
备药管理：分为未备药列表、已备药列表，其中已备药列表需要固化并能够导出Excel，区分中心目录药品、增补目录药品、患者备药明细。
药品管理：提供运行目录，区分中心目录和增补目录。我们还给操作者贴心设计了点击药品能够查看有多少人在用的功能，落地后也受到了操作医生的喜爱。
这里交互操作最多的是“如何为已签约人员添加常用药品”。让医生一个个敲键盘输入，显然是不现实的。既然主要是在上级医院配的药，我们设计了从用药记录里选择添加的功能。但由于上级医院的药品字典和基层社区的药品字典是相互独立的，如何识别这个药就是这个药？在考虑了多种方法后，我们最后选择了通过医保代码来识别唯一性。当一个药品从用药记录里被选中、添加到患者用药时，系统通过医保代码对比，确认其是否在社区卫生中心的药品字典中存在？如果存在，则定义为中心目录；如果没有，则定义为增补目录。这些被添加到签约人员用药清单的药品，同时也进入了系统的运行目录。
在调研过程中，中心药库还提出了增补目录需要药库审核、缺药提醒等功能，系统都逐一迭代满足。
看着似乎很和谐，接下来应该进行开发，然后上线试运行了。然而这是理想，实际的情况一言难尽。
曲折的落地之路
在“两慢病基层用药管理系统”的落地之路上，各种角色都在给你挖坑，而你必须逐一踩过去才能成功。
1. 纯手工上线第一个试点
由于前面政策确认花费了不少时间，接到这个任务并确定试点社区卫生服务站上线，只留给我们10天时间。这么短的时间显然是不可能开发出全部功能的（仅产品逻辑确认就花了2天），经过商量后，我们决定优先开发核心的添加药品和备药功能，但评估工期最快也得2周时间，无法赶在试点上线当天发版。于是，我们只能一边拿着Demo给客户演示，另一边产品和项目联合，手工拍照登记现场的药品，然后回去手工导入。
得益于此前处方外流项目的运营经验，在上线当天，我们打印了医院确认过的签约名单，按照核对、签约、登记拍照依次坐好，排起了流水线，俨然一副严阵以待的样子。群众们听闻有如此方便的举措，都带着医保卡和药盒来到现场，其中还有不少不在名单上的人，一问都是人传人带来的。当天我们登记了30多名慢病患者，涉及上百个药品。
回去后，团队对着照片整理了2天的Excel表格，让开发人员把表格导入数据库，通过代码手段实现了服务人员清单和药品清单；然后结合着开发完的备药功能，实现了第一轮的备药。
随后，就出现了一系列的问题：常规HIS的设计是会制作一张药品字典表（记录药品基本信息）和一张患者用药信息表（记录患者的用药信息），中间通过药品ID进行关联；在患者用药信息表里，并不会保存药品字典相关字段。由于开发人员不熟悉医疗行业，在操作中发现：修改药品字典，患者对应的用药信息并不会跟着修改，进而在备药单生成了2条甚至更多的重复记录。为此，我们重新做了表结构关联设计，但在同步过程中又出现了重复数据和丢数据的情况，纠正这一情况，又花费了大量时间。
不过，等这批药品送到社区卫生服务站，患者第一次在家门口把此前需要到大医院才能配到的药配走时，我们感到所有的付出都是值得的。
2. 后续试点上线
卫健部门给我们紧锣密鼓安排了8个站点的上线任务。好在一周后1.0版本的全功能产品发布了，在第2个试点，我们已经可以使用系统来进行添加患者、药品的操作，整体效率提升明显。
前7个站点都是我们亲自到现场，为每位患者进行添加药品操作。相当于我们亲自使用自己的产品，对自己提出迭代需求，按照一周一个版本的迭代进度，我们逐渐完善了不少功能，并制作了产品手册与快速入门手册。
在第8个站点上线时，我们并没有前往现场，医生通过线上指导完成了5位患者的纳管操作，这代表着产品从原型走向真正落地迈出了最重要的一步。
在8个站点均完成一轮备药后，卫健部门又安排了全区域每街道中心3个站点的上线任务。我们布置了上线任务表，安排5人每人每天负责一个街道中心的培训和上线工作，在一周内完成了所有任务，甚至还创造了1天时间在一个中心上线12个站点的“奇迹”。
随着产品功能的稳定，我们只需要在线上解答社区卫生服务站遇到的问题即可，全区可以自行按照任务倒排的时间表安排上线工作。同时我们也增加了产品运营人员，专门处理客户的问题和反馈，整体的产品落地之路也越走越扎实。
总结
产品的落地之路，看似规划得一路平坦，但在实际过程中往往伴随着艰辛和反复。笔者总结归纳了一些关键步骤，不一定所有场景都适用，供大家参考，欢迎大家批评指正。
产品GTM步骤（点击可查看大图）
政策暖风频吹，临床营养信息化机遇与挑战并存
搭建端到端数字基础架构，英特尔拥抱智能边缘新时代
数据集成与互操作性公司Lyniate并购医疗术语管理公司CareCom
困扰电子病历数据临床研究的三个问题 | 郑西川专栏
寻求“商务合作”，长按二维码可快速与我们取得联系
投稿：gong_chen@HIT180.com
商务合作：(010)82373062
本公众号原创文章，版权归HIT专家网和原作者所有。
未经许可，谢绝转载或以其他形式使用文章内容进行传播。