33 lines
13 KiB
Plaintext
33 lines
13 KiB
Plaintext
event: phase
|
||
data: {"id":"evt_1789663519038949547_1","type":"phase","timestamp":"2026-09-17T16:45:19.038950507Z","phase":{"phase_id":"intent_recognizing","message":"正在研判您的意图与项目上下文...","role":"coordinator"}}
|
||
|
||
event: turn_ack
|
||
data: {"id":"evt_1789663519046202771_2","type":"turn_ack","timestamp":"2026-09-17T16:45:19.046205441Z","turn":{"user_message_id":3627,"status":"processing"}}
|
||
|
||
event: status
|
||
data: {"id":"evt_1789663519048229581_3","type":"status","timestamp":"2026-09-17T16:45:19.048230441Z","status":{"intent":"CASUAL_CHAT","branch":"AMBIGUOUS_FALLBACK","current_stage":"V0.1_triage","message":"识别分支: AMBIGUOUS_FALLBACK (置信度: 20%)"}}
|
||
|
||
event: phase
|
||
data: {"id":"evt_1789663520016667046_4","type":"phase","timestamp":"2026-09-17T16:45:20.016668616Z","phase":{"phase_id":"dialogue_generating","message":"正在整理回复...","role":"assistant","progress":40}}
|
||
|
||
event: status
|
||
data: {"id":"evt_1789663520016723644_5","type":"status","timestamp":"2026-09-17T16:45:20.016724074Z","status":{"intent":"CASUAL_CHAT","branch":"AMBIGUOUS_FALLBACK","current_stage":"V0.1_triage","message":"意图判定: CASUAL_CHAT (置信度: 20%)"}}
|
||
|
||
event: phase
|
||
data: {"id":"evt_1789663520016913708_6","type":"phase","timestamp":"2026-09-17T16:45:20.016913968Z","phase":{"phase_id":"dialogue_generating","message":"正在生成项目助手回复...","role":"assistant","progress":60}}
|
||
|
||
: heartbeat 1789663534
|
||
|
||
: heartbeat 1789663549
|
||
|
||
: heartbeat 1789663564
|
||
|
||
: heartbeat 1789663579
|
||
|
||
event: delta
|
||
data: {"id":"evt_1789663589203412243_7","type":"delta","timestamp":"2026-09-17T16:46:29.203413813Z","delta":"# IEC 62304 与 ISO 13485 交叉合规要点——可执行检查项清单\n\n\u003e **适用说明**：本清单聚焦软件类医疗器械（SA/SB级）开发与质量管理体系的核心交叉节点，适用于注册前内部审计或委托方核查参考。具体证据要求请以官方审核意见及实际检测结果为准。\n\n---\n\n## 一、顶层体系架构（对应 ISO 13485 Cl.4 / IEC 62304 Cl.4）\n\n### 检查项 1：软件质量管理体系覆盖完整性\n\n**理由**：IEC 62304 将软件生命周期过程嵌入质量管理体系框架，若QMS未明确覆盖软件特定要求（如变更控制、配置管理），两者即存在体系缝隙。\n\n**证据要求**：\n- 质量手册中明确引用 IEC 62304 作为支持性标准\n- 程序文件覆盖软件计划、需求、设计、验证、确认、维护全过程\n- 质量目标分解至软件关键过程\n\n**常见失败模式**：\n- QMS文件仅笼统提及\"软件开发\"但未细化软件特定过程\n- IEC 62304要求被作为\"参考\"而非\"强制\"嵌入体系\n\n---\n\n### 检查项 2：风险管理整合（ISO 14971 × IEC 62304）\n\n**理由**：IEC 62304要求软件相关风险控制措施纳入软件计划，并与ISO 14971风险管理体系对接。软件安全分类（SA/SB/SC）直接影响开发过程要求深度。\n\n**证据要求**：\n- 风险管理文档明确软件危险源识别与控制措施\n- 软件安全分类决策记录及依据\n- 危险情况与软件需求的追溯矩阵\n\n**常见失败模式**：\n- 软件风险分析脱离产品整体风险管理文档\n- 安全分类无充分依据或分类决策无记录\n\n---\n\n## 二、软件生命周期策划（对应 ISO 13485 Cl.5.4 / IEC 62304 Cl.4.1-4.2）\n\n### 检查项 3：软件开发计划与质量计划的对应\n\n**理由**：软件开发计划（SDP）是IEC 62304核心交付物，需与ISO 13485质量计划形成映射，确保资源、责任、里程碑一致。\n\n**证据要求**：\n- SDP涵盖范围、角色职责、阶段入口/出口准则、交付物清单\n- SDP与项目总体质量计划引用关系明确\n- 计划变更记录与审批记录完整\n\n**常见失败模式**：\n- SDP与质量计划各自独立，缺乏交叉引用\n- 里程碑与设计历史文件（DHF）节点不对应\n\n---\n\n### 检查项 4：软件相关供应商/分包商控制\n\n**理由**：若软件组件由第三方开发（含开源组件、OEM模块），ISO 13485要求对供方进行控制，IEC 62304要求在开发计划中明确委托开发范围。\n\n**证据要求**：\n- 供应商评估记录（含软件开发能力、质量体系符合性）\n- 委托开发协议明确需求、验收准则、交付物\n- 来料/接收检验记录或等效确认记录\n\n**常见失败模式**：\n- 采购订单未明确软件验收标准\n- 使用开源组件但无许可证合规性评估\n- 第三方代码无配置管理纳入记录\n\n---\n\n## 三、软件需求管理（对应 ISO 13485 Cl.7.2 / IEC 62304 Cl.4.3）\n\n### 检查项 5：软件需求的可追溯性\n\n**理由**：IEC 62304强制要求软件需求与上层系统/用户需求、后续设计、测试用例形成双向追溯链，ISO 13485的CAPA与设计变更同样依赖追溯性。\n\n**证据要求**：\n- 软件需求规格（SRS）包含唯一标识\n- 追溯矩阵覆盖：用户需求→软件需求→软件架构→详细设计→单元测试→集成测试\n- 需求变更影响分析记录\n\n**常见失败模式**：\n- 追溯矩阵缺失或仅单向追溯\n- 需求变更未触发影响分析\n- 追溯链断裂（设计/测试无法回溯至原始需求）\n\n---\n\n### 检查项 6：软件需求变更控制\n\n**理由**：软件需求变更若无受控流程，将导致设计漂移、验证不充分，与ISO 13485设计控制变更要求和CAPA机制直接关联。\n\n**证据要求**：\n- 需求变更申请（CR）记录及审批记录\n- 变更影响评估文档\n- 变更实施后的验证/确认记录\n\n**常见失败模式**：\n- 变更未走正式审批流程（口头变更或邮件替代文件）\n- 变更实施后未重新执行相关测试\n- 变更记录与实际代码版本不对应\n\n---\n\n## 四、软件设计与开发（对应 ISO 13485 Cl.7.3 / IEC 62304 Cl.4.4-4.5）\n\n### 检查项 7：软件架构设计文档完整性\n\n**理由**：软件架构是IEC 62304对B/C级软件的强制要求，也是评估软件可维护性、可验证性的基础。\n\n**证据要求**：\n- 软件架构规格文档（含模块划分、接口定义、数据流）\n- 软件安全架构设计（若适用）\n- 架构设计与需求的一致性确认记录\n\n**常见失败模式**：\n- 架构文档缺失或过于简略（仅框图无说明）\n- 接口定义不清晰导致集成阶段问题\n- 未体现容错/冗余等安全机制\n\n---\n\n### 检查项 8：软件详细设计与代码规范执行\n\n**理由**：IEC 62304要求C级软件必须有详细设计，代码应符合编码规范；ISO 13485要求生产与服务控制覆盖软件交付。\n\n**证据要求**：\n- 详细设计规格文档（DDSD）或等效记录\n- 代码规范/编程规则文档\n- 代码评审记录（含静态分析结果）\n- 编译器/工具链版本记录\n\n**常见失败模式**：\n- 详细设计与代码实现不一致\n- 代码评审流于形式（无实质问题记录）\n- 使用未经确认的工具版本\n\n---\n\n### 检查项 9：SOUP组件管理（IEC 62304专有要求）\n\n**理由**：使用现成软件（SOUP）时需证明其适用于预期用途，SOUP管理是IEC 62304对软件安全性评估的关键环节。\n\n**证据要求**：\n- SOUP清单（含名称、版本、供应商、用途）\n- SOUP适用性分析记录\n- SOUP已知问题/漏洞清单及风险评估\n- SOUP更新验证记录\n\n**常见失败模式**：\n- SOUP未纳入配置管理\n- 适用性分析缺失或照抄厂商声明\n- SOUP版本变更未重新评估影响\n\n---\n\n## 五、软件验证与确认（对应 ISO 13485 Cl.7.3.4 / IEC 62304 Cl.4.6-4.7）\n\n### 检查项 10：单元测试与集成测试的充分性\n\n**理由**：IEC 62304根据安全分类规定测试覆盖率要求（B/C级需结构覆盖率分析），测试记录是验证软件满足需求的核心证据。\n\n**证据要求**：\n- 测试计划/用例规格文档\n- 测试执行记录（通过/失败记录）\n- 结构覆盖率分析报告（C/B级）\n- 缺陷管理与回归测试记录\n\n**常见失败模式**：\n- 测试用例与软件需求无追溯关系\n- 结构覆盖率不满足A级要求（B/C级）\n- 失败的测试用例未完成根本原因分析即关闭\n\n---\n\n### 检查项 11：软件确认（用户现场测试/临床测试）\n\n**理由**：软件确认需证明产品在真实使用环境下满足用户需求，与临床评价、可用性工程紧密关联。\n\n**证据要求**：\n- 确认计划与用例\n- 模拟使用环境测试记录\n- 用户代表参与确认的签到/反馈记录\n- 确认报告与需求符合性声明\n\n**常见失败模式**：\n- 确认环境未真实模拟临床使用场景\n- 确认样本量不足以支持临床评价结论\n- 确认发现的问题未纳入CAPA\n\n---\n\n## 六、软件维护与变更（对应 ISO 13485 Cl.8.5 / IEC 62304 Cl.4.8-4.9）\n\n### 检查项 12：软件变更控制流程\n\n**理由**：软件维护阶段变更若无受控流程，可能引入新风险；ISO 13485的变更控制与CAPA机制需覆盖软件变更。\n\n**证据要求**：\n- 变更请求记录与影响评估\n- 变更实施记录（含代码、文档更新）\n- 变更后验证/回归测试记录\n- 变更版本发布记录\n\n**常见失败模式**：\n- 紧急修补未走变更流程即发布\n- 变更记录与实际版本不匹配\n- 变更未重新执行完整测试\n\n---\n\n### 检查项 13：软件问题报告与纠正措施\n\n**理由**：运行阶段软件问题需通过CAPA系统处理，与ISO 13485不合格品控制、客户抱怨管理对接。\n\n**证据要求**：\n- 软件问题/缺陷追踪记录\n- 问题根本原因分析（适宜时采用FMEA/FTA）\n- CAPA记录与有效性验证\n- 问题关闭审批记录\n\n**常见失败模式**：\n- 问题追踪系统未与QMS CAPA系统对接\n- 根本原因分析流于表面（仅描述现象未查根因）\n- CAPA有效性验证缺失或敷衍\n\n---\n\n## 七、配置管理与交付（对应 ISO 13485 Cl.7.5 / IEC 62304 Cl.4.10）\n\n### 检查项 14：软件配置管理系统有效性\n\n**理由**：配置管理是IEC 62304强制要求，需唯一标识软件版本、保持可追溯性，防止未授权变更。\n\n**证据要求**：\n- 配置管理计划（含配置项定义、变更控制流程）\n- 软件版本记录表（BOM清单）\n- 基线建立与变更审计记录\n- 配置状态报告\n\n**常见失败模式**：\n- 配置管理工具与开发环境未集成\n- 多版本并存无版本隔离控制\n- 基线变更无正式审批记录\n\n---\n\n### 检查项 15：软件交付与安装确认\n\n**理由**：软件交付物需受控，确保临床环境安装版本与注册确认版本一致。\n\n**证据要求**：\n- 交付物清单与签收记录\n- 安装验证/确认记录\n- 客户环境兼容性声明\n- 交付后支持与维护协议\n\n**常见失败模式**：\n- 交付版本与注册版本不一致\n- 客户现场安装无记录\n- 交付物清单与实际提供内容不符\n\n---\n\n## 八、文档与记录（对应 ISO 13485 Cl.4.2 / IEC 62304 Cl.9）\n\n### 检查项 16：软件文档完整性核查\n\n**理由**：IEC 62304规定软件生命周期各阶段的文档输出要求，监管审核时需完整提供；文档缺失是常见审核开项。\n\n**证据要求**：\n- DHF（设计历史文档）清单完整性\n- 各阶段技术文档与 IEC 62304 Table 3-9 对照检查记录\n- 文档审阅与批准记录\n\n**常见失败模式**：\n- 文档版本与软件版本不对应\n- 阶段交付物缺失（如无架构设计文档）\n- 文档签署不完整（缺审核/批准）\n\n---\n\n### 检查项 17：设计转移与制造确认\n\n**理由**：软件从开发向生产的转移需受控，确保批量生产软件与确认软件一致。\n\n**证据要求**：\n- 设计转移检查清单\n- 生产和检验设备确认记录\n- 首批/首批次生产记录\n- 软件版本放行记录\n\n**常见失败模式**：\n- 生产版本未经验证即放行\n- 放行记录无责任人签署\n- 生产环境与开发环境差异未评估\n\n---\n\n## 九、总结建议\n\n以上 17 条检查项覆盖 IEC 62304 与 ISO 13485 交叉合规的核心高风险点。建议贵司在正式审核前按以下优先级开展自查：\n\n| 优先级 | 领域 | 关键风险 |\n|--------|------|----------|\n| P1 | 需求追溯与变更控制 | 设计漂移、验证不充分 |\n| P1 | 文档完整性 | 审核开项重灾区 |\n| P2 | SOUP管理 | 安全分类与风险控制 |\n| P2 | 确认与交付 | 临床使用合规 |\n| P3 | 供应商控制 | 供应链合规漏洞 |\n\n\u003e **提示**：以上内容基于 IEC 62304:2006/AMD1:2015 与 ISO 13485:2016 通用理解，具体项目应以注册申报受理意见及官方检测报告为准。如需针对贵司产品（device_type 未明确）细化检查项，我再进一步补充。"}
|
||
|
||
event: done
|
||
data: {"id":"evt_1789663589203505600_8","type":"done","timestamp":"2026-09-17T16:46:29.20350667Z","done":{"session_id":"wave0-sse-1789663519","duration_ms":70164,"total_events":7,"user_message_id":3627,"message_id":3628,"status":"completed","content_revision":1,"content_sha256":"0abbdab3223ec9aa0c2b42b73384c88d45f58fe5e562fb82fbe00b5f5dcf4661","export_capability":{"policy":"full","formats":["rich_clipboard","markdown","docx","pdf","private_document"],"body_selector":"content_only","content_revision":1,"content_sha256":"0abbdab3223ec9aa0c2b42b73384c88d45f58fe5e562fb82fbe00b5f5dcf4661"}}}
|
||
|