企业官网建设流程全解析

简介：面向健康管理产品经理、需求分析与医疗信息化初学者的一份产品需求说明书，聚焦传智健康系统的业务建模与功能拆解。文档围绕数据结构类型管理展开，细化序号、指标名称、参考值、单位及针对性别等字段规则，并梳理用户、医护人员与管理员三类角色在会员管理、预约管理、健康评估和健康干预中的操作边界，配合流程图与功能详情帮助读者理解从需求到流程的落地方式。资源包共1个docx文件，约890KB，结构完整、便于直接查阅与二次整理。已有600人学习下载。读者可从中获得较规范的PRD目录框架、功能摘要写法、流程图与特性描述示例，也能借鉴健康评估指标标准化和预约流程设计的表达方式，适合用作课程设计、项目原型或需求文档模板参考。

1. 拿到一份健康管理系统 PRD：先看它能不能直接拆成开发任务

翻需求文档最怕一种情况：流程图很漂亮，字段表却只写“字符型、可空”，开发一动手全靠猜。这份健康管理平台 PRD 文档 V1.0 初版，是一套健康管理机构业务系统的需求说明书，核心落在会员管理、预约管理、健康评估、健康干预、知识库、统计分析、系统管理七个模块，重点描述数据结构管理、用户角色和操作流程。它能帮产品、前后端和测试把“谁在什么状态下能改哪些字段”对齐，适合正在做健康管理类项目、需要一份可拆解需求基线的人。文档不是可运行代码包，价值在字段、状态和业务规则，拿到后先别急着画页面，先拆角色和数据结构。

2. 角色与模块地图：把三类用户和七个模块拆成权限矩阵

PRD 第一页写了管理员、健康管理师、患者三类角色，但开发不能只停在角色名上。角色要落到“端、菜单、接口、字段、数据范围”五层，否则前端会把按钮藏起来，后端接口却谁都能调。健康管理类系统还有个特点：同一个患者数据，健康管理师能改，管理员也能改，但患者只能看自己的，权限边界比普通后台更细。

2.1 角色边界：管理员、健康管理师、患者各自能碰什么

管理员是平台维护角色，负责菜单管理、权限设置、用户管理、题库管理、问卷管理、系统设置，也能对平台信息做增删改查。健康管理师是业务执行角色，围绕会员档案、预约确认、健康评估、健康干预、回访展开，知识库对它应该是只读。患者是微信端角色，能预约、查报告、做评估、写健康日记。三者不是简单的“管理员 > 健康管理师 > 患者”等级关系，患者并不在后台菜单体系里，而是另一个端。

字段级权限要单独列。会员档案里“健康管理师”字段是分配关系，普通健康管理师只能看分配给自己的患者，管理员可以看全部；知识库的评估建议、膳食库、运动项目库，管理员可增删改查，健康管理师只读；统计分析的查看范围要按权限限定，不能只按菜单控制。我一般会让后端在接口层做一次角色校验，再用数据范围过滤一次，菜单隐藏只当体验优化，不当安全边界。

2.2 七个模块的依赖顺序：为什么知识库要排在干预前面

七个模块不是并列的。系统管理是底座，知识库是基础数据，会员是主数据，预约和评估是过程数据，干预依赖评估结果和知识库内容，统计依赖前面所有过程数据。如果先做干预页面，模板下拉没数据，开发就会临时造脏数据，后面清理成本很高。知识库看起来像“后台维护页”，实际上是干预模板的原料仓库，评估建议还依赖评估指标，所以它的优先级不能低。

这里有个反直觉的点：知识库维护页面可以晚点做，但知识库的数据模型要先定。因为干预模板保存时到底存知识库 ID，还是存内容快照，会直接影响历史方案能不能追溯。我一般会要求模板和方案都存快照，知识库后续改价格、改运动强度，不会把旧方案改得面目全非。

2.3 从功能摘要反推菜单树和接口前缀

功能摘要里列了很多“增删改查”，如果直接按页面做，很容易做出十几个孤立 CRUD。更稳的做法是先按模块拆路由和接口前缀，让前后端对同一套边界。下面这张表不是强制规范，是我拆这类 PRD 时常用的映射方式，目的是让会员、预约、评估、干预各自有清晰命名空间。

这样拆还有个好处：测试用例可以按前缀组织。会员和预约的异常流是档案号重复、号源冲突；评估的异常流是指标区间缺失、问卷未答完；干预的异常流是模板被停用、回访超期。接口前缀统一后，排查问题时看 URL 就知道大概落在哪个模块，不用在一堆 Controller 里翻。

2.4 三条主流程先落状态机，不然后面统计全是玄学

PRD 里画了预约、评估、干预三条流程图，但流程图节点不等于状态字段。预约有“待确认、已确认、已到诊、已取消、爽约”，评估有“未评估、进行中、已生成报告、已解读”，干预有“待制定、执行中、已回访、已结束、已调整”。这些状态如果不拆清楚，统计口径就会漂移。比如“本月预约量”到底算创建时间还是预约日期，“到诊率”分母是已确认还是全部预约，必须先约定。

状态字段最好配一张状态变更日志表，记录谁在什么时间把状态从 A 改到 B。统计不要用当前状态倒推历史，比如患者现在是“已结束”，不代表他上个月不是“执行中”。这类健康管理项目到后期做运营报表时，状态日志就是后悔药，没有它只能重新洗数据。

3. 数据字典落地：会员档案、体检报告、评估指标三张核心表怎么建

PRD 的数据结构表是最值钱的部分，但字段类型写得粗，很多地方写“字符型、可空、可修改”。落到数据库不能照抄，要把“可修改”翻译成接口可更新字段，把“可为空”翻译成是否允许 NULL，把“字符型”翻译成实际长度和校验规则。健康管理类系统字段多、指标多，表结构一旦松，后面评估报告和干预方案都会跟着飘。

3.1 会员档案表：必填、可空、可改三列先对齐

会员档案是主数据，档案号是患者体检、预约、评估、干预的串联键。PRD 里档案号不可空、不可修改，这个约束要直接落到唯一索引；姓名、性别、身份证号、手机号、登录密码也是不可空，但可修改；民族、出生日期、邮箱、婚姻状态、职业、文化程度、身高体重、血压、BMI、既往史等字段可空。出生日期写的是“根据身份证号自动计算”，但实际业务里身份证可能录错，所以接口可以自动算，同时保留手工修正入口，修正后要留痕。

-- 会员档案核心字段示例，实际表可按 PRD 继续扩展 CREATE TABLE member_archive ( archive_no VARCHAR(32) NOT NULL COMMENT '档案号，业务主键', patient_name VARCHAR(50) NOT NULL COMMENT '患者姓名', id_card VARCHAR(18) NOT NULL COMMENT '身份证号', mobile VARCHAR(20) NOT NULL COMMENT '手机号', birth_date DATE NULL COMMENT '出生日期，可由身份证计算', height_cm DECIMAL(5,1) NULL COMMENT '身高，厘米', weight_kg DECIMAL(5,1) NULL COMMENT '体重，千克', bmi DECIMAL(4,1) NULL COMMENT 'BMI，接口按身高体重重算', systolic_bp SMALLINT NULL COMMENT '收缩压', diastolic_bp SMALLINT NULL COMMENT '舒张压', health_manager VARCHAR(32) NOT NULL COMMENT '分配的健康管理师用户ID', status TINYINT NOT NULL DEFAULT 1 COMMENT '1启用 0停用', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (archive_no), UNIQUE KEY uk_id_card (id_card), KEY idx_health_manager (health_manager) ) COMMENT='会员档案表';

这段 SQL 的逻辑是把 PRD 里“不可空、不可改”的档案号直接做成主键，身份证号加唯一索引，健康管理师加普通索引用于数据范围查询。参数上，身高体重用 decimal 不用字符型，BMI 保留一位小数；血压用 smallint，不用 varchar，避免后面统计时还要转类型。身份证唯一索引要根据实际业务确认，有些机构允许同一身份证多次建档，那就改成“档案号唯一 + 身份证普通索引 + 业务查重”，不要为了图省事硬加唯一约束导致导入失败。

3.2 体检报告上传：文件状态要和到检状态分开

体检报告表在 PRD 里有档案号、体检时间、姓名、手机号、检测套餐、报告状态、文件。业务规则是手动上传，选择患者体检信息上传报告，报告状态按体检时间排序。这里最容易出的问题是把“报告状态”和“预约到诊状态”混在一个字段。到诊是预约流程的状态，报告是文件上传的状态，两者生命周期不同。患者到诊了，报告可能还没出；报告上传了，预约可能早已关闭。

上传步骤我一般会拆成四步：先按档案号查患者，校验档案状态；再校验该体检时间是否已有报告，有则走新版本而不是覆盖；然后上传文件、计算哈希、写报告记录；最后回写预约的到诊备注，但不改预约状态。报告删除做软删除，文件保留，统计和追溯都能查到。报告列表按 exam_time 倒序，PRD 写“最先检查的在最前面”，实际页面通常是最新在前，这里要跟产品确认清楚，不要自己猜。

3.3 评估指标表：左右临界值不是正常参考值的复制

评估指标表是整份 PRD 里最需要抠细节的地方。字段有序号、指标名称、正常参考值、单位、针对性别、左临界值、右临界值。业务规则写得很关键：左右临界值是实际评估对照值，正常参考值是显示值；同一指标针对性别不同，正常参考值会有不同。这意味着报告上显示的“正常范围 3.9-6.1”和程序判断用的区间可能不是同一个，如果开发直接拿正常参考值做比较，报告可能大面积标红。

-- 按性别取指标区间并判断结果，边界规则需与产品确认 SELECT r.record_id, r.indicator_id, r.value_num, i.display_range, CASE WHEN r.value_num < i.left_critical THEN '偏低' WHEN r.value_num > i.right_critical THEN '偏高' ELSE '正常' END AS result_label FROM assessment_result r JOIN assessment_indicator i ON i.indicator_id = r.indicator_id AND (i.gender = r.gender OR i.gender = 'A') WHERE r.record_id = ?;

这段查询的逻辑是先按记录取指标值，再按性别匹配指标区间，通用指标用 A 兜底。参数上，value_num 要用数值类型，不能沿用 PRD 里的字符型，否则比较时会出现“9 > 10”这种字符串比较问题。边界规则要明确：等于左临界值算正常还是偏低，等于右临界值算正常还是偏高，必须写进验收用例。还有单位换算，血糖可能用 mmol/L 也可能用 mg/dL，指标表最好加一个 unit_factor 字段，别在代码里写死。

3.4 知识库四张表的最小字段集

知识库包括评估建议、健康方案、运动项目库、膳食库、疾病库、宣教内容。PRD 里字段不少，落地时不用一次全做，但最小字段集要先定。评估建议要能按评估结果关联推荐内容；膳食库要有能量、蛋白质、脂肪和适用人群；运动项目库要有强度、千步当量、运动时间、年龄区间、运动方法和注意事项；疾病库和宣教内容至少要有名称、分类、正文、适用人群、状态。

这里要强调快照。干预模板引用膳食库和运动项目库时，如果只存 ID，知识库一改，历史模板和已执行方案都会跟着变。比较稳的做法是模板保存时存一份内容快照，方案生成时再从模板复制一份快照，方案执行期间不随知识库变化。这样健康管理师回看历史方案，能看到当时到底建议了什么。

提示：知识库的写权限只给管理员，健康管理师只读。接口层要校验，不要只靠前端隐藏按钮。

4. 流程与接口：预约、评估、干预如何串起来

PRD 的流程图是业务节点，不是接口清单。落到开发要回答三个问题：谁调用、传什么参数、失败怎么回。健康管理类系统的流程串行性强，预约没到诊就做不了现场评估，评估没完成就不好制定干预方案，所以接口设计要把前置校验写清楚，不能等页面报错才补。

4.1 预约管理：号源、套餐、到诊确认

预约管理的流程是：管理员维护检查项和套餐，设置开诊时间；患者从微信端或健康管理师从后台新增预约；健康管理师确认预约；患者到诊后登记到诊，或者取消预约。PRD 里预约类型分电话预约和微信预约，预约状态要能表达待确认、已确认、已到诊、已取消。号源是这里最容易超卖的地方，预约设置里的日历排班要按日期和时段扣减名额。

新增预约时先校验档案号存在、套餐启用、预约日期有号源，再用数据库行锁或唯一约束扣减号源。取消预约要释放号源，但不要物理删除预约记录，统计还要用。到诊登记单独接口，不要和确认接口合并，否则统计到诊率时会把确认当成到诊。重复预约校验按“档案号 + 预约日期 + 套餐”做，允许同一天约不同套餐，但同一套餐不要重复占号。

4.2 健康评估：问卷、指标、报告生成

评估流程分两条线：患者在前台自己填问卷，健康管理师在后台查看结果；患者到诊后由健康管理师新建评估，完成问卷后生成报告。PRD 里评估分风险评估、体质测评、心理测评，每类有自己的问卷和指标。接口设计要把问卷、答案、报告分开，不要一个接口全塞。

报告生成时要把指标的正常参考值、左右临界值、单位一起快照到结果表。否则指标维护员改一次区间，历史报告全变。答案存储可以用明细表，也可以先存 JSON，但报告结果要结构化，方便统计和干预引用。评估记录要加来源字段，区分患者自填和健管师代填，后面统计评估完成量时口径不一样。

4.3 健康干预：人群预分类、模板、方案执行

干预流程是：患者评估后系统预分类，健康管理师确认人群分类；选择干预模板，生成干预方案；执行方案并定期回访；有效则结束，无效则调整方案。PRD 里干预模板有模板标题、关键词、适用人群、方案目标、启用、备注、运动方案、膳食方案、健康方案。制定方案时引用模板，方案本身也要有启用状态和备注。

预分类规则要可解释，不能只给一个分类结果。至少告诉健康管理师是按哪次评估、哪个指标、什么区间分出来的。模板生成方案时复制内容快照，方案执行中改模板不影响已生成方案。回访记录要单独表，统计工作量时“回访量”按回访记录数算，还是按方案数算，要提前定。方案结束前必须有一次回访完成记录，否则结束量会虚高。

4.4 统计分析：工作量统计口径先定，再写 SQL

统计分析模块看起来简单，实际上最容易扯皮。PRD 里工作量统计要显示健康管理师干预方案总量、干预回访量、干预结束量，还要选择时间区间，并按权限限定查看人员。三个指标的口径必须写清楚：方案总量按创建时间还是执行时间，回访量按回访记录还是方案去重，结束量按状态变更时间还是方案创建时间。口径不统一，两个人跑出来的报表能差一倍。

-- 按时间区间统计健康管理师工作量，参数由前端传入 SELECT p.manager_id, COUNT(DISTINCT p.plan_id) AS plan_total, COUNT(DISTINCT f.follow_id) AS follow_total, COUNT(DISTINCT CASE WHEN p.status = 3 THEN p.plan_id END) AS finish_total FROM intervention_plan p LEFT JOIN follow_up_record f ON f.plan_id = p.plan_id WHERE p.created_at >= ? AND p.created_at < ? AND (? IS NULL OR p.manager_id = ?) GROUP BY p.manager_id;

这段 SQL 的逻辑是按方案创建时间圈定区间，左连接回访记录，分别统计方案数、回访数和结束数。参数上，时间区间用左闭右开，避免月底重复统计；manager_id 为空时由后端按权限注入，不要让前端随便传。结束量建议再关联状态日志表，按状态变更时间统计，而不是看当前状态，这样历史区间才准。统计接口最好加缓存，但缓存键要带权限范围和时间区间，别把管理员的数字缓存给健康管理师。

5. 避坑与排查：PRD 转开发时最容易翻车的五个地方

PRD 写得再细，落地也会有歧义。健康管理类系统字段多、角色多、状态多，下面五条是这类项目里最常见的翻车点，每条按现象、原因、解决写。有些问题在开发阶段看不出来，等到导入数据、生成报告、跑统计时才爆，返工成本比一开始加约束高得多。

5.1 档案号没做唯一约束，批量导入后患者被覆盖

现象：批量导入体检报告后，同名患者档案被合并，历史评估记录找不到，健康管理师说“人还是那个人，数据没了”。原因：PRD 只写档案号字符型、不可空，没强调唯一；导入脚本用姓名加手机号匹配，遇到同名同手机号或手机号录错就覆盖。解决：档案号加唯一索引，导入前先按档案号查，查不到再按身份证查，仍然冲突的进待处理队列，不自动覆盖。导入日志要记录原始行号和冲突原因，方便人工修正。

5.2 把左右临界值当正常参考值用，评估报告大面积标红

现象：同一批体检数据生成评估报告，大部分指标都显示异常，健康管理师不敢发。原因：程序拿正常参考值做判断，但 PRD 明确左右临界值才是实际评估对照值；另外性别分组没带上，男性用了女性区间。解决：判断逻辑只读 left_critical 和 right_critical，正常参考值只用于展示；按性别匹配区间，通用指标用 A 兜底；边界等于临界值时按产品确认的规则处理；报告保存指标快照。上线前用几条已知正常、偏低、偏高的数据做回归。

5.3 预约状态和到诊状态混在一个字段，统计口径漂移

现象：本月预约量把取消的也算进去，到诊率算不出来，运营和健康管理师各说各的。原因：预约状态一个字段塞了待确认、已确认、已到诊、已取消，统计时只能猜。解决：预约状态和到诊状态分字段，或者用状态加事件表；取消释放号源但不删记录；到诊单独记到达时间；统计预约量按创建时间，到诊量按到诊时间，取消量按取消时间。状态变更写日志，后面补报表不用洗数据。

5.4 知识库权限只做菜单级，健康管理师能改基础数据

现象：健康管理师在干预页面能改膳食库内容，改完后历史方案里的饮食建议跟着变。原因：权限只控制了菜单显示，接口没做角色校验；干预模板直接引用知识库 ID，没有快照。解决：知识库写接口只允许管理员角色；健康管理师接口只读；模板和方案保存内容快照；所有知识库修改写审计日志。前端隐藏按钮只能算体验优化，不能当权限。

5.5 报告文件只存路径没做版本，删了无法追溯

现象：报告上传错了重新传，旧文件被覆盖；删除报告后文件还在存储里，或者文件删了记录还在。原因：报告表用档案号加体检时间做唯一键，上传直接覆盖；删除做物理删除。解决：报告表用 report_id 做主键，加 version、file_hash、deleted 字段；覆盖上传生成新版本，旧版本保留；删除做软删除，文件按保留策略清理；下载接口校验权限，不直接暴露存储路径。这样出了问题还能查是哪一版、谁传的、什么时候传的。

6. 验收前我会补的三张表：字段级验收用例、状态迁移表、权限回归清单

PRD 功能详情里“增删改查”四个字最容易漏验收。我现在拿到这类健康管理 PRD，会先补三张表再让测试写用例：字段级验收用例、状态迁移表、权限回归清单。字段级用例按“字段、必填、边界、预期”列，比如档案号重复导入必须报错，BMI 要按身高体重重算，血压收缩压小于舒张压要拦截；状态迁移表按“当前状态、动作、下一状态、操作人”列，预约取消后能不能重新预约，干预结束后能不能调整，都要有明确断言；权限回归清单按“角色、菜单、接口、数据范围”列，健康管理师不能调知识库写接口，患者不能查别人报告。

这三张表不用等开发全做完才补，需求评审后就能拉。字段级用例直接对着 PRD 的数据结构表逐行过，状态迁移表对着流程图过，权限清单对着用户角色描述过。每发现一个歧义，就在表里加一条待确认，别留在聊天记录里。从那以后我每次拿到健康管理类 PRD，都先把角色表和字段表对一遍，再让前端画页面，避免页面先出来字段对不上。希望帮到你。

本文还有配套的精品资源，点击获取