医院信息系统产品系统

门诊场景：从建卡/挂号开始，患者信息（门诊号、ID）即被系统记录并共享。医生在工作站开立处方或检查单，系统会调取药品库存、既往过敏史和配伍禁忌进行提示。患者缴费后，处方信息自动传至药房，药房可提前配药或按窗口分流发药，减少排队。整个流程的关键在于状态流转：挂号→就诊→收费→发药，每个节点的操作人和时间戳都需要被记录，这与你在处方单设计中关注的“审核、调配、核对、发药”追溯逻辑是一致的。

住院场景：入院登记生成住院号并关联押金账户。医生开立医嘱后，护士站进行核对与执行，医技科室（如检验、影像）完成检查并回传报告，HIS根据实际执行情况自动计费。这里涉及一个重要的业务规则：医嘱与计费的绑定。药品、检查、治疗等项目必须与实际执行挂钩，防止“只记费不执行”或“执行了漏记费”的账务漏洞。

门诊医生工作站是核心入口。医生在这里完成问诊记录、下达诊断（ICD编码）、开具处方和检查检验申请单。系统需要支持调阅患者既往就诊史、过敏史，并对处方进行配伍禁忌和剂量的合理性提醒。处方确认后，自动流向收费和药房系统。

住院医生工作站则管理长期和临时医嘱，涵盖用药、检查、护理等级等，同时支持电子病历书写和打印。护士工作站负责医嘱的执行确认、床位管理、输液和皮试管理等，所有护理操作都需要在系统中留痕，确保可追溯。

HIS 系统对并发响应（挂号收费不能卡）、数据一致性（不能多收钱/漏发药）、接口对接（医保、LIS、PACS）要求极高。

后端技术栈：Java + Spring Boot（结合你之前排查的 Spring 问题，这是主流选择）。如果医院规模大（三甲），建议采用微服务架构（Spring Cloud）；如果是一二级医院，单体架构或模块化单体（如 RuoYi 这种后台框架）足够。

前端：Vue + Element UI / Ant Design。因为收费窗口和护士站通常需要开多个页签，对浏览器内存管理有要求，建议做单页应用（SPA）优化。

数据库：强烈建议使用 Oracle 或 SQL Server。虽然 MySQL 也能用，但在处理大量存储过程、复杂报表、高并发事务时，传统医疗软件（如东华、卫宁）大多重度依赖 Oracle。

中间件：Redis（缓存字典数据）、RabbitMQ/RocketMQ（处理异步消息，如发药通知、医保上传）。