简介：传智健康PRD文档1是面向健康管理系统的产品需求说明书，适合产品经理、开发测试人员及健康行业需求分析者阅读。文档重点描述了健康评估指标的数据结构管理，包括指标名称、参考值、单位、针对性别等字段的规范化定义，同时也覆盖了用户（病人）、医护人员、管理员三类角色的权限划分，以及会员管理、预约管理、健康评估、健康干预等核心功能模块的流程和操作细节，结构完整、条目清晰。资源整体为1个docx文件，压缩包约890KB，内容采用标准PRD写作格式，包含修订记录、目录、功能详情和流程图说明，便于直接查阅、批注与复用。目前已有599人学习下载。通过学习该文档，可以快速理解健康管理平台的功能框架与数据结构类型设计思路，掌握预约评估等关键流程的需求表达方式，也能为同类产品设计、需求评审或相关岗位求职面试提供直接参考。
1. 传智健康PRD文档拆解：值钱的不在功能列表，在数据结构
拿到一份健康管理系统的 PRD 文档，第一反应大都是扫功能列表——会员管理、预约管理、健康评估、健康干预、知识库、统计分析、系统管理，七个模块摆在那儿，乍看和普通业务系统没有太大差别。但这份文档真正花心思的是数据结构：一个会员档案列了三十多个字段，从身高、体重、血压到既往史、家族史、过敏史；评估指标单独维护正常参考值、单位、针对性别和左/右临界值。这是给后端开发和产品经理看的东西，不是给销售看的功能彩页。把字段、角色、流程和业务规则一条条对齐，才能真正评估工作量。下面按数据结构、流程、权限、模块联动和交付清单的顺序拆。
2. 会员档案与评估指标：先从字段表建立数据模型
任何健康管理系统的地基都是数据模型，而这正好是这份PRD里写得最实的地方。会员档案、评估指标、体检报告这三块表字段齐全，拿到手可以直接转成建库草案。但照着字段建表只是第一步，难的是理解每个字段的“可修改”“可为空”背后对应的页面规则和业务含义。
2.1 会员档案：一张表把身份信息、体征数据和既往病史捆在一起
会员档案的字段结构可以分成三组看。第一组是身份信息，第二组是体征数据，第三组是病史信息。下面列出关键字段，便于后续建模时对照：
| 字段名 | 类型 | 可修改 | 可为空 | 说明 |
|---|---|---|---|---|
| 档案号 | 字符型 | 否 | 否 | 患者体检的档案号，业务主键 |
| 姓名 | 文本 | 是 | 否 | 患者姓名 |
| 身份证号 | 字符型 | 是 | 否 | 患者身份证号 |
| 手机号 | 字符型 | 是 | 否 | 患者手机号 |
| 登录密码 | 字符型 | 是 | 否 | 患者微信端登录密码 |
| 出生日期 | 字符型 | 是 | 是 | 根据身份证号自动计算 |
| 健康管理师 | 文本 | 是 | 否 | 分配给患者的健康管理师 |
| 身高 | 字符型 | 是 | 是 | 患者身高 |
| 体重 | 字符型 | 是 | 是 | 患者体重 |
| 收缩压/舒张压 | 字符型 | 是 | 是 | 患者血压 |
| BMI | 字符型 | 是 | 是 | 患者BMI |
| 既往史/家族史/过敏史 | 文本 | 是 | 是 | 患者病史信息 |
| 慢性病 | 文本 | 是 | 是 | 患者慢性病描述 |
注意几个容易被忽略的点：档案号标记为“不可修改、不可为空”，它就是业务主键，不能用数据库自增ID替代；出生日期是“根据身份证号自动计算”，意味着身份证号变更时，出生日期必须联动重算；健康管理师字段“可修改、不可为空”，说明新建会员时必须指定归属健管师，如果机构里还没有健管师用户，这个约束会导致建档流程走不通。身高、体重、BMI全是字符型，PRD没有说BMI是手动录入还是根据身高体重自动计算，这是我拆文档时第一个存疑的地方，后面要在评审会上明确。
2.2 评估指标管理：左/右临界值管判断，正常参考值只管显示
健康评估模块隐藏着全文档最有信息量的规则。指标管理的字段如下：
| 字段名 | 类型 | 可修改 | 可为空 | 说明 |
|---|---|---|---|---|
| 序号 | 字符型 | 否 | 否 | 评估指标的序号 |
| 指标名称 | 文本 | 是 | 否 | 如血压、血糖 |
| 正常参考值 | 字符型 | 是 | 是 | 评估指标的正常范围，页面展示用 |
| 单位 | 字符型 | 是 | 是 | 指标单位 |
| 针对性别 | 文本 | 是 | 是 | 指标针对的性别 |
| 左/右临界值 | 字符型 | 是 | 是 | 实际评估对照值 |
关键规则原文是：左右临界值为实际评估对照值，正常值参考为显示值；同一指标针对性别不同，正常参考值会有不同。这两句话决定了后端判读逻辑怎么设计。正常参考值是给人看的“100~140”这种范围，而真正判断是否异常用的是左/右临界值。开发的时候最忌讳把这两个值合并成一个字段，或者直接拿页面展示的参考范围做判断。
另外一个建模问题：既然“同一指标针对性别不同，正常参考值会有不同”，那一行指标数据就表达不完整。比较好的做法是拆成指标主表和指标参考值子表，子表按“指标ID + 性别”作为唯一键，存放正常参考值、左临界值、右临界值。PRD没有明确要求的表结构，但它的字段设计已经暗示了需要按性别拆行，评审时可以把“拆子表还是同一行加性别字段”作为一个议题提出来。我一般支持子表方案，因为后面再加年龄分层也方便。
2.3 体检报告上传：状态按体检时间正序排列是个易错点
体检上传的字段比档案简单：档案号、体检时间、姓名、手机号、检测套餐、报告状态、文件。业务规则有两条：体检报告为手动上传，选择患者体检信息上传体检报告；报告状态根据体检时间按顺序排列，最先检查的在最前面。
这里有个容易理解错的地方。“报告状态根据体检时间按顺序排列”不是让列表倒序展示最新报告，而是按体检时间正序把最早体检的记录排在最前面。前端列表排序逻辑、后端查询的ORDER BY方向都要跟着这条规则走，不能想当然按创建时间倒序。另外，体检报告是“手动上传”，说明没有接口对接体检机构，上传动作大概率是选择文件后POST到服务器，报告状态需要有一个“未上传/已上传/已删除”之类的枚举来驱动列表展示。文档里没有给枚举值，但字段“报告状态”的类型是文件，这里类型标注并不严谨，评审时值得追问。
2.4 数据结构单元的边界：PRD没写的部分
PRD把字段给了，但不是所有建模信息都给全。没有数据字典、没有索引方案、没有主外键关系图。举个例子，运动项目库里的“千步当量”是个专业概念，表示运动量相当于走一千步的消耗，这种字段在页面里通常是只读展示，但它没有写在“可修改”列里，建模时就要注意。另一个容易被忽略的边界是“人群分类”字段既出现在健康干预模块，又作为系统预分类的结果存在，这个字段到底是冗余存储还是关联查询，需要在设计数据库时定下来。拿到这类PRD，第一步抄字段，第二步就是找评审会要这些没写的边界决定。
3. 预约与健康评估两条主流程：时序执行与状态流转
PRD里有两张流程图最值得研究：预约管理流程和健康评估流程。功能列表什么时候都能抄，但流程的执行顺序决定接口怎么设计、状态机怎么定义、异常分支怎么兜底。这一章把两条流程拆成步骤和状态，并给出后端接口设计时可以直接落地的状态约束。
3.1 预约管理：从维护套餐到批量导入开诊时间
预约流程的完整路径是：健康管理师先维护体检项、组合、套餐，维护预约设置；进入预约页面，选择预约项目；完善预约信息，确认预约；查看预约信息；确认是否预约成功，成功则预约流程结束，否则取消预约。
拆成开发语言是这样的时序：
- 维护基础数据：体检项、组合、套餐都属于预约的前置数据，必须先有可选的检测套餐，才能进入预约操作。
- 预约设置：日历预约和批量导入开诊时间都挂在预约设置下。批量导入意味着后端需要一个模板解析接口，校验开诊时间格式、冲突时间，并把合法数据批量写入预约日历表。
- 患者预约：患者通过微信端发起预约，选择预约项目和体检时间。
- 确认预约：要么健康管理师在后台确认，要么系统按预约设置自动确认。
- 取消分支：患者或健管师取消预约后，之前占用的开诊时间要释放。
预约列表字段里有“预约类型”，取值为电话预约或微信预约，说明预约入口至少有两个，前置校验逻辑一致，但数据来源要区分。还要注意预约状态字段，PRD只写了“电话回访患者确认是否按时到诊”，没有给状态枚举。我一般会按“待确认→已确认→已到诊→已完成→已取消”五态去设计，到诊确认由健管师操作，已取消状态则单独保留创建人和取消时间，便于后续追溯。
3.2 健康评估：线上线下双入口，报告按问卷类型动态生成
健康评估流程图比预约流程多了一个关键分支：判断是否做过健康评估。做过则直接查看评估结果，没做过则新建评估。评估发起有两种路径，一种是在门诊场景下由健管师代操作，另一种是患者在公众号里自助问卷。两条路径最终都落到“填写问卷→生成评估报告”，评估报告不是固定模板，而是“根据不同问卷，显示不同报告”。
问卷字段表给出的是：档案号、姓名、评估日期、评估结果、查询、活动主办方id。这里的“活动主办方 id”字段很特殊，它暗示同一份问卷可能被多个评估活动复用，或者不同机构发起的问卷需要区分数据来源。领域建模时可以考虑把问卷模板和评估记录分开，评估记录引用问卷模板ID，而不把问卷内容冗余存进每一条评估记录。
双入口带来的问题是权限和归属。公众号端患者自评，没有健管师参与，生成的报告状态是未审核；门诊评估由健管师当面操作，生成报告可以直接进入下一步健康干预。如果开发时不区分这两个来源，统计报表里的“评估数量”就会混入自评和审核两类数据，后面工作量统计会对不上。建议在评估记录表里增加来源字段：1-门诊评估，2-公众号自评，3-人工补录。
3.3 流程转状态机：PRD没画，但开发必须有
流程图是给人看的，状态机是给系统用的。预约和评估两组状态可以这样拆：
| 流程 | 状态流转 |
|---|---|
| 预约 | 待确认 → 已确认 → 已到诊 → 已完成 |
| 预约 | 已确认 → 已取消 |
| 评估 | 未评估 → 评估中 → 报告已生成 → 已纳入干预 |
评估流程的“已纳入干预”是从健康评估到健康干预的纽带。如果评估报告生成后不去干预，那评估只做了一半。后面的健康干预模块会以评估结果作为人群分类依据，所以评估状态必须有一个值标识“已经进入干预流程”，否则数据联动会断掉。
还有个边界要明确：同一患者在一年内可能多次评估，评估记录是一对多关系，那“当前有效的评估报告”是取最新一条，还是按评估类型各取一条？PRD没有写，但界面展示“查看结果”时需要约定取数规则。我一般推荐按问卷类型取最近一次有效评估，这样可以同时支持风险评估、心理测评等多套问卷并行。
4. 拆这份PRD时容易踩的五个坑：现象、原因与解决路径
这份PRD整体完整度不低，但靠它直接进入开发，还是会踩坑。下面五条是我在拆这类健康管理需求时真实遇到的麻烦，每一条都按现象、原因、解决路径写清楚，供你排需求时对照。
4.1 坑一：预约列表里的档案号可以为空
现象：做预约管理时发现患者还没到诊，预约列表里的档案号字段就没有值；但会员档案模块里档案号又标记为不可为空。前端列表渲染为空，后端不知道拿什么字段关联患者。
原因：这份PRD的用户角色分三类，患者可以在微信端直接预约，此时并不要求先建档。预约产生时档案不存在，档案号自然为空。
解决：预约记录不强制档案号，而是用“预约单号”关联患者手机号和患者ID。患者到诊时，健管师完善会员信息并建档，系统再把预约记录里的临时档案号更新为正式档案号。我在设计数据库时会把预约表拆成预约主表和预约人信息表，手机号作为弱关联字段，到诊后再回填档案ID。
4.2 坑二：把正常参考值当判断条件用
现象：评估功能开发时，后端同学拿着“正常参考值”字段判断患者指标是否异常，结果发现拿到的范围值和医生现场判断不一致。
原因：业务规则里明确写了“左右临界值为实际评估对照值，正常参考值只是显示值”，但字段表里正常参考值排在前面，开发和测试最容易按直觉使用。
解决：先读业务规则再建表。指标判断逻辑的输入参数必须是左/右临界值，正常参考值仅用于页面展示。以血压为例，页面展示“正常参考值 90~140”，后端判断却要用临界值 85~145，展示和判断是两套数据。这个规则要写进接口文档，避免前端自己拿展示值做校验。
4.3 坑三：性别相关指标没有拆行设计
现象：风险评估里有一个指标“血红蛋白”，男性和女性的正常参考值不同。数据模型里只有一行指标配置，页面不知道按哪个性别取参考值。
原因：PRD只是说“同一指标针对性别不同，正常参考值会有不同”，没有明确让同一指标拆成两行。
解决：指标主表存指标名称、单位、序号；指标参考值子表按“指标ID + 性别”唯一存储正常参考值、左临界值、右临界值。这样女性取女性配置，男性取男性配置，都通过一次子表查询完成。如果后续还要按年龄分层，再增加年龄区间字段，对现有结构影响最小。
4.4 坑四：知识库权限“只看”和“可改”没有细分到按钮
现象：健康管理师要使用干预模板，却发现模板内容来自运动项目库、膳食库，而这些知识库模块文档规定只有系统管理员能改。健管师想复制一个模板，发现页面连“新增”按钮都没有。
原因：知识库模块的权限描述只写了一句“系统管理员可以对膳食库进行增删改查，健康管理师仅可以查看”。干预模板的维护权限又属于健康干预模块，两个模块紧耦合但权限描述没对齐。
解决：把权限拆到按钮级。知识库基础数据（膳食库、运动项目库、疾病库）只有管理员可增删改，健管师只读；干预模板的增删改属于健康干预模块，健管师可操作。实现时沿用常规的 RBAC 菜单权限加按钮权限，权限管理里的“菜单管理”正好对应这个需求。
4.5 坑五：工作量统计口径说不清
现象：月度报表里健康管理师甲显示干预方案总量 120 条，干预完成量 80 条，但甲自己觉得只做了 100 条方案。两边对不上，上线后业务方立刻提缺陷。
原因：PRD里“干预方案总量、干预回访量、干预完成量”没有定义统计口径。一个方案被制定但被调整了三次，算一条还是三条？回访记录是每次回访都计数，还是只统计有效回访？这些没约定，不同统计接口自然结果不同。
解决：评审时锁死口径：干预方案总量按“方案主表记录数”统计，一次制定只计一条；方案调整不增加总量；干预完成量按方案状态为“已完成”的记录数统计；干预回访量按干预回访明细表的记录数统计。统计模块按权限限定查看人员，管理员看全部健管师，健管师本人只看自己名下的数据。
5. 健康干预与知识库：数据关联、角色权限和运营统计
健康干预模块是整套系统的价值出口，前面评估做得再漂亮，最终目的都是为了生成可执行的干预方案。这一章把人群分类、干预模板、知识库和统计分析串起来，重点说明模块之间通过哪些字段关联，以及角色权限的边界在哪里。
5.1 人群分类：系统预分类是自动的，人工确认是必选的
人群分类的数据结构比普通业务表多了一层“预分类”语义。字段包括档案号、姓名、性别、年龄、状态、人群分类、健康管理师。其中业务规则写明：患者评估后，系统对患者进行预分类，健康管理师根据患者信息进行确认分类。
这说明人群分类不是一个纯人工填写的字段，而是由系统根据评估结果自动给出预分类标签，健管师确认后生效。设计上可以把“人群分类状态”作为审核字段：待确认、已确认、已驳回。系统预分类写入时应记录使用的评估报告ID，便于健管师在确认页面回看评估依据。这条链路从评估到分类再到干预，中间不能断。
5.2 干预模板与制定方案：字段几乎一样，落差在数据来源
干预模板的关键字段是模板标题、关键词、适用人群、方案目标、启用状态、运动方案、膳食方案、健康方案。制定方案的字段是档案号、姓名、性别、年龄、启用状态、运动方案、膳食方案、健康方案。两者只差一个“患者身份”和“模板关键词”。
实际操作就是：健管师在知识库里维护运动、膳食、健康方案；制定干预方案时，选择患者，选择一套运动方案加一套膳食方案，再关联健康方案，组装成一条干预计划。如果机构有标准化需求，可以先把知识库里的内容组装成模板，再复制模板生成方案。这里的复制不是简单克隆，而是生成新的方案记录，后续修改只能改患者方案，不能回改模板。数据库设计时，干预方案表里关联运动方案、膳食方案、健康方案三个外键，模板表也是同样的三个外键，复制动作一次INSERT加一次SELECT就能完成。
5.3 膳食库和运动项目库：编码字段是留给对接和导入的
膳食库字段：编码、食品名称、所属类型、100g含能量、蛋白质含量、脂肪含量、建议人群、备注。运动项目库字段：编码、项目名称、运动强度、千步当量、运动时间、年龄区间、运动方法、注意事项。
这两张表本质是标定数据，单独看好像只是一个字典表，但“编码”字段暴露了真实用途：食品和运动项目可能来自外部标准数据库，比如营养成分表、运动医学标准，编码是外部数据的唯一标识。如果机构需要批量导入膳食和运动数据，编码字段就是去重键。我一般会在这两张表上增加“来源”和“外部编码”字段，方便后续对接第三方数据时不改主结构。另外“千步当量”这个字段很容易被忽略，它是运动项目库特有的计量单位，建议按字符串存，因为不同来源的数据格式可能不统一。
5.4 统计分析：权限限定查看范围，时间区间是硬条件
工作量的数据结构非常朴素：姓名、干预方案总量、干预回访量、干预完成量、时间选择。业务规则两条：根据权限限定查看人员；选择查看时间区间。
这里最容易出问题的不是报表本身，而是“干预方案总量”的时间口径。如果方案制定时间是 1 月，但最后一次回访是 3 月，那这个方案算 1 月的还是 3 月的？我建议统计时按“方案创建时间”归入创建月份，回访量按“回访执行时间”归入回访月份，完成量按“状态变更为完成的时间”归入完成月份。三个指标各自独立计数，互不影响。这样报表上方案总量和完成量对不上也说得清楚，因为统计维度本来就不同。角色权限上，管理员看全部健管师的数据，健管师本人只能看自己的，这条要在权限管理里配置数据范围。
6. 交付前把需求文档拆成四个清单：从开发排期到验收测试
拆完这份PRD，我有一个固定的动作：不急着写代码，先把它转成四个清单。这四个清单是给开发、测试和评审会用的落地工具，比反复翻原文效率高得多。
第一个是数据模型清单。把每节的数据结构字段汇总成一张建库草稿表，标注主键、外键、可空性、类型，重点关注两个字段：出生日期由身份证号自动计算，评估结果由指标临界值判断生成，这两个都属于计算字段，不直接录入。第二个是角色操作清单。按管理员、健康管理师、患者三个角色分别列操作点，比如管理员维护知识库，健管师确认人群分类并制定方案，患者在微信端预约和自评。角色和操作对齐后，权限树就出来了。第三个是业务规则清单。把PRD里所有的“业务规则”段落提取出来，逐条转成判定逻辑，例如“临界值判断、正常参考值展示”“报告状态按体检时间正序排列”。第四条是接口验收清单。基于流程状态机和字段约束，生成接口测试用例，比如预约取消后开诊时间是否释放、关键指标缺失时评估报告是否还能生成。
把需求文档拆成这四个清单后，排期、分工、测试都能直接按清单推进。以指标判断逻辑为例，可以用一个可测试的函数表达：
// 按指标ID和性别取配置，左/右临界值用于判断，正常参考值仅展示 function evaluateIndicator({ indicatorId, gender, measuredValue }) { const config = getIndicatorConfig(indicatorId, gender); if (!config) { return { status: 'UNKNOWN', displayRange: null }; } const { leftLimit, rightLimit, normalDisplay } = config; const abnormal = measuredValue < leftLimit || measuredValue > rightLimit; return { status: abnormal ? 'ABNORMAL' : 'NORMAL', displayRange: normalDisplay }; }这段代码里的getIndicatorConfig对应“指标参考值子表”，按指标ID和性别查询；normalDisplay对应正常参考值字段。这样设计后，前端只需要拿到status和displayRange，判断逻辑收敛在后端，测试只需构造不同性别和测量值即可覆盖。
第一次拆这类健康管理系统 PRD 时，我拿到功能列表就开始排期，结果评审会上被问了一个问题：BMI 在档案里是字符型，是手动录入还是身高体重自动计算的？我没答上来。从那以后，我每次拆需求文档都强制先过一遍四个清单，再谈开发排期。希望帮到你。
本文还有配套的精品资源，点击获取
