博主介绍：✌ 专注于VUE,小程序，安卓，Java,python,物联网专业，有18年开发经验，长年从事毕业指导，项目实战✌选取一个适合的毕业设计题目很重要。✌关注✌私信我✌具体的问题，我会尽力帮助你。

一、研究目的

本研究旨在构建一套基于SpringBoot框架的糖尿病风险预测评估系统，以期为临床医生和公共卫生决策者提供一种高效、可扩展且易于部署的工具，帮助其在早期识别潜在糖尿病患者并实施精准干预。随着全球糖尿病患病率持续攀升，传统的筛查方式往往受限于时间成本、专业人力和诊断设备等因素，导致高危人群被忽视或误诊；本系统通过整合电子健康记录、基因组信息及生活方式数据，利用机器学习算法对多维特征进行建模，实现对个体糖尿病风险的量化评估。采用SpringBoot作为后端技术，可充分利用其模块化、微服务友好的特性，快速实现数据采集、模型推理、结果存储与接口暴露等功能，并支持与现有医院信息系统的无缝对接。系统设计强调可解释性与安全性，在模型输出中提供特征重要性分析，帮助临床医师理解风险因素，同时通过OAuth2.0和JWT等机制保障患者数据的隐私与访问控制。通过前端可视化界面，用户能够直观查看风险评分、趋势预测以及个性化建议，从而在临床决策中实现数据驱动与人文关怀的统一。研究最终目标是验证该系统在多中心、真实世界数据环境下的有效性与可行性，为糖尿病早期干预提供技术支持，并为类似慢性病风险评估平台的开发提供可复制、可推广的技术范式。

二、研究意义

本研究通过构建基于SpringBoot的糖尿病风险预测评估系统，致力于填补当前临床筛查与大数据分析之间的技术鸿沟，从而实现对高危人群的精准识别与早期干预。 在全球糖尿病患病率持续攀升、医疗资源分布不均以及传统诊断流程耗时耗力的背景下，该系统所提供的实时风险评估功能能够显著降低误诊漏诊率，提升临床决策效率，并为公共卫生部门提供可量化的数据支持，以便制定更具针对性的预防策略。 通过将电子健康记录、基因组信息、生活方式与环境因素等多源数据进行融合，并采用可解释的机器学习模型，本研究不仅能够揭示糖尿病发生的多维驱动机制，还能为个体化干预方案提供科学依据，进而促进精准医学在慢性病管理中的落地应用。 此外，基于SpringBoot的微服务架构与开放接口设计，使得系统具备高度可扩展性与跨平台兼容性，可在不同医疗机构、科研平台乃至移动终端中实现无缝部署，为未来大规模健康管理项目奠定技术基础。 综上所述，本研究的意义不仅体现在提升糖尿病早期筛查与干预的技术水平，更在于为慢性疾病风险评估提供一种可复制、可推广的技术范式，推动医疗大数据与人工智能在公共卫生领域的深度融合，最终实现降低社会医疗成本、提升人群健康水平的宏观目标。

三、国内外研究现状

国内外在糖尿病风险预测与评估领域的研究已形成多条互补的技术路线，主要聚焦于数据驱动模型构建、临床数据集成与多模态信息融合、可解释性分析以及系统化部署与临床应用。 在国外，早期以统计学方法为主的风险评分体系，如美国糖尿病协会发布的A1C基准、英国NHS的FINDRISC工具等，在临床实践中已得到广泛验证，其核心优势在于模型简洁、易于解释；随后，随着大数据与机器学习技术的发展，学术界陆续提出基于逻辑回归、支持向量机、随机森林以及梯度提升树的多变量预测模型，这些模型在公开数据集（如NHANES、UK Biobank）上实现了0.80以上的AUC值，并通过交叉验证与外部验证进一步证明了其稳健性。 同时，深度学习方法也逐渐进入糖尿病预测研究领域，研究者利用卷积神经网络对眼底图像、皮肤表面温度图以及基因表达谱进行特征提取，取得了与传统模型相当甚至更高的预测准确率；此外，混合模型将传统统计方法与深度学习相结合，实现了多模态信息的协同学习，在多中心临床试验中表现出优异的泛化能力。 在国内，随着国家健康大数据平台建设与精准医疗战略推进，糖尿病风险预测研究呈现出从单一指标到多维数据融合、从单中心验证到多中心协同验证的演进趋势。 早期以电子健康记录（EHR）为基础的基于逻辑回归与决策树的风险评分模型已在部分省级医院得到应用，并通过与临床路径管理系统对接实现了实时预警；随后，国内高校与科研机构利用公开数据库（如中国疾病预防控制中心的糖尿病监测数据）构建了基于随机森林、XGBoost以及轻量级深度网络的预测模型，部分模型在本土数据集上实现了0.85以上的AUC值，并通过可解释性工具（如SHAP、LIME）揭示了年龄、BMI、血压等传统指标与新型生物标志物的相对重要性。 近年来，国内研究进一步聚焦于多组学数据融合与移动健康技术应用，利用基因组测序结果、代谢组学特征以及穿戴式设备采集的心率变异性、步数等行为数据，构建了多维特征向量并采用图卷积网络进行学习，显著提升了预测性能；与此同时，一些研究团队将预测模型嵌入基于SpringBoot或Django的微服务框架中，实现了与医院信息系统（HIS）、实验室信息管理系统（LIS）的无缝对接，并通过RESTful API向前端提供实时风险评估结果，已在多家三级甲等医院完成试点部署。 在技术层面，国内外学者普遍关注模型的可解释性与公平性，针对不同人群（如少数民族、农村地区）进行亚组分析，并通过对模型输入特征进行敏感性评估，以避免算法偏差导致的诊疗不平等。 此外，随着区块链与分布式账本技术在医疗数据安全领域的探索，一些研究尝试将患者数据存储于去中心化网络中，以保证数据隐私与可追溯性，同时保持对预测模型训练所需的大规模数据访问。 总体而言，国内外在糖尿病风险预测研究方面已取得了从单变量统计模型到多模态深度学习、从单中心验证到多中心协同验证、从离线算法到在线系统化部署等一系列技术突破；然而，如何在保证预测准确性的同时兼顾模型可解释性、数据安全与临床可操作性，仍是当前研究的关键挑战。

四、预期达到目标及解决的关键问题

本研究的总体目标是构建一套基于SpringBoot框架的糖尿病风险预测评估系统，该系统能够在临床环境中实现高效、可扩展且安全的数据采集、模型推理与结果呈现，从而为医生提供实时、可解释的风险评分，支持早期干预与个体化管理。 为实现这一目标，研究计划在数据层面完成多源异构数据的统一建模与清洗工作，包括电子健康记录、基因组信息、生活方式监测以及环境因素等；在算法层面开发并验证多种机器学习模型，涵盖逻辑回归、随机森林、梯度提升树与轻量级深度网络，并通过交叉验证与外部验证评估其泛化性能；在系统层面实现微服务化架构，利用SpringBoot的模块化特性完成数据接口、模型推理服务、结果缓存与安全认证等功能，并通过RESTful API向前端提供可视化展示；在应用层面开展多中心临床试点，评估系统在真实世界环境中的可用性与临床价值，并根据反馈进行迭代优化。 关键问题主要集中在以下几个方面：首先，如何在保证模型准确性的同时提升可解释性，以满足医生对诊断依据的透明度需求；其次，如何解决多源数据异构性与缺失值问题，确保数据质量与模型鲁棒性；再次，在系统安全层面，需要实现基于OAuth2.0与JWT的细粒度访问控制，并采用加密存储与传输技术保障患者隐私；此外，如何在分布式部署环境中保持模型推理的低延迟与高可用性，也是技术实现的重要挑战；最后，在多中心验证过程中，需关注不同人群、不同医疗机构间的差异性，避免算法偏差导致的诊疗不平等。 通过对上述目标与关键问题的系统化研究，本项目期望在技术创新、临床应用与社会价值三方面实现突破，为糖尿病早期筛查与精准干预提供可复制、可推广的技术方案。

五、研究内容

本研究的整体内容可分为五个主要阶段，分别为数据采集与预处理、特征工程与模型构建、系统架构设计与实现、临床验证与性能评估以及系统部署与持续改进。 在数据采集与预处理阶段，首先通过接口对接医院信息系统（HIS）、实验室信息管理系统（LIS）以及可穿戴设备，获取电子健康记录、实验室检验结果、基因组测序数据和生活方式监测数据；随后采用标准化转换、缺失值插补与异常值检测等技术，对原始数据进行清洗与统一编码，以构建面向模型训练的干净数据集。 在特征工程与模型构建阶段，基于医学知识与统计分析，提取临床指标（如血糖、血压、BMI）、生物标志物（如胰岛素水平、炎症因子）以及行为特征（如睡眠时长、步数）等多维特征；利用信息熵、互信息等方法进行特征筛选，进一步降低维度；随后在同一数据集上训练并比较逻辑回归、随机森林、梯度提升树以及轻量级深度网络（如MLP）等多种算法，并通过交叉验证与外部验证评估其AUC、准确率与召回率，最终选取性能最优且可解释性最强的模型作为系统核心。 在系统架构设计与实现阶段，采用SpringBoot框架搭建微服务化后端，拆分为数据采集服务、模型推理服务、结果缓存服务与安全认证服务；通过RESTful API实现前后端通信，并利用JWT进行访问令牌管理；在模型推理层面，将训练好的模型序列化为ONNX或PMML格式，以便在Java环境中高效加载并执行；在前端层面，采用Vue.js等技术构建可视化仪表盘，展示风险评分、关键特征重要性以及历史趋势。 在临床验证与性能评估阶段，选取多家三级甲等医院作为试点，对系统进行真实世界数据的在线评估；通过对比传统FINDRISC工具与本系统预测结果，计算误诊率、漏诊率及成本收益；同时收集医生与患者的使用反馈，评估系统的易用性、可解释性与临床决策支持价值。 在系统部署与持续改进阶段，利用Docker容器化技术将各微服务打包，并通过Kubernetes实现弹性伸缩；在数据安全层面，采用TLS加密传输、AES加密存储以及基于角色的访问控制；同时建立模型监控与再训练机制，定期使用新收集的数据对模型进行微调，以适应人群结构与疾病谱的变化。 通过上述五个阶段的系统化推进，本研究将实现从数据获取到临床应用的一体化流程，为糖尿病早期风险评估提供可复制、可推广且具备高可解释性的技术方案。

六、需求分析

用户需求方面，本系统的主要使用者包括临床医生、医疗机构管理人员、数据分析师以及糖尿病高危人群。临床医生需要一个简洁直观的界面，能够快速获取患者的风险评分、关键影响因素以及历史趋势，从而在门诊或住院期间做出精准干预决策；他们还期望系统能够提供可解释的特征重要性分析，以便将模型输出与医学知识相结合，提高诊疗信任度。医疗机构管理人员则关注系统的整体性能与运营成本，需能通过统一的管理后台监控服务状态、用户访问日志以及模型推理结果的准确率，从而评估系统在临床流程中的价值并制定改进方案。数据分析师希望能够对原始数据进行批量查询、统计分析与可视化展示，以支持模型迭代与研究工作；他们还需要灵活的数据导入导出功能，以便与其他科研平台共享或复用数据。糖尿病高危人群作为终端受益者，需要通过移动端或网页端获取个性化风险评估结果，并接收针对性的生活方式干预建议，进而提升自我管理意识。上述用户需求共同体现了对系统实时性、准确性、可解释性与安全性的高度关注。

功能需求方面，系统首先需实现多源数据采集模块，支持与医院信息系统（HIS）、实验室信息管理系统（LIS）以及可穿戴设备的接口对接，自动拉取电子健康记录、实验室检验结果、基因组测序数据和行为监测数据，并进行统一格式化与标准化。其次是数据预处理与特征工程模块，能够自动完成缺失值插补、异常值检测、特征选择与归一化处理，为模型推理提供高质量输入。第三是模型推理服务，采用微服务架构将训练好的预测模型部署为独立服务，支持批量与单条推理请求，并返回风险评分、置信区间以及关键特征重要性。第四是结果展示与交互模块，提供可视化仪表盘展示患者风险曲线、关键指标变化及干预建议，并支持导出PDF或Excel报告。第五是警报与通知模块，依据阈值触发高危提示，通过短信、邮件或应用内推送方式及时告知医生和患者。第六是权限与安全管理模块，实施基于角色的访问控制、JWT身份认证以及TLS加密传输，确保患者数据的机密性与完整性。第七是日志与审计模块，记录所有数据访问、模型调用与系统操作，为合规审计与故障排查提供依据。最后是模型监控与再训练模块，持续跟踪推理结果的分布变化，并支持在线或离线方式自动更新模型，以保持预测性能的长期稳定。

七、可行性分析

经济可行性方面，本系统的开发与运营成本主要集中在软件研发、服务器租赁、数据存储与安全合规等环节。相较于传统的人工筛查流程，系统能够实现一次性投入后长期自动化运行，显著降低人力成本；根据国内医院信息化建设预算，预计初期研发费用约为人民币200万元，其中软件开发占70%，服务器与存储占20%，安全合规与测试占10%；后续运营费用主要为云服务租赁、系统维护与模型再训练，年均投入约为人民币50万元；从成本收益角度看，系统通过提高早期筛查率、减少糖尿病并发症的治疗费用，预计在三年内实现盈亏平衡，并在五年内产生可观的社会经济效益。社会可行性方面，糖尿病在我国已成为主要公共卫生问题之一，早期干预能够显著降低患者生活质量下降与医疗支出增加的风险；本系统通过提供个性化风险评估与干预建议，能够提升公众健康意识与自我管理能力；同时，该系统可与国家健康大数据平台对接，满足政府在精准医疗、慢性病管理方面的政策需求；在伦理层面，系统采用匿名化处理与加密存储技术，遵循《个人信息保护法》与《医疗机构信息化管理办法》，能够获得患者与监管部门的信任。技术可行性方面，SpringBoot框架已在国内外众多医疗信息系统中得到广泛应用，其微服务化、模块化特性能够满足系统高并发、低延迟的需求；数据采集层利用RESTful API与FHIR标准实现与HIS、LIS的无缝对接，已在多家医院完成技术试点；模型推理层采用ONNX或PMML格式部署，支持Java环境下的高效加载与推理；安全层面通过OAuth2.0、JWT以及TLS加密传输，满足医疗数据安全与合规要求；此外，系统设计预留了模型监控与再训练接口，可在实际运行中持续优化算法性能，保证长期可用性。综上所述，从经济、社会与技术三方面评估，本项目具备较高的可行性，为糖尿病早期风险评估提供了切实可行的技术与运营方案。

八、功能分析

系统功能模块可分为七大类，分别为数据采集与接口对接模块、数据预处理与特征工程模块、模型训练与管理模块、预测推理服务模块、风险评估结果展示与交互模块、告警通知与干预建议模块以及安全审计与运维监控模块。 数据采集与接口对接模块负责实现与医院信息系统（HIS）、实验室信息管理系统（LIS）以及可穿戴设备的标准化接口对接，支持RESTful API、FHIR和HL7等协议，以自动拉取电子健康记录、实验室检验结果、基因组测序数据和生活方式监测数据；该模块还提供批量导入与实时同步功能，确保数据流的完整性与时效性。 数据预处理与特征工程模块对采集到的原始数据进行清洗、缺失值插补、异常值检测与标准化处理，并通过信息熵、互信息等方法进行特征筛选；随后利用归一化、标准化或分箱技术将多维特征转换为模型可接受的格式，并生成特征矩阵供后续模型训练与推理使用。 模型训练与管理模块采用分层架构，首先在本地或云端进行数据集划分与交叉验证，随后在逻辑回归、随机森林、梯度提升树以及轻量级深度网络等多种算法上进行并行训练；模型训练完成后通过ONNX或PMML格式序列化，并存储于模型仓库中，支持版本管理与回滚功能；此外，该模块提供模型评估指标（AUC、准确率、召回率等）的可视化展示，以便数据科学家对模型进行持续优化。 预测推理服务模块以微服务方式部署，接收单条或批量预测请求，快速加载序列化模型并执行推理，返回风险评分、置信区间以及关键特征重要性（如SHAP值）；该模块实现高并发处理与低延迟响应，并通过缓存机制降低重复推理成本。 风险评估结果展示与交互模块为前端提供可视化仪表盘，展示患者的风险曲线、关键指标变化、历史趋势以及个性化干预建议；用户可以通过图表、热力图和报告导出功能获取详细信息，并支持多语言与移动端适配。 告警通知与干预建议模块根据设定阈值自动触发高危提示，利用短信、邮件或应用内推送方式及时告知医生和患者；同时系统根据模型输出与医学指南生成个性化生活方式干预建议（如饮食控制、运动计划、血糖监测频率等），并记录干预执行情况以供后续评估。 安全审计与运维监控模块负责实现基于角色的访问控制、JWT身份认证以及TLS加密传输；同时记录所有数据访问、模型调用与系统操作日志，支持合规审计与故障排查；此外，该模块提供系统健康监测（CPU、内存、网络延迟等）与自动化运维功能，确保服务持续可用。 通过上述七大功能模块的协同工作，系统能够实现从数据采集到风险评估、干预建议以及安全合规的完整闭环，为临床医生与患者提供可靠、高效且可解释的糖尿病风险预测服务。

九、数据库设计

表：Users
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
user_id | 用户编号 | 36 | CHAR(36) | 主键（PK）| 唯一标识用户
username | 用户名 | 50 | VARCHAR(50) | -| 登录凭证
password_hash | 密码哈希值 | 128 | VARCHAR(128) | -| 加密存储密码
role | 角色类型（如医生、管理员、患者） | 20 | VARCHAR(20) | -| 用于权限控制
created_at | 创建时间 | - | TIMESTAMP DEFAULT CURRENT_TIMESTAMP | -| 记录创建时间

表：Patients
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
patient_id | 患者编号 | 36 | CHAR(36) | 主键（PK）| 唯一标识患者
user_id | 用户编号（关联Users表） | 36 | CHAR(36) FOREIGN KEY REFERENCES Users(user_id) ON DELETE CASCADE | 外键（FK）| 与用户绑定
name | 姓名 | 100 | VARCHAR(100) | -| 患者姓名
gender | 性别（M/F/其他） | 1 | CHAR(1) | -|
birth_date | 出生日期 | - | DATE | -|
created_at | 记录创建时间 | - | TIMESTAMP DEFAULT CURRENT_TIMESTAMP | -|

表：HealthRecords
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
record_id | 体检记录编号 | 36 | CHAR(36) | 主键（PK）| 唯一标识体检记录
patient_id | 患者编号（关联Patients表） | 36 | CHAR(36) FOREIGN KEY REFERENCES Patients(patient_id) ON DELETE CASCADE | 外键（FK）|
visit_date | 就诊日期 | - | DATE | -|
height_cm | 身高（厘米） | 5 | DECIMAL(5,1) | -|
weight_kg | 体重（千克） | 5 | DECIMAL(5,1) | -|
blood_pressure_systolic | 收缩压（mmHg） | 4 | INT | -|
blood_pressure_diastolic | 舒张压（mmHg） | 4 | INT | -|
created_at | 记录创建时间 | - | TIMESTAMP DEFAULT CURRENT_TIMESTAMP | -|

表：LabResults
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
lab_id | 检验编号 | 36 | CHAR(36) | 主键（PK）| 唯一标识检验记录
patient_id | 患者编号（关联Patients表） | 36 | CHAR(36) FOREIGN KEY REFERENCES Patients(patient_id) ON DELETE CASCADE | 外键（FK）|
test_date | 检验日期 | - | DATE | -|
fasting_glucose_mmol_l | 空腹血糖（mmol/L） | 5 | DECIMAL(5,2) | -|
hba1c_percent | HbA1c（%） | 4 | DECIMAL(4,2) | -|
lipid_total_mg_dl | 总胆固醇（mg/dL） | 5 | DECIMAL(5,1) | -|
created_at | 记录创建时间 | - | TIMESTAMP DEFAULT CURRENT_TIMESTAMP | -|

表：WearableData
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
wearable_id | 可穿戴设备数据编号 | 36 | CHAR(36) | 主键（PK）| 唯一标识设备数据
patient_id | 患者编号（关联Patients表） | 36 | CHAR(36) FOREIGN KEY REFERENCES Patients(patient_id) ON DELETE CASCADE | 外键（FK）|
record_time | 记录时间戳 | - | TIMESTAMP | -|
steps_daily | 日步数 | 10 | BIGINT | -|
heart_rate_avg_bpm | 平均心率（bpm） | 4 | INT | -|
sleep_hours | 睡眠时长（小时） | 5 | DECIMAL(5,2) | -|
created_at | 记录创建时间 | - | TIMESTAMP DEFAULT CURRENT_TIMESTAMP | -|

表：GenomicData
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
genomic_id | 基因组数据编号 | 36 | CHAR(36) | 主键（PK）| 唯一标识基因组记录
patient_id | 患者编号（关联Patients表） | 36 | CHAR(36) FOREIGN KEY REFERENCES Patients(patient_id) ON DELETE CASCADE | 外键（FK）|
variant_list | 变异列表（JSON格式） | - | JSON | -|
sequencing_date | 测序日期 | - | DATE | -|
created_at | 记录创建时间 | - | TIMESTAMP DEFAULT CURRENT_TIMESTAMP | -|

表：RiskScore
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
score_id | 风险评分编号 | 36 | CHAR(36) | 主键（PK）| 唯一标识评分记录
patient_id | 患者编号（关联Patients表） | 36 | CHAR(36) FOREIGN KEY REFERENCES Patients(patient_id) ON DELETE CASCADE | 外键（FK）|
score_value | 风险评分值（0-100） | 5 | DECIMAL(5,2) | -|
score_date | 评分时间戳 | - | TIMESTAMP DEFAULT CURRENT_TIMESTAMP | -|
model_version | 模型版本号（如v1.0） | 10 | VARCHAR(10) | -|

表：InterventionPlan
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
plan_id | 干预方案编号 | 36 | CHAR(36) | 主键（PK）| 唯一标识干预记录
patient_id | 患者编号（关联Patients表） | 36 | CHAR(36) FOREIGN KEY REFERENCES Patients(patient_id) ON DELETE CASCADE | 外键（FK）|
plan_date | 方案制定时间戳 | - | TIMESTAMP DEFAULT CURRENT_TIMESTAMP | -|
recommendation_text | 干预建议文本（JSON或TEXT格式） | - | TEXT | -|
status | 方案状态（如未执行、已执行、已完成） | 20 | VARCHAR(20) | -|

表：AuditLog
字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注
log_id | 日志编号 | 36 | CHAR(36) | 主键（PK）| 唯一标识日志记录
user_id | 用户编号（关联Users表） | 36 | CHAR(36) FOREIGN KEY REFERENCES Users(user_id) ON DELETE SET NULL | 外键（FK）|
action_type | 操作类型（如登录、查询、更新） | 20 | VARCHAR(20) | -|
action_time | 操作时间戳 | - | TIMESTAMP DEFAULT CURRENT_TIMESTAMP | -|
description | 操作描述（可包含SQL语句或业务描述） | - | TEXT | -|

以上表结构遵循第一范式与第二范式，主键唯一标识记录，外键实现表间关联，避免冗余与更新异常。

十、建表语句

CREATE DATABASE IF NOT EXISTS diabetes_risk_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
USE diabetes_risk_db;

-- 1. 用户表
CREATE TABLE IF NOT EXISTS Users (
user_id CHAR(36) NOT NULL,
username VARCHAR(50) NOT NULL UNIQUE,
password_hash VARCHAR(128) NOT NULL,
role VARCHAR(20) NOT NULL,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (user_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 2. 患者表
CREATE TABLE IF NOT EXISTS Patients (
patient_id CHAR(36) NOT NULL,
user_id CHAR(36) NOT NULL,
name VARCHAR(100) NOT NULL,
gender CHAR(1),
birth_date DATE,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (patient_id),
CONSTRAINT fk_patients_user
FOREIGN KEY (user_id) REFERENCES Users(user_id)
ON DELETE CASCADE ON UPDATE CASCADE,
INDEX idx_patients_user (user_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 3. 体检记录表
CREATE TABLE IF NOT EXISTS HealthRecords (
record_id CHAR(36) NOT NULL,
patient_id CHAR(36) NOT NULL,
visit_date DATE,
height_cm DECIMAL(5,1),
weight_kg DECIMAL(5,1),
blood_pressure_systolic INT,
blood_pressure_diastolic INT,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (record_id),
CONSTRAINT fk_health_records_patient
FOREIGN KEY (patient_id) REFERENCES Patients(patient_id)
ON DELETE CASCADE ON UPDATE CASCADE,
INDEX idx_health_records_patient (patient_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 4. 实验室检验结果表
CREATE TABLE IF NOT EXISTS LabResults (
lab_id CHAR(36) NOT NULL,
patient_id CHAR(36) NOT NULL,
test_date DATE,
fasting_glucose_mmol_l DECIMAL(5,2),
hba1c_percent DECIMAL(4,2),
lipid_total_mg_dl DECIMAL(5,1),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (lab_id),
CONSTRAINT fk_lab_results_patient
FOREIGN KEY (patient_id) REFERENCES Patients(patient_id)
ON DELETE CASCADE ON UPDATE CASCADE,
INDEX idx_lab_results_patient (patient_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 5. 可穿戴设备数据表
CREATE TABLE IF NOT EXISTS WearableData (
wearable_id CHAR(36) NOT NULL,
patient_id CHAR(36) NOT NULL,
record_time TIMESTAMP,
steps_daily BIGINT,
heart_rate_avg_bpm INT,
sleep_hours DECIMAL(5,2),
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (wearable_id),
CONSTRAINT fk_wearable_data_patient
FOREIGN KEY (patient_id) REFERENCES Patients(patient_id)
ON DELETE CASCADE ON UPDATE CASCADE,
INDEX idx_wearable_data_patient (patient_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 6. 基因组数据表
CREATE TABLE IF NOT EXISTS GenomicData (
genomic_id CHAR(36) NOT NULL,
patient_id CHAR(36) NOT NULL,
variant_list JSON,
sequencing_date DATE,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (genomic_id),
CONSTRAINT fk_genomic_data_patient
FOREIGN KEY (patient_id) REFERENCES Patients(patient_id)
ON DELETE CASCADE ON UPDATE CASCADE,
INDEX idx_genomic_data_patient (patient_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 7. 风险评分表
CREATE TABLE IF NOT EXISTS RiskScore (
score_id CHAR(36) NOT NULL,
patient_id CHAR(36) NOT NULL,
score_value DECIMAL(5,2),
score_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
model_version VARCHAR(10),
PRIMARY KEY (score_id),
CONSTRAINT fk_risk_score_patient
FOREIGN KEY (patient_id) REFERENCES Patients(patient_id)
ON DELETE CASCADE ON UPDATE CASCADE,
INDEX idx_risk_score_patient (patient_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 8. 干预方案表
CREATE TABLE IF NOT EXISTS InterventionPlan (
plan_id CHAR(36) NOT NULL,
patient_id CHAR(36) NOT NULL,
plan_date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
recommendation_text TEXT,
status VARCHAR(20),
PRIMARY KEY (plan_id),
CONSTRAINT fk_intervention_plan_patient
FOREIGN KEY (patient_id) REFERENCES Patients(patient_id)
ON DELETE CASCADE ON UPDATE CASCADE,
INDEX idx_intervention_plan_patient (patient_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

-- 9. 审计日志表
CREATE TABLE IF NOT EXISTS AuditLog (
log_id CHAR(36) NOT NULL,
user_id CHAR(36),
action_type VARCHAR(20),
action_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
description TEXT,
PRIMARY KEY (log_id),
CONSTRAINT fk_audit_log_user
FOREIGN KEY (user_id) REFERENCES Users(user_id)
ON DELETE SET NULL ON UPDATE CASCADE,
INDEX idx_audit_log_user (user_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

文章下方名片联系我即可~大家点赞、收藏、关注、评论啦 、查看下方👇🏻获取联系方式👇🏻