sdu软件学院创新实训个人博客6

2026/6/15 19:06:35

前言

在本阶段的创新实训项目开发中，我主要完成了“患儿既往史健康档案仓”这一功能模块的设计与实现。该模块功能主要存放在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_submit=True):

把整套录入流程封装进同一个表单中。这样用户只有点击提交按钮时，系统才会统一处理表单内容，避免输入过程中因为页面实时重跑而打断录入体验。表单中我主要设置了以下字段：

患儿姓名/昵称
确诊疾病名称
医院确诊/就诊日期
就诊确诊医院
治疗方案/用药说明
备注信息

其中，确诊疾病名称是我设置的核心必填项，因为它决定了这条档案最基本的医学含义；而医院、治疗方案、备注等字段允许为空，但会在提交前做兜底处理，避免写入数据库后出现结构不完整的问题。

3. 数据落盘与接口封装

如果只有前端表单而没有后端落盘，那么“健康档案仓”依然只是一个界面概念。因此在录入功能完成后，我继续补齐了数据层逻辑，把既往史信息正式写入数据库。

在实现方式上，我没有把 SQL 直接写进页面文件，而是把与既往史相关的操作统一封装到app/db/models.py中，分别提供了：

create_medical_history(...)
get_medical_history_by_user(...)
delete_medical_history(...)

与此同时，我在app/db/database.py中新增了medical_history表，用于存储患儿既往史相关信息，主要字段包括：

user_id
child_name
disease_name
diagnosed_date
hospital
treatment
notes

为了让按账户查询更加高效，我还为user_id建立了索引。这样设计之后，页面层负责收集输入和反馈结果，数据层负责真正的持久化操作，整个模块的职责边界就比较清晰。

4. 既往史卡片展示

在有了数据之后，我接着实现的是既往史档案的查看功能。这里我没有采用简单的字段直出，而是选择通过容器循环渲染的方式，把每条病史档案做成独立卡片。

页面中我先调用了

histories = get_medical_history_by_user(current_user["id"])

获取当前账户下的全部既往史记录，再逐条生成卡片式内容。卡片中我对信息做了分层处理：

标题层展示确诊疾病和患儿姓名；
元信息层展示确诊日期和医院；
正文层展示治疗方案与备注说明。

为了提升页面可读性，我还通过st.markdown(..., unsafe_allow_html=True)注入了自定义 CSS，对卡片的圆角、边框、阴影、留白、字体层级和浅色背景进行了统一设计。这样做的原因很简单：既往史数据本身信息密度高，如果直接用原始列表堆出来，用户阅读时会很累；而卡片式展示更适合医疗档案这种需要快速扫读和核对的业务场景。