HIS医院信息系统的设计与实现
1概述
1.1选题背景
我国医疗健康信息化建设已经步入云智时代，医疗卫生机构信息化建设也迎来前所未有的机遇和挑战，更智慧的应用、更全面的信息服务、更加安全可靠的系统、更好的信息资产，以及弹性、开放的中台化总体架构，是我国智慧医疗健康信息化建设的核心需求[1]。近年来,计算机、互联网、物联网和大数据技术在医疗领域的应用,为患者的健康和安全带来了更多的保障[2]。提升医院信息系统的管理，是我国医疗健康信息化建设在云智时代数字化转型的重要建设，也是信息技术部门进一步加强（Information Technology，缩写IT）治理、显示IT价值的核心手段。
在很多医院中，不同的科室之间常常会采用不同的系统去完成不同的业务，这一决策可能是为了节省成本，也可能是某个系统觉得很好用。但随着各个系统数据的不断增长，这样一来很容易使得各个系统之间的数据交互成为难题，到年底或是医院级别审查阶段，各个系统的数据如果不能统一，将会是一个很费时费力的事情。 那么通过一个系统即可完成整个医院业务管理的系统是很有必要的。
1.2研究的目的和意义
1.2.1目的
多方面推动医院发展互通，达成医院对于电子病历、互联互通等的一些评级要求，消除信息孤岛。优化医疗服务流程，从患者挂号到出院各环节，实现信息实时共享，减少等待时间，提升效率并实现无纸化操作。现今医院信息系统已经开始逐步从单一的数据管理、效率提升转向为辅助决策、临床应用的方向深度发展[3]。借助先进AI技术深度分析医疗数据，为质量控制提供依据，辅助医护精准决策，提高诊疗水平。同时，系统讲各种数据以报表的方式展示，为医疗科研提供资源，推动成果转化。让整个医院通过一个系统即可完成各个工作，让数据更易管理。
1.2.2 意义
医疗系统的意义是多方面的。对患者而言，可以减少排队等待的时间，享受便捷的医疗服务，获得更精准的医疗保障。对医护人员而言，系统助力快速获取信息，降低医疗风险，还提供学习交流的AI平台，一定程度上可以提升专业能力。对医院管理者而言，可以通过各个报表精确把控医院的状况，以便于及时做出一些调整决策。
总的来说，整合资源、降低成本、提升服务质量与管理水平，增强患者满意度与忠诚度，提升声誉与医院形象，也为科研提供强大支持，提升科研实力。从医疗行业整体看，推动行业信息化、智能化，促进资源合理配置，缩小医疗差距，积累的数据和成果为政策与标准制定提供参考，还能促进与其他行业融合，为医疗创新注入活力。
2 技术简介
2.1 前端技术
1、VUE3：
VUE基于标准HTML、CSS和JavaScript(缩写JS)构建，并提供了一套声明式的、组件化的编程模型，帮助我们高效地开发用户界面[5]。
本系统采用最新的VUE3前端框架，通过网上许多的测评可以知道，其性能将近是VUE2的2倍，而且代码的体积将会更小，但吸引我使用VUE3的原因是其支持组合API，那么何为组合式API？用我的话概括就是更有组织性，系统某个功能所定义的接口将会统一放在一起，从而更好的达到高内聚、低耦合的软件开发目的。而VUE2使用选项API，接口常常会放在对应的.vue文件中，这样一来随着项目的演变、功能的增大，维护成本将会大大增加，代码的理解难度将会逐步上升。在我看来未来VUE3将会慢慢替代VUE2，其会更加规范、更加方便去开发前端展示界面。
2、TypeScript（缩写TS）:
我们知道浏览器能识别的是JS语言，那为何前端页面开发还使用TS？ JS是一个弱类型的语言，很多错误在没有运行的时候是发现不了的，而TS这一语言，是强类型语言，通过扩展JS的语法，提供编译时的一个静态的类型检查，从而会避免很多错误。当然TS经过编译后，会生成纯JS，在浏览器上运行。同时，TS还支持模块化、命名空间和接口等的特性，让前端代码的开发会更加的灵活。
3、Element-Plus：
基于VUE3，面向设计者和开发者的组件库[6]。
采用Element-Plus完成前端页面的组件化开发。这个组件能很好的适应VUE3的环境，对一些已有的很多优秀的组件可以复用，提升前端页面的美观性和高效性，除此之外，其具有一致、反馈、效率、可控等的特性，在我看来，开发前端页面的过程中高效而又优雅，其次，在我之前的很多项目中，前端页面基本使用它来进行组件化开发，使得界面交互更友好，也更加的迅速。
4、Axios：
Axios是一个基于promise的网络请求库，可以用于浏览器和node.js[7]。
主要是用于前端向后端发送请求，获取请求响应等，还有很多的功能，比如：自动将请求体序列化为JSON、自动转换JSON数据等。在实际使用中，会基于Axios对前端的请求进行统一的封装，定义专门的接口文件，使得前端向后端发送请求时更加的规范，也方便后期软件的维护。
5、ESLint：
一个根据方案识别并报告JS代码问题的工具[8]。
将其集成到前端项目中的目的是为了保证代码风格一致并且避免错误，配置了之后，可以自动进行代码的检查，除此之外，ESLint是插件式的，意味着每一个规则都是一个插件，我们可以自定义的添加很多特色插件。
6、Pnpm：
速度快、节省磁盘空间的软件包管理器[9]。
之前一直使用npm进行前端依赖的下载，不同的项目中的依赖都需要完全下载，在项目比较庞大时，极易费时费力。因此本系统使用pnpm来代替npm，用来下载前端的资源包，在使用pnpm时，依赖会存储在内容可寻址的存储中，相较于npm，Pnpm的下载速度比npm快将近2倍，且节省磁盘空间，除此之外，也可以进行node.js的管理、副作用缓存、内容可寻址储存等。由于node.js不用的项目有着很大的区别，各个版本之间兼容不是很好，因此node.js的管理也是很重要的，为了保证各个node版本之间的切换，我使用nvm进行管理，pnpm管理node的功能，尚未使用。总之，pnpm快速、高效。
2.2 后端技术
1、Sa-Token：
一个轻量级Java权限认证框架，主要解决：登录认证、权限认证、单点登录、OAuth2.0等一系列权限相关问题[10]。
图2-1 sa-token功能结构图
由上图可以知道，Sa-Token在权限管理这一块，有着很多的功能，也有着很强的优势，其有着很活跃的开源社区，文档齐全，在我看来是一款非常优秀的开源的权限管理框架，因此本系统集成Sa-Token并结合Redis完成登录认证和权限认证等功能，既方便权限管理更方便系统之后的拓展。
2、SpringBoot3：
最新的SpringBoot框架，之所以用它是因为SpringAI在SpringBoot3的环境更加适配，故我的项目使用SpringBoot3作为后端的主框架。由于SpringBoot3最低的要求jdk17以上，所以本系统使用jdk21。
3、SpringAI：
一个人工智能工程应用框架。其目标是将 Spring 生态系统的设计原则应用于人工智能领域[11]。
可以通过这个框架，去调用Ollama本地部署的AI模型，或者现有的云服务如：DeepSeek、Moonshot等的AI模型，从而完成AI辅助的功能。在医院真实的场景下，会使用本地的AI模型，如今deepseek等的模型本地化部署已经非常普遍。AI辅助，既能让医生熟悉软件操作，更能构建医院独有的知识库，从而更加方便医生日常的工作，也有利于患者的病情诊断。
4、MyBatis-Flex：
MyBatis-Flex是一个优雅的MyBatis增强框架，它非常轻量、同时拥有极高的性能与灵活性[12]。
这个框架更加的轻量、灵活，而且具有更好的性能。除了依赖MyBatis本身之外，没有其它第三方的依赖，具有更好的自主性、把控性和稳定性，可以使用QueryWrapper进行关联查询、多表查询等MyBatis-Plus不支持或收费的操作。因此本次系统开发选用该框架。总结：免费、功能多、轻巧优雅。
5、OSS文件存储：
之前一直使用的是阿里云的OSS文件存储服务，但为了保证数据的安全，大都的医院均是在内网环境下运行，大都会采取本地化部署的方法，这里我使用比较流行的MinIO文件存储。MinIO是一个对象存储解决方案，它提供了与Amazon Web Services S3兼容的API，并支持所有核心S3功能[13]。
Easyexcel：
由阿里巴巴开源的一个用于处理Excel文件的框架，简单易用，方便本系统的一些数据的导入和导出。在使用的时，只需在主要字段上加相关的注解，即可完成字段的对应，从而将数据导出为Excel或者将Excel数据添加到系统数据库中。
6、Docker：
Docker是用来容器化部署程序和服务的工具，使用“docker pull”命令即可将mysql等的镜像给拉取下来，之后通过“docker run”设置端口、挂载等信息后便可运行服务。本系统所使用的如mysql、redis等的服务没有在windows上去部署，服务基本都使用docker容器化部署到Centos7的Linux服务器上。这样一来很容易使用docker进行容器化管理，除此之外，也可以拜托对特定系统的依赖，更好的支持开源系统或者国产化系统。
7、Gitee:
代码管理工具。在以往的项目中，一直将代码提交到GitHub中，但是国内来说访问很慢时常会出现代码push失败的情况，而且访问GitHub有一定的限制，所以选用Gitee进行代码的管理，对于我们国内来说Gitee访问起来更加的快捷和方便，社区虽没有GitHub那样活跃，但在国内在我看来Gitee是比较好的GitHub替代者。当然如果在开发的过程中代码的保密性比较高，通过会私有化部署GitLab等的服务，去提交代码。本次是毕业设计，提交的代码不涉及保密等要求，故直接提交到Gitee 。这样一来，也可以防止因电脑损坏导致代码丢失。
8、JimuReport：
积木报表，是一款免费的数据可视化报表，含报表、仪表盘和大屏设计[14]。正如它的名称一样，使用起来如同搭建积木一样简单，在后端集成即可。在用户操作的过程中，如同Excel表格一般，可以通过拖拉拽完成报表的设计，使得所见即所得，将来医院的用户设计个性化报表时将会节省很多的工作量。
3 需求分析
3.1系统功能性需求
3.1.1功能模块分析
本系统将要实现的主要功能，通过角色去划分不同的功能，以方便本系统功能和权限的划分。当不同角色的医院员工登录本系统时，将会有不同的操作界面，保证医生只需访问支撑自己日常工作内容所需的菜单。以下将详细叙述各个科室所需完成的功能：
1、医务科：主要完成对医生的排班操作，并对医院的医生进行管理操作，除此之外，也可以根据需求联系医院的管理员查看一些数据的报表。
2、收费科：根据医生的排班信息为患者挂号，在医生下了医嘱后为患者执行缴费或退费操作。
3、门诊医生：医生可以对挂了号的患者进行诊疗操作，可以给患者写病历、下诊断、开医嘱，在医嘱的最前面会显示医嘱的执行状态，当为检验医嘱显示“已完成”时，医生可以查看到患者的检验结果。如果患者要对已经执行的医嘱退费时，需要医生这边提交申请退费操作，走医院的退费审批流程。
4、检验科：为患者执行检验医嘱。首先是根据医嘱对患者进行采集样本的操作并打印条码，其次是检验科对样本进行接收操作，接收后的样本会通过条码的医嘱信息再通过医嘱项目与测试项目的对照，获取到具体的测试项目，检验科的医师可以填写检验结果，当检验结果与仪器上的无误之后，便可以点击审核样本。检验科人员也要维护好医嘱项目于测试项目的对照。
5、药房：主要是保证药品的入库和发药出库的操作。
6、管理员：通常是指医院的信息科，可以维护医院医生的权限，已经完成科室的个性化报表，并对医院系统进行管理操作。
7、超级管理员：可以对整个系统进行管理，也可以对各个租户，也就是用本系统的所有医院进行管理，可以更改各个医院的套餐等的信息。
3.1.2 用例分析
图3-1主功能用例图
医生是本系统主要业务的用例图。各个角色的功能已经在功能结构图中表述清楚，下面将主要描述一下功能与功能之间的联系，并且为了简洁，省略了信息查询功能。
1、医生：医生若想查看到检验的结果，前提是检验医师将患者的样本已经处理完毕，在系统中就是检验医师点击了样本审核按钮。医生在下药品医嘱之前会访问药房当前的库存情况，保证患者缴费后去药房可以拿到药。
2、患者：患者在进行挂号操作时，前提是所挂的医生和科室有排班信息。当患者查看检验结果时前提也是检验科审核了患者的检验结果。
3、收费处人员：在进行收费操作时，要通过患者的挂号信息获取到医生的挂号费用、在医嘱收费时通过患者的医院好获取到患者的所有的医嘱信息，从而进行结算。特别注意的时，患者首次在医院挂号时，在挂号成功时往往会将患者的基本信息保存到医院患者信息表中。
4、检验医师：主要进行样本的处理。样本的处理分为三步：第一步，样本采集，根据门诊医生下达的检验医嘱。第二步，样本接收，这里意味着已经确费了样本已经到了检验科马上要进行上机操作，医生无法取消医嘱了。第三步，进行各项检验项目的操作，并记录检验结果。最后样本审核，样本被审核之后，医生端便可以看到患者的检验结果。
至于医务科和药房处人员的功能详见图3-1系统功能模块图。
图3-2权限功能用例图
上图展示了管理员和超级管理员之间的权限。在医院中，信息科人员是本系统的管理员。管理员和超级管理员均可以对当前租户进行的管理，给不用的用户不同的权限，可以管理系统数据字典数据库等。对于医院外部，还有租户权限的管理，这里的租户即是医院，本系统可以被多家医院部署使用，但是每个医院可访问的资源，由签署的合同决定，这些均由超级管理员进行管理。
3.2系统非功能性需求
本系统在运行过程中，需要有一台Linux服务器满足内存大于2GB，处理器数量大于2，硬盘内存要大于20GB，如果资源充足条件下建议Redis服务等的部署采用集群方式，方式服务器出问题导致数据丢失或者不一致。为了完成系统中的一些打印、扫码等操作，最好有打印机、扫描球或扫描枪等的工具。此外，使用本系统时建议在谷歌浏览器中进行，因为谷歌浏览器对页面的渲染更加的全面，如果使用其它未测试的浏览器的使用，可能会有未知的错误导致一些组件加载不出来。
3.3 可行性分析
技术可行性：采用Java语言（SpringBoot3框架）+ MySQL技术栈构建核心业务系统，前端使用VUE3+TS实现数据可视化。通过Restful API与医疗设备进行数据交互，结合Docker容器化部署方案提升系统扩展性，能够支持项目目标的实现。
成本预估：基础设施层面采用本地的Linux开源虚拟机，开发IDE选用IntelliJ IDEA教育版、Gitee等开源生态资源，结合Docker进行部署，实现开发运维成本最优。
市场需求：随着国家对医疗信息化的推动政策，加速医疗数据数字化处理和管理的需求日益迫切。本项目能够满足这一需求，为医疗机构提供高效、安全的数据管理解决方案。
资源支持：本次毕业设计不仅有着学校资源的支持，也可以利用东软医疗相关资源，在智慧医疗方面，其有着成熟的医疗系统解决方案，可以作为本项目的参考资料，有利于本项目的开展。
开发周期管理：分为三阶段完成（需求分析、核心模块开发、系统测试），需求分析时会完成医疗机构的业务流程调研，再进行核心模块如：电子病历、医嘱开立、收费等的开发。
数据隐私保护：医疗数据在各种中间机构之间不断交易共享，患者无法参与自身医疗数据共享过程且隐私泄露严重[15]。如何保护好病患的隐私数据防止其敏感数据泄露具有重要意义[16]。本系统在数据采集、存储和传输过程中，采取严格的数据加密和访问权限控制措施，确保用户信息安全。
3.4 业务流程需求调研
表3 - 1系统主要功能模块
| 功能编号 | 系统功能名称 | 系统功能描述 |
| SRHIS01 | 门诊收/退费 | 门诊收费处人员给患者确费、退费 |
| SRHIS02 | 病历书写 | 医生给患者写电子病历。 |
| SRHIS03 | 医嘱开立 | 医生患者开立相关医嘱、下诊断。 |
| SRHIS04 | 取/退药 | 患者缴费后可以到药房进行取药。 |
| SRHIS05 | 做检验 | 患者到检验科做检验。 |
| SRHIS06 | 查询统计 | 医务人员对诊疗数据进行查询统计。 |
| SRHIS07 | Ai辅助 | 可以通过对话的方式操作本系统部分功能。 |
这里编号使用“SRHIS”，原因是本系统的项目名称为“LsrHis”取用项目名称中的后5位作为编号前缀
3.4.1 门诊收/退费（SRHIS01）
1）业务处理流程
图3-3门诊收/退费流程
2）业务功能描述
表3-2门诊收/退费功能介绍
| 业务功能名称 | 门诊收/退费 | 业务功能编号 | SRHIS01 |
| 业务功能描述 | 门诊患者进行挂号、医嘱收费，并对于一些医嘱、药品等进行退费操作。 | ||
| 输入 | 输入患者的就诊号或者身份证号，以及收费或退费项目。 | ||
| 输出 |
| ||
| 优先级 | 高 | ||
| 备注 | 无 | ||
3）实现思路
这里主要的处理收费和退费时，必须保证数据库操作的原子性。比如收费时，生成记录和更新库存要在一个事务里，避免部分操作失败导致数据不一致。可以使用Spring的@Transactional注解来管理事务。
支付方面，需要集成多种支付方式，比如现金、医保、支付宝、微信等。不同支付方式的接口和处理流程可能不同，设计统一的支付接口，方便扩展。
3.4.2病历书写（SRHIS02）
1）业务处理流程图
无
2）业务功能描述
表3-3病历书写业务描述
| 业务功能名称 | 病历书写 | 业务功能编号 | SRHIS02 |
| 业务功能描述 | 医生根据患者的实际情况进行病历的填写。 | ||
| 输入 | 患者的病情信息。 | ||
| 输出 | 可预览病历并支持打印。 | ||
| 优先级 | 高 | ||
| 备注 |
| ||
3）实现思路
这里主要的问题在于病历模板的维护，如何展示病历的信息，既方便医生填写，又方便预览。Element-Plus等组件可以作为尝试，在开发时会尽可能展示A4的病历模板以供医生直接填写。前端方面还需要再进行探索。
3.4.3医嘱开立（SRHIS03）
1）业务处理流程图
无
2）业务功能描述
表3-4医嘱开立业务功能描述
| 业务功能名称 | 医嘱开立 | 业务功能编号 | SRHIS03 |
| 业务功能描述 | 医生给患者开立医嘱。 | ||
| 输入 | 开立收费项目 | ||
| 输出 | 医嘱开立信息 | ||
| 优先级 | 高 | ||
| 备注 |
| ||
3）实现思路
这里设计的数据库较多，需要保证数据的一致性，再开立医嘱前检查是否该项目可以做或药房等有存货。在代码实现过程中，前端技术方面进行细节处理，用不同的颜色标识医嘱的执行情况。（签发、收费、执行、退费等）
3.4.4取/退药（SRHIS04）
1）业务处理流程图
图3-4取/退药流程
2）业务功能描述
表3-5取/退药业务功能描述
| 业务功能名称 | 取/退药 | 业务功能编号 | SRHIS04 |
| 业务功能描述 | 患者对医生开立的药物医嘱领用。 | ||
| 输入描述 | 开立时间，药物医嘱项目。 | ||
| 输出描述 | 这里主要是给患者发药，并更新医嘱状态。 | ||
| 优先级 | 中 | ||
| 备注 |
| ||
3）实现思路
要设计一个药房的子系统。对药物进行入库和出库操作。保证数据的一致性，并提供接口，方便医生开立医嘱时查询药瓶余量是否充足。
3.4.5做检验（SRHIS05）
1）业务处理流程图
图3-6患者做检验流程
2）业务功能描述
表3-6做检验业务功能描述
| 业务功能名称 | 做检验 | 业务功能编号 | SRHIS05 |
| 业务功能描述 | 患者到检验科做检验。 | ||
| 输入 | 检验条码。 | ||
| 输出 | 条码包含的医嘱项目。 | ||
| 优先级 | 中 | ||
| 备注 |
| ||
3）实现思路
这里主要会实现检验的一个业务流程，关于检验厂家仪器等硬件的对接、检验结果、质控等数据解析不做实现。检验的报告的生成可以使用采用报表的方式完成。
3.4.6查询统计（SRHIS06）
1）业务处理流程图
无
2）业务功能描述
表3-7查询统计业务功能描述
| 业务功能名称 | 查询统计 | 业务功能编号 | SRHIS06 |
| 业务功能描述 | 系统系统对一些业务数据的查询功能。 | ||
| 输入 | 查询条件 | ||
| 输出 | 数据 | ||
| 优先级 | 中 | ||
| 备注 | 数据查询需要设置权限。 | ||
3）实现思路
这里需要优化查询的效率，对sql进行调优，除此之外，对于数据的展示尽量会使用报表的方式，借助Java的报表制作工具积木等，如果数据需要展示，也是通过Echarts对数据进行图表展示。
3.4.7 AI辅助（SRHIS07）
1）业务处理流程图
无。
2）业务功能描述
表3-8AI辅助业务功能描述
| 业务功能名称 | AI辅助 | 业务功能编号 | SRHIS07 |
| 业务功能描述 | 通过对话的方式，操作本系统，对检验等结果进行AI审核。 | ||
| 输入描述 | 对话文本 | ||
| 输出描述 | 操作提示，或具体操作。 | ||
| 优先级 | 低 | ||
| 备注 |
| ||
3）实现思路
有时间的情况下实现。后端架构采用springai或langchain4j，利用ollama（本地部署，对硬件要求高，安全）或moonshot等现成大模型（付费、数据安全得考虑），搭建系统知识库，给用户操作解答，并构建函数调用（moonshot有此功能，或者阿里的），以对话的形式操作本系统。在存储本系统使用文件时，采用向量数据库更好，如：PostgreSQL。
4 系统分析与设计
4.1 软件体系结构设计
本次系统设计架构见图4 - 1软件体系结构图。
图4-1软件体系结构图
本系统在设计的过程中，虽然进行了模块化开发，但只是为了方便之后升级架构，目前依旧使用单体项目逻辑，前端发送请求给后端的controller层，这里再访问接口的时候，会通过私钥进行解密，成功后可以访问后端的应用，进而调用服务层的接口函数，之后调用数据库服务，从而给前端返回必要的结果。在整个流程中，依赖系统层中的各个模块，让整体的业务代码更加简洁和高效。
4.2 模块划分与接口设计
4.2.1前端模块
本系统的前端进行了详细的模块划分。每个模块作用如下：
Public：公共模块，这里主要存储logo的图片等。
src：主要的资源目录。
api：与后端对接的接口。
components：前端组件。
enums：常量。
layout：前端布局，主要是一些导航的vue文件。
plugins：插件。
router：路由，主要是控制页面挑战的ts文件。
store：pinia持久化存储
types：数据类型
utils：工具类
views：主要展示页面
前端通过结构化开发，封装API接口，将主页面的路由跳转设置为自动发现，通过扫描views目录，从而在大的框架不变的情况下，页面的路由添加只需在前端页面可视化配置即可，添加的页面代码需要放到对应的views的目录下。
4.2.2 后端模块
后端代码如图4 - 2项目模块架构所示。
图4-2项目模块架构
本系统采用模块化开发，项目架构由很多个模块组成。以下是本系统的后端代码目录结构的作用描述：
his-admin:系统主启动模块，登录、权限认证的入口在该模块中，项目的主要配置文件也在这里。
his-common:本系统的一些公用的模块，这些被应用到相应的his-modules中的模块中。
his-common-core:本系统的核心模块。很多系统的配置、工具类、常量等的都在这里。
his-common-encrypt:加密模块。
his-common-excel: excel表格模块。
his-common-json: json数据处理模块。
his-common-log: 配置日志输入输出。
his-common-orm: 数据操作的统一配置，如：mybatis-flex等数据源的配置在这里。
his-common-oss: 文件存储的配置。
his-common-redis: redis缓存配置。
his-common-sercurity:权限配置。
his-common-springdoc: 接口文档配置。
his-common-tenant: 租户用到的公共配置和方法。
his-common-web: Spring中统一的web配置，统一给前端响应。
his-common-websocket:消息推送模块。
his-modules: 系统中的功能模块。
his-charge: 收费系统功能模块。
his-clinic: 门诊医生站系统功能模块。
his-kb: 医院知识库系统模块。
his-lis: 检验系统功能模块。
his-medical: 医务工作站系统功能模块。
his-report: 报表模块。
his-springai: AI智能助手模块。
his-system: 系统运行的主框架，如：权限、菜单、部门等的维护在这里。
4.2.3接口设计
1、前端设计：
图4-3 前端接口设计
上图为系统前端的接口设计，以门诊收费接口为例，这里对其业务结构进行了统一的封装，收费处所用到的所有接口统一写在api目录的相应index.ts文件中。每个接口中均定义了请求后端的链接、请求方式、请求参数，对于一些请求和响应的参数均定义在types.ts中，并且在index.ts中引用。
图4-4 使用接口
在前端定义好接口后便在正式的vue文件中引用进来正式向后端发送请求，并对响应数据进行处理。
2、后端设计：
图4-5 后端controller层
这里后端接收前端的请求，并通过调用service层与数据库进行交互。
在本系统中，均使用以上的方式进行接口的设计，为了保证字段的一致性，前后端在开发的过程中，也在尽可能的后端保证视图对象（后缀为Vo）字段一一对应前端的响应体，后端的业务对象（后缀为Bo）字段一一对应前端的请求体。其余接口不再详细赘述。
5 系统实现
5.1 开发环境与工具链
Idea：作为后端代码的主要开发工具。
Redis：进行数据的缓存操作，减轻数据库访问压力。
PostgreSQL：向量数据库，使用pgvector插件大幅度提升本地知识库的检索效率和精度[15]。
Jdk21：Java运行环境。
Centos7：linux环境，本系统的用的几乎所有服务，均使用docker部署到linux环境中。
Cursor：前端的主要开发工具，有着较为成熟的AI辅助功能，可以优化前端页面的一些样式，使得前端页面更加的美观，也能加快前端页面的开发速率。
5.2 核心算法与关键技术实现
rsa接口非对称加密实现：
图5-1 ras加密过程
这里可以分四步去实现：
第一步：前端和后端准备好自己的公钥和私钥。前端将自己的公钥发送给后端，让后端保存。
第二步：后端将自己的公钥发送给前端，前端进行保存。
第三步：前端在发送请求的时候，用后端给的公钥进行加密发送，后端经过自己的私钥解密，获取的解密后的请求。
第四步：后端返回响应，通过前端的公钥进行加密，到前端后前端使用私钥解密获取响应体。
这样便保证了数据的安全。在此过程中有一个问题，这样是否就安全了？在很多场景下可能的考虑如果会有“中间人”会插一脚，将自己公钥给前端和后端，从而用自己的私钥解密获取到信息，由此有了签名证书进一步保证安全。考虑到医院几乎时内网环境，因此本系统没有去进行签名证书的这个操作。
图5-2 rsa加密实例
以上是一个加密的实例，由于用户登录过程中涉及到一些敏感信息所以请求载荷为一大串字符串，是前端使用了后端的公钥进行了加密，防止用户登录信息泄漏。
5.3 第三方组件集成
Element-Plus组件：在本系统的设计过程中，为了保存操作页面的美观和舒适，前端进行组件化的开发，利用element-plus中优秀的开源组件，去开发本系统的前端界面，从而大幅度提升了系统的美观性，也更容易让医生用户能够去接收。本系统的很多页面几乎都是使用Element-Plus里的组件库实现的。
WINGPT2.0：在本系统中，使用了卫宁健康的开源AI智能体，WINGPT2.0。一个医疗垂直领域大模型，将专业的医学知识、信息等融会贯通，为医疗行业提供智能化的医疗问答、诊断支持等信息服务[18]。提升医疗服务质量。这个AI主要是考虑到其在医院领域是开源的，在处理医疗相关的问题时，或许有着一些意想不到的优势，所有可以作为AI体中的一个，解答医生所遇到的问题。
5.4主要功能界面及实现
5.4.1 系统主界面
图5-3系统主界面
主界面，主要展示开发系统用的技术栈、版本等的信息。页面的相关布局可以通过不同的医院去个性化的配置。
这些界面的实现主要前端路由的动态渲染展示，侧边栏和导航均是固定的，通过侧边栏的选择进而确定主显示的路由。
5.4.2 医务工作站
图5-4医务工作站界面
完成医院医生的日常排班工作，以便于患者去挂对应的医生的号。医生姓名、科室向后端发送请求进行获取。时间段设置为上午、下午、晚上、全天，可以根据客户医院具体的工作时间去调整。
从后端获取到医生列表，排班时选中医生的姓名之后前端触发选中事件，将医生的科室等的信息自动填入，医务人员选好其它数据后，即可提交排班信息到doctor_schedule表中。涉及简单的数据库插入操作，但在插入前需要验证排班时间段是否存在重叠，如果存在则无法完成排班。
5.4.3 门诊挂号
图5-5门诊挂号界面
门诊挂号界面，收费处人员可以通过填写必要信息，给患者进行挂号操作。
填写身份证号后，会自动解析该身份证号，会查询后端的his_oppatient表，如果存在该患者将自动把姓名、电话等患者信息自动填充进去，如果没有查询到前端则会解析身份证号，只将性别、出生日期、年龄信息做一个自动填充，为了保证这些数据与身份证一致，解析之后不容许进行修改。在选择了挂号科室后，会访问后端的接口查询当前时间可以的挂号的医生列表，前端会跟踪排班医生的双击事件，当双击医生后即可把医生的信息带到挂号表单中。在提交挂号之后会弹出缴费的界面，患者可以选择缴费的方式，缴费后会提交挂号的表单到挂号表charge_register_info中，并返回患者的医院号。这里的医院号与患者对应，从进院到出院会保证唯一，患者再次入院时，将会复用。
特别注意的是，生成患者号的规则由后端制定，本系统采用“前缀+当日日期+累计值”的字符串形式，这里的累计值会通过“前缀+当日日期”模糊查找挂号表得到匹配数，之后在这个匹配数之上+1，即产生当前挂号患者的医院号。
5.4.4 医生站
图5-6医生站界面
医生可以在这给挂了号的患者写病历、下医嘱和诊断等的操作。
这里不同的医生看到的患者是不一样的，在查询患者时会根据医生的工号进行筛选，从而显示挂了当前医生的患者列表。在页面加载之前，通过前端的onMound（）方法获取后端的如医嘱、药物等的信息，医生在下医嘱时只需筛选即可。当进行医嘱签发的时候，会将病历、诊断以及医嘱信息保存到后端的对应表中。当点击“完成就诊”后，表示该患者已经治疗完毕，在执行该业务的时候，会判断患者的所有医嘱是否已经全部执行完毕，如果没有执行完毕则无法完成就诊。医嘱在没有收费之前，医生这边均可以执行退费操作，后端会删除已经签发的医嘱。医嘱执行流程：签发->缴费->执行->已完成。
5.4.5 检验工作站
图5-7样本采集界面
给做检验的患者打印条码，采集样本。
通过患者医院号在his_order医嘱表中查询患者的医嘱信息，这里会筛选医嘱中状态为“已缴费”的医嘱且医嘱类别为检验的，如果有医嘱便可以通过勾选医嘱给患者打印条码，条码的生成通过前端的jsBarcode组件生成条码，点击打印后会将条码与患者的所有信息保存到条码信息表lis_barcode_info中，让患者的医嘱项目、患者信息等关键信息与条码号绑定到一起，以后的检验操作将通过条码号进行。
图5-8检验样本接收界面
检验科样本采集完毕后，会进入到样本接收的阶段，在这一阶段会通过查询医嘱项目与测试对照表lis_item_group，将患者的检验医嘱对应的测试项目一一列出，双击后，可以查看到每条医嘱的测试项目信息，在样本上机出结果后医生将结果填入，在经过审核之后，结果存储到lis_result表中便可被医生那边获取并读取。在实际的医院中，结果的读取一般都是自动传送的，通过仪器厂家给的通信协议，去开发监听系统并配置解析质控结果和检验结果的动态库文件，得以自动传出到lis系统中，由于这块对接需要仪器厂家的配合，本次项目不进行这块的开发。
5.4.6药房
图5-9门诊药房界面
可以根据患者号，查询到患者的医嘱列表从而对患者进行发药操作，如果一旦发药之后，将会更新医嘱的执行情况，医生无法直接取消医嘱，需要进行医嘱的取消申请操作，在医务科和执行科室审批通过后方可取消。
5.4.7字段管理
图5-10字典管理界面
在整个的流程中，很多很多的字段是以下拉框的形式方便医生去选择，这些以字典给的形式保存到系统字典表中，医生也可以进行维护。在需要时可以向后端发送请求通过字典类型查询字典表sys_dict_data表。
5.4.8 AI问答
图5-11 AI问答界面
为了方便医生的操作，本系统接入了moonshot、DeepSeek等的AI模型，并配合向量数据库PostgreSQL完成个性化的智能问答，帮助医生更高效的了解本系统以及查找一些专业的知识。
为了实现个性化的查找，将医院的一些知识文件可以保存到pgvector数据库中，在构建AI的时候将vectorStore也作为defaultAdvisors的参数，使得本系统的AI不仅拥有上下文记忆能力，也拥有向量数据库检索能力。对于一些医院独有的知识可以让AI去搜索向量数据库而得到信息，并返回给前端。
5.4.9数据展示：
1、报表设计
图5-14 报表设计界面
可以通过积木报表的工具个性化制作报表。至于积木报表如何使用可以参见积木报表的官网，这里不在叙述。
2、报表查看
图5-15 报表查看界面
当管理员设计好科室所需要的报表后，可以看到设计好的报表的界面，在这里可以选择打印报表等的操作。
5.5系统重难点及解决方案
5.5.1 权限认证
众所周知，医院的体系是比较庞大的，人员很多，假设没有权限的细分，很有可能发生一些跨科室数据的添加和修改，这样很有可能会提升医疗事故的发生概率，因此需要给每一位用户设置可以访问的功能权限，按照医院的管理层级去设计权限，对于数据删除、修改等的权限，给科室或小组的主管，提升整个医院管理水平的同时，也可以杜绝一些医疗事故的发生。
为了达到这一目的，在设计系统之初，花了大量的时间去设置权限管理的业务，利用Sa-Token这里框架，将所有的目录、菜单、按钮那些个资源管控起来，设置专门的角色，给角色设置菜单资源的访问权限，再给用户设置对应的角色，从而达到用户可访问前端资源的权限，但是也要避免有人模拟前端向后端发送请求，所以会在后端也进行了访问权限的控制，通过@SaCheckPermission("charge:register:list")，这里的"charge:register:list"是在功能添加时设置的权限标识，在后端接收到请求后会进行权限标识的判断，如果没有则拒绝访问访问接口。
5.5.2 医嘱开立
医生开立的医嘱需要在各个科室可以查询到，并且需要医生可以看到医嘱的状态，能开具不同的医嘱。
针对以上的问题，如图5-6医生站界面，首先是要设计一个便于操作的前端界面，其中的数据在页面初始化时调用方法从后端数据库中获取。至于后端的业务处理过程中，表单的提交会让多个业务执行，如医生点击“完成就诊”之后，将会在后端保存病历、医嘱等信息，为了保证业务的一致性，后端进行业务的管理，通过@Transactional的注解，启用数据库事务的管理。在数据库表层面，给医嘱表添加了医嘱状态，在之后的医嘱执行过程中，都会专门去更新医嘱的状态到医嘱表中。也设置了医嘱的签发标识，只有医生签发的医嘱，才可以在各个科室查询到医嘱的信息。不同的医嘱开立为了保证简单，在前端专门设置了不同医嘱开立的按钮，方便医生去选择性的开立不同类型的医嘱。
5.5.3 数据查看
一般来说，HIS系统的数据是繁多杂乱的，将各个数据给医院以更好地形式展示，各个医院的报表并不相同，如何去个性化显示报表，是两个难点问题。
医院中很多数据的展示均使用报表的形式，因此这一块是非常重要的，在开发过程中，尝试了很多种报表工具去展示数据，通过给挂菜单的方式将表格、图表等方式的数据展示给用户。这些操作很多的报表工具均能达到，但是如何很方便、快捷的个性化设计报表呢？总不能医院需要报表的均由系统开发人员开发，这样将会导致成本非常大，所以引入一个医院信息科人员方便维护的报表工具是必要的，兼顾简单、功能丰富、扩展性强。由此试用了很多的工具，最终选用积木报表，开源、简单、功能强大，非常适合这样的环境，去让医院自己的人员去个性化设置报表，让医生可以更加方便获取到各种数据的统计结果，也可以节省系统开发人员的时间和资源。
5.5.4 条码生成
方案一：后端实现。SpringBoot整合ZXing生成检验条码。可以利用开源的条码生成工具ZXing，将其集成到本系统中专门用于检验条码的生成，可以通过可以动态的设置文本、宽、高等属性，生成条码的图片，并将图片存储到指定的位置，
方案二：前端实现。前端通过安装jsBarcode去生成检验条码，依旧通过设置宽高等属性，来调整条码的样式。
在本系统的开发过程中，我尝试了以上两种方法，结果发现后端生成的虽然快捷，但很难进行维护，对于字体位置的调整很难达到个性化，修改的过程中，常常需要直接修改后端的源码，可维护性大打折扣，不适合后期的维护。因此选择了方案二，在前端实现条码的生成功能，之后存储到后端数据库，保证数据一致性的同时，也方便维护条码的打印格式，可以实现医院检验条码的个性化打印操作，且可以直接进行打印预览，避免出错而浪费条码。
该功能主要是打印出检验条码并贴到试管上，让仪器通过扫描试管上的条码，从而获取到条码中的内容。
浙公网安备 33010602011771号