简介：《传智健康PRD文档1》是一份面向健康管理系统产品设计与需求分析的产品需求说明书，适合产品经理、需求分析人员及健康信息化学习者参考。文档围绕会员管理、预约管理、健康评估与健康干预展开，覆盖用户角色划分、产品总体流程、功能摘要及功能操作说明，并对健康评估中的数据结构类型管理作出规范，包括序号、指标名称、参考值、单位、针对性别等字段定义，便于理解指标标准化与数据录入逻辑。压缩包共1个docx文件，约890KB，篇幅紧凑，可用于需求梳理、原型设计对照或项目文档写作参考。已有600人学习下载。其价值在于以完整目录和流程图串联产品结构、特性描述与操作流程，帮助读者快速把握健康管理平台从会员信息维护、预约服务到评估干预的业务链路，也可为同类系统的需求文档撰写提供结构范本。
1. 需求先立住：健康管理系统到底要解决谁的什么问题
健康管理机构最怕的一件事，是数据散落在各个表格里，健康管理师靠经验拍脑袋出方案——患者体检报告在 A 表、评估问卷在 B 表、干预记录在微信聊天记录里，一个患者换一个健康管理师，信息就断档了。这份健康管理系统的 PRD 要解决的正是这个问题：把“建档—预约—体检—评估—干预—回访”整条链路收进一个系统里，让健康管理师、患者、机构管理者三方在同一套数据上协作。它适合正在做医疗健康类毕设或课程设计的同学，也适合需要交付一套健康管理平台方案的从业者。整份文档按会员管理、预约管理、健康评估、健康干预、知识库、统计分析、系统管理七个模块展开，每个模块都给出结构图、特性描述、功能操作和数据结构，这正好是能直接照着做设计与开发的骨架。
2. 总体设计：七个模块的职责边界与数据主线
七个模块看着多，落到系统里其实是一条主线加两个支撑。主线是患者从建档到干预结束的业务流，支撑是知识库和系统管理。设计的时候先想清楚这条主线，再往两侧挂模块，后面建表、拆接口、分权限都会顺很多。
2.1 一条业务主线：从建档到干预闭环
把主流程串起来，大概是这样：患者在微信端或到诊注册，产生会员档案；患者预约体检项目和时间，健康管理师确认到诊并上传体检报告；到诊后做健康评估，问卷结果生成评估报告；系统按评估结果给患者做预分类，健康管理师确认分类后制定干预方案；干预过程中定期回访，无效则调整方案，有效则结束干预。这条链路决定了模块之间的调用顺序，也决定了数据库里哪些表是主表、哪些是附属表——会员档案表是根，预约、体检报告、评估记录、干预方案都挂在档案号上。设计时我一般会先把这条主线画出来，再回头看每个模块的输入输出，这样不会出现“评估做完了但干预找不到人”的断点。
2.2 两类支撑模块：知识库与管理后台
知识库不是给患者看的，是给健康管理师“选料”用的。评估建议库把评估结果和健康建议关联起来；膳食库、运动项目库、疾病库提供干预方案里可选的素材；干预模板则是把这些素材预先组合好，制定方案时直接套用。它的设计要点是：内容由管理员维护，健康管理师只读。权限这条线必须在设计阶段就定死，否则后面加个“健康管理师能不能改膳食库”的争论会拖慢开发。
系统管理负责菜单、权限、用户、题库、问卷、系统设置，是所有模块的地基。菜单和权限要做成树形结构，用户挂角色，角色挂权限，这样后面统计分析的“根据权限限定查看人员”才有依据。统计分析模块本身不产生数据，它读的是干预方案的制定量、回访量、完成量，所以它对前面模块的依赖最重，通常放在最后做。
2.3 角色与权限模型怎么落到表结构上
PRD 里写明了三类角色：管理员、健康管理师、患者。落到实现上，通常的做法是用户表、角色表、权限表三张表加两张关联表。患者端在微信侧，只暴露预约、查报告、评估、健康日记这几个入口，管理员端和健康管理师端在 PC 侧，功能按角色裁剪。下面是一段建表的核心结构示意，字段名做了简化，重点看关系：
-- 用户表：三类角色共用一张主表，用 type 区分 CREATE TABLE sys_user ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL COMMENT '登录账号', password VARCHAR(100) NOT NULL COMMENT '加密后的密码', real_name VARCHAR(50) COMMENT '真实姓名', user_type TINYINT NOT NULL COMMENT '1管理员 2健康管理师 3患者', status TINYINT DEFAULT 1 COMMENT '1启用 0禁用' ); -- 角色权限关联：菜单权限用树形编码 CREATE TABLE sys_role_menu ( role_id BIGINT NOT NULL, menu_id BIGINT NOT NULL, PRIMARY KEY (role_id, menu_id) ); -- 会员档案：业务主表，档案号是全局业务主键 CREATE TABLE member_archive ( archive_no VARCHAR(32) PRIMARY KEY COMMENT '档案号', name VARCHAR(50) NOT NULL COMMENT '姓名', id_card VARCHAR(20) NOT NULL COMMENT '身份证号', phone VARCHAR(20) NOT NULL COMMENT '手机号', manager_id BIGINT COMMENT '所属健康管理师', archive_status TINYINT DEFAULT 1 COMMENT '档案状态', bmi DECIMAL(4,1) COMMENT 'BMI，由身高体重计算' );这段结构的关键在于：用户和会员是两套概念。用户是登录主体，会员档案是业务主体，患者注册后先生成用户，再由健康管理师补全档案，两者通过手机号或绑定关系关联。权限表用“角色—菜单”关联而不是“用户—菜单”，是为了后面批量调整角色权限时不用逐人改。档案号做主键而不是自增 ID，是因为体检报告、预约、评估都要按档案号跨模块查询，用业务编号更直观，也方便和线下档案对上。
3. 核心模块实现：会员、预约、评估、干预四段怎么落地
主线上的四个模块是这套系统的工作量大头，也是答辩或评审时被问得最多的部分。每个模块我都按“数据结构—业务规则—关键实现”讲，结构直接取自 PRD 里的字段表，实现部分补的是常见做法。
3.1 会员管理：档案字段设计与体检报告上传
会员档案的字段在 PRD 里列了三十多个，从档案号、姓名、身份证号，到身高、体重、血压、腰围臀围、BMI、血氧饱和度，再到既往史、家族史、过敏史、慢性病。设计时要注意两点：一是基本信息（姓名、性别、身份证、手机号）不可为空，体征数据（身高体重血压等）可为空，因为到诊时不一定测全；二是出生日期根据身份证号自动计算，BMI 根据身高体重自动算，这类派生字段不要在表单里让用户填，减少脏数据。
体检报告上传模块的数据结构里有个细节值得注意：报告状态按体检时间排序，最先检查的排在最前面。实现上通常按体检时间倒序或正序查列表，报告文件单独存一张表，关联档案号和体检时间，文件本身放对象存储，表里只存路径。到检患者可以直接新增信息，也就是说这个页面要同时支持“从预约列表选人”和“新建档案”两个入口，设计时把新增表单抽成公共组件，两个入口复用。
提示：档案状态和启用状态是两个字段，前者表示档案处于建档/在管/归档哪个阶段，后者表示账号能否登录，别合并成一个字段，后面统计在管人数时会用到。
3.2 预约管理：预约状态机与开诊时间维护
预约管理的流程是：管理员先维护体检项、组合和套餐，设置开诊时间（支持日历排班和批量导入）；患者选项目和时间提交预约；健康管理师在预约列表查看，电话回访确认是否按时到诊；患者也可取消预约。这里最容易设计错的是预约状态。通常的做法是定义一个状态机：待确认 → 已确认 → 已到诊 / 已取消 / 爽约。状态流转只能按固定路径走，比如已到诊不能退回待确认，避免数据回滚造成统计口径混乱。
预约设置里的“日历预约”和“批量导入”是两个入口，底层是同一张开诊时间表：日期、时段、可约人数、已约人数。批量导入用模板文件解析后批量插表，导入前要校验日期格式和人数上限，导入失败要给出逐行错误提示，这个细节 PRD 没写，但实际做的时候不做，运营人员会反复来问“为什么导不进去”。预约列表的查询条件按档案号、预约日期、预约类型（电话/微信）、预约状态组合，分页查询，列表里年龄由出生日期实时计算而不是存字段。
3.3 健康评估：指标管理与问卷结果的关联
健康评估分三块：风险评估、体质测评、心理测评，每块都是“选问卷—填问卷—生成报告—查结果”的流程。真正的设计难点在指标管理。PRD 里的指标表有这些字段：序号、指标名称、正常参考值、单位、针对性别（左/右）、临界值。业务规则写得很清楚——左右临界值是实际评估对照值，正常参考值是显示值；同一指标针对性别不同，正常参考值会不同。
这意味着评估判定的逻辑不能写死。通常的做法是：问卷题目关联指标，指标按性别维护多套参考区间，提交问卷时逐项比对临界值，超出范围就标记异常并关联对应的评估建议。比如血压指标，男性女性参考区间可能不同，判定时先按患者性别取对应记录，再比左右临界值。这样指标库改一次配置，所有问卷的判定同时生效，不用改代码。
// 指标判定核心逻辑：按性别取参考区间，比对临界值 function judgeIndicator(value, indicator, gender) { // 同一指标可能有多条记录，性别为通用或匹配当前性别 const rule = indicator.rules.find( r => r.gender === '通用' || r.gender === gender ); if (!rule) return { level: 'unknown', advice: null }; if (value < rule.leftCritical) { return { level: 'low', advice: rule.adviceId }; // 低于左临界值 } if (value > rule.rightCritical) { return { level: 'high', advice: rule.adviceId }; // 高于右临界值 } return { level: 'normal', advice: null }; }这段逻辑的要点是：临界值从数据库读，不写常量；性别匹配优先精确匹配，找不到再走通用规则；判定结果带上建议 ID，前端生成报告时直接按 ID 取建议文案。评估列表里健康管理师能看到患者在前台自己做完的评估结果，也能给到诊患者现场新建评估，两条数据来源同一张评估记录表，用来源字段区分。
3.4 健康干预：人群预分类与干预模板复用
健康干预的流程是：患者评估后系统预分类，健康管理师查看信息确认分类；制定干预方案时，可以从干预模板里选运动方案、膳食方案、健康方案，也可以手动从知识库里挑；方案执行中定期回访，无效则调整，有效则结束。人群分类表的字段里，人群分类是系统根据评估结果预填的，健康管理师可以选择修改，这个“预填 + 可改”的设计很关键——系统只做建议，最终判断权在人。
干预模板是提效的核心。模板表里存模板标题、关键词、适用人群、方案目标、运动方案、膳食方案、健康方案、启用状态。制定方案时按适用人群筛模板，选中后把模板内容复制成患者的干预方案记录，而不是引用模板 ID。为什么复制而不是引用：模板后续会被修改，如果方案引用模板，历史方案的內容会跟着变，回访时对不上账。这个坑我在类似项目里踩过，后来统一改成快照式存储。
3.5 知识库与统计分析：内容维护与工作量口径
知识库五个子库的结构都类似：编码、名称、分类、具体内容字段。膳食库有能量、蛋白质、脂肪含量和建议人群；运动项目库有运动强度、千步当量、运动时间、年龄区间、运动方法和注意事项；评估建议库把评估结果和建议文本关联。统一规则是管理员增删改查、健康管理师只读。设计时把五个库的公共字段抽出来，做一套通用的字典维护界面，能省不少重复开发。
统计分析模块目前只有工作量统计：按健康管理师统计干预方案总量、回访量、完成量，支持时间区间筛选，并按权限限定查看人员。这里的口径要提前定清楚：方案总量按创建时间算还是按开始执行时间算，回访量按回访记录条数算还是按方案数算。口径不定，两个人查同一段时间会得出两个数，这种事在验收时最容易被追问。建议把口径写进 PRD 附录，代码里的统计 SQL 加注释对应口径说明。
4. 避坑与常见问题：五处最容易翻车的地方
4.1 档案号和用户 ID 混用
现象是体检报告、预约、评估几张表有的关联档案号，有的关联用户 ID，查一个人要连好几张表还对不上。原因是建档时没统一主键口径。解决方式是一开始就明确：业务数据一律挂档案号，用户表只负责登录和角色，两者通过绑定关系表关联，写完建表语句后全组过一遍。
4.2 干预方案引用模板导致历史数据漂移
现象是模板改了一次，之前制定过的方案内容也跟着变，回访记录和方案对不上。原因是方案表存的是模板 ID。解决办法是把模板内容在制定方案时复制成快照字段存入方案表，模板只作为生产工具，不参与方案的历史展示。
4.3 评估指标按性别维护后判定错乱
现象是同一份问卷，男性患者被判成异常，女性患者判成正常，或者反过来。原因是指标表里同一指标有多条记录，判定时没按性别取对应行，随机取到了第一条。解决方式是查询时按“性别精确匹配优先、通用规则兜底”排序取一条，并在指标管理界面把同一指标的性别记录分组展示，避免维护时重复录入。
4.4 预约状态手工改库造成统计失真
现象是月底统计到诊率对不上，查出来是有人直接在数据库里把爽约改成了已到诊。原因是状态流转没有约束。解决办法是把状态变更收进统一的服务方法，每次变更记一条操作日志，页面不提供任意状态跳转的按钮，只提供“确认到诊”“取消”这类语义化操作。
4.5 权限只在前端隐藏菜单
现象是健康管理师通过接口直接调到了管理员才能用的知识库增删改接口。原因是权限只做了菜单隐藏，没做接口鉴权。解决方式是在后端统一拦截，按角色校验接口权限，菜单隐藏只是体验层，真正的边界在服务端。这个点在答辩时被问到的概率不低，能主动讲出来是加分项。
5. 怎么验收与答辩：用一条患者轨迹跑通全链路
验收这套系统，我一般不按模块逐个点，而是造一条完整的患者轨迹：新建一个会员档案，预约一次体检，上传报告，做一次风险评估，确认人群分类，套模板制定干预方案，回访两次后结束干预，最后去统计分析里核对这个健康管理师的工作量数字。一条轨迹跑完，七个模块的联动问题基本都会暴露——比如评估结果没带出建议、干预方案查不到模板、统计数字和实际记录差一条。
答辩或评审时，建议准备一张对照表，把 PRD 里的业务规则和实现方式一一对应，被问到时直接指：
| 业务规则 | 实现方式 | 验收动作 |
|---|---|---|
| 出生日期按身份证自动计算 | 建档保存时解析身份证并回填 | 输入身份证观察出生日期 |
| 报告按体检时间排序 | 列表查询按体检时间排序 | 上传多份报告看顺序 |
| 指标按性别区分参考值 | 判定时按性别取规则行 | 男女患者各测一次同指标 |
| 干预方案与模板解耦 | 制定方案时复制模板内容 | 改模板后查历史方案不变 |
| 统计按权限限定人员 | 后端按角色过滤查询范围 | 用不同角色登录看数字差异 |
演示节奏上，先用两分钟讲业务主线和三类角色，再用一条轨迹走系统，最后留一个模块讲深——通常选健康评估的指标判定，因为那里有真实的业务复杂度，能体现设计思考。常见追问集中在数据一致性和权限边界，提前把这两块的实现说清楚，比堆功能列表有用得多。
从那以后我每次做这类业务系统，都强制自己先用一条完整业务轨迹跑验收，再回头补边界用例——模块单点能跑通不代表链路能跑通，这个习惯帮我提前揪出过不少跨模块的坑。希望这套结构能帮到正在做健康管理系统设计的你。
需要这份完整 PRD 文档做参考的，按文末方式获取即可，里面的功能摘要表、数据结构表和各模块流程图可以直接对着搭你的设计与开发计划。
本文还有配套的精品资源，点击获取
