| 分析点 | 原文档描述 | 优化 / 补充建议 | 理由 | 类型 |
|---|---|---|---|---|
| 患者来源 | 直接"录入患者个人信息"，未区分新建和选择已有患者 |
流程起点应增加「选择已有患者 / 新建患者」分支
已有患者应可直接调取历史病历，关联本次就诊记录
|
复诊是中医馆的核心场景。若每次就诊都新建患者，会导致同一患者出现多条重复档案，病历数据碎片化，无法形成连续的诊疗记录，也影响后续处方参考。
|
缺失 |
| 四诊信息 | 未提及 |
建议增加四诊信息采集字段：望（舌象图片）、闻、问、切（脉象描述）
舌象可复用已有的"上传图片"功能，脉象可用文字字段
|
望闻问切是中医诊疗的基本方法论，是辨证论治的基础依据。如果病历中不记录四诊信息，复诊时医生无法对比病情变化，也无法支撑后续的证型判断和用药调整。
|
补充 |
| 处方预览确认 | 生成处方后直接进入代煎选择，无确认环节 |
生成处方后增加「处方预览确认」步骤，医生可在此步骤检查完整处方内容
药物冲突检测结果应在此步骤醒目高亮展示，而非仅弹窗提示
|
处方涉及多味药材和复杂的用量配伍，直接跳转下一步容易遗漏检查。确认步骤是防错的最后一道关卡，尤其对药物冲突警告，需要医生明确看到并决定是否继续。
|
优化 |
| 订单状态流转 | 未提及 |
结算后应有完整状态链：待付款 → 已付款 → 配药中 → 待发货/待自取 → 已完成
医生端和管理后台均应可查看订单当前状态
|
没有订单状态，医生不知道哪些处方已收款、哪些需要配药、哪些已发货；仓库不知道哪些订单需要配药出库。结算和发货之间缺少中间状态会导致流程混乱，容易出现漏发货、重复发货等问题。
|
缺失 |
| 处方修改/撤销 | 未提及 |
支持处方生成后、结算前的修改和撤销操作
已结算的处方如需修改，应有退款/作废流程
|
实际诊疗中，医生开完处方后调整用药方案是常见场景（如患者反馈某药过敏、临时增加药味等）。如果没有修改能力，只能废弃整张处方重新开，浪费时间且容易产生大量无效处方数据。
|
缺失 |
| 支付确认机制 | 结算（显示收款码），但无支付确认环节 |
收款码展示后，需有确认收款操作（医生手动确认 或 对接支付系统自动回调）
未确认收款的处方不应进入配药/发货流程
|
展示收款码不等于完成支付。如果没有确认机制，医生无法区分"已展示收款码但患者未付款"和"已完成支付"的情况，会导致未收款就发货的资金风险。
|
缺失 |
| 功能点 | 原文档描述 | 优化 / 补充建议 | 理由 | 类型 |
|---|---|---|---|---|
| 实名认证审核 | 上传身份证、执业医师证等资料，后台审核需要实名认证 |
应有审核状态反馈：待审核 / 已通过 / 已驳回（附驳回原因）
需明确认证未通过时的功能权限范围：能否浏览但不能开方？还是完全不可使用？
|
医生提交资料后如果没有任何状态反馈，会反复提交或流失。驳回时不说明原因，医生无法修正资料。同时，医疗行业对执业资格有严格要求，必须明确未认证状态下的系统行为，避免出现无资质人员使用系统开方的合规风险。
|
优化 |
| 账号安全 | 账号密码登录、手机验证码登录、微信授权登录、忘记密码 |
建议增加登录设备管理（查看当前登录设备，可踢出异常设备）
建议增加登录异常提醒（异地登录、新设备登录时短信通知）
|
医生账号关联处方权和患者隐私数据，账号被盗用可能导致非法开方或患者信息泄露。多登录方式增加了被盗风险面，设备管理可以及时发现和阻止异常访问。
|
补充 |
| 功能点 | 原文档描述 | 优化 / 补充建议 | 理由 | 类型 |
|---|---|---|---|---|
| 今日数据 | 今日数据、开处方数量 |
"今日数据"定义模糊，建议拆分为具体指标：今日就诊人数、今日处方数、今日收入金额、待处理订单数
增加待办提醒：待发货订单、待处理事项
|
"今日数据"过于笼统，开发和设计时无法落地。明确的指标卡片让医生打开首页就能看到当天核心工作状态。待办提醒能帮助医生快速识别需要处理的事项，避免遗漏发货等时效性操作。
|
优化 |
| 功能点 | 原文档描述 | 优化 / 补充建议 | 理由 | 类型 |
|---|---|---|---|---|
| 患者信息字段 | 填写患者信息、患者症状描述、新建档案 |
需明确患者基本信息字段：姓名、性别、年龄/出生日期、手机号、身份证号、过敏史、既往病史、体重（儿童用药需参考）
区分必填字段和选填字段，避免录入负担过重
|
不定义字段，开发无法实施。性别、年龄影响用药剂量；过敏史是安全用药的关键前置条件，如果遗漏可能导致医疗事故；儿童中药用量需按体重计算，这些字段直接影响开方的安全性和准确性。
|
缺失 |
| 患者列表 | 支持关键字查找、服务过的患者列表、搜索查找患者档案 |
"支持关键字查找"和"搜索查找患者档案"功能重复，建议合并为一个搜索组件
列表应有排序和筛选：按最近就诊时间排序、按复诊/初诊筛选
建议增加患者标签功能：慢性病、复诊患者、VIP 等
|
"关键字查找"和"搜索查找"在文档中出现了两次，实际是同一功能，重复描述会增加开发工作量。排序筛选是列表页面的基础能力，医生最常用的场景是"找到最近来看过的患者"，默认排序应满足此需求。标签功能帮助医生快速分类管理大量患者。
|
优化 |
| 档案管理 | 未提及档案的删除/停用 |
增加患者档案的归档/停用功能（不建议物理删除）
归档的患者默认不在列表中显示，但可通过搜索找到
|
医疗数据有保存时限的合规要求，不能随意删除。但长期不活跃的患者档案如果始终显示在列表中，会影响医生查找常用患者的效率。归档是兼顾合规和体验的方案。
|
缺失 |
| 功能点 | 原文档描述 | 优化 / 补充建议 | 理由 | 类型 |
|---|---|---|---|---|
| 诊断内容 | 文字说明 |
诊断内容应结构化：主诉、现病史、证型/证候、治法（至少包含证型和治法）
建议支持常用诊断模板：医生可保存和复用常用诊断组合
小程序端建议支持语音输入转文字
|
仅"文字说明"过于宽泛，不同医生书写习惯差异大，不利于后续复诊查阅和数据统计。结构化的证型/治法是中医诊断的核心输出，也是选方用药的直接依据。诊断模板可以大幅减少重复录入（中医常见病证型相对固定），语音输入则解决手机端打字效率低的问题。
|
优化 |
| 功能点 | 原文档描述 | 优化 / 补充建议 | 理由 | 类型 |
|---|---|---|---|---|
| 处方副数 | 未提及 |
增加处方副数（剂数）字段，系统默认常用剂数（如 7 副），支持修改
|
中药处方必须明确剂数，它直接决定药材总用量和总价。缺少此字段，配药环节无法执行，结算金额也无法计算。这是处方最基本的要素之一。
|
缺失 |
| 用法用量说明 | 未提及 |
增加用法用量字段：如"水煎服，每日一剂，分早晚两次温服"
提供常用用法模板供选择，也支持自定义输入
|
用法用量是处方的法定要素。没有用法说明，患者不知道如何煎药和服用，影响疗效甚至可能因错误服用方式导致不良反应。《处方管理办法》明确要求处方必须包含用法用量。
|
缺失 |
| 禁忌/注意事项 | 未提及 |
增加禁忌和注意事项字段：忌口说明（忌辛辣/生冷/油腻）、特殊人群提示（孕妇慎用等）
|
中药治疗非常注重饮食禁忌，某些药材与特定食物同服会降低药效甚至产生副作用。如果没有注意事项字段，医生只能口头告知，患者容易遗忘，影响治疗效果。
|
缺失 |
| 药物冲突处理 | 系统要判断出，该处方是否有药物冲突（冲突的药物，提前在后台进行录入） |
需明确冲突检测后的处理策略：仅弹出警告（医生可选择继续），还是强制拦截（不允许生成处方）？
建议分两级：严重冲突（如十八反）强制拦截；一般冲突（如配伍注意）警告但允许医生确认后继续
冲突检测结果应记录到操作日志，便于追溯
|
仅"判断出"不够，必须定义判断后的系统行为。十八反（如甘草与海藻）是中医公认的绝对禁忌，应强制拦截防止医疗事故；而部分配伍注意（如某些药合用需谨慎）可由医生根据临床经验判断是否使用。记录日志则是为了事后追溯责任。
|
优化 |
| 协定方管理 | 选择协定方：展示出自己之前开过的药方，医生可以直接选择使用 |
协定方不应只有"自己之前开过的药方"，还应有医馆统一的协定方库（由管理后台维护）
协定方管理应支持：新增、编辑、停用、分类、搜索
区分"个人常用方"和"医馆协定方"两个维度
|
协定方是指经医疗机构审定、固定组成的处方（如银翘散、小柴胡汤等经典方），是医馆的标准治疗方案。仅展示医生个人历史药方，新入职医生无法使用已有协定方，也不利于医馆统一治疗标准和质量控制。
|
优化 |
| 2/3量转换 | 要求：可设置转换2/3量 |
需明确转换规则：是针对全方所有药材统一转换，还是单味药可单独设置？
转换时机：是开方时一键转换，还是生成处方前自动计算？
转换后是否保留原始剂量的记录？
|
"2/3量"是中医儿科和体弱患者常用的剂量折算方式，但文档描述过于简略，开发无法理解具体交互逻辑。必须明确是全局操作还是逐药操作，以及转换后原始数据是否需要留存（便于回溯和调整）。
|
待确认 |
| 代煎中药 | 选择是否代煎中药（饮片、膏方等特殊药品需要有煎药费，按副收取） |
需明确煎药费的计费标准：每副固定金额？不同药品类型（饮片 vs 膏方）费用是否不同？
煎药费应在管理后台可配置，而非硬编码
颗粒和粉剂不涉及代煎，选择颗粒/粉剂时应自动隐藏代煎选项
|
煎药费直接影响结算金额，如果计费标准不明确，开发无法实现。代煎费用可能随运营成本调整（如人工涨价），硬编码会导致每次调价都需要修改代码。颗粒和粉剂本身不需要煎煮，展示代煎选项会造成用户困惑。
|
优化 |
| 功能点 | 原文档描述 | 优化 / 补充建议 | 理由 | 类型 |
|---|---|---|---|---|
| 物流管理 | 发货：填写患者收货地址、联系人、电话等 |
增加物流公司和物流单号填写字段
增加发货通知功能：发货后通过短信或微信模板消息通知患者
自取方式应有取药码/核销机制，确认患者已取药
|
没有物流单号，医生和仓库无法追踪包裹状态，患者咨询物流进度时无法回答。没有发货通知，患者不知道药品已发出，会频繁咨询。自取如果没有核销机制，无法确认患者是否已取药，订单状态无法闭环。
|
缺失 |
| 结算明细 | 显示总价结算、展示收款码 |
应展示费用明细：药材费（按药材逐项列出）、代煎费（每副 x 副数）、邮费，分项列出后显示总价
收款码建议动态生成对应金额的收款码，而非固定码
缺少退款流程说明：哪些场景可退？谁来审批退款？退款后订单和库存如何处理？
|
仅显示总价，患者无法了解费用构成，容易产生费用争议。动态收款码可以避免患者手动输入金额导致的错误付款。退款是必然存在的业务场景（如药物过敏、处方错误等），没有退款流程会导致财务对账混乱。
|
缺失 |
| 功能点 | 原文档描述 | 优化 / 补充建议 | 理由 | 类型 |
|---|---|---|---|---|
| 积分体系 | 积分数量显示、积分明细、积分规则说明、查找（按时间段查询） |
需定义积分获取规则：每次开处方获得多少积分？按处方金额比例还是固定值？
需定义积分用途：积分能做什么？提现？兑换礼品？排名展示？抵扣？
如积分可提现，需明确提现规则和手续费
|
积分体系是医生端的重要激励机制，但文档仅描述了积分的展示（查看数量/明细/规则），完全没有定义积分的来源规则和消耗规则。没有明确规则，开发无法实现积分的计算逻辑，积分体系也就形同虚设。
|
待确认 |
| 业绩统计 | 业绩显示：开处方数量；本月总业绩：开处方数量 |
"业绩"仅用处方数量衡量过于单一，建议增加处方金额统计
增加时间段筛选：本周/本月/本季度/自定义日期范围
增加业绩数据的图表展示：处方数量趋势折线图、药品类型分布饼图
|
处方数量不能完整反映业绩——一张 3 味药的简单处方和一张 20 味药的复杂处方工作量差异很大。金额统计能更全面反映业绩。图表展示帮助医生直观了解业务趋势，比纯数字更有参考价值。
|
优化 |
| 功能点 | 原文档描述 | 优化 / 补充建议 | 理由 | 类型 |
|---|---|---|---|---|
| 在线客服 | 展示平台客服联系方式、在线沟通（需对接第三方在线客服系统） |
需明确对接哪个第三方客服系统（如美洽、智齿、网易七鱼、企业微信客服等）
如暂不确定，建议先预留标准化的接入接口，后续灵活切换
|
不同第三方客服系统的对接方式和成本差异很大（如美洽是 JS SDK 嵌入，企微客服需要企业认证），不明确选型会导致开发方案无法确定，也可能在后期被迫返工。
|
待确认 |
| 多终端同步 | 小程序 + PC网站，数据同步 |
需明确：PC网站和小程序的功能范围是否完全一致？
建议 PC 端支持批量操作和数据导出（适合重度办公场景），小程序侧重移动场景下的快速开方
数据同步建议为实时同步（同一账号在两端操作不应出现数据不一致）
|
PC 和小程序的使用场景差异大——PC 适合长时间坐诊开方，小程序适合外出会诊或临时补开处方。如果不做功能差异化，PC 端会浪费大屏优势，小程序端则会因功能过重导致体验差。实时同步是基本预期，定时同步会导致两端数据不一致的混乱。
|
待确认 |
| 功能点 | 原文档描述 | 优化 / 补充建议 | 理由 | 类型 |
|---|---|---|---|---|
| 申请采购 | 申请采购 |
需细化采购流程：采购单创建 → 审批 → 供应商下单 → 到货验收 → 入库
增加供应商管理模块：供应商名称、联系方式、资质、主营品类
需明确审批流程：仓库员提交，管理员审批？还是多级审批？
支持根据库存预警自动生成采购建议
|
"申请采购"四个字无法支撑一个完整的业务模块。药品采购涉及资金支出，必须有审批流程控制。供应商管理是采购的基础，不知道从哪家供应商采购就无法下单。库存预警联动采购建议可以减少人工监控库存的工作量，避免断货影响开方。
|
缺失 |
| 入库管理 | 入库管理 |
入库需记录：药品名称、批号、生产日期、有效期、数量、供应商、采购单关联
应有入库验收环节：核对数量、检查品质、确认是否与采购单一致
入库后自动更新库存数量
|
药品是特殊商品，批号和有效期是法规要求必须追溯的信息（《药品管理法》）。入库不关联采购单，就无法核对到货是否完整、是否多收或少收。不验收直接入库，可能出现品质问题无法追溯。
|
优化 |
| 出库管理 | 出库管理 |
明确出库类型：处方配药出库、报损出库、退货出库、样品出库
应遵循先进先出（FIFO）原则：优先出库有效期较近的批次
出库应自动扣减库存并记录出库明细
|
不同出库类型的业务含义和财务处理不同，混在一起会导致库存数据不准确。先进先出是药品管理的标准做法，避免近效期药品积压过期造成浪费。出库不自动扣库存会导致账面库存与实际库存不符。
|
优化 |
| 库存盘点 | 库存盘点 |
支持全盘（全部药品）和抽盘（按品类/库位抽查）两种方式
盘点差异应有盘盈/盘亏处理流程：差异确认 → 审批 → 系统调整库存
盘点期间是否冻结出入库操作？需明确
|
全盘适合月末/季末大盘点，抽盘适合日常抽查，两种方式互补。盘点发现差异后如果没有处理流程，差异数据就一直挂在那里无法平账。盘点期间如果不冻结出入库，盘点的结果可能因为同时发生的出入库操作而变得不准确。
|
补充 |
| 发货管理 | 发货管理 |
需明确仓库端发货与医生端"发货"的职责划分：医生端负责填写收货信息和发起发货请求，仓库端负责实际配药、打包、录入物流单号
仓库端发货应支持批量操作：批量打印发货单、批量录入物流信息
|
文档中医生端和管理后台都有"发货"功能，职责不清会导致同一笔订单被两方重复操作，或互相推诿。明确分工后，医生只负责"告诉系统发给谁、发到哪里"，仓库负责"实际配药打包发货"，各司其职。
|
优化 |
| 效期管理 | 未提及 |
增加药品有效期管理：入库时录入有效期，系统自动计算近效期药品
设置近效期预警（如距过期 90 天/60 天/30 天分级预警）
过期药品应有锁定和报损处理流程，防止误用
|
使用过期药品是严重的医疗安全事件，可能面临行政处罚甚至刑事责任。效期管理是药房管理的刚需，不是可选项。近效期预警可以提前处理（促销消化或退货），减少过期损失。过期药品必须锁定，防止被误配到患者处方中。
|
补充 |
| 功能点 | 原文档描述 | 优化 / 补充建议 | 理由 | 类型 |
|---|---|---|---|---|
| 账号体系 | 管理后台进行手动注册、手机号注册、微信授权注册 |
需明确：管理后台、医生端是统一账号体系还是各自独立？
建议采用统一账号体系，通过角色区分不同终端的权限
|
如果各端独立注册，同一个医生在医生端和管理后台会有两个账号，数据无法打通，也无法统一管理人员。统一账号体系是行业通用做法，一个人一个账号，通过角色决定他能访问哪些功能和数据。
|
待确认 |
| 角色权限管理 | 未提及 |
增加角色权限管理模块，至少包含以下角色：超级管理员、管理员、仓库管理员、医生
权限粒度至少到菜单级别（哪些角色能看到哪些菜单），建议支持到按钮级别（如只能查看不能编辑）
医生只能查看和操作自己的患者和处方数据，不能看到其他医生的数据
|
没有权限控制，所有登录用户都能看到和操作所有功能，仓库员可以修改处方，医生可以操作采购——这在任何系统中都是不可接受的。权限管理是后台系统的基础设施，不是可选功能。
|
缺失 |
| 操作日志 | 未提及 |
增加操作日志功能：记录关键操作的执行人、操作时间、操作内容、变更前后数据
关键操作包括：登录/登出、处方创建/修改/删除、库存变更、权限变更、系统配置修改
|
涉及药品和医疗记录的系统，操作追溯是基本安全要求。如果出现处方被篡改、库存数据异常、权限被违规修改等问题，没有操作日志就无法排查原因和确定责任人。
|
补充 |
| 功能点 | 原文档描述 | 优化 / 补充建议 | 理由 | 类型 |
|---|---|---|---|---|
| 药库分类 | 颗粒药库和中药饮片药库 |
药库只提到颗粒和饮片，缺少膏方药库和粉剂药库
四种药品类型应有各自独立的库存管理，因为同一种药材在不同形态下的库存和价格不同
|
医生端开处方时支持四种药品类型（颗粒/膏方/饮片/粉剂），但药库只有两种，意味着膏方和粉剂的库存没有管理，医生开了膏方或粉剂处方后，仓库无法知道库存是否充足，也无法进行出库操作。
|
缺失 |
| 药品基础信息 | 手动录入对应的药品情况 |
需定义药品基础信息字段：药品编码、名称、别名、产地、等级、规格、单位、单价、药品类型（饮片/膏方/颗粒/粉剂）
建议支持药品导入功能（Excel 批量导入），逐条手动录入效率极低
|
"手动录入药品情况"没有定义需要录入哪些信息。药品编码是唯一标识，别名方便搜索（如"金银花"别名"忍冬花"），产地和等级影响价格和质量。一味中药可能有数百种常用药材，逐条手动录入工作量巨大，导入功能是效率的刚需。
|
缺失 |
| 药物冲突数据 | 有冲突的中药，会在后台提前录入进去 |
需要有药物配伍禁忌管理模块：维护药物冲突对（如甘草-海藻、乌头-半夏等）
建议预置常见的十八反、十九畏数据，同时支持后台手动添加/修改/删除
冲突数据应标注严重等级（绝对禁忌 vs 相对注意）
|
文档提到"冲突的中药会在后台提前录入"，但没有描述录入的管理入口。没有管理模块，冲突数据无法维护，处方冲突检测功能也就无法运行。预置常见禁忌数据可以减少从零开始的录入工作量，严重等级区分则支撑冲突检测的分级处理策略。
|
缺失 |
| 库存不足提醒 | 药品库存不足提醒 |
每种药品应支持自定义预警阈值（如黄芪低于 500g 时提醒，甘草低于 1kg 时提醒）
提醒方式需明确：站内消息？短信？管理后台首页弹窗？
建议增加一键生成补货采购单功能
|
不同药品的消耗速度差异很大（常用药消耗快、冷门药消耗慢），统一阈值无法满足实际需求。提醒后如果没有便捷的补货操作，仓库人员还需要手动去创建采购单，流程断裂。一键补货可以将预警和采购衔接起来。
|
优化 |
| 后台开关 | 后台开关 |
需明确"后台开关"控制的具体功能：是控制医生端某个功能的启用/停用？还是控制某种药品类型的上架/下架？
|
"后台开关"在文档中出现了两次，但都没有说明控制什么。开发无法实现一个没有明确目标的"开关"功能，需要明确开关的对象、默认值和影响范围。
|
待确认 |
| 功能点 | 原文档描述 | 优化 / 补充建议 | 理由 | 类型 |
|---|---|---|---|---|
| 处方统计维度 | 关键字查找处方列表、查看处方详情、开处方数量、自己开处方的数量 |
"自己开处方的数量"出现在管理后台不合理——管理员不等于医生。建议改为按医生维度查看处方统计
管理员应能看到所有医生的处方汇总，并可按医生筛选
|
管理后台是管理员使用的系统，管理员的核心诉求是"看全局数据"，而不是"看我自己的处方"。"自己开处方的数量"是医生端的功能，出现在管理后台说明文档可能存在模块混淆，需要重新梳理。
|
优化 |
| 处方导出 | 未提及 |
增加处方打印功能：按照中医处方标准格式打印
支持导出 Excel，便于统计分析和存档
|
中医馆实际工作中，纸质处方仍然是重要的存档和配药依据。仓库配药时通常需要纸质处方作为拣药单。不支持打印，医生就只能截图或手抄，效率低且容易出错。
|
补充 |
| 协定方管理 | 未提及管理入口 |
管理后台应有协定方管理模块：新增/编辑/停用/分类/搜索
协定方应包含：方名、组成（药材+用量）、功效、适用证型、创建人、状态（启用/停用）
|
协定方是医馆的标准化治疗方案，需要有人维护。如果没有管理入口，协定方数据就无处维护，医生端的"选择协定方"功能也就没有数据源。
|
缺失 |
| 功能点 | 原文档描述 | 优化 / 补充建议 | 理由 | 类型 |
|---|---|---|---|---|
| 数据统计 | 需要支持驾驶舱大屏展示；历史数据 |
建议聚焦核心业务报表：处方统计（按医生/时间段/药品类型）、营收统计、库存变动流水
"历史数据"描述为空，需明确查询维度和导出方式
|
大屏展示属于锦上添花的展示层功能，优先级低于核心业务流程。先保证处方统计、营收报表、库存流水等基础数据查询能力可用，后续按需再增加可视化展示。
|
优化 |
| 财务管理 | 未提及 |
增加财务管理模块：收入统计（日/周/月/年）、对账管理、退款审批、收支明细
支持按医生维度查看业绩，用于提成/绩效结算
|
系统涉及收款（结算）和采购支出，必须有财务管理来统计收入、核对账目、管理退款。没有财务模块，医馆经营者无法了解经营状况，也无法进行财务对账和税务申报。
|
补充 |
| 系统设置 | 未提及 |
增加系统设置模块：医馆基本信息、煎药费设置、邮费规则设置、默认药材用量设置（5g/10g/15g/20g）、打印模板管理
|
煎药费、邮费、默认用量等参数散落在各个业务流程中被引用，如果硬编码在代码中，每次调整都需要开发人员修改代码重新部署。通过系统设置模块，管理员可以自主调整这些参数，降低运维成本。
|
补充 |
| 维度 | 原文档描述 | 建议补充 | 理由 | 类型 |
|---|---|---|---|---|
| 数据安全 | 未提及 |
患者病历属于敏感医疗数据，需明确数据加密存储、传输加密、访问控制和脱敏策略
身份证号、手机号等隐私信息在前端展示时应脱敏处理（如 138****5678）
|
患者病历包含姓名、身份证号、病史等高度敏感个人信息，受《个人信息保护法》《数据安全法》保护。如果发生数据泄露，不仅面临高额罚款，还会严重损害医馆声誉。数据安全不是可选项，是法律底线。
|
缺失 |
| 医疗合规 | 未提及 |
处方管理需考虑《处方管理办法》《药品管理法》等法规要求
电子处方是否有电子签名要求？处方数据保存时限？
|
医疗系统不同于普通业务系统，处方管理有明确的法律规范。如果系统设计不符合法规要求，上线后可能面临监管处罚。需要在开发前确认合规要求，避免后期大规模返工。
|
风险 |
| 数据备份 | 未提及 |
医疗数据应有定期自动备份和灾难恢复方案
建议每日自动备份，备份数据异地存储
|
处方和病历数据一旦丢失不可恢复，不仅影响患者后续复诊（医生无法查阅历史诊疗记录），还可能因无法提供诊疗记录而面临法律纠纷。
|
补充 |
| 打印功能 | 未提及 |
中医馆场景下需要支持：处方笺打印、发货单/快递面单打印、药品标签打印
|
仓库配药需要纸质处方或拣药单，发货需要快递面单，药品包装需要标签（标注患者姓名、药品名称、用法用量）。这些都是日常操作的高频需求，不支持打印会严重影响工作效率。
|
补充 |
| 消息通知 | 仅提到"系统推送的消息提醒" |
需明确通知渠道：微信模板消息、短信、站内信
需明确通知场景：发货通知、库存预警、认证审核结果、系统公告、待办提醒等
|
不同通知渠道的接入方式和成本不同（短信按条计费，微信模板消息免费但需用户关注公众号/使用小程序）。不同场景的紧急程度不同，对应不同的渠道选择（紧急用短信，日常用站内信）。不明确这些，开发无法设计通知模块。
|
优化 |