docs(requirements): 补充飞书接入与法规规则源口径
This commit is contained in:
@@ -12,6 +12,8 @@
|
||||
|
||||
本系统面向 **NMPA 境内第三类体外诊断试剂注册申报资料准备与审核** 场景，服务于需要整理、核查、抽取、回填和追踪注册资料的业务人员。
|
||||
|
||||
系统主体围绕注册申报审核场景展开，但能力目标是沉淀为“通用的试剂盒临床注册文件准备与审核智能体”，而不是只绑定某一个具体试剂盒产品。
|
||||
|
||||
系统不再以“适配任意业务题”的通用 Demo 作为对外主叙事，而是聚焦以下业务价值：
|
||||
|
||||
1. 自动汇总注册资料目录与页数。
|
||||
@@ -29,6 +31,18 @@
|
||||
2. `docs/目标产品说明书.docx`
|
||||
3. `docs/附件 4 体外诊断试剂注册申报资料要求及说明.doc`
|
||||
4. `docs/第1章 监管信息/` 下的监管目录、申请表、产品列表、声明与沟通记录样例
|
||||
5. `docs/原始材料/关于公布体外诊断试剂注册申报资料要求和批准证明文件格式的公告/` 下的公告附件包
|
||||
|
||||
其中新增公告附件包使法规依据不再只是单篇“资料要求说明”，而是扩展为一组正式规则来源，包括：
|
||||
|
||||
1. 体外诊断试剂注册申报资料要求及说明
|
||||
2. 医疗器械注册申报资料和批准证明文件格式要求（体外诊断试剂）
|
||||
3. 体外诊断试剂安全和性能基本原则清单
|
||||
4. 中华人民共和国医疗器械注册证（体外诊断试剂）格式
|
||||
5. 体外诊断试剂变更备案 / 变更注册申报资料要求及说明
|
||||
6. 体外诊断试剂延续注册申报资料要求及说明
|
||||
|
||||
当前 V1 默认以“公告附件包”作为主规则来源，并将 `附件 4 体外诊断试剂注册申报资料要求及说明` 视作同源补充材料，而不是独立的第二套规则来源。
|
||||
|
||||
## 4. V1 范围
|
||||
|
||||
@@ -45,11 +59,19 @@ V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环，
|
||||
7. 审计留痕
|
||||
8. 本地可运行与 Docker 演示启动
|
||||
|
||||
其中第 3 项“法规完整性检查”在 V1 中建议明确分为三层：
|
||||
|
||||
1. 资料齐套性检查
|
||||
2. 章节点和结构合规性检查
|
||||
3. 批准证明文件格式与输出映射检查
|
||||
|
||||
### 4.2 V1 可接受的简化
|
||||
|
||||
1. 首版可优先覆盖第 1 章监管信息，并为全章扩展预留结构。
|
||||
2. 首版可先展示“字段回填结果”和“回填预览”，不把保真 Word 导出作为硬门槛。
|
||||
2. 首版允许分阶段完成 Word 输出能力，但目标交付应包含“生成新的 Word 文档并支持导出”，同时尽量保留原始格式。
|
||||
3. 首版法规校验可以本地规则为主，不强依赖联网抓取最新法规。
|
||||
4. 首版主体仍以 Web 工作台为主，但应纳入飞书接入方案，至少预留飞书消息触发、结果回传和责任人通知链路。
|
||||
5. 首版法规任务边界以“注册申报”主流程为核心，变更备案和延续注册暂作为规则扩展方向。
|
||||
|
||||
## 5. 业务闭环
|
||||
|
||||
@@ -62,6 +84,18 @@ V1 聚焦“可运行、可讲解、可演示”的注册资料审核闭环，
|
||||
5. 对同名字段进行跨文档一致性比对。
|
||||
6. 形成风险清单、回填结果和审计记录。
|
||||
|
||||
在规则执行层，建议采用“双层知识底座”：
|
||||
|
||||
1. 结构化规则文件负责完整性判断、强一致比对和风险映射。
|
||||
2. 公告附件原文切片入 RAG，负责条款引用、证据检索和解释说明。
|
||||
|
||||
在法规维度上，建议把完整流程理解为：
|
||||
|
||||
1. 识别当前审核任务属于“注册申报”主流程。
|
||||
2. 匹配对应的资料要求与章节点模板。
|
||||
3. 检查资料齐套性与章节结构。
|
||||
4. 对需要回填或输出的批准证明文件格式做字段映射准备。
|
||||
|
||||
## 6. 模块拆分
|
||||
|
||||
V1 需求分析按项目现有主模块拆分，不做过度细分：
|
||||
@@ -89,12 +123,29 @@ V1 需求分析按项目现有主模块拆分，不做过度细分：
|
||||
|
||||
### 7.3 系统必须具备“冲突识别”
|
||||
|
||||
当前样例中已经存在不同产品资料混入的迹象，这类问题应被系统识别为高价值异常，而不是忽略。
|
||||
当前样例中已经存在不同产品资料混入的迹象。这不要求系统默认把全部材料视为同一个产品，而是要求系统具备以下能力：
|
||||
|
||||
1. 支持按项目批次或文档范围界定审核对象。
|
||||
2. 对被划入同一审核对象的资料执行严格一致性检查。
|
||||
3. 对混档、错归类和跨产品资料混入给出风险提示。
|
||||
|
||||
### 7.4 系统必须具备“可解释性”
|
||||
|
||||
所有缺失判断、字段抽取和风险预警都应尽量有证据、有来源、有审计记录。
|
||||
|
||||
### 7.5 系统必须具备“法规分层引用”
|
||||
|
||||
结合新增公告附件包，系统应能区分并引用不同层级的规则来源，而不是把所有法规依据混成一条说明：
|
||||
|
||||
1. 资料要求类依据
|
||||
2. 格式要求类依据
|
||||
3. 安全和性能基本原则类依据
|
||||
4. 批准证明文件格式类依据
|
||||
|
||||
### 7.6 系统需要具备“多入口访问能力”
|
||||
|
||||
V1 主体虽然仍以 Web 端演示为主，但系统应预留并逐步实现飞书入口能力，使审核任务可以从浏览器工作台扩展到飞书会话、飞书机器人和文档评论协作场景。
|
||||
|
||||
## 8. 后续文档与实现衔接建议
|
||||
|
||||
后续若继续推进设计与开发，建议按如下顺序展开：
|
||||
|
||||
Reference in New Issue
Block a user