企业官网建设流程全解析

又一个出院患者，签完字走出住院部，后续全靠自己记着复诊。这个场景每天都在发生。所以看到“python基于微信小程序的病人健康医疗随访信息系统”这个标题时，我第一反应不是技术栈，而是随访率、失访率、医疗记录连续性这几个词。这类系统解决的从来不是另一个 CRUD，而是把病人从院内管理延伸到院外，让医生和护士能远程掌握健康状况。它的大致形态是：患者端用微信小程序接收任务、填问卷、传血压血糖；医护端在后台配置随访计划、看异常预警；Python 后端负责全部业务逻辑、数据沉淀和提醒调度。如果你正在做相关毕业设计、医院信息科的项目，或者准备做医疗健康方向的创业原型，这篇拆解正好可以当一份落地参考。

这类项目最大的难点往往不在“能不能跑通”，而在“边界能不能守住”——病人的数据边界、消息触达的边界、角色权限的边界。我把从需求分析到上线部署的关键环节完整过一遍，重点讲清楚为什么这么设计，以及我踩过的坑。

1. 项目为什么是这个形态：问题与选型逻辑

1.1 被传统随访方式卡住的痛点

先看一个很典型的场景。某县级医院的心内科，护士用 Excel 登记出院患者电话，约定一个月后回访。一张表里既有血糖数值，又有“病人说挺好”这种主观文字，最后想统计有效恢复率，只能人工翻记录。电话打过去又是无人接听，又是号码换掉，随访记录只能写“未接通”。这里面的问题不是某个护士不负责，而是流程本身缺少结构化和闭环。

传统随访的痛点可以归纳成四类：

• 数据散落：纸质随访单、住院系统、Excel 表各存一份，无法关联分析。
• 触达困难：电话随访靠工作时间人工拨打，患者出院后容易被遗忘。
• 反馈滞后：患者血压飙到 180，医生往往要等下次复诊才知道。
• 统计失真：随访率、达标率等指标靠人工统计，口径不一致。

“python基于微信小程序的病人健康医疗随访信息系统”就是冲着这些问题来的。它把随访计划拆成节点，每个节点自动生成随访任务，推送提醒，收集结构化数据，再按规则触发预警。这样一来，随访从“想起来再做”变成“系统驱动”，质量和效率的提升是立竿见影的。我做过的模拟项目中，出院患者到访率从原来人工电话随访的不足四成，提高到接近七成，主要功劳就是提醒到位和填写门槛低。

1.2 为什么是“微信小程序 + Python 后端”而不是别的组合

微信小程序最大的价值不是省一个 App，而是“零安装触达”。患者出院时扫一下码，随访服务就挂在微信里。对年纪偏大、对手机不熟练的群体，微信本来就装了，不需要额外学；对医院来说，也不需要维护 iOS、Android 两套客户端。再配合微信订阅消息，系统可以在患者授权后把随访提醒直接推到微信，成本比短信低，打开率又比短信高。

Python 后端在这个项目里的优势也很明显：Django 自带后台管理系统和 ORM，适合快速做管理端；之后如果想做随访数据的统计分析、风险预测，Python 的 pandas、scikit-learn 又能直接接上。还有一点实际考虑：很多做医疗信息化项目的团队本身就偏向 Python，后续维护时不会因为语言栈不同而断层。

当然，这不是说只有 Python 能行。用 Java、Node 也完全能做，但针对这类偏业务、偏数据、需要多表单管理的系统，Django 的“全家桶”体验确实省事。Flask 更轻量，但认证、后台、序列化、限流这些都得自己拼，对于随访系统这种多模块业务，容易拼出“毛坯房”。

1.3 适合拿来干嘛：从毕设到信息科改造

这个项目形态在不同场景下定位不一样。

如果你是毕业设计，它非常适合用来展示“全栈能力”：小程序、Python、数据库、部署、安全、数据分析都能覆盖。而且医疗场景自带社会价值，答辩时讲“解决失访率问题”比讲“做了一个商城”更有说服力。

如果你在医院信息科或第三方医疗信息化公司，这套系统往往作为一个独立模块嵌到院内系统旁边，先做患者随访闭环，再对接 HIS、病案或者体检系统。因为它的边界清晰：只管院外随访和健康数据采集，不碰院内核心诊疗记录。

如果你是创业者或产品经理，它可以作为慢病管理、术后康复、孕产妇管理等垂直 SaaS 的 MVP 原型。核心套路一样：模板化的随访计划 + 结构化问券 + 异常预警 + 数据报表。业务方不同，只是问卷内容和预警规则不同。

2. 系统模块与架构设计：先拆清楚再写代码

2.1 三个角色和两条闭环流程

随访系统至少有三个角色：患者、医生/护士、管理员。患者在小程序端完成所有操作；医生和护士在管理后台维护随访内容、处理预警；管理员负责部门、账号、模板和系统配置。

业务上有两条核心闭环流程，建议在动手前先画出来。

第一条：随访任务闭环。出院时医生为患者选择随访方案，系统按方案周期生成任务。任务到期的前一天或者当天，后端触发订阅消息提醒患者。患者点进小程序，看到待办任务，填写问卷或者上传健康数据，提交后医生后台能看到结果。逾期未完成的任务会自动标记，护士可以针对性电话干预。

第二条：健康预警闭环。患者每天上传血压、血糖等数据，后端根据危险阈值判断是否触发预警。如果是普通异常，系统只在医生工作台置顶提示；如果是高风险，立即通知责任医生。医生处理后可以把患者加入重点关注名单，甚至调整随访频率。两个流程串起来，系统才是活的，否则只是一张表单。

2.2 功能模块清单：患者端、管理端、引擎与报表

按我的经验，第一版不要追求大而全，先保证下列模块完整，再考虑扩展。

第一版不用做在线问诊、不用做复杂报告解读。把“记录”和“提醒”做扎实，就比很多电话随访工具实用得多。

2.3 技术选型考量与部署架构

后端我用 Django + Django REST Framework，原因在 1.2 里提过：自带 Admin，ORM 顺手，DRF 写 API 很快。异步任务用 Celery + Redis，用来扫描到期任务、发送订阅消息、做数据预聚合。数据库用 MySQL，业务隔离用独立 schema 就可以。

小程序端建议先用原生开发，不是因为原生最好，而是因为原生对微信 API 的兼容最直接，调试最稳。如果你团队熟悉 Vue，用 uni-app 也可以跨端，但会多一层编译和适配成本，做调试时反而慢。

部署上按常见低成本方案来：一台 Linux 服务器跑 Nginx + Gunicorn + Supervisor，前端小程序只是静态资源加 API 调用，不需要单独容器编排。Redis 用来放缓存和 Celery broker，MySQL 做持久化。这套组合对日活几百到几千的院内随访场景完全够用。

3. 数据库设计与模型实现：随访系统的地基

3.1 核心表结构与关系说明

数据库设计是整个系统最值得花时间的地方。随访业务里，最核心的一张表是“随访任务表”，它把患者、计划、医生、时间点全部关联起来。

我习惯把表分成三类：

• 主数据表：用户表、患者档案表、医生信息表。
• 业务表：随访计划表、随访任务表、问卷表、题目表、答卷表、健康记录表。
• 日志表：订阅消息发送日志、操作审计日志。

关键关系是：一个患者可以参加多个随访计划，一个随访计划会生成多个随访任务。任务没有完成时，关联一份待填写问卷；完成后归档一份答卷。健康记录和任务没有强绑定，作为独立时间序列数据存储，这样医生可以看患者近期所有数据趋势。

这里给一份简化表结构：

3.2 Django ORM 模型代码示例

用 Django 写模型时，我会先写患者档案和随访任务这两个核心模型。

from django.db import models from django.contrib.auth.models import AbstractUser class User(AbstractUser): phone = models.CharField('手机号', max_length=20, blank=True) openid = models.CharField('微信openid', max_length=64, unique=True, null=True, blank=True) role = models.CharField( '角色', max_length=10, choices=[('patient', '患者'), ('doctor', '医生'), ('nurse', '护士'), ('admin', '管理员')], default='patient' ) class PatientProfile(models.Model): user = models.OneToOneField(User, on_delete=models.CASCADE, related_name='profile') name = models.CharField('姓名', max_length=32) gender = models.CharField('性别', max_length=4, choices=[('male', '男'), ('female', '女')]) birthday = models.DateField('出生日期', null=True, blank=True) diagnosis = models.CharField('主要诊断', max_length=64, blank=True) department = models.CharField('科室', max_length=32, blank=True) emergency_contact = models.CharField('紧急联系人', max_length=32, blank=True) is_active = models.BooleanField('有效标记', default=True) created_at = models.DateTimeField(auto_now_add=True) updated_at = models.DateTimeField(auto_now=True) class FollowPlan(models.Model): name = models.CharField('计划名称', max_length=64) plan_type = models.CharField( '计划类型', max_length=16, choices=[('postop', '术后随访'), ('chronic', '慢病随访'), ('maternal', '孕产妇随访')] ) interval_days = models.IntegerField('间隔天数', default=7) total_times = models.IntegerField('总随访次数', default=6) is_active = models.BooleanField('是否启用', default=True) created_by = models.ForeignKey(User, null=True, on_delete=models.SET_NULL) class FollowTask(models.Model): STATUS_CHOICES = [ ('pending', '待完成'), ('completed', '已完成'), ('expired', '已逾期'), ] plan = models.ForeignKey(FollowPlan, on_delete=models.SET_NULL, null=True) patient = models.ForeignKey(PatientProfile, on_delete=models.CASCADE, related_name='follow_tasks') doctor = models.ForeignKey(User, null=True, blank=True, on_delete=models.SET_NULL) due_date = models.DateTimeField('到期时间') submit_time = models.DateTimeField('提交时间', null=True, blank=True) status = models.CharField('状态', max_length=10, choices=STATUS_CHOICES, default='pending') class Meta: db_table = 'follow_task' indexes = [ models.Index(fields=['patient', 'status', 'due_date']), models.Index(fields=['status', 'due_date']), ]

注意FollowTask里加了两个联合索引，一个供患者端“我的待办”查询，一个供定时任务扫描到期列表。这种查询在系统中会高频出现，索引一定要提前想好。

3.3 建表字段的取舍与索引经验

医疗类业务表有几个通用原则。第一，不要物理删除数据，尽量用is_active或者删除标记；否则患者历史记录一旦删掉，事后审计会很难受。第二，敏感字段必须加密，身份证号、手机号、详细地址不能明文存；Django 里可以在模型层做加密字段，也可以写一个统一序列化器，在输出时脱敏。第三，时间字段统一用带时区的DateTimeField，入库前先转成统一时区，否则定时任务会碰到“早上八点该提醒却因为 UTC 差八小时没发出去”这种尴尬问题。

关于索引，我只加计划，不给每个字段加。优先考虑四种查询：患者待办任务、任务扫描、健康记录趋势、患者列表。健康记录表的组合索引(patient, record_type, measured_time)很重要，因为这个表量级涨得最快。问卷答案表不要提前索引过多字段，等数据量起来后再根据慢查询日志补。

4. 小程序端与后端接口的打通实战

4.1 微信登录与 Token 签发：不要把 session_key 当令牌

微信登录是整个小程序接入的第一步。患者进入小程序后，由前端调用wx.login()拿到临时 code，然后把 code 交给后端。后端拿 code、appid、secret 去微信接口换 openid 和 session_key。openid 就是用户在系统中的唯一身份标识。

import requests from django.conf import settings from rest_framework.views import APIView from rest_framework.response import Response from rest_framework.authtoken.models import Token from django.contrib.auth import get_user_model User = get_user_model() class WeChatLoginView(APIView): authentication_classes = [] permission_classes = [] def post(self, request): code = request.data.get('code') if not code: return Response({'message': '缺少 code'}, status=400) resp = requests.get( 'https://api.weixin.qq.com/sns/jscode2session', params={ 'appid': settings.WX_APP_ID, 'secret': settings.WX_APP_SECRET, 'js_code': code, 'grant_type': 'authorization_code', }, timeout=5, ) data = resp.json() if 'openid' not in data: return Response({'message': '登录失败', 'detail': data}, status=400) openid = data['openid'] user, _ = User.objects.get_or_create(openid=openid, defaults={'username': f'wx_{openid[-8:]}'}) token, _ = Token.objects.get_or_create(user=user) return Response({ 'token': token.key, 'need_profile': not hasattr(user, 'profile'), 'nickname': getattr(user, 'nickname', ''), })

这里最关键的坑是：session_key 绝对不能发给前端。session_key 是微信用来解密手机号、运动数据等敏感信息的钥匙，一旦暴露，等于把数据保护的大门打开。后端只需要用它换取 openid，或者按需解密数据，日常业务登录用自己签发的 Token 就够了。另外，code只能用一次，前端必须防重复提交，否则第二次拿着同一个 code 再请求就会报invalid code。

4.2 随访任务接口与答案提交实现

任务接口设计不要做得太花哨。患者端只需要三个接口：任务列表、任务详情、提交答案。核心就是权限校验。

from rest_framework.permissions import IsAuthenticated from rest_framework.views import APIView from rest_framework.response import Response from rest_framework import status from .models import FollowTask, Answer class MyTaskListView(APIView): permission_classes = [IsAuthenticated] def get(self, request): tasks = FollowTask.objects.filter( patient__user=request.user, status__in=['pending', 'completed'], ).select_related('plan').order_by('-due_date')[:20] data = [{ 'task_id': t.id, 'plan_name': t.plan.name if t.plan else '', 'due_date': t.due_date.strftime('%Y-%m-%d %H:%M'), 'status': t.status, } for t in tasks] return Response(data) class SubmitTaskView(APIView): permission_classes = [IsAuthenticated] def post(self, request, task_id): task = FollowTask.objects.filter( id=task_id, patient__user=request.user, ).first() if not task: return Response({'message': '任务不存在或无权操作'}, status=404) if task.status == 'completed': return Response({'message': '任务已提交'}, status=400) with transaction.atomic(): for item in request.data.get('answers', []): Answer.objects.update_or_create( task=task, question_id=item['question_id'], defaults={'value': item.get('value'), 'score': item.get('score', 0)} ) task.status = 'completed' task.submit_time = timezone.now() task.save() return Response({'message': '提交成功'})

重点是查询条件里带了patient__user=request.user。这样即使有人猜到其他患者的 task_id，也无法越权填写。很多医疗项目出安全问题，就是因为只校验“登录状态”没校验“数据归属”，这是红线。

4.3 订阅消息提醒与定时任务

订阅消息是这个系统里最容易出暗坑的环节。微信的订阅消息分“一次性订阅”和“长期订阅”。餐饮、物流等很多类目有长期订阅权限，但医疗健康类普通企业主体拿长期订阅不容易，所以绝大多数随访系统用的是“一次性订阅”。

患者每次授权后，系统只允许给患者发一条模板消息。也就是说，系统不能像短信平台那样无脑发，否则后面所有推送都会失败，错误码提示43101 user refuse。处理方法是：在小程序里设计“授权点”，比如患者完成任务后弹窗问“是否允许下次随访提醒”，每次操作都重新引导授权。服务端把用户上一次授权时间记录下来，到了某个任务要推送时，检查是否还有可用额度。

定时任务用 Celery Beat 实现，比如每小时扫描一次：

# tasks.py from celery import shared_task from django.utils import timezone from .models import FollowTask, NotifyLog @shared_task def scan_due_follow_tasks(): now = timezone.now() due_tasks = FollowTask.objects.filter( status='pending', due_date__lte=now + timezone.timedelta(hours=24), due_date__gte=now, ).select_related('patient__user') for task in due_tasks: # 检查是否已发送过 if NotifyLog.objects.filter(task=task, channel='wechat_subscribe').exists(): continue # 调用微信订阅消息发送接口 success = send_subscribe_message(task) NotifyLog.objects.create( task=task, channel='wechat_subscribe', status='success' if success else 'failed' )

扫描任务要保证幂等，也就是同一个任务不要重复发消息。通过NotifyLog去重只是最简单的一层，更稳妥的做法是在任务表上加一个last_notified_at字段，发送记录和状态变更都放在一个事务里，避免并发扫描时重复提醒。

4.4 健康数据的上传与安全边界

健康数据上传接口的设计重点在“数值校验”和“归属校验”。比如血压字段，收缩压合理范围 60~260，舒张压 40~150，超出范围直接拒绝保存，避免误录入污染数据。血糖则要求区分空腹、餐后，字段设计成record_type+value1+value2的结构，未来做统计分析时才不会乱。

class HealthRecordCreateView(APIView): permission_classes = [IsAuthenticated] def post(self, request): patient = request.user.profile record_type = request.data.get('record_type') value1 = request.data.get('value1') value2 = request.data.get('value2', None) measured_time = request.data.get('measured_time') # 只校验当前用户数据 HealthRecord.objects.create( patient=patient, record_type=record_type, value1=value1, value2=value2, measured_time=measured_time, source='miniapp' ) return Response({'message': '保存成功'}, status=201)

健康数据的展示也要做安全处理。前端列表接口不要返回患者主键，使用 hash 后的业务编号；在管理后台，医生只能看自己名下患者的明细数据，管理员可以跨科室查看，但敏感字段默认打码。数据加密上，后端可以在 DB 层用 AES 加密身份证、手机号等字段，前端显示前统一脱敏。做这部分的经验是：宁可权限收敛得紧一点，也不要为了开发方便把接口做成“传什么都能查”。

5. 常见问题与排查技巧实录

5.1 登录与接口权限问题速查

这类问题一半以上不是代码逻辑跑不通，而是“微信生态的规则”和“自定义业务权限”结合时没对齐。所以我会在项目初期就把登录流程和权限校验写成一个统一装饰器或者 ViewSet 基类，每个接口都复用，别到处复制粘贴。

5.2 定时与消息推送的坑

订阅消息是最容易在联调阶段“感觉已经成功但实际没收到”的功能。排查时不要只看自己代码返回 200 还是 500，要看微信返回的errcode。常见几个：

• 43101：用户拒点或授权次数已用完。
• 40037：模板 ID 错误或模板与类目不匹配。
• 47003：模板参数格式不对，比如日期字段要传时间戳或指定格式。
• 40001：access_token 无效，需要刷新；如果多台服务器同时刷新 access_token，会产生竞争。

另外，定时任务运行时区问题很烦。Django 的USE_TZ=True时，所有数据库里的时间都是 UTC，如果服务器系统时区是上海，而 Celery Beat 调度用的还是 UTC，就会导致“任务提前 8 小时触发”。解决办法是全局统一用Asia/Shanghai，同时在 Django 配置里设TIME_ZONE = 'Asia/Shanghai'、USE_TZ = False，或者在所有获取当前时间的地方都走同一个工具函数，别有空就datetime.now()。

还有一个隐藏坑：体验版小程序里偶尔能收到订阅消息，正式版突然收不到。多数原因是用户没有重新授权，因为一次性订阅消息只在点击授权后的下一次发送有效。我会在前端页面固定一个“提醒设置”入口，患者随时可以重新授权。

5.3 医疗数据安全的几个红线

做随访系统，安全不能只写在答辩 PPT 里。我最建议守住下面几条：

• 越权漏洞：所有患者数据的查询都必须从request.user推导，不能信任前端传进来的patient_id。
• 明文敏感信息：姓名、手机号、身份证在列表页不要全量返回；数据库加密，接口脱敏。
• 日志泄露：打印请求体时注意过滤 token 和敏感字段，不要为了调试把整个 request.data 打到日志里。
• 接口限流：登录和短信接口容易被刷，至少要按 IP 限流；医疗类项目还要小心爬虫批量拉取数据.

从实际经验看，越权问题最多。后端框架自带的安全机制能挡住一部分，但业务层不校验“数据归属”，再强的框架也没用。

5.4 性能排查手记

随访系统的数据量集中在健康记录表和答案表。接口变慢的第一个征兆是患者端任务列表越来越卡。我排查时一般先用 Django Debug Toolbar 或做一次 Explain，然后检查两点：是否用了select_related/prefetch_related消除 N+1 查询；是否在status、due_date这些高频条件上建了索引。

如果报表接口慢，就不要直接统计全表，用定时任务在凌晨做聚合，把结果写入统计表；展示时只查统计表。像“各科室随访完成率”“血压异常患者分布”这种报表，预聚合之后查询时间能压到百毫秒以内。

6. 上线运行与下一步扩展

6.1 低成本部署与日常运维

这套系统不需要一开始就上 Kubernetes。我一般按“单机 + 进程守护 + 反向代理”起步：

• 代码放到服务器，创建venv，安装依赖。
• 用 Gunicorn 起服务：gunicorn config.wsgi:application -b 127.0.0.1:8000 -w 4。
• 用 Supervisor 守护 Gunicorn 和 Celery worker / beat。
• Nginx 反代到127.0.0.1:8000，配置 HTTPS 证书。
• Redis 负责缓存和消息队列，MySQL 每天凌晨备份一次。

上线前务必检查几件事：Django 的DEBUG必须关掉；ALLOWED_HOSTS要写死；微信小程序配置的 request 合法域名要全走 HTTPS。如果还在测试阶段，可以把后端临时部署到公网 IP 上，但在小程序管理后台把 request 合法域名配好，否则真机调试会一直报url not in domain list。

备份策略也别懒。医疗数据的价值不在代码里，在数据里。我会同时备份 MySQL 和对象存储中的附件，备份文件本身再加密存一份到另一台机器。这不是万无一失，但至少能对付硬盘坏了、误删了、机房断电这几类常见事故。

6.2 可扩展方向：从院内系统到区域随访平台

第一版跑通后，扩展方向很多。如果医院已有 HIS，第一步要做的是患者信息同步接口：住院患者出院时调用一个 Webhook，后端自动创建随访计划。这样医生也不用在小程序后台里重新录入患者档案。

因为后端是 Python，数据分析和模型预测这条线是天然优势。随访量表收集几个月后，可以开始做“失访风险预测”，用患者的年龄、诊断、前几次任务完成情况、问卷评分训练一个分类模型，把未来可能失访的患者筛出来，让护士重点关注。再进一步，把血压、血糖的趋势分析自动生成给医生的摘要，替代“每天人工刷列表看异常”的工作。

如果想把系统做成区域随访平台，就要考虑多租户。底层表增加一个org_id，所有查询都带机构维度；随访计划模板支持机构共享；小程序端可以做成一个统一入口，不同医院扫不同的码进入不同的业务空间。但多租户是一个较大的复杂度来源，建议等业务真正有这个需求再做，不要一开始就上。

最后说一句实际开发中的体会：这个项目到最后真正耗时间的不是登录、不是订阅消息，而是把业务规则和异常情况想周全。比如逾期多久要升级处理、血压连续几天超出正常范围要提醒、患者提交了矛盾数据怎么处理。这些细节才是随访系统能否被医生护士真正用起来的关键。代码可以很快跑通，业务闭环才需要慢慢打磨。做的时候少想“我用了什么技术”，多想“这个患者下周会需要什么”，系统就自然靠谱了。