Menu
医疗合规管理技能，覆盖NMPA医疗器械软件变更类型判定、注册准备文件清单、DICOM一致性声明维护等内容。适用于PACS/RIS产品经理在医疗信息化项目中的合规管理工作，确保产品符合NMPA法规要求和DICOM标准规范。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
季度竞品分析技能。每季度系统化收集市场竞品情报、构建竞争全景图、深度画像竞品、分析市场格局演变、提炼战略洞察，输出完整季度竞品分析报告。适用于产品战略规划、年度路线图制定、投融资汇报、高管决策支持等场景。当用户需要每季度深入了解竞争格局、识别战略机会、形成完整竞品分析报告时使用此 skill。
Git 标准操作流程 SOP，包含 init、add、commit、push、status、log、pull 等常用操作及自动检查验证。使用场景：用户要求执行 git 操作时。
API design specifications. 当用户需要设计 API、讨论 RESTful 规范、设计 GraphQL schema 或制定 API 规范时使用此skill。
Architecture quality assessment. 当用户需要评估架构质量、检查系统性能、分析安全风险或评估可扩展性时使用此skill。
System architecture design. 当用户需要设计系统架构、画架构图、讨论微服务拆分、CQRS、事件驱动、DDD等架构模式时使用此skill。
Code architecture review. 当用户需要评审代码架构、讨论设计模式、检查代码质量或进行代码评审时使用此skill。
| name | pm-gamma-medical-compliance |
| description | 医疗合规管理技能，覆盖NMPA医疗器械软件变更类型判定、注册准备文件清单、DICOM一致性声明维护等内容。适用于PACS/RIS产品经理在医疗信息化项目中的合规管理工作，确保产品符合NMPA法规要求和DICOM标准规范。 |
医疗信息化产品处于严格监管环境下，PACS/RIS产品经理必须掌握NMPA医疗器械软件注册相关合规要求，确保产品变更合规、注册文档完备、DICOM标准持续符合。
根据 YY/T 0664 标准，软件变更分为三个级别：
| 变更类型 | 判定标准 | 处置方式 |
|---|---|---|
| 重大软件版本 | 新增临床功能、修改核心算法、扩展预期用途 | 变更注册申请 |
| 次要软件版本 | 性能优化、非核心模块改动、UI 优化 | 技术文件更新存档 |
| 维护版本 | 缺陷修复、安全补丁 | 变更控制程序记录 |
├── 新增 AI 辅助诊断功能 → 可能触发三类器械重新注册
├── 修改图像重建/后处理核心算法 → 变更注册 + 性能测试报告
├── 新增患者数据传输接口 → 网络安全文档更新
├── 扩展至新影像模态（如核医学） → 预期用途变更
└── 与第三方 AI 平台深度集成 → 独立软件组件评估
Step 1 — 功能变更梳理
Step 2 — 法规条款对标
Step 3 — 检测要求确认
Step 4 — 文档更新清单
□ 功能变更是否影响临床诊断结果？
□ 是否新增或修改了图像处理算法？
□ 是否扩展了支持的影像模态类型？
□ 是否改变了产品预期用途描述？
□ 是否涉及患者数据导出或传输功能？
□ 是否对接了未经注册的第三方组件？
□ 是否修改了与硬件设备的通信协议？
□ 产品说明书是否需要同步更新？
基础注册文件（常备更新）
├── 软件描述文档（SDD）
│ ├── 软件架构描述
│ ├── 核心功能模块说明
│ ├── 数据流图
│ └── 第三方组件清单（含版本号和开源协议）
├── 网络安全描述文档
│ ├── 资产清单与威胁分析
│ ├── 安全控制措施
│ └── 漏洞管理程序
├── 软件版本控制文档
│ ├── 版本命名规则
│ ├── 变更历史记录
│ └── 配置管理说明
└── 剩余风险评估报告（ISO 14971）
三类器械附加文件
├── 临床评价报告
├── 算法验证报告（含测试数据集说明）
└── 上市后监督计划
文件版本控制要求
├── 所有注册文件采用版本号管理（主版本.次版本.修订号）
├── 每次变更需更新文件版本号并记录变更说明
├── 历史版本文件需归档保存
├── 文件审批流程：起草 → 技术审核 → 法规审核 → 批准发布
└── 关键文件（SDD、网络安全文档）需专人管理
申报常见问题预防
├── 确保软件版本号在技术文件中一致
├── 第三方组件需提供购买/使用证明
├── 开源组件需提供License兼容性分析
├── 检测报告与注册申报资料版本一致
└── 临床评价报告需覆盖全部适应症
DICOM一致性声明更新触发条件
├── 新增支持的 SOP Class（如 SR/KOS/GSPS）
├── 修改现有 SOP Class 的必选 Tag 处理逻辑
├── 新增支持的影像设备品牌/型号
└── 修改传输语法（Transfer Syntax）支持列表
| 风险等级 | SOP Class | 测试要求 |
|---|---|---|
| 高风险 | RT 系列（RT Plan/RT Image/RT Dose） | 必须全覆盖测试 |
| 高风险 | SR（Structured Report） | 结构化报告内容验证 |
| 中风险 | MWL（Modality Worklist） | HIS/RIS对接测试 |
| 中风险 | GSPS（Grayscale Softcopy PS） | 显示一致性测试 |
| 低风险 | Storage Commitment | 存储确认机制测试 |
更新流程
1. 研发列出变更的 DICOM 功能清单
2. PD 确认对应 Conformance Statement 章节
3. 专业 DICOM 工程师完成文档修订
4. DICOM 验证工具（DCM4CHE/OsiriX）回归测试
5. 文档版本同步至官网和注册文件
影像模态兼容性测试要求（必须覆盖）
├── CT（螺旋/平扫/增强）
├── MR（多序列：T1/T2/DWI/MRCP）
├── DR/CR（数字放射摄影）
├── DSA（数字减影血管造影）
├── 超声（二维/彩超/三维）
└── PET/CT、核医学（SPECT）
Tag处理规则
├── 必选（Mandatory）Tag：必须支持且正确解析
├── 可选（Optional）Tag：按声明处理，不支持则忽略
├── 私有（Private）Tag：需与厂商协商确认含义
└── 关键Tag示例：
├── 患者信息：(0010,0010) Patient Name
├── 检查信息：(0008,0020) Study Date
├── 影像数据：(7FE0,0010) Pixel Data
└── 设备信息：(0008,0070) Manufacturer
安全要求清单
├── 身份认证：双因素认证/CA 证书
├── 访问控制：基于角色的权限模型（RBAC）
├── 安全审计：操作日志留存 ≥ 6 个月
├── 数据加密：传输层 TLS 1.2+，存储加密（含磁盘级）
└── 入侵防范：异常访问检测与告警
患者隐私保护（PHI 处理规范）
├── 影像数据不得离开院区（私有化部署原则）
├── 科研数据导出须经患者信息脱敏（DICOM Tag 清洗）
├── 系统日志不得记录完整患者 ID
└── API 接口调用须实施身份验证与权限校验
| 工具 | 用途 |
|---|---|
| DCM4CHE tools / DCMTK | DICOM 服务测试 |
| Horos / OsiriX / MicroDicom | DICOM 文件查看/调试 |
| HAPI FHIR TestPanel | HL7 消息解析与发送测试 |
| Wireshark | DICOM/HL7 协议层排查 |
| 资源 | 说明 |
|---|---|
| DICOM 官方标准 | dicom.nema.org — 最新 PS 3.x 规范 |
| NMPA 医疗器械 | nmpa.gov.cn — 注册指导原则/公告 |
| IHE 技术框架 | ihe.net — 放射科 RAD 集成规范 |
| YY/T 0664 标准 | 医疗器械软件 软件生存周期过程 |