微信小程序病人随访系统开发实战：从需求到闭环设计

如果把“基于微信小程序的病人健康医疗随访信息系统”简单理解成“做一个电子问卷”，开发到一半大概率会翻车。真实场景里，你面对的可能是一群刚办了出院手续、身体状态还在恢复中的患者，还有一个每天要打电话回访、还要手写记录到本子上的护士。我接手这个项目时，最早的调研就暴露出一个真相：很多科室的随访率不理想，并不完全是医生不想做，而是“名单整理、电话沟通、结果记录、异常追踪”这些动作全散在人工流程里，任何一环断了，整个随访就断了。

这篇文章把我从需求分析、数据库设计、小程序端表单渲染，到订阅消息和权限配置踩过的坑，完整拆开讲一遍。既适合把“基于微信小程序的毕设”当成练手项目的开发者，也适合医院信息科或者想给科室做小工具的基层技术团队参考。你不一定要照抄我的每一行代码，但这里的业务边界、数据结构和微信限制，值得在做之前先想清楚。

1. 先读懂随访场景：这不是做一个问卷工具那么简单

随访系统在医院里不是新鲜词，但它和普通问卷最大的区别在于：问卷是一次性采集“我想知道的信息”，随访是围绕“某一个具体患者”的持续性观察记录。

单纯按问卷工具开发的系统，很容易做成这样：一个表单模板，患者填完，存在数据库里，管理员能导成 Excel，好像就完事了。可实际使用时，护士会问几个让你愣住的问题：这个患者出院后第7天的随访任务是谁安排的？如果他第5天就来复查了，还需要打电话问吗？上一次随访记录里有“胸闷”，这次有没有变化？这些需求都指向同一个事实——随访系统必须围绕“患者任务”来组织数据，而不是围绕“表单”来组织数据。

1.1 传统电话随访模式里最拖后腿的三个环节

我先说我看到的典型工作流：护士把出院患者登记在一个本子上，每天上班先翻本子，看哪些人到了随访时间，然后依次打电话。打完电话，再把“伤口恢复良好、需继续换药、血压偏高”等内容手写到记录栏里。

这个流程有三个明显的断点：

第一，名单很容易漏。出院患者分布在不同的科室和病区，如果护士休假或者临时换岗，接手的同事只能依赖本子上的手写记录，很难快速知道“今天应该随访哪些人”。

第二，过程数据是散的。电话里聊到的信息，有的护士会认真记，有的可能只写一句“已联系，暂无异常”。到月底写总结时，缺少结构化数据，既统计不出随访完成率，也看不出患者症状变化的趋势。

第三，异常情况没有闭环。比如电话里患者说“伤口有点红肿”，护士在电话里提醒继续观察，然后呢？没有人知道几天后红肿有没有好转。因为下一次随访任务和上一次结果之间，没有任何联动逻辑。

这些痛点，其实就是一个随访信息系统的核心价值：把任务排期、结构化记录、异常提醒连起来。

1.2 为什么入口选微信小程序，而不是 App 或 Web 页面

微信小程序在这个场景里的优势非常明显：患者不需要下载新软件，微信扫一扫或者点开聊天记录里的小程序码就能进入；对年龄偏大、对手机操作不熟悉的患者，微信本身就是他们最熟悉的应用，学习成本最低。很多出院患者家里还会让子女帮忙操作，小程序转发给子女后，家属代填也很方便。

但微信小程序也给你带来了额外的开发约束，这一点必须提前接受：

• 小程序包体大小有限，不适合塞大图表和复杂报表；
• 类目审核和隐私保护声明有门槛，尤其涉及“健康信息”时，需要比普通工具类小程序多准备不少材料；
• 订阅消息虽然能做随访提醒，但不能像服务号一样自由推送，也没有“无限推送”的能力。

所以我的项目整体定位是：小程序端只做患者填报和轻度查询，真正给医护看的后台管理放到单独的管理端页面。一个复杂系统硬塞进小程序，体验一定糟糕。

2. 落地一个 MVP 之前，先把核心数据流设计出来

很多开发者的习惯是一上来就写页面，把小程序前端搞得花里胡哨，最后做到一半发现没法填数据。正确顺序是先画业务数据流：谁创建任务、谁接任务、谁填结果、谁看结果。

我设计的核心闭环是下面这样一条链：

1. 医护人员在后台录入出院患者基础信息，并为其绑定一份随访模板；
2. 系统根据随访计划自动（或人工）生成一次待完成随访任务；
3. 患者端小程序收到任务提醒，打开对应的随访表单；
4. 患者填写完成后，结果进入随访记录表；
5. 后台根据规则判断记录是否存在异常指标，并展示在护士待办中。

这里面有几个角色：患者、医护人员、系统管理员。其中患者永远不应该是“登录后台”的角色，他只通过微信小程序与系统交互。

2.1 最少需要哪些数据对象

我梳理下来，最少需要四类对象：患者档案、随访模板、随访任务、随访记录。如果只做“出院后7天随访一次”这种极简场景，可以暂时不做“患者档案”以外的用户权限系统，但模板、任务、记录这三张表不能省。

为什么任务表不能省？因为你要统计“应随访多少人、实际完成多少人”。如果没有任务表，只存在一张“患者填过什么表单”的记录表，你根本说不清哪些人是被漏掉的。这也是随访系统区别问卷表工具的核心所在。

2.2 表单模板必须是动态数据，不能写死页面

不同科室的随访内容差异很大：呼吸内科出院随访要问咳嗽、咳痰、体温；骨科手术随访要问切口、疼痛评分、功能锻炼；慢病随访要关注血压、血糖、服药依从性。如果每个科室都开发一套写死的页面，你至少要做几十个页面，且后续每次内容调整都要重新发版审核。

所以必须把“一份随访表”描述成结构化数据，让同一个页面引擎去渲染。我用的表单描述结构大致是这样的：

json复制{
  "templateId": "resp_7day",
  "name": "呼吸科出院7天随访",
  "items": [
    {
      "key": "temperature",
      "label": "最近3天测量的最高体温",
      "type": "input",
      "placeholder": "例如 36.8"
    },
    {
      "key": "cough",
      "label": "是否仍然咳嗽",
      "type": "radio",
      "options": [
        { "label": "没有咳嗽", "value": "none" },
        { "label": "偶尔咳嗽", "value": "occasional" },
        { "label": "经常咳嗽", "value": "frequent" }
      ]
    },
    {
      "key": "symptoms",
      "label": "目前有哪些不适症状",
      "type": "checkbox",
      "options": [
        { "label": "胸闷", "value": "chest_tightness" },
        { "label": "呼吸困难", "value": "dyspnea" },
        { "label": "咳黄痰", "value": "yellow_sputum" },
        { "label": "无明显不适", "value": "none" }
      ]
    }
  ]
}

页面上渲染时，只需要遍历 items，根据 type 决定渲染输入框、单选组还是多选组。这样每个科室只需要在后台配置一份 JSON，就能生成自己的随访表。这个思路极大减少了后续维护成本，也是这个项目里我明显觉得“值”的设计。

2.3 数据表基础字段设计

我用的是微信云开发，底层是文档型数据库，集合结构设计如下：

在实际开发中，有一个字段很多人容易漏：phoneTail。患者绑定身份时，我们用“住院号 + 姓名 + 留院手机号后四位”做校验，比单纯依赖微信手机号授权要可靠得多。后面我会专门展开讲为什么需要这个降级方案。

3. 小程序端如何实现“患者友好”的填报体验

页面设计并不复杂，但需要从患者视角考虑整个操作节奏。我把小程序端分成了四个主要页面：

• 首页：展示“当前待完成随访”和“即将到期随访”，点击直接进入填报；
• 随访填报页：根据模板动态渲染表单；
• 历史记录页：查看自己过去提交过的随访结果；
• 我的页面：身份绑定、提醒开关、关于说明。

登录设计上，我这里没有采用“强制授权才能使用”的思路。很多刚上手的开发者会给小程序加一个登录页，用户不点允许就不给进，这在随访系统里是致命的——患者本身就可能不太舒服，还被一道授权弹窗拦住，很容易直接关掉。

3.1 动线设计：先扫码进入，再完成身份绑定

完整的动线应该是这样的：患者在护士台扫小程序码，进入首页后先看到“请先绑定出院患者身份”的提示，输入住院号、姓名、手机号后四位，后端校验通过，就完成绑定。技术底层仍然用 wx.login 获取 openid，但这个 openid 并不会在一开始就用来拦住用户，只是作为患者表的关联字段。

这样做的原因是，微信的 openid 对普通用户来说毫无感知，他根本不关心你是不是拿到了他的身份标识，他只关心填这些信息会不会泄露隐私。你先把“待随访任务”展示出来，再引导绑定，转化率远高于“先注册/登录”的设计。

3.2 动态渲染表单的关键代码结构

小程序 WXML 里用一个 wx:for 循环就能渲染整套表单：

xml复制<view class="form-card" wx:for="{{formItems}}" wx:key="key">
  <view class="form-label">{{item.label}}</view>

  <input
    wx:if="{{item.type === 'input'}}"
    value="{{formData[item.key]}}"
    bindinput="onInputChange"
    data-key="{{item.key}}"
    placeholder="{{item.placeholder}}"
  />

  <radio-group
    wx:elif="{{item.type === 'radio'}}"
    bindchange="onRadioChange"
    data-key="{{item.key}}"
  >
    <label class="option" wx:for="{{item.options}}" wx:for-item="opt" wx:key="value">
      <radio value="{{opt.value}}" checked="{{formData[item.key] === opt.value}}" />
      <text>{{opt.label}}</text>
    </label>
  </radio-group>

  <checkbox-group
    wx:elif="{{item.type === 'checkbox'}}"
    bindchange="onCheckboxChange"
    data-key="{{item.key}}"
  >
    <label class="option" wx:for="{{item.options}}" wx:for-item="opt" wx:key="value">
      <checkbox value="{{opt.value}}" checked="{{selectSet[item.key][opt.value]}}" />
      <text>{{opt.label}}</text>
    </label>
  </checkbox-group>
</view>

这里有一个非常关键的细节：单选的值是字符串，多选的值是数组。radio-group 的 bindchange 事件里，event.detail.value 直接是比如 "occasional" 这样的字符串。但 checkbox-group 里返回的是一个数组，例如 ["none"]，或者 ["cough","chest_tightness"]。提交时不能只把两个字段原样存起来，最好统一序列化成 JSON，这样数据库里保持同一种结构。

多选还有一个容易踩的坑：选项里有“无明显不适”，患者又勾了“胸闷”。这种情况不是技术错误，是业务逻辑冲突，但病人不会觉得是自己选错了，只会觉得系统有点“傻”。处理方式是在 onCheckboxChange 里做互斥判断：如果选了“无明显不适”，则清空其他项；如果选了其他项，则自动去掉“无明显不适”。这个小逻辑不复杂，但对实际体验提升非常大。

3.3 草稿、暂存和提交成功的交互原则

很多患者填到一半可能去接电话、照顾孩子，或者手滑退出了小程序。如果没有草稿功能，再进来又要从头填，体验会很差。

我的处理方式很简单：在 onInputChange、onRadioChange、onCheckboxChange 的事件里，每次更新 formData 后同步写入 wx.setStorageSync('draft_' + taskId, formData)。在页面加载时优先从缓存里恢复。提交成功后再移除缓存。

提交成功页不要只放一个“已完成”文字，最好在按钮区提供“查看本次填报明细”。因为很多患者会担心自己是不是没填对，让他立刻看到填报内容能减少很多焦虑。另外也要注意，在“提交成功”这个页面上，可以顺势提供“接收下一次随访提醒”的按钮，这个动作直接关联到订阅消息授权，比一开始进页面就弹授权要自然得多。

4. 服务端与微信开放能力：登录、订阅消息、隐私接口

小程序前端只是入口，真正让随访流程自动转起来的是服务端逻辑。我采用的是微信云开发，因为它能省去服务器采购和部署流程，在项目早期阶段快速验证业务模型非常划算。如果你的团队已经熟悉 Spring Boot、NestJS 这类后端，也不影响，核心逻辑是一样的，只是把数据接口从云函数换成 HTTP 接口而已。

4.1 通过云函数获取 openid 并完成校验

在云开发环境下，云函数中可以直接通过 cloud.getWXContext() 拿到调用者的 openid：

js复制const cloud = require('wx-server-sdk')
cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV })
const db = cloud.database()

exports.main = async (event, context) => {
  const wxContext = cloud.getWXContext()
  const openid = wxContext.OPENID

  if (!openid) {
    return { code: 401, msg: '未获取到用户身份' }
  }

  // 示例：根据 openid 查找患者
  const res = await db.collection('patients').where({ openid }).get()
  return { code: 0, data: { isBound: res.data.length > 0 } }
}

这里必须提醒一件事：千万不要把数据库集合权限设成“所有用户可读写”，然后让前端直接调用 wx.cloud.database() 去写 patients。虽然这样开发最快，但意味着任何用户只要知道集合名，就能读取或修改别人的患者记录。健康信息属于个人敏感信息，不能开这种口子。我在项目里把所有写操作都放在云函数里，前端只能调用云函数，由云函数校验当前 openid 对应的患者身份，再执行数据库操作。

4.2 订阅消息推送：时机比内容更重要

微信小程序里做随访提醒，绕不开订阅消息。但订阅消息有个核心限制：它不能像服务号那样“后台自由下发给所有用户”，必须由用户点击时主动授权一次，而且一次性订阅通常只能发一次。

所以我的用法是：在患者完成一次随访提交后的成功页，设置一个“接收下次提醒”的按钮，按钮点击时再调用 wx.requestSubscribeMessage。这时候用户刚完成一次操作，知道自己下次还需要随访，授权意愿明显更高。千万不要在首页 onLoad 里弹订阅授权，那会非常打扰，而且用户因不了解上下文而拒绝后，后续再想引导会难很多。

订阅消息还有个特点：用户如果点了“总是保持以上选择”，后续可能一键允许；但如果点了拒绝，你在短期内不能再弹第二次，只能在页面里留一个“开启提醒”的入口。所以个人中心里必须提供开关，让用户随时自行开启。

写消息内容时也要克制：只发“您有一条出院随访待填写”这样的提醒，不要附带病史和敏感症状描述。毕竟消息可能被别人看到，健康信息不适合直接展示在系统通知里。

4.3 医疗类目、隐私保护接口和审核门槛

这个项目开发过程中，最大的外在风险其实是“小程序平台对医疗健康类功能的限制”。如果你要获取用户手机号，必须完成微信认证，并且接口能力会受主体类型影响。个人主体的小程序通常无法直接获取手机号，所以我在患者绑定方案里做了降级：不依赖手机号一键授权，而是用“住院号 + 姓名 + 手机号后四位”作为主要校验手段。

上线提审时，如果小程序简介里明确涉及“随访、健康数据采集”，微信后台通常要求选择合适服务类目，并可能需要提供医疗机构相关资质。如果是学生做项目或技术预研，我建议别急着正式发布，先用“体验版”验证完整流程，体验版加上真机调试，足够完成开发和效果演示了。

另外还需要在“小程序隐私保护指引”中声明采集哪些用户信息。健康信息属于敏感信息，后台的声明越清晰，后续审核越顺。这个步骤经常被开发者忽略，结果是自己连“保存患者信息”的接口都调不通，还以为是代码写错了。

5. 联调过程中容易翻车的几个实际问题

微信小程序开发工具里跑得好好的，一到真机就出问题，这种现象太常见了。我把自己在这个项目里踩过的三个相对高频的坑写出来，给大家做个参考。

5.1 手机号快捷获取没有返回值

这个项目早期版本，我设想患者直接用微信“手机号快速验证”组件完成身份绑定，少敲几个字。但真实测试时发现按钮点击后没有返回任何信息。查了一圈，原因是：当前小程序主体没有开通相关能力，或者基础库版本太低；只有企业主体且完成微信认证的小程序，才能正常调用 getPhoneNumber 换取手机号。个人开发的小程序基本用不了这个能力。

而且即便能用，button 组件里返回的也不是明文手机号，而是一个动态 code，需要由服务端拿着这个 code 向微信接口交换手机号。很多人初次做都会误以为前端能直接拿到手机号明文，这是一个常见误解。

最后我做的调整是：把“手机号一键获取”当作体验增强项，而非必选项。无法调用时，就让患者手动输入手机号后四位进行校验。反正身份绑定的核心目的是匹配患者档案，不是真的要把手机号存下来。

5.2 iOS 端时间格式化问题导致任务逾期误判

后端返回的时间字段，如果是 "2025-03-16 10:30:00" 这种格式，在 iOS 上直接用 new Date("2025-03-16 10:30:00") 会得到 Invalid Date，解析结果变成 NaN。但在开发者工具和 Android 手机上，这段代码又正常。

就是因为这个差异，我在 iOS 测试时发现首页的任务逾期判断一直出错：明明任务还没到时间，系统却把时间解析成非法值，导致逾期状态判断错乱。解决办法是把字符串里的连字符替换成斜杠：

js复制function parseTime(str) {
  if (!str) return null
  // iOS 不支持 yyyy-MM-dd HH:mm:ss，统一转成斜杠格式
  return new Date(str.replace(/-/g, '/'))
}

这种“开发工具正常、真机异常”的 bug 排查起来很耗时，最好的办法是在项目最开始封装一个统一的时间工具函数，所有时间解析都走同一个入口。

5.3 页面键盘遮挡底部提交按钮

随访页面如果放在底部一个固定“提交”按钮，在表单较长时，患者在手机上点输入框，键盘弹起来会把提交按钮顶到屏幕外面。虽然微信小程序里 input 和 textarea 默认有 adjust-position 行为，但在自定义导航栏、自定义底部按钮的页面里，表现并不可靠。

我的处理方法是：不在页面底部放固定按钮，而是把提交按钮放在表单内容的最后，作为表单末尾的一个长按钮。用户在填写过程中滚动页面，也顺便看到了自己填过的所有内容。这样既避免了键盘遮挡，又比固定底部按钮更不容易误触。另一个办法是监听键盘高度 bindkeyboardheightchange，动态给页面底部留出空间，但实现起来更复杂，适合确实需要固定按钮的场景。

6. 从“能演示”到“能落地”还要补哪些功能

做项目最忌讳止步于“能跑通”。如果你只是做个课程设计，上面的功能已经足够交付了。但如果你想把这个系统真的给一个科室试用，下面三件事至少得补上一件，否则护士大概率用两周就不会再打开。

6.1 把随访计划做成规则，而不是人工逐个创建

假设某个病区每月出院 200 人，总不能靠护士每天手动在系统里创建随访任务。更合理的方式是设计“计划规则”：比如“呼吸科出院患者，出院后第 7 天随访一次，第 30 天随访一次”。

系统每天早上定时扫描出院患者列表，到时间就自动生成对应随访任务。如果患者在第 5 天提前来复查，后台可以把原任务改期或者标记为“复查已完成，免随访”，避免给患者制造重复打扰。

在设计数据库时，上面的 followupTasks 表其实还应该增加一个来源字段，比如 sourcePlanId，标识这个任务是由哪条计划规则生成的。这样当同一患者出院第 7 天任务已经完成，而第 30 天任务还没生成时，系统也知道下一步要做什么。

6.2 关注异常指标的自动筛查，而不只是“收集数据”

随访数据最大的价值在于趋势观察。比如慢病随访中患者血压连续三次偏高，系统如果能把这个情况标记出来，推给医生，会明显减少医生逐个翻记录的负担。

实现上可以在模板配置里增加一个可选的“阈值规则”，例如：

json复制{
  "key": "systolicPressure",
  "label": "收缩压",
  "type": "input",
  "alertRule": {
    "min": 90,
    "max": 160
  }
}

后台拿到一条随访记录后，遍历模板里的阈值规则，一旦某项超出范围就自动把记录状态置为“异常待复核”，同时给对应的责任医护生成一条待办。这个功能虽然不难，但价值往往超过精美图表。

6.3 给后台留下可追踪的操作记录

随访数据涉及患者隐私，后台人员每次查看、导出、修改记录都应该有日志。特别是后续如果交给医院信息科维护，他们会非常关注这类审计能力。最轻量实现方式是在“随访记录”集合里增加两个字段：createdBy 和 updatedBy，记录操作者和操作时间。进一步的方案是把“查看患者列表”“导出数据”这类行为单独写入操作日志集合。不用做得很重，但要有留痕的设计意识。

结尾想说的是，随访系统真正的难点从来不在“能不能填一张表”，而在“患者为什么愿意持续填”和“护士为什么愿意每天打开看”。给患者一个足够简单的入口，给护士一个足够清晰的待办，给管理者一个能看出趋势的统计，这个系统才算闭环。如果你也只能做其中一件事，我强烈建议先把“随访任务生成 + 患者端待办 + 结果回传”这条循环跑通，哪怕表单内容简陋一点。我在实际开发中最受益的一点，就是几乎没有任何一步是脱离真实流程空想出来的，很多设计是从护士一边翻本子一边记录的动作里“翻译”成系统能力的。