博主介绍✌ 专注于VUE,小程序安卓Java,python,物联网专业 从事毕业指导项目实战✌选取一个适合的毕业设计题目很重要。✌关注✌私信我✌具体的问题我会尽力帮助你。一、研究目的研究旨在构建一种基于SpringBoot框架与微信小程序技术的社区健康档案管理系统以满足当前社区医疗服务数字化转型的迫切需求。随着人口老龄化加剧和慢性疾病谱扩展传统纸质档案管理方式已难以满足精准医疗、连续随访及多方协同的要求导致信息孤岛现象普遍存在。通过引入SpringBoot强大的后端服务能力与微信小程序的广泛用户基础本研究计划实现健康档案数据的统一采集、存储与共享提升数据完整性与可追溯性。系统将采用RESTful API接口设计支持多终端访问并通过OAuth2.0认证机制保障用户隐私与数据安全。研究还将聚焦于模块化设计原则确保功能扩展的可维护性与兼容性从而为社区医疗机构提供可持续的技术支撑。最终目标是实现健康档案管理的高效、精准与智能化为公共卫生决策提供可靠的数据支撑并通过系统评估验证其在实际应用中的可行性与价值。通过本研究期望为我国社区医疗信息化建设提供一种可复制、可推广的技术方案并为相关领域的学术研究与产业实践提供参考与借鉴。二、研究意义本研究通过整合SpringBoot后端服务与微信小程序前端技术构建社区健康档案管理系统具有显著的理论与实践价值。 在理论层面该系统提供了基于微服务架构的数据治理模型可为健康信息学研究提供可复制的实验平台从而推动数据标准化与互操作性的深入探讨。 从实践角度看系统实现了健康档案的统一采集、存储与共享显著降低了社区医疗机构在信息录入、查询与统计方面的人工成本提高了工作效率。 此外系统通过OAuth2.0认证与加密存储机制有效保障了个人健康信息的隐私安全为大数据时代下的健康信息治理提供了可行的技术方案。 该平台支持多终端访问与模块化扩展可快速集成慢病管理、健康教育、远程诊疗等功能满足社区医疗服务多元化、个性化需求。 通过对系统的功能评估与用户体验调查本研究将为社区健康档案数字化转型提供实证依据并为相关政策制定与技术推广提供决策支持。 综上所述本研究不仅填补了国内社区健康档案管理系统在技术架构与安全性方面的空白还为公共卫生信息化建设提供了可复制、可持续的解决方案具有重要的社会价值与推广意义。三、国内外研究现状国内外在社区健康档案管理系统领域的研究呈现出多元化发展趋势主要可归纳为信息标准化与互操作性、系统架构与技术实现、数据安全与隐私保护以及移动端应用与用户体验四大方向。 在信息标准化方面国外学者普遍采用 HL7 FHIR 规范进行健康数据的结构化描述并通过 OMOP Common Data Model 进行跨机构数据整合取得了可观的互操作性成果国内则在国家卫生健康委发布的《电子健康档案技术标准》基础上结合 GB/T 35273-2018 标准开展了本土化的标准化研究并推动了 FHIR 与中国医疗信息系统的兼容性实验。 在系统架构与技术实现层面国外研究多聚焦于微服务架构与云原生部署利用 Kubernetes、Docker 等技术实现弹性扩展国内学术工作则以 SpringBoot 为核心框架探索基于微服务的社区健康档案管理平台并通过 API 网关、服务熔断等机制提升系统可用性。 在数据安全与隐私保护方面欧美学者借助 HIPAA 等法规制定了严格的数据访问控制模型并在区块链技术上实现了不可篡改的健康记录链国内则侧重于多层加密、角色权限管理以及基于 GDPR 的跨境数据流动研究提出了符合国内法律环境的安全策略。 在移动端应用与用户体验领域国外研究多采用 React Native、Flutter 等跨平台框架构建患者门户和健康管理 APP强调交互设计与个性化服务国内则以小程序技术为载体结合社区医疗机构的服务流程开展了基于微信生态的健康档案查询与随访功能实验并通过用户行为分析优化界面布局与功能模块。 综上所述国内外研究在技术标准、系统架构、数据安全和移动端应用等方面均已取得显著进展但仍存在标准统一度不足、跨机构数据共享受限以及移动端体验不够友好的问题。 本研究将借鉴国外成熟的微服务与 FHIR 标准并结合国内社区医疗特点采用 SpringBoot 与小程序技术实现高效、安全、易用的社区健康档案管理系统以期填补现有研究空白并推动我国社区医疗信息化水平提升。四、预期达到目标及解决的关键问题预期目标在于构建一套基于SpringBoot后端服务与微信小程序前端技术的社区健康档案管理系统该系统能够实现健康数据的统一采集、标准化存储与高效共享并通过多层安全机制保障个人隐私与数据完整性。首先系统将采用微服务架构将用户身份认证、档案管理、随访提醒、统计分析等功能拆分为独立服务以实现模块化开发与灵活扩展其次后端将遵循 HL7 FHIR 标准对健康信息进行结构化描述并通过统一的接口层向前端提供 RESTful API确保数据在不同终端之间的无缝交互再次在安全层面将引入 OAuth2.0 授权框架与 AES 加密存储机制配合数据库访问控制与日志审计实现对数据访问的细粒度管理最后在用户体验层面微信小程序将采用响应式设计与交互式表单简化健康信息录入流程并通过推送通知实现随访提醒与健康教育推送从而提升社区居民的使用黏性与满意度。通过上述目标的实现本研究期望在技术可行性、数据安全性与用户友好性方面达到国内领先水平为社区医疗机构提供一套可复制、可持续的健康档案管理解决方案。关键问题主要集中在数据异构性、隐私合规性、系统互操作性与用户接受度四个方面。首先社区健康档案来源多样包括纸质记录、医院电子病历与个人自测数据等导致数据格式、编码标准不统一如何通过 ETL 过程实现高质量的数据清洗与映射是技术挑战其次个人健康信息属于高度敏感数据需严格遵守《网络安全法》与《个人信息保护法》相关条款如何在保证功能完整性的前提下实现数据脱敏、访问审计与合规审查是系统设计的核心难点再次系统需要与现有医疗信息平台如 HIS、EMR以及政府健康管理平台实现互联互通需解决不同标准与接口协议之间的兼容问题并通过统一的数据治理框架保证数据一致性最后用户接受度受到技术熟悉度、隐私担忧与使用习惯等多重因素影响如何通过简洁的界面设计、透明的隐私说明与持续的用户教育提升系统采纳率是实现社会价值的重要考量。针对上述关键问题本研究将采用标准化数据模型、分层安全架构、微服务治理与用户体验迭代等方法力求在技术创新与社会实践之间搭建稳固桥梁。五、研究内容本研究总体框架围绕基于SpringBoot与微信小程序的社区健康档案管理系统构建展开主要包括需求分析、系统设计、关键技术实现、性能评估与推广应用五个环节。首先在需求分析阶段将通过访谈社区医疗机构工作人员、居民以及卫生信息管理专家梳理健康档案采集流程、数据存储结构、权限管理需求以及用户交互习惯并形成系统功能规格说明书随后在系统设计阶段将采用微服务架构对后端进行模块化拆分包括用户认证服务、档案管理服务、随访提醒服务与统计分析服务等并通过统一的 API 网关实现跨域调用前端则采用微信小程序框架设计响应式界面支持多种输入方式表单、扫描二维码、语音识别以提升数据录入效率在关键技术实现阶段将重点解决数据标准化问题利用 HL7 FHIR 资源模型对健康信息进行结构化描述并通过 ETL 工具将异构来源的数据映射至统一数据库同时系统将实现 OAuth2.0 授权与 JWT 令牌机制配合 AES-256 加密存储与日志审计功能确保个人健康信息在传输与存储过程中的机密性与完整性此外为满足社区医疗机构对报表与统计的需求将构建基于 Spark 或 Flink 的实时数据分析管道并提供可视化仪表盘供管理员查看关键指标。性能评估阶段将采用负载测试工具如 JMeter模拟多用户并发访问评估系统在峰值流量下的响应时间与吞吐量并通过安全渗透测试验证系统抵御常见攻击手段的能力最后在推广应用阶段将选择典型社区医疗机构进行试点部署收集使用反馈迭代优化产品功能并制定技术手册与培训方案为大规模推广提供可复制的实施路径。通过上述研究内容本项目旨在实现一套安全、高效、易用的社区健康档案管理系统为社区医疗服务数字化转型提供技术支撑与实践案例。六、需求分析用户需求方面社区健康档案管理系统的主要使用者包括社区卫生服务人员、居民以及社区医疗机构管理层。社区卫生服务人员需要快速、准确地采集居民的基本信息、既往病史、慢性疾病管理记录以及随访结果并能够在工作现场通过移动终端即时录入数据避免因纸质记录导致的信息延迟与错误居民则期望通过微信小程序轻松查询自己的健康档案、接收健康教育推送、预约随访并对个人信息进行自主管理提升健康管理的主动性与参与度社区医疗机构管理层关注系统的整体运营效率与数据质量需通过统计分析功能掌握社区居民健康状况分布、慢性疾病患病率以及医疗资源利用情况以便制定精准干预措施。除此之外所有用户都对系统的安全性与隐私保护抱有高度关注期望在保证信息完整性的前提下能够获得明确的数据访问权限说明与异常告警提示从而建立对系统的信任。功能需求方面系统首先必须实现健康档案的统一采集模块该模块支持多种数据来源纸质转录、电子病历接口、居民自测设备同步并通过标准化映射将异构数据转换为 HL7 FHIR 资源格式其次档案存储与管理模块需提供高可用数据库方案支持事务一致性、版本控制与审计日志以满足医疗信息系统对数据完整性的严格要求随后查询与检索功能必须实现多维度筛选时间范围、疾病类型、服务机构等并提供快速响应满足临床决策与公共卫生监测的即时需求另外随访提醒与健康教育推送模块应支持定时任务调度、个性化内容推送以及用户反馈收集以提升居民健康管理的持续性在权限与安全管理方面系统需实现基于角色的访问控制、OAuth2.0 授权认证、数据加密存储与传输以及安全审计与合规报告生成功能最后为支持决策制定系统应提供报表生成与可视化分析功能包括疾病流行趋势图、资源利用率图表以及居民健康评分体系以便管理层快速获取洞察。七、可行性分析经济可行性方面系统的研发与部署成本主要集中在后端微服务开发、数据库建设、前端小程序设计以及安全加密与合规审计等技术环节。通过采用开源框架 SpringBoot 与 Docker 容器化部署可显著降低软件许可费用与运维成本同时利用微信小程序的生态优势前端开发成本相对传统 App 更为低廉。系统上线后将实现居民健康信息的电子化管理减少纸质档案的打印、存储与人工录入工作从而在社区卫生服务中心产生可观的人力成本节约与工作效率提升。基于此预计在系统运行的第三年即可实现投入产出比平衡并在随后的运营周期内为社区医疗机构带来持续的经济收益。社会可行性方面随着居民健康意识的提升以及政府对数字健康管理的政策支持社区健康档案管理系统具有较高的社会接受度。系统通过微信小程序平台实现与居民日常使用场景的无缝对接使居民能够便捷地查询个人健康记录、接收随访提醒及健康教育内容从而增强其主动参与健康管理的意愿。与此同时系统提供的数据统计与分析功能可为社区卫生服务中心制定精准干预措施、优化资源配置提供依据进一步提升公共卫生服务质量与社会效益。技术可行性方面系统采用微服务架构与容器化部署能够实现高可用性与弹性扩展满足社区医疗机构对系统稳定性的严格要求。数据层面通过 HL7 FHIR 标准实现健康信息的结构化描述并利用 OAuth2.0 与 JWT 机制保障身份认证与授权安全在存储与传输过程中采用 AES-256 加密技术符合《网络安全法》与《个人信息保护法》的合规要求。综上所述从经济、社会与技术三维度来看该系统具备较高的可行性为社区健康档案管理提供了可复制、可持续的解决方案。八、功能分析系统功能模块设计围绕用户需求与技术实现两大维度展开逻辑层次分为四大功能域身份与权限管理、健康档案数据处理、社区服务交互与提醒以及数据分析与决策支持。 在身份与权限管理域内系统提供基于 OAuth2.0 的统一认证服务支持社区卫生服务人员、居民及管理层三类角色的登录授权并通过角色权限表实现细粒度访问控制同时用户信息模块维护个人基本资料、联系方式与隐私设置并通过加密存储与安全审计机制保障数据完整性与合规性。 在健康档案数据处理域中系统集成多源数据采集接口包括纸质转录、医院 HIS/EMR 电子接口及居民自测设备同步通过 ETL 流程将异构数据映射至 HL7 FHIR 资源模型并存入统一数据库档案管理子模块支持增删改查、版本追溯与历史记录回溯满足临床决策与公共卫生监测需求。 在社区服务交互与提醒域系统实现预约随访管理功能支持时间调度、提醒推送与状态跟踪消息通知子模块利用微信小程序推送机制向居民发送健康教育内容、疾病预防提示及个性化随访提醒同时在线问卷与反馈收集模块为社区医疗机构提供居民满意度与服务改进依据。 在数据分析与决策支持域系统搭建实时统计引擎聚合慢性病患病率、就诊频次、资源利用率等关键指标并通过可视化仪表盘呈现趋势图表报表生成子模块支持自定义报表模板与定期导出功能为管理层制定精准干预策略提供数据支撑此外合规报告生成模块能够自动汇总安全审计日志、访问记录与数据脱敏操作满足政府监管与行业标准要求。 通过上述功能模块的协同工作系统实现了从数据采集到决策支持的闭环管理为社区健康档案数字化提供完整、可扩展且安全可靠的技术方案。九、数据库设计表名users字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注id | 用户唯一标识主键。 | 36 | CHAR(36) | PK | UUIDusername | 登录用户名唯一。 | 50 | VARCHAR(50) | |password_hash | 密码哈希值。 | 128 | VARCHAR(128) |email | 邮箱地址。 | 100 | VARCHAR(100) |phone | 联系电话。 | 20 | VARCHAR(20) |role_id | 用户角色标识外键关联roles.id。 | 36 | CHAR(36) | FK to roles.id |created_at | 创建时间。 | 19 | DATETIME |updated_at | 最后更新时间。 | 19 | DATETIME |表名roles字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注id | 角色唯一标识主键。 | 36 | CHAR(36) | PK |name | 角色名称例如“管理员”“社区医生”“居民”。 | 50 | VARCHAR(50) |表名user_roles字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注user_id | 用户标识外键关联users.id。 | 36 | CHAR(36) | FK to users.id |role_id | 角色标识外键关联roles.id。 | 36 | CHAR(36) | FK to roles.id |表名permissions字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注id | 权限唯一标识主键。 | 36 | CHAR(36) | PK |name | 权限描述例如“查看档案”“编辑档案”。 | 100 | VARCHAR(100) |表名role_permissions字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注role_id | 角色标识外键关联roles.id。 | 36 | CHAR(36) | FK to roles.id |permission_id | 权限标识外键关联permissions.id。 | 36 | CHAR(36) | FK to permissions.id |表名patient_info字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注patient_id | 患者唯一标识主键。 | 36 | CHAR(36) | PK |user_id | 与users表关联的用户标识外键。 | 36 | CHAR(36) | FK to users.id |name | 患者姓名。 | 50 | VARCHAR(50) |gender | 性别枚举值“男”“女”。 | 10 | VARCHAR(10) |birthdate | 出生日期。 | 10 | DATE |address | 居住地址。 | 200 | VARCHAR(200) |phone | 联系电话。 | 20 | VARCHAR(20) |email | 邮箱地址。 | 100 | VARCHAR(100) |表名health_record字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注record_id | 档案唯一标识主键。 | 36 | CHAR(36) | PK |patient_id | 患者标识外键关联patient_info.patient_id。 | 36 | CHAR(36) | FK to patient_info.patient_id |record_type | 档案类型例如“门诊”“检查”。 | 20 | VARCHAR(20) |content | 档案内容JSON或文本。 | 65535 | TEXT |created_at | 创建时间。 | 19 | DATETIME |表名chronic_disease字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注disease_id | 疾病记录唯一标识主键。 | 36 | CHAR(36) | PK |patient_id | 患者标识外键关联patient_info.patient_id。 | 36 | CHAR(36) | FK to patient_info.patient_id |disease_name | 疾病名称。 | 100 | VARCHAR(100) |diagnosis_date | 诊断日期。 | 10 | DATE |status | 疾病状态例如“已治愈”“持续管理”。 | 20 | VARCHAR(20) |表名appointment字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注appointment_id | 预约唯一标识主键。 | 36 | CHAR(36) | PK |patient_id | 患者标识外键关联patient_info.patient_id。 | 36 | CHAR(36) | FK to patient_info.patient_id |staff_user_id | 医务人员用户标识外键关联users.id。 | 36 | CHAR(36) | FK to users.id |scheduled_time | 预约时间。 | 19 | DATETIME |status | 预约状态例如“待确认”“已完成”。 | 20 | VARCHAR(20) |表名notification_log字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注notification_id | 通知唯一标识主键。 | 36 | CHAR(36) | PK |user_id | 接收用户标识外键关联users.id。 | 36 | CHAR(36) | FK to users.id |title | 通知标题。 | 100 | VARCHAR(100) |content | 通知内容。 | 65535 | TEXT |sent_at | 发送时间。 | 19 | DATETIME |read_at | 阅读时间若未读则为空。 | 19 | DATETIME |表名audit_log字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注audit_id | 审计日志唯一标识主键。 | 36 | CHAR(36) | PK |user_id | 操作用户标识外键关联users.id。 | 36 | CHAR(36) | FK to users.id |action | 操作类型例如“新增”“修改”。 | 50 | VARCHAR(50) |target_table | 受影响的表名。 | 50 | VARCHAR(50) |target_id | 受影响记录的主键值。 | 36 | CHAR(36) |timestamp | 操作时间。 | 19 | DATETIME |表名fhir_resource字段名(英文) | 说明(中文) | 大小 | 类型 | 主外键 | 备注resource_id | FHIR资源唯一标识主键。 | 36 | CHAR(36) | PK |patient_id | 患者标识外键关联patient_info.patient_id。 | 36 | CHAR(36) | FK to patient_info.patient_id |resource_type | FHIR资源类型例如“Patient”“Observation”。 | 50 | VARCHAR(50) |resource_json | 资源完整JSON内容。 | 65535 | TEXT |以上表结构均遵循第一范式与第二范式字段拆分避免冗余主外键关系清晰满足系统对数据完整性、可扩展性与安全性的需求。十、建表语句CREATE TABLE roles (id CHAR(36) NOT NULL,name VARCHAR(50) NOT NULL,PRIMARY KEY (id),UNIQUE KEY idx_roles_name (name)) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE permissions (id CHAR(36) NOT NULL,name VARCHAR(100) NOT NULL,PRIMARY KEY (id),UNIQUE KEY idx_permissions_name (name)) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE users (id CHAR(36) NOT NULL,username VARCHAR(50) NOT NULL,password_hash VARCHAR(128) NOT NULL,email VARCHAR(100),phone VARCHAR(20),role_id CHAR(36),created_at DATETIME DEFAULT CURRENT_TIMESTAMP,updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,PRIMARY KEY (id),UNIQUE KEY idx_users_username (username),KEY idx_users_role_id (role_id),CONSTRAINT fk_users_role_id FOREIGN KEY (role_id) REFERENCES roles(id) ON DELETE SET NULL ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE user_roles (user_id CHAR(36) NOT NULL,role_id CHAR(36) NOT NULL,PRIMARY KEY (user_id, role_id),KEY idx_user_roles_role_id (role_id),CONSTRAINT fk_user_roles_user_id FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE ON UPDATE CASCADE,CONSTRAINT fk_user_roles_role_id FOREIGN KEY (role_id) REFERENCES roles(id) ON DELETE CASCADE ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE role_permissions (role_id CHAR(36) NOT NULL,permission_id CHAR(36) NOT NULL,PRIMARY KEY (role_id, permission_id),KEY idx_role_permissions_permission_id (permission_id),CONSTRAINT fk_role_permissions_role_id FOREIGN KEY (role_id) REFERENCES roles(id) ON DELETE CASCADE ON UPDATE CASCADE,CONSTRAINT fk_role_permissions_permission_id FOREIGN KEY (permission_id) REFERENCES permissions(id) ON DELETE CASCADE ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE patient_info (patient_id CHAR(36) NOT NULL,user_id CHAR(36),name VARCHAR(50) NOT NULL,gender VARCHAR(10),birthdate DATE,address VARCHAR(200),phone VARCHAR(20),email VARCHAR(100),PRIMARY KEY (patient_id),KEY idx_patient_info_user_id (user_id),CONSTRAINT fk_patient_info_user_id FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE SET NULL ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE health_record (record_id CHAR(36) NOT NULL,patient_id CHAR(36) NOT NULL,record_type VARCHAR(20),content TEXT,created_at DATETIME DEFAULT CURRENT_TIMESTAMP,PRIMARY KEY (record_id),KEY idx_health_record_patient_id (patient_id),CONSTRAINT fk_health_record_patient_id FOREIGN KEY (patient_id) REFERENCES patient_info(patient_id) ON DELETE CASCADE ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE chronic_disease (disease_id CHAR(36) NOT NULL,patient_id CHAR(36) NOT NULL,disease_name VARCHAR(100),diagnosis_date DATE,status VARCHAR(20),PRIMARY KEY (disease_id),KEY idx_chronic_disease_patient_id (patient_id),CONSTRAINT fk_chronic_disease_patient_id FOREIGN KEY (patient_id) REFERENCES patient_info(patient_id) ON DELETE CASCADE ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE appointment (appointment_id CHAR(36) NOT NULL,patient_id CHAR(36) NOT NULL,staff_user_id CHAR(36),scheduled_time DATETIME NOT NULL,status VARCHAR(20),PRIMARY KEY (appointment_id),KEY idx_appointment_patient_id (patient_id),KEY idx_appointment_staff_user_id (staff_user_id),CONSTRAINT fk_appointment_patient_id FOREIGN KEY (patient_id) REFERENCES patient_info(patient_id) ON DELETE CASCADE ON UPDATE CASCADE,CONSTRAINT fk_appointment_staff_user_id FOREIGN KEY (staff_user_id) REFERENCES users(id) ON DELETE SET NULL ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE notification_log (notification_id CHAR(36) NOT NULL,user_id CHAR(36),title VARCHAR(100),content TEXT,sent_at DATETIME DEFAULT CURRENT_TIMESTAMP,read_at DATETIME,PRIMARY KEY (notification_id),KEY idx_notification_log_user_id (user_id),CONSTRAINT fk_notification_log_user_id FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE SET NULL ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE audit_log (audit_id CHAR(36) NOT NULL,user_id CHAR(36),action VARCHAR(50),target_table VARCHAR(50),target_id CHAR(36),timestamp DATETIME DEFAULT CURRENT_TIMESTAMP,PRIMARY KEY (audit_id),KEY idx_audit_log_user_id (user_id),CONSTRAINT fk_audit_log_user_id FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE SET NULL ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE fhir_resource (resource_id CHAR(36) NOT NULL,patient_id CHAR(36),resource_type VARCHAR(50),resource_json TEXT,PRIMARY KEY (resource_id),KEY idx_fhir_resource_patient_id (patient_id),CONSTRAINT fk_fhir_resource_patient_id FOREIGN KEY (patient_id) REFERENCES patient_info(patient_id) ON DELETE SET NULL ON UPDATE CASCADE) ENGINEInnoDB DEFAULT CHARSETutf8mb4;文章下方名片联系我即可~大家点赞、收藏、关注、评论啦 、查看下方获取联系方式