01随访闭环
下发、填报、催办，都在库里
按患者与表单下发任务，支持周期与草稿。患者端填报、医生端看进度，催办有 24 小时频控，避免同一天反复打扰同一个人。趋势序列按时间轴输出，医生看的是曲线，不是散点。
任务四态 · 草稿续填 · 催办频控 24h
85条
后端接口 · 全部已接真实数据
35张
数据库表 · PostgreSQL 16
22屏
医生端页面
12个
患者端路由
8页
运营后台页面
01 — 为什么重做
随访最贵的成本，
不是打电话。
是打完电话之后：分数没人算、异常没人接、记录对不上。把这些环节拆开看，每一环都不难；连不起来，就永远在补漏。
| 现在常见的做法 | 后果 | Loopmed 的做法 |
|---|---|---|
| 随访靠电话与微信群 | 谁打过、打了几次、患者说了什么，只在个人记忆里 | 任务下发带周期，填报与催办进库，频控防打扰 |
| 量表用 Excel 手工算分 | 换一版规则，历史分数全部失真 | 计分规则随版本固化，历史按当时规则可复算 |
| 异常指标靠医生自己盯 | 发现时已经错过干预窗口 | 阈值规则产出预警，进待办中心，指派与处置留痕 |
| 病历改了就说不清 | 版本之间无法自证，争议时无从核对 | 版本链逐版哈希串接，可独立校验完整性 |
| 不良反应上报散落在纸上 | 患者说了、医生没记录、复诊时想不起来 | 患者上报进系统，医生回访与用药调整同一处关联 |
02 — 核心能力
四项能力，
一条闭环。
不是功能清单的堆叠。四项能力互为输入：下发决定数据从哪来，计分决定数据意味着什么，预警决定谁在什么时候要动手，病历决定这一切能不能被核对。
02量表引擎
规则版本固化，历史不会被改写
表单定义与计分规则分开管理，规则变更生成新版本而不是原地覆盖。同一份提交永远按提交时的规则计分，跨年对比才有意义。写接口对医生开放，量表库改版不需要发版。
表单定义 · 规则版本固化 · 提交即计分
03预警与待办
异常不是一个红点，是一条待办
阈值规则产出预警，分档呈现；预警可指派到人，处置过程留痕。医生端有独立的待办中心，把「该处理的事」从「该看的资料」里分出来。平台侧提供默认规则，租户可按科室调整。
阈值规则 · 指派 · 处置留痕
04门诊病历
每一版都能自证没被改过
病历按版本保存，每版计算摘要并与上一版串接成链，任一版被改动都会破坏链条。校验接口独立于业务逻辑，可单独跑。签名文件与照片独立存档，走短期签名地址取用。
sha256 串链 · 独立校验 · 签名 URL 15 分钟
05用药与不良反应
停药与开新药，一次调用完成
用药记录、患者上报、医生回访三张表互相关联。调整用药时「停旧开新」是一个原子动作，不会留下两段互不相干的记录。列级注释写进数据库，导出与科研复用不会认错字段。
06扫码绑定
医生签码，患者扫码，不需要注册
医生端生成带参二维码，患者扫码即绑定到对应医生，取图接口免登录但有 IP 限流。绑定关系进入团队可见性规则，谁能看谁的患者由团队配置决定，不由前端决定。
07团队与可见性
停用医生不会带走患者
团队成员、患者归属、换负责人都在服务端收口。停用医生或移交患者是阻塞式流程，必须指定接手人才能完成，避免出现无主档案。团队内可见范围按配置执行。
08通知中心
站内消息与业务写入同一事务
随访下发、预警、指派等五处关键动作与通知写入在同一个事务里，不会出现「业务成功但消息丢了」。已读状态归一，多端一致。
03 — 随访闭环
五个节点，
每个节点都有可核对的东西。
从医生建一张档案，到一份带哈希的随访记录归档，中间没有一步需要人工搬运数据。
01
建档与绑定
医生新建患者档案，手机号加密存储，列表只回脱敏值。签码给患者扫，绑定关系即时生效。
02
下发随访
按表单与周期下发任务，可选是否提醒。任务状态在下发那一刻确定，后续每一步都能查到是谁改的。
03
患者填报
患者端逐项填写，支持草稿续填。提交即按当时规则计分，不需要医生事后算。
04
计分与预警
分数落库，命中阈值即产出预警并进待办。指派到人，处置动作留痕。
05
核验与归档
医生确认后写入病历版本链，计算摘要与上一版串接。此后任何改动都会破坏链条，可被独立校验发现。
04 — 技术形态
一套代码，
两种交付。
平台型多租户和部署到医院机房，用的是同一套东西。交给信息科的清单最好不超过一个镜像、一个编排文件、一个数据库——微服务会把这份清单变成十几项。
| 层 | 选型 | 为什么是它 |
|---|---|---|
| 前端 | Taro 3 + React 18 | 一套代码出微信小程序与 H5，医院端口与互联网端口不写两遍 |
| 后端 | NestJS 模块化单体 | 一个镜像三种启动参数；模块边界用依赖白名单脚本守着，不靠自觉 |
| 数据库 | PostgreSQL 16 | JSONB、部分唯一索引、SKIP LOCKED 三样都要；队列也用库里的表，不引 Redis |
| 数据访问 | Prisma | 迁移可审查，建库只走 migrate，删列与改类型强制分两次发布 |
| 部署 | docker compose + Caddy | 一条命令起完，证书自动签发续期；不上 K8s，两台机器的场景运维成本超过收益 |
| 存储 | S3 协议适配层 | 默认本地盘，需要对象存储时切 profile，不改业务代码 |
05 — 交付方式
三种规模，
同一个编排文件。
应用进程本身很轻，常驻不到两百兆。真正会长的是随访照片与签名文件，所以预算应该花在磁盘和备份上，不是 CPU。
单院区试点
推荐先跑这档2C4G一台虚机
一个科室起步的标准配置。数据库与应用同机，一条命令起完，适合先把闭环跑通、让医生用起来。
- ≤ 50 医生 · ≤ 5,000 患者
- 磁盘按三年文件量预留
- 每日全量备份，保留七份
平台型多租户
多家医院2 台+ 托管库
应用节点横向扩展，数据库走云上主备。租户隔离在服务端强制注入，不依赖前端传参。
- 多租户 · 多科室 · 多角色
- 对象存储承载文件
- RPO ≤ 1h · RTO ≤ 4h
院内独立部署
客户机房离线升级包
部署在客户机房，不上公网也能运行核心业务。升级包与回滚路径固定，每次发布是一条命令。
- 一台服务器 + 一块数据盘
- 镜像离线导入，不依赖外网仓库
- 升级前强制备份，失败即中止
06 — 边界
不做什么，
写在这里。
医疗系统里，边界不清比功能不足更危险。下面这些是有意不做的，不是还没做。
✓系统负责
- 随访任务的产生、下发、提醒与进度追踪
- 量表按版本计分，历史分数可复算
- 阈值命中后产出预警、指派与处置留痕
- 病历版本的哈希串链与完整性校验
- 租户隔离、角色权限、审计日志
- 手机号加密存储，对外只给脱敏值
—系统不做
- 不做诊断建议、不生成治疗方案
- 不做处方审核、不替代药师判断
- 不做影像 AI 读片
- 不做互联网医院与在线处方流转
- 不替客户判断量表版权与适用范围
- 不承诺「电子签名具备法律效力」——那是机构与资质问题
07 — 现状
已经到哪一步。
这一节写的是实际进度，不是路线图。未完成的部分列出来，避免把「计划中」当成「已具备」。
| 模块 | 状态 | 说明 |
|---|---|---|
| 后端接口 | 已完成 | 身份与租户、患者档案、团队、量表、扫码绑定、随访、预警、病历、用药与不良反应、通知，共 85 条接口 |
| 医生端 / 患者端页面 | 已完成 | 页面全部接真实接口，生产构建里假数据会被替换成调用即报错的空实现 |
| 租户运营后台 | 已完成 | 登录、团队与医生、预警阈值、租户配置、公告 |
| 平台运营后台 | 前端完成，接口未开工 | 量表库、疾病库、消息模板三屏仍为示例数据 |
| 微信订阅消息 / 短信 | 未开工 | 触达通道是空实现，患者目前收不到站外提醒 |
| 图片识别回填 | 未开工 | 适配层留了端口，未接入识别服务 |
| 号源与预约 | 未开工 | 患者端为空状态页，后端无对应模块 |
| 科研 CRF | 未开工 | 仅有模块骨架 |