互联网慢病管理-软件架构设计.pdfVIP

案例一：互联网慢病管理

某三甲医院提出需求，后来其他三甲医院加入，覆盖医生近500，管理入组患者。

病历（初诊、复诊）

线上问诊（选择医生、预定、派单、图文视频、支付）

随访（量表定制、按科、按病，推送，收集，分析）

会诊（内部会诊、外部会诊）

网上送药（审核、生成订单、自有药自行配送、药店接单药店配送、药店签约管理、快递签

约管理）

机构管理（医院、诊所、科室）

数据分析（患者数据分析、治疗方案分析、用药分析）

————————————————

架构图：

设计特点：启动3个数据库服务器实例，2个程序服务器实例，使用Nginx和zuul

网管技术，既可以提高并发访问的效率也可以提高可靠性，同时需要考虑患者隐

私安全性设计。

功能结构：系统采用BS架构开发的，客户端可采用PC和APP，系统功能：账户

服务、医生服务、订单服务、药店服务、医保服务、支付服务、派单服务。

技术设计：采用Nginx代理可以更好的进行负载均衡；为了更好的实现并发访问

机制采用Zuul技术提，供动态路由，监控，弹性的技术优势；RocketMQ提高了

应用程序的响应效率的同时还保证了应用程序和应用程序之间的顺序消费。

数据库：关系数据可采用Mysql；定义完整规则，对标签特性进行数据挖掘更好

对患者数据分析形成数据画像，协助医生对患者进行合理用药；采用redis数据

库进行缓存提交了系统读取数据的效率。

集成工具：为了高效、高可用的进行系统部署可采用k8s、docker、jenkins工

具。

用例图：主要包含：系统管理员、医生、患者、药店、快递员用例。

类图：账户管理相关类、机构管理相关类、医生问诊相关类、购药相关类、派单

相关类。

风险清单：

互联网慢病管理系统风险清单

序号风险类别风险描述检查结果

1.需求分析需求定义不明确，进一步的定义会扩展需求

2.需求分析阶段客户参与不够

3.添加额外需求

4.需求说明书制定完成后，需求仍会发生变化

5.计划分析计划、资源、产品定义全平客户领导口头指令，并

且不一致

6.计划基于图使用特定的小组成员，而那个特定的小

组成员其实指望不上

7.产品范围扩大，在设计和实现上花费的时间比预期

的多

8.人员风险特定小组成员兼并多个项目，本项目无法及时参与

9.开发人员与管理层关系不佳，导致决策缓慢

10.缺乏激励措施，士气低下，降低生产能力

11.异地又因疫情管控，导致成员之间沟通不顺畅

12.政策风险因为疫情管控政策，影响项目进度

13.安可政策，中间件需要做国产化适配

14.客户风险客户对问题的答复时间长

15.客户对前期的规划、原型、规格审核决策周期长

16.客户对于已交付产品的部分模块不满意，要求重新

设计和开发

17.客户对接人员有多个，且需求标准不统一

18.设计实现风险需求持续变化，导致整体设计质量底下

19.过高估计了增强型工具对计划进度的节省

20.国产化适配组件使用不顺畅，导致部分设计修改调