sdu软件学院创新实训 个人博客6 前言在本阶段的创新实训项目开发中我主要完成了“患儿既往史健康档案仓”这一功能模块的设计与实现。该模块功能主要存放在pages/2_medical_history.py其目标并不是单纯新增一个表单页而是让系统具备既往史信息的结构化录入、档案化展示、物理删除以及普通登录用户可自主维护 的完整能力。这一阶段的工作重点是把原本分散、一次性的病史信息整理成一个可查看、可管理、可复用、可与账户绑定的健康档案仓为后续智能预诊提供更加稳定的前置医疗信息支撑。本阶段的主要功能实现1. 登录门控与权限下放我在做这个模块时首先处理的不是表单而是权限边界。因为既往史属于敏感健康信息如果页面能被未登录用户直接访问那么后续所有功能都失去了意义。所以我在pages/2_medical_history.py中优先通过st.session_state.get(logged_in)判断用户是否已登录如果未登录就直接提示并跳转回主页面同时调用st.stop()终止后续的渲染。在完成基础门控之后我进一步把这一功能模块从偏管理员控制的逻辑中释放出来真正实现了 权限下放。这里的下放并不是让所有人都能看所有数据而是让普通登录用户也能自主维护自己的既往史档案。因此我在页面中使用current_user st.session_state.user并将新增、查询、删除操作全部与current_user[id]绑定。这样一来登录用户可以进入既往史页面每个用户只能读取自己账户下的病史档案每个用户也只能操作属于自己的记录。这个功能的作用非常直接它让系统从“后台可维护”变成了“前台可自助”同时又保证了数据隔离是我这一阶段在业务权限设计上的一个关键改进。2. 结构化表单录入在完成访问控制之后我又实现了既往史的录入功能。过去病史信息如果只是零散地写在对话里不仅不方便复用也不利于后续分析。所以我在这个阶段把病史录入做成了一个正式的结构化表单让它真正具备“建档”的意义。具体实现时我使用了 Streamlit 的with st.form(medical_history_form, clear_on_submitTrue):把整套录入流程封装进同一个表单中。这样用户只有点击提交按钮时系统才会统一处理表单内容避免输入过程中因为页面实时重跑而打断录入体验。表单中我主要设置了以下字段患儿姓名/昵称确诊疾病名称医院确诊/就诊日期就诊确诊医院治疗方案/用药说明备注信息其中确诊疾病名称是我设置的核心必填项因为它决定了这条档案最基本的医学含义而医院、治疗方案、备注等字段允许为空但会在提交前做兜底处理避免写入数据库后出现结构不完整的问题。3. 数据落盘与接口封装如果只有前端表单而没有后端落盘那么“健康档案仓”依然只是一个界面概念。因此在录入功能完成后我继续补齐了数据层逻辑把既往史信息正式写入数据库。在实现方式上我没有把 SQL 直接写进页面文件而是把与既往史相关的操作统一封装到app/db/models.py中分别提供了create_medical_history(...)get_medical_history_by_user(...)delete_medical_history(...)与此同时我在app/db/database.py中新增了medical_history表用于存储患儿既往史相关信息主要字段包括user_idchild_namedisease_namediagnosed_datehospitaltreatmentnotes为了让按账户查询更加高效我还为user_id建立了索引。这样设计之后页面层负责收集输入和反馈结果数据层负责真正的持久化操作整个模块的职责边界就比较清晰。4. 既往史卡片展示在有了数据之后我接着实现的是既往史档案的查看功能。这里我没有采用简单的字段直出而是选择通过容器循环渲染的方式把每条病史档案做成独立卡片。页面中我先调用了histories get_medical_history_by_user(current_user[id])获取当前账户下的全部既往史记录再逐条生成卡片式内容。卡片中我对信息做了分层处理标题层展示确诊疾病和患儿姓名元信息层展示确诊日期和医院正文层展示治疗方案与备注说明。为了提升页面可读性我还通过st.markdown(..., unsafe_allow_htmlTrue)注入了自定义 CSS对卡片的圆角、边框、阴影、留白、字体层级和浅色背景进行了统一设计。这样做的原因很简单既往史数据本身信息密度高如果直接用原始列表堆出来用户阅读时会很累而卡片式展示更适合医疗档案这种需要快速扫读和核对的业务场景。5. 物理删除与动态刷新既往史档案一旦进入系统就必须允许用户在录入错误、重复提交或信息失效时进行纠正。因此在这一阶段我还完成了删除功能并且把删除后的页面刷新一起打通形成了完整闭环。具体来说我为每一条既往史卡片都配置了独立的删除按钮。用户点击后系统会调用delete_medical_history(h[id])对对应记录进行物理删除。删除成功后我进一步执行st.rerun()这样页面会立即重跑并重新加载最新数据用户可以立刻看到删除后的结果而不会出现“数据删了但界面还停留在原状态”的问题。这个功能的作用不仅仅是“提供删除按钮”更重要的是实现了错误数据可回收、前端视图可同步、交互结果可即时确认。对一个健康档案类模块来说这种一致性是非常重要的。总结总体来说这一阶段我主要完成了一个围绕患儿既往史信息展开的小型健康档案仓模块。将页面交互、权限控制、数据库落盘、卡片展示与动态刷新几部分工作的内容打通形成了较完整的阶段性成果。在后续迭代中我准备继续围绕该模块做进一步完善主要方向包括补充真正的修改功能、增强结构化程度、补充筛选与检索能力。