📢 大家好，我是 【战神刘玉栋】，有10多年的研发经验，致力于前后端技术栈的知识沉淀和传播。 💗
🌻 近期刚转战 CSDN，会严格把控文章质量，绝不滥竽充数，欢迎多多交流。👍

---

写在前面的话

本篇文章分享一下博主所在公司的动态药房分配的实现方案。
主要是基于 LatentFactor + Redis + ES 实现，由于涉及公司代码要求，内容主要以方案介绍为主，有需要探讨的可以留言。
好，让我们开始。

---

背景技术

医院药房是集管理、技术、经营、服务等于一体的综合性科室，是医院的重要职能部门之一，其管理影响着医院的药品管理水平和服务质量。随着医院管理模式不断改革和优化，在大规模的医院，药房逐渐趋于多元化管理，不再是以前的单点综合大药房。
门诊和住院往往会根据实际需要，配套建设不同的发药药房，不同的门诊或住院科室开药可以方便患者就近取药。同个科室在不同时间或工作日，都有可能动态配套不同发药药房。
传统模式下，医院采取维护药房配置清单，存储在关系型数据库的二维表中，管理不同维度下药房的分配情况。当医生开单时候将会访问药房配置表，动态获取符合要求的药房，并提示患者前往取药。
由于全院医生的开单操作十分频繁，判定分配药房这一逻辑，需要先从关系表加载药房配置表获取数据后，再进行大量的计算规则判断，在高并发情况下，整体接口响应效率较低，严重影响医生的开药效率和患者就医体验。同时，药房配置规则仅仅考虑单维度情况下的规则分配，因此，最终得出的药房结果，可能存在不是最优药房的情况。

---

发明目的

本方案发明的目的是基于ES 和 Redis 的相关技术领域，实现一种动态药房分配模式，最终形成一种高效的、更具科学性的的药房管理方法。
该方案具备如下特点：
1、支持维护多维度药房分配规则，包含但不限于科室、时间段、距离、药品库存等，改变了传统药房分配模式采用的单一因素简单验证方式，使得出的药房结果更加合理化和人性化；
2、利用 ES 和 Redis 等技术带来的快速查询机制，分别存储药房规则配置和药房分配结果，改变了传统药房分配模式采用关系型数据库的单独二维配置表方式带来的性能瓶颈，为高频开单操作下的药房分配逻辑的性能带来显著提升；
3、支持以定时策略对预置规则进行不断校准，排除不合理的因素，使规则制定更具备智能化和合理性等特性；

---

具体方案

本方案是一种基于 LatentFactor + Redis + ES 实现的动态药房分配方法，具体技术方案实现如下。

一、动态药房分配前置准备

1、部署 ES 环境，程序引入 ES 相关依赖，并进行相关配置与功能集成，ES 定义不同维度下的药房分配规则，建立相关结构索引；
2、部署 Redis 环境，程序引入 Redis 相关依赖，并进行相关配置与功能集成，Redis 定义药房规则提取的存储结构；
3、预先维护药房分配规则，包含但不限于如下：不同时间段下药房分配规则、不同科室下的默认药房分配规则、药房与药品库存的对照规则，医院科室与药房距离分布规则等等；
4、将上述维护好的规则，进行加工处理，同步分解各科室所有时间段规则数据，自动往ES的各个索引，写入动态药房基表数据。

---

二、动态药房分配实现逻辑

若采用动态药房分配模式，当产生药品开单时，其具体流程如下：
1、医生在医生工作站进行下医嘱或处方等操作时，相应的后端HIS服务将接收当前科室、时间、药品等信息，从ES的不同规则索引中，快速查找并命中数据，提取出相应的药房初始设定的规则；
2、程序将提取到的规则，按科室、时间段、各项药品库存、距离等不同策略，进行药房分配运算，得出当前入参情况下的最优药房，具体实现步骤如下；
a、根据入参传递的开单科室，从ES中提取出该科室对应的药房列表，列表中的每一个药房配置项，都配置了推荐因子，程序将药房列表根据推荐因子从大到小排列，暂存为临时变量A，利用LatentFactor潜在因子算法的矩阵编排，得到矩阵清单，“药房/科室 - 潜在因子矩阵”；
b、根据入参传递的开单时间段，从ES中提取出该时间段对应的药房列表，列表中的每一个药房配置项，都配置了时间段所属区段类型，包含但不限于班内班外、工作日和非工作日、节假日和特殊时段等元素，程序将结合当前时间段的正确定位，计算出符合要求的药房交集，并同科室步骤，按推荐因子排序，暂存为临时变量B，并得到相应的“药房/时间段 - 潜在因子矩阵”；
c、根据入参传递的药品信息，从ES中提取出所有药品对应的有存放药品的药房列表，针对列表数据取交集，即获得同时满足所有开单药品需要的药房信息，同时结合药品库存表，实时计算出库存最充足的药房，并同科室步骤，进行排序后，暂存为临时变量C,并得到相应的“药房/药品 - 潜在因子矩阵”；
d、根据入参传递的开单科室的楼层位置，利用定位服务Api，计算出和院内所有药房的实际距离，按距离大小进行排列，距离小的优先，排列后暂存为临时变量D,并得到相应的“药房/位置 - 潜在因子矩阵”；
e、针对上述规则计算得到的潜在矩阵列表，利用LatentFactor算法的稀疏矩阵求和，分别计算四个维度的用户期望药房评分矩阵R1-R4，最终汇总形成“用户/药房的总评分矩阵”，最终得到推荐因子从大到小排列的药房列表，逐个进行再次遍历核验，如果其中一个药房满足需求，则选定为最终分配药房，退出循环；
3、将上述规则计算运算得到的药房分配结果，以Key-Value结构存储到Redis中，其Key为入参传入的药品、科室、当前时间等信息，Value为Object类型，其包含药房分配结果、计算因子、计算耗时、推荐指数、有效利用次数等属性；当下次产生开单操作时，会优先从Redis中尝试查找结果数据。若匹配后，将根据相关Value属性，判定是否采用该结果，若采用则不需要再重复上述的ES提取以及规则运算逻辑。
4、同时将上述计算得到的药房分配结果，存储到开单的相关数据表中，同时返回给前端，流程结束，患者可以根据相应药房信息，前往药房取药；
5、动态药房分配系统会定期进行 ES 和 Redis 存储数据进行排查，当从中发现利用率较低、或计算因子较大、或存在互斥冲突的分配规则，及时调整相应的规则数据；

---

三、动态药房分配流程

---

LatentFactor 矩阵因子推导示例

背景：以三个矩阵，入参是科室A、早上、药品A、位置A为例。

---

总结陈词

上文介绍了博主所在公司的《基于 LatentFactor + Redis + ES 实现动态药房分配方法》方案。
💗 后续会逐步分享企业实际开发中的实战经验，有需要交流的可以联系博主。