简介《传智健康PRD文档1》是一份面向健康管理系统的产品需求说明书适合产品经理、研发与测试人员梳理业务逻辑、明确功能边界。文档围绕数据结构管理展开对健康评估指标进行规范化定义涵盖序号、指标名称、参考值、单位、针对性别等核心字段明确字段类型与可空要求同时描述用户、医护人员、管理员三类角色的权限和使用场景为权限设计提供依据。目录覆盖会员管理、预约管理、健康评估、健康干预四大业务模块包含产品结构图、流程图和功能操作说明可直接用于系统开发、需求评审或同类PRD编写。资源包共1个docx文档压缩包约890KB文字形式便于检索和二次编辑。目前已有599人学习适合需要快速掌握健康管理平台核心需求的产品与研发人员。1. 一份健康管理系统 PRD它到底在管什么这是一份健康管理系统 PRD面向健康管理机构业务系统覆盖会员管理、预约管理、健康评估、健康干预、知识库、统计分析、系统管理七个模块。它不只是讲「患者能挂号、能看报告」而是把健康管理师的日常工作拆成「评估→分类→干预→回访」的闭环同时把会员档案、体检报告、评估指标、干预模板这些对象的数据结构定义到字段级。文档里大量篇幅是表格几乎每个子功能后面都跟一张数据字典表这对后端反推表结构、前端对齐功能清单非常友好。适合谁后端开发拿它做数据库设计前端开发拿它列页面功能产品经理拿它评审流程缺口你要复现一套健康管理平台这份文档就是一个现成的需求底稿。2. 角色、流程与状态机先把「谁在做什么」串起来2.1 三种角色的权限边界PRD 的角色模型很简单但很关键管理员、健康管理师、患者三种角色各管一段。管理员负责平台所有基础数据的增删改查落到功能上就是系统管理里的菜单管理、权限设置、用户管理、题库管理、问卷管理以及知识库里的评估建议、膳食库、运动项目库、疾病库这些公共主数据。健康管理师是业务执行者主要负责患者评估、干预、随访以及会员档案维护和确认人群分类但注意知识库对健康管理师是只读的他们不能改膳食库和运动库内容只能引用。患者走微信端能操作预约、查询报告、评估、健康日记但 PRD 里没有给患者端展开独立的字段设计这说明移动端的细节基本由前后端在开发阶段自行补齐文档只是把入口和流程画了出来。这个角色划分直接决定了权限设计知识库是「管理员维护、健管师只读」评估结果是「健管师可写、患者可查」系统管理是「仅管理员可见」。你如果把它翻译成菜单树就等于大部分业务页面挂给健康管理师基础数据维护页面挂给管理员患者端单独是一套轻量 UI。我在看过大量 PRD 之后的一个习惯是先画「角色 × 模块 × 操作」矩阵再落到具体页面不然开发到权限这一层又会回来反复确认。2.2 预约管理流程从套餐维护到到诊确认预约管理是整条业务链的入口PRD 给了一张很完整的流程图健康管理师先维护体检项、组合、套餐维护预约设置然后进入预约选择预约项目完善预约信息确认预约接着健康管理师查看预约信息确认是否预约成功不成功就走取消分支成功则进入预约成功状态。整个流程可以拆成三段配置段维护检测项、检测套餐、预约设置包括用日历排开诊时间、批量导入开诊时间。这是整个预约系统的地基套餐不维护好患者端根本选不到项目。下单段预约类型分电话预约和微信预约患者选择预约项目、完善信息、确认预约。电话预约由健康管理师代操作微信预约由患者自己操作两条入口最终落到同一条预约记录。确认段健康管理师在预约列表里看到全部预约通过电话回访确认患者是否按时到诊然后把预约状态改成对应状态。这里有一个容易被忽略的设计点预约列表的数据结构里同时放了婚姻状态、出生日期、性别、年龄这些会员冗余字段。为什么列表要冗余这些信息因为健康管理师在回访前就需要判断对方是不是需要特殊对待的群体如果每次都要去会员档案里查一遍工作效率会低很多。所以把展示字段冗余在预约列表里是合理的查询优化手段。检测套餐字段同理预约记录里除了套餐 ID还应冗余套餐名称因为套餐可能会被管理员改造历史预约记录不能被影响。2.3 评估与干预流程一份问卷如何变成干预方案健康评估的流程在 PRD 里有两条路径。第一条是患者到诊后健康管理师先判断他是否做过评估如果没做过就现场选择评估问卷、填写评估信息、生成评估报告如果做过就直接查看之前的评估结果。第二条是患者自己在公众号/微信端做健康评估填写问卷后直接生成报告健康管理师在评估列表中查看结果。两条路径最终都汇入健康干预流程先判断患者是否完成体检和评估没完成就先补完成后根据评估结果和患者信息制定干预方案确认人群分类然后定期回访回访发现方案无效就调整方案有效则干预结束。这条链路里最核心的设计是「预分类」。PRD 明确写了患者评估后系统对患者进行预分类健康管理师根据患者信息进行确认分类。也就是说系统先根据评估结果自动判断这个人大概属于哪个人群然后人工再确认。这是典型的「机器推荐 人工确认」模式既照顾效率又保留人的判断权。2.4 我建议补上的状态机表PRD 里没有画状态机但所有流程描述都在暗示状态变化。如果开发前不把状态枚举定清楚到联调阶段一定翻车。我一般会把预约、评估、干预三条线各抽出一组状态业务线状态建议说明预约待确认 / 已预约 / 已到诊 / 已取消 / 已完成电话回访前是待确认回访确认后是已预约到检后更新到诊状态评估未评估 / 评估中 / 已完成 / 已查看「已完成」表示问卷填写完毕并生成报告「已查看」表示报告被查阅干预预分类 / 已确认 / 已制定 / 执行中 / 已完成预分类是系统自动产生确认分类后进入人工制定这套状态机不是 PRD 原文但它是从 PRD 的流程图里反推出来的。开发时把状态枚举直接写进数据库字典前端的按钮显隐、后端的接口校验就都有据可依了。3. 会员与预约管理数据结构字段级拆解3.1 会员档案为什么这份 PRD 要定义三十多个字段会员档案是这份 PRD 里数据字典最完整的地方。它把档案分成了几类信息身份信息、生理指标、病史背景、账号与状态。我把关键字段整理成组方便你对照表结构设计字段分组代表字段空值规则设计意图身份信息档案号、姓名、性别、身份证号、手机号、民族、出生日期、邮箱档案号、身份证号、手机号必填档案号是患者唯一标识出生日期可根据身份证号自动计算婚姻状态婚姻状态字段必填健康管理机构需要评估家庭支持度所以单列职业与文化职业、文化程度可空用于人群分析和健康干预建议的辅助判断体征数据身高、体重、BMI、收缩压、舒张压、呼吸频次、体温、腰围、臀围、血氧饱和度可空体检报告导入后回填BMI 建议由系统根据身高体重自动计算不手工录入病史背景既往史、家族史、过敏史、病史、慢性病可空多个文本字段开发时建议用大文本或独立子表避免单行数据过长管理信息登录密码、健康管理师、档案状态、启用状态、备注健康管理师必填档案状态和启用状态是两种状态档案状态是档案本身的完整度启用状态是账号是否可用为什么字段这么多因为后续的健康评估、人群预分类、干预方案都要以这份档案为基础。比如预分类时系统要结合年龄、性别、慢性病信息制定干预方案时要参考运动禁忌和既往史。字段多不是缺点但开发时一定要区分「创建时必填」和「后续补录」身份证号、手机号、健康管理师分配必须在创建会员时完成身高体重这些体征可以等体检报告上传后回填。这里还有个细节值得注意PRD 的会员来源写得很清楚包括到诊直接注册和预约到诊两种。到诊注册是健康管理师直接为患者建档预约到诊是患者先在微信端产生预约记录到诊后再由健康管理师完善档案信息。所以会员管理页面要支持「从预约记录一键创建会员档案」而不是让健康管理师从头敲一遍信息。3.2 报告上传与预约列表两个容易被低估的子功能报告上传看起来简单其实业务规则很讲究。PRD 规定体检报告是手动上传由健康管理师选择患者体检信息后上传上传字段包括档案号、体检时间、姓名、手机号、检测套餐、报告状态和报告文件。其中「报告状态按照体检时间按顺序排列最先检查的在最前面」——这句话实际上定义了列表的排序规则不是按上传时间排序而是按体检时间倒序排列。这个排序规则如果前端不留意就会做成「最新上传的放最上面」健康管理师可能会找不到最早的那份报告。我在做类似系统时吃过这个亏后来统一口径是报告上传时间和体检时间分开列表展示按体检时间排序体检时间为空时按上传时间兜底。预约列表的数据结构里除了预约本身的字段还带着婚姻状态、出生日期、性别、年龄。这一段我再提醒一次这些字段是冗余展示字段不是预约表应该存储的核心字段。建议的落库方式是预约主表存档案号、预约日期、预约类型、预约状态性别年龄等通过档案号关联查询但查询接口里做冗余返回。PRD 把冗余字段直接列在预约列表的字典里本质上是告诉你「这个列表页面要展示这些列」而不是「预约表要存这些字段」。理解这个区别建表时才不会把会员字段重复塞进预约表。3.3 落地推演从 PRD 字段到物理表的步骤把这份 PRD 的字段翻译成物理表我会按下面几步走第一步把文档里所有「数据结构」表格抽取出来合并同类字段建立字段清单。一份 PRD 往往有十几张字段表分散在各功能描述里不提前整理开发时容易漏字段。第二步按业务对象分组成表。会员档案落在 member 表报告上传落在 report 表预约落在 appointment 表套餐落在 package 表检测项落在 item 表。以档案号为主键贯穿所有业务表。第三步识别字典字段。婚姻状态、档案状态、预约类型、预约状态这类字段一律抽出为字典表或者至少用枚举值统一约束不要在业务表里随手写字符串。第四步确认哪些字段系统自动生成、哪些自动计算。档案号建议系统生成出生日期根据身份证号自动提取BMI 根据身高体重自动计算年龄根据出生日期动态计算。这些逻辑要写进后端接口不能放给前端随意输入。第五步做一次反向走查从患者注册到报告上传把所有页面对应到表字段查一遍有没有字段无来源、有来源无字段。这套方法不只适用于这份 PRD任何以字段表为核心的需求文档都能这样落地。关键是把「文档结构」翻译成「数据结构」时不要照搬字段名而是先识别每个字段属于哪个业务对象、由谁产生、在哪个环节更新。4. 健康评估与干预指标标准化与模板化4.1 指标管理的「左右临界值」设计健康评估模块是这份 PRD 的技术含量所在而指标管理则是评估模块的核心。PRD 中指标管理的数据结构有六个关键字段序号、指标名称、正常参考值、单位、针对性别、左/右临界值。这里有一段业务规则值得细读左右临界值为实际评估对照值正常参考值为显示值同一指标针对性别不同正常参考值会有不同。这说明设计者把「展示」和「判定」拆开了。正常参考值给患者看左右临界值给系统算。举个例子一个指标的判定逻辑是如果 检测值 在 左临界值 和 右临界值 之间判定为正常 如果 检测值 超出右临界值判定为异常偏高 如果 检测值 低于左临界值判定为异常偏低而正常参考值只是展示层的一个范围字符串。这套设计的好处是不同指标的正常参考值显示方式和判定方式可以各自独立调整显示层改了不影响判定逻辑判定逻辑改了不用动前端展示。开发时我建议把左右临界值拆成两个数值字段left_threshold和right_threshold而不是存一个字符串否则每次判定都要解析字符串既慢又容易出错。指标还有一个「针对性别」字段这意味着一张指标表里同一指标可能有多条记录按性别区分。建表时唯一索引建议设计为「指标名称 针对性别」联合唯一避免同性别同指标重复录入。PRD 还写到体质测评、心理测评、风险测评三套评估方式每一套都有新增评估、查看结果、条件查询评估信息。而且评估问卷和题库在系统管理里有独立的维护入口说明评估内容是可配置的不是写死在代码里。也就是说评估系统和题库系统之间是「题库定义问卷、问卷产生结果、结果关联指标」的关系。4.2 预分类、确认分类与干预方案模板健康干预模块的起点是人群分类。PRD 的人群分类数据结构里人群分类字段明确标注为「系统根据患者评估结果进行预分类」同时还有一个健康管理师字段。整段设计是系统先根据评估结果给患者打一个预分类标签健康管理师查看患者信息后确认这个分类确认后才进入制定干预方案阶段。这个流程要落地前端需要两个列表一个是预分类列表展示系统自动分类结果状态为待确认另一个是已确认列表展示健康管理师确认后的分类结果。后端要提供两个操作确认分类、重新分类。PRD 没有明说预分类的规则是什么但既然评估结果来自指标判定那预分类就应该是根据指标异常的数量和程度做规则映射。比如多个核心指标异常预分类为高风险人群全部正常分类为一般人群。这套规则在开发阶段需要和业务方确认PRD 只负责把流程框架定下来。干预模板的数据结构设置了模板标题、关键词、适用人群、方案目标、启用状态、备注以及运动方案、膳食方案、健康方案。注意「适用人群」这个字段它和人群分类必然有关联。我在设计时会用分类编码做关联键模板里applicable_category存的就是人群分类字典的编码健康管理师制定方案时系统按人群分类自动过滤可选模板。这里还要区分「模板」和「方案」模板是提前维护的通用内容方案是针对具体患者定制的实例。制定方案时健康管理师从模板里选运动、膳食、健康三套内容再结合患者个体情况调整。很多团队在这里会犯一个错误就是把模板字段和方案字段混在一张表里导致同一行数据既像模板又像实例后期根本没法统计。正确做法是模板一张表、方案一张表方案通过字段引用模板 ID。4.3 知识库怎么支撑模板生成知识库是给干预模块供应的素材库PRD 把它拆成评估建议、健康方案、运动项目库、膳食库、疾病库、宣教内容六类。实际展开的数据结构有评估建议库、膳食库、运动项目库三张表每一张都定义到字段级。膳食库的字段包括编码、食品名称、所属类型、100g 含能量、蛋白质含量、脂肪含量、建议人群、备注。运动项目库的字段包括编码、项目名称、运动强度、千步当量、运动时间、年龄区间、运动方法、注意事项。这些字段的价值在于让干预方案可量化膳食方案能算能量摄入运动方案能算运动量而不是一句「多吃蔬菜多运动」这种空话。在实际建表时评估建议库要和评估指标关联运动项目库要支持按强度筛选膳食库要支持按营养成分检索。健康干预模板选择运动方案和膳食方案时本质上是从这些库中筛选后组合。我建议模板与知识库内容之间用多对多关系表因为一个模板往往包含多个运动项目和多个膳食条目模板与项目之间是多对多不是一对一的单行文本拼接。PRD 里把运动方案、膳食方案、健康方案直接作为文本字段放在模板表里是一种简化写法落地时如果希望模板真正可复用、可调整就一定要拆关系表。4.4 把 PRD 描述推成规则伪代码把前面几节连起来评估到干预的完整链路可以表达成这样一段伪代码# 指标判定通过左右临界值判断单个指标是否异常 def evaluate_metric(value, left_threshold, right_threshold): if left_threshold value right_threshold: return normal return abnormal # 评估汇总一份问卷对应多个指标汇总异常项 def summarize_assessment(metric_results): abnormal_items [r for r in metric_results if r[status] abnormal] if len(abnormal_items) 3: return high_risk if len(abnormal_items) 0: return medium_risk return general # 模板匹配根据人群分类查找可用的干预模板 def match_templates(category, template_list): return [t for t in template_list if t[applicable_category] category]这段代码的作用是帮助你理解 PRD 没写明的规则部分evaluate_metric 对应指标管理里的左右临界值判定summarize_assessment 对应系统预分类match_templates 对应健康管理师在制定方案时筛选模板。实际项目的判定规则一定比这个复杂比如异常指标要分主次、要结合年龄性别、要有历史数据对比但框架是这个框架。开发前把这段伪代码拿去和业务方过一遍比对着 PRD 猜要高效得多。4.5 知识库与干预模板的权限边界这段本来应该在系统管理里说但因为涉及知识库和干预的实际使用放到这里更合适。PRD 的权限规则是系统管理员可以对评估建议库、膳食库、运动项目库进行增删改查健康管理师仅可以查看。这不是一句废话它决定了知识库所有写操作都要做角色校验前端要隐藏或禁用编辑按钮后端接口要做权限注解。尤其是批量导入功能如果知识库支持 Excel 导入导入接口必须走管理员权限校验而且导入后要有操作日志记录方便追溯是谁改了哪条知识数据。5. 避坑与排查这份 PRD 里没写明白的地方这份 PRD 整体质量不低字段定义足够细流程也有图但它不是完美的。下面这五处是我拆解时认为最容易让开发翻车的地方每条都按「现象 → 原因 → 解决」来讲。5.1 表格命名残留文章、频道、问答、活动现象这份 PRD 的数据结构表格里会员档案对应的表名叫「文章管理」报告上传对应的表名叫「频道管理」预约列表对应的表名叫「问答管理」评估问卷对应的表名叫「活动管理」指标管理对应的表名叫「类型管理」。原因文档是从某个通用 PRD 模板复制过来的表格里的字段内容改成了业务字段但表名没改或者改了模块标题却漏了表名。这是典型的模板残留问题。解决开发前先做一次全局搜索把「文章管理」「频道管理」「问答管理」「活动管理」「类型管理」这些词全部捞出来对照实际业务映射成会员档案、报告上传、预约列表、评估问卷、指标管理等真实表名。这个工作最好在需求评审阶段就做完不然测试用例写出来都是错位的。5.2 预约状态机不闭环取消之后怎么办现象预约管理的流程图里有一条「预约取消」的分支但整个预约管理功能列表里只有预约查询、预约列表、新增预约、日历预约、批量导入、预约设置、取消预约、检测项管理、套餐管理这些操作没有说明取消预约后号源怎么处理、患者怎么重新预约。原因PRD 把「取消预约」当成一个动作写了但没有深入到取消后的业务规则。这属于需求文档常见的主流程完整、异常分支缺失问题。解决开发前主动定义取消规则。我会把状态机补成待确认 → 已预约 → 已到诊 / 已取消已取消后对应的预约时段释放患者可重新预约同时取消操作需要记录取消人和取消时间便于运营复盘爽约率。你如果不补这一段测试阶段就会发现取消预约后时段还占着患者无法再次预约。5.3 评估结果与指标关联是黑匣子现象健康评估模块说「生成评估报告」指标管理也说「评估根据指标限定内容进行评估」但整份文档没有写评估结果是由哪些指标、通过什么规则计算出来的。原因PRD 把评估规则当成业务逻辑留给开发去咨询业务方但开发如果没有咨询就会自己拍脑袋写一个规则做完发现和业务预期不一致。解决拿到文档后第一时间把这个问题抛给产品和业务方列出评估问卷对应的指标清单逐项确认判定规则。如果业务方也说不清先按 4.4 的伪代码框架实现一个基础版指标判定是否异常异常项汇总后映射人群分类后续再补充权重、复杂规则。关键是要把判定规则做成可配置而不是写在代码里。5.4 三套「方案」字段高度相似容易混现象干预模板里有「运动方案、膳食方案、健康方案」制定方案的数据结构里也是「运动方案、膳食方案、健康方案」人群分类里还有「健康管理师」字段。三层结构字段长得几乎一样很容易在开发时合并成一张表。原因PRD 用同一套名词描述模板和实例没有明确区分「预置模板」和「患者实例」两个概念。模板是给所有患者复用的方案是针对单个患者定制的。解决落库时分两层。模板表存模板 ID、适用人群、启用状态以及关联的知识库项目方案表存患者档案号、模板 ID、健康管理师 ID、实际执行的运动项目和膳食条目。界面命名也分开模板管理、方案制定、工作台执行。这样统计健康管理师工作量时直接按方案表分组清晰明了。5.5 权限规则只有一句话现象统计分析模块的工作量统计规则写着「根据权限限定查看人员」系统管理里有菜单管理和权限设置但管理员权限、健康管理师查看数据范围的边界都没有展开。结果是开发只知道要控制不知道控制到什么粒度。原因PRD 把权限设计省略了只留了一句模糊的话。这在需求文档里很常见因为作者默认权限是后台通用功能。解决按 RBAC 模型落地至少做三级权限菜单权限控制左侧导航栏按钮权限控制新增/编辑/删除按钮数据权限控制健康管理师只能看到自己名下患者的数据。工作量统计页面要通过数据权限拦截确保一个健康管理师查不到另一个健康管理师的干预量。别等到联调时再补权限那时改动成本非常高。6. 把 PRD 用起来反向核对九步6.1 用九步核对法把文档走透这套 PRD 最实用的用法不是从头到尾读一遍而是把它当核对清单走一遍反向验证。我处理这类文档时固定做九步第一步读用户角色定义画角色权限矩阵第二步读功能摘要画功能树第三步把全篇所有「数据结构」字段表导出成一份字段清单第四步查模板残留修正所有错误表名第五步抽公共字典字段统一枚举第六步画三条主流程的状态机补全异常分支第七步逐条核对每段「业务规则」看是否有歧义第八步列出文档里没定义的事项如评估计算规则、权限粒度、取消预约后的号源处理第九步拿原型工具快速走查一遍主流程让业务方确认没有遗漏。做完这九步这份 PRD 就不再是「一份文档」而是变成了「一份需求基线」。后面的开发、测试、验收都能以这套基线为参照。这里附上我整理好的 PRD 原文件与上述核对表资源包里已经打包好可以直接作为你内部评审的对照材料。6.2 一个教训成了习惯我做过的健康类项目里凡是跳过第五步、第六步直接进开发的后期几乎都要返工要么表名对不上需求描述要么取消预约流程卡住。后来我接手新 PRD 时强制规定必须先出权限矩阵和状态机表再排开发计划这两张纸出了这轮需求的地基才算打牢。希望这套拆解手法帮到你少踩几个我看到过的坑。本文还有配套的精品资源点击获取