MDR 2017/745 概述¶
学习目标¶
完成本模块后，你将能够： - 理解MDR法规的背景和主要变化 - 掌握医疗器械分类规则 - 了解基本安全和性能要求（GSPR） - 理解合格评定程序 - 掌握经济运营商的责任 - 应用MDR要求到产品开发
前置知识¶
- 医疗器械基础概念
- 质量管理体系基础
- 风险管理基础
内容¶
MDR法规背景¶
MDR (Medical Device Regulation) 2017/745 于2017年5月发布，2021年5月26日全面实施。
为什么需要MDR？
旧的MDD指令存在的问题： - 监管不够严格 - 临床证据要求不足 - 上市后监督薄弱 - 公告机构监管不统一 - 透明度不够
MDR的主要变化：
MDD (旧指令) → MDR (新法规)
├── 更严格的临床评价要求
├── 加强的上市后监督
├── 新的医疗器械分类规则
├── 更严格的公告机构要求
├── 欧盟数据库(EUDAMED)强制使用
├── 唯一器械标识(UDI)系统
└── 更高的透明度要求
医疗器械定义¶
MDR第2条定义：
医疗器械是指制造商预期用于人类的任何仪器、装置、器具、软件、植入物、试剂、材料或其他物品，单独或组合使用，其主要预期作用不是通过药理学、免疫学或代谢手段实现，但可能通过这些手段辅助实现其功能。
预期用途包括： - 疾病的诊断、预防、监测、预测、预后、治疗或缓解 - 损伤或残疾的诊断、监测、治疗、缓解或补偿 - 解剖或生理过程的研究、替代或修改 - 通过体外检查人体样本提供信息
软件作为医疗器械：
MDR明确规定，具有医疗预期用途的软件本身就是医疗器械，即使它不驱动或影响硬件设备。
// 示例：医疗器械软件
// 1. 独立软件（SaMD）
// - 医学影像分析软件
// - 疾病风险评估软件
// - 治疗决策支持软件
// 2. 嵌入式软件
// - 血糖仪中的算法
// - 心电监护仪的信号处理
// - 输液泵的控制软件
医疗器械分类¶
MDR将医疗器械分为四类：I类、IIa类、IIb类、III类，风险从低到高。
分类规则¶
MDR附录VIII包含22条分类规则：
规则1-4：非侵入性器械 - 规则1：暂时使用的非侵入性器械 → I类 - 规则2：引导或储存体液的器械 → IIa类 - 规则3：改变体液生物或化学成分的器械 → IIb类 - 规则4：接触受损皮肤的器械 → I类或IIa类
规则5-8：侵入性器械 - 规则5：体腔侵入性器械 - 短期使用 → I类或IIa类 - 长期使用 → IIa类或IIb类 - 规则6：手术侵入性器械 - 短期使用 → IIa类 - 长期使用 → IIb类或III类 - 规则7：手术侵入性器械（特殊部位） - 中枢循环系统、中枢神经系统 → III类 - 规则8：植入性器械 - 一般 → IIb类或III类 - 特殊部位 → III类
规则9-13：有源器械 - 规则9：治疗性有源器械 → IIa类 - 规则10：诊断性有源器械 → IIa类 - 规则11：给药或移除体液的有源器械 → IIb类 - 规则12：监测生命参数的有源器械 - 一般 → IIa类 - 关键参数 → IIb类 - 规则13：诊断或治疗电离辐射的器械 → IIb类
规则14-22：特殊规则 - 规则14：含有药物的器械 → III类 - 规则15：含有生物材料的器械 → III类 - 规则16：改变体内生物或化学成分的器械 → IIb类或III类 - 规则17：避孕或预防性传播疾病的器械 → IIb类或III类 - 规则18：消毒或灭菌的器械 → IIa类、IIb类或III类 - 规则19：记录X射线影像的器械 → IIa类 - 规则20：含有纳米材料的器械 → 提升一级 - 规则21：侵入体腔和体孔的器械 → 提升一级 - 规则22：软件 → 根据预期用途分类
软件分类详解¶
规则11（软件驱动器械）： - 软件驱动或影响医疗器械的使用 → 与该器械相同分类
规则22（独立软件）：
软件预期用途 分类
├── 提供信息支持诊断/治疗决策
│ ├── 严重疾病或状况 → IIb类或III类
│ ├── 中等严重疾病 → IIa类
│ └── 轻微疾病 → I类
├── 监测生理过程
│ ├── 关键生命参数 → IIb类
│ └── 一般参数 → IIa类
└── 其他医疗用途 → 根据风险评估
示例：
// Class I 软件示例
// - 健康信息记录软件（无诊断功能）
// - 医院管理系统
// - 预约挂号系统
// Class IIa 软件示例
// - 糖尿病管理软件（监测血糖）
// - 运动康复指导软件
// - 轻度抑郁症筛查软件
// Class IIb 软件示例
// - 心电图分析软件（检测心律失常）
// - 糖尿病视网膜病变筛查软件
// - 睡眠呼吸暂停诊断软件
// Class III 软件示例
// - 放射治疗计划软件
// - 心脏手术导航软件
// - 重症监护决策支持软件
基本安全和性能要求（GSPR）¶
MDR附录I规定了通用安全和性能要求（General Safety and Performance Requirements）。
第I章：一般要求¶
1. 器械应达到预期性能 - 符合制造商声明的预期用途 - 在正常使用条件下安全有效
2. 风险管理 - 建立、实施和维护风险管理系统 - 符合ISO 14971标准 - 残余风险必须可接受
3. 设计和制造 - 消除或降低风险 - 采取适当的保护措施 - 告知用户残余风险
第II章：设计和制造要求¶
4. 化学、物理和生物特性 - 材料选择和兼容性 - 生物相容性（ISO 10993） - 感染和微生物污染
5. 感染和微生物污染 - 微生物污染风险最小化 - 灭菌器械的要求 - 无菌包装
6. 环境和使用条件 - 运输和储存条件 - 环境条件（温度、湿度、压力） - 电磁兼容性（EMC）
7. 含有测量功能的器械 - 测量准确性和精度 - 测量单位符合国际标准 - 测量不确定度
8. 辐射防护 - 电离辐射最小化 - 非电离辐射（激光、超声）安全
9. 电气、机械和热风险防护 - 电气安全（IEC 60601-1） - 机械风险防护 - 热风险防护
10. 软件相关要求 - 软件开发生命周期（IEC 62304） - 软件验证和确认 - IT安全（网络安全）
11. 有源器械和连接器械 - 电源故障保护 - 报警系统 - 用户界面和显示
12. 机械和热风险防护 - 运动部件防护 - 压力容器安全 - 热表面防护
13. 给药器械 - 剂量准确性 - 给药速率控制 - 防止误用
14. 患者和用户信息 - 使用说明书 - 标签和符号 - 培训要求
软件特定要求（附录I，第17章）¶
17.1 软件开发生命周期
器械中包含的软件或本身为软件的器械应根据最新技术水平进行开发和制造，考虑到： - 开发生命周期 - 风险管理 - 验证和确认 - 配置管理
17.2 软件验证和确认
// 软件验证和确认流程
typedef struct {
// 验证（Verification）：我们是否正确地构建了产品？
bool unit_tests_passed; // 单元测试通过
bool integration_tests_passed; // 集成测试通过
bool code_review_completed; // 代码审查完成
bool static_analysis_passed; // 静态分析通过
// 确认（Validation）：我们是否构建了正确的产品？
bool requirements_traced; // 需求可追溯
bool user_needs_met; // 满足用户需求
bool clinical_validation_done; // 临床确认完成
bool usability_validated; // 可用性确认
} Software_VV_Status_t;
17.3 IT安全（网络安全）
软件应： - 防止未授权访问 - 保护数据完整性和机密性 - 检测和响应安全事件 - 定期更新安全补丁
17.4 软件更新
制造商应： - 定义软件更新策略 - 验证更新不会引入新风险 - 通知用户重要更新 - 保持更新历史记录
合格评定程序¶
根据器械分类，选择相应的合格评定程序：
I类器械（不含测量功能和无菌）¶
程序：自我声明 - 制造商自行评估符合性 - 编制技术文档 - 签署EU符合性声明 - 加贴CE标志 - 无需公告机构参与
I类器械（含测量功能或无菌）¶
程序：部分公告机构参与 - 测量功能：附录IX第2部分 - 无菌：附录IX第3部分 - 公告机构审核相关方面 - 其他方面自我声明
IIa类器械¶
程序选择：
选项1：附录IX（完整质量保证）+ 附录II第2部分 - 公告机构审核质量管理体系 - 公告机构审核技术文档（抽样）
选项2：附录IX第4部分（产品质量保证） - 公告机构审核产品质量保证 - 公告机构审核技术文档（抽样）
选项3：附录X（型式检验）+ 附录IX第6部分 - 公告机构进行型式检验 - 公告机构审核产品符合性
IIb类和III类器械¶
程序：附录IX（完整质量保证）+ 附录II - 公告机构审核质量管理体系 - 公告机构审核技术文档（全部） - III类器械：临床评价咨询专家组
定制器械： - 附录XIII - 简化程序 - 无需公告机构
经济运营商责任¶
制造商（Manufacturer）¶
主要责任： - 设计和制造符合MDR的器械 - 建立质量管理体系 - 编制技术文档 - 进行临床评价 - 实施上市后监督 - 报告严重事件 - 注册EUDAMED
软件制造商特殊责任：
// 制造商责任清单
typedef struct {
// 设计和开发
bool software_development_plan; // 软件开发计划
bool risk_management_file; // 风险管理文件
bool software_requirements_spec; // 软件需求规格
bool software_architecture_design; // 软件架构设计
// 验证和确认
bool verification_report; // 验证报告
bool validation_report; // 确认报告
bool clinical_evaluation_report; // 临床评价报告
// 文档
bool technical_documentation; // 技术文档
bool instructions_for_use; // 使用说明书
bool declaration_of_conformity; // 符合性声明
// 上市后
bool post_market_surveillance_plan; // 上市后监督计划
bool vigilance_system; // 警戒系统
bool periodic_safety_update_report; // 定期安全更新报告
} Manufacturer_Obligations_t;
授权代表（Authorized Representative）¶
- 代表非欧盟制造商
- 与主管当局联络
- 协助制造商履行义务
- 保存技术文档副本
进口商（Importer）¶
- 确保制造商符合MDR
- 验证器械有CE标志
- 保存符合性声明副本
- 报告不符合情况
经销商（Distributor）¶
- 确保器械有CE标志
- 验证使用说明书
- 适当储存和运输
- 报告不符合情况
唯一器械标识（UDI）¶
UDI系统组成：
UDI = UDI-DI + UDI-PI
UDI-DI (Device Identifier)：器械标识
- 识别制造商和器械型号
- 固定不变（除非设计变更）
UDI-PI (Production Identifier)：生产标识
- 批号、序列号、生产日期、失效日期
- 每批/每个器械不同
UDI载体： - 条形码（1D或2D） - RFID - 人类可读格式
UDI要求时间表：
| 器械类别 | UDI-DI | UDI-PI |
|---|---|---|
| III类和植入式 | 2021年5月 | 2021年5月 |
| IIa类和IIb类 | 2023年5月 | 2023年5月 |
| I类 | 2025年5月 | 2027年5月 |
软件UDI： - 软件作为医疗器械需要UDI - 软件版本变更需要新的UDI-DI - 软件补丁可能不需要新UDI
// UDI示例
// UDI-DI: (01)04012345678901 // GTIN
// UDI-PI: (17)250531(10)ABC123 // 失效日期 + 批号
// 完整UDI: (01)04012345678901(17)250531(10)ABC123
typedef struct {
char udi_di[50]; // 器械标识
char udi_pi[50]; // 生产标识
char lot_number[20]; // 批号
char serial_number[20]; // 序列号
char expiry_date[10]; // 失效日期 YYMMDD
char manufacture_date[10]; // 生产日期
} UDI_Data_t;
EUDAMED数据库¶
欧盟医疗器械数据库（European Database on Medical Devices）
功能模块： 1. 演员注册：制造商、授权代表、进口商 2. UDI和器械注册：所有器械信息 3. 公告机构和证书：公告机构信息和证书 4. 临床研究：临床试验信息 5. 警戒和上市后监督：不良事件报告 6. 市场监督：主管当局活动
制造商义务： - 注册公司信息 - 注册器械信息 - 上传技术文档摘要 - 更新器械状态 - 报告严重事件
公开信息： - 器械基本信息 - UDI数据 - 证书信息 - 临床研究摘要 - 安全通知
最佳实践¶
MDR合规建议
- 早期规划：在产品设计阶段就考虑MDR要求
- 质量体系：建立符合ISO 13485的质量管理体系
- 风险管理：严格执行ISO 14971风险管理流程
- 软件开发：遵循IEC 62304软件生命周期标准
- 临床证据：收集充分的临床数据和文献
- 技术文档：保持技术文档完整和最新
- 公告机构：尽早联系公告机构，了解具体要求
- 持续监控：建立有效的上市后监督系统
常见陷阱¶
注意事项
- 低估时间：MDR认证通常需要12-24个月
- 临床证据不足：临床评价要求比MDD严格得多
- 软件文档不完整：软件开发文档必须完整可追溯
- 忽视网络安全：IT安全是强制要求
- UDI准备不足：UDI系统实施需要时间
- 上市后监督薄弱：PMS是持续义务，不是一次性活动
- 变更管理不当：任何变更都需要评估是否影响符合性
- 公告机构选择不当：选择有经验的公告机构很重要
实践练习¶
- 器械分类练习：
- 分析一个血糖监测系统（包括硬件和移动应用）
- 确定每个组件的分类
-
说明分类依据
-
GSPR映射：
- 选择一个医疗器械软件
- 列出适用的GSPR条款
-
说明如何满足每个要求
-
合格评定程序选择：
- 根据器械分类
- 选择合适的合格评定程序
-
列出所需文档和步骤
-
UDI实施：
- 设计UDI标签
- 确定UDI载体
- 规划EUDAMED注册
自测问题¶
问题1：MDR与MDD的主要区别是什么？为什么需要MDR？
答案
MDR与MDD的主要区别：
| 方面 | MDD (旧指令) | MDR (新法规) |
|---|---|---|
| 法律性质 | 指令（需成员国转化） | 法规（直接适用） |
| 临床评价 | 要求较宽松 | 要求严格，需持续更新 |
| 上市后监督 | 要求较弱 | 强制性PMS和PSUR |
| 公告机构 | 监管不统一 | 更严格的指定和监督 |
| 透明度 | 有限 | EUDAMED公开信息 |
| UDI | 无要求 | 强制要求 |
| 软件 | 规定不明确 | 明确规定和要求 |
| 网络安全 | 无明确要求 | 强制要求 |
为什么需要MDR： 1. 安全事件：PIP乳房植入物丑闻等事件暴露了MDD的不足 2. 技术进步：软件、AI等新技术需要新的监管框架 3. 患者安全：需要更严格的监管保护患者 4. 市场统一：法规直接适用，避免成员国差异 5. 国际协调：与FDA等其他监管机构协调
知识点回顾：MDR是对MDD的全面升级，显著提高了医疗器械监管的严格程度。
问题2：如何确定医疗器械软件的分类？请举例说明。
答案
软件分类方法：
根据MDR附录VIII规则11和规则22：
步骤1：确定软件类型 - 驱动或影响硬件器械 → 规则11 - 独立软件（SaMD） → 规则22
步骤2：评估预期用途和风险 - 疾病严重程度 - 决策影响程度 - 监测参数重要性
分类示例：
Class I（低风险）：
Class IIa（中低风险）：
Class IIb（中高风险）：
Class III（高风险）：
决策树：
软件预期用途
├── 提供信息支持诊断/治疗
│ ├── 严重/危及生命 → IIb或III
│ ├── 中等严重 → IIa
│ └── 轻微 → I
├── 监测生理参数
│ ├── 关键生命参数 → IIb
│ └── 一般参数 → IIa
└── 驱动/影响器械
└── 与该器械相同分类
知识点回顾：软件分类主要基于预期用途和风险，疾病严重程度和决策影响是关键因素。
问题3：MDR对软件开发有哪些特定要求？如何满足这些要求？
答案
MDR软件特定要求（附录I第17章）：
1. 软件开发生命周期
要求： - 根据最新技术水平开发 - 考虑开发生命周期 - 实施风险管理 - 进行验证和确认
满足方法：
遵循IEC 62304标准：
├── 软件开发计划
├── 软件需求分析
├── 软件架构设计
├── 软件详细设计
├── 软件单元实现和验证
├── 软件集成和集成测试
├── 软件系统测试
└── 软件发布
2. 风险管理
要求： - 识别软件相关风险 - 评估和控制风险 - 验证风险控制措施
满足方法：
// 软件风险管理示例
typedef struct {
char hazard[100]; // 危害
char cause[100]; // 原因
char consequence[100]; // 后果
int severity; // 严重度 (1-5)
int probability; // 概率 (1-5)
int risk_level; // 风险等级
char control_measure[200]; // 控制措施
int residual_risk; // 残余风险
} Software_Risk_t;
// 示例风险
Software_Risk_t risk1 = {
.hazard = "算法错误",
.cause = "软件缺陷",
.consequence = "错误诊断",
.severity = 5,
.probability = 3,
.risk_level = 15,
.control_measure = "代码审查、单元测试、集成测试、临床验证",
.residual_risk = 5
};
3. 验证和确认
要求： - 验证：确认软件正确实现 - 确认：确认软件满足用户需求
满足方法：
4. IT安全（网络安全）
要求： - 防止未授权访问 - 保护数据完整性和机密性 - 检测和响应安全事件
满足方法：
// 网络安全措施示例
typedef struct {
// 访问控制
bool user_authentication; // 用户认证
bool role_based_access; // 基于角色的访问控制
bool session_management; // 会话管理
// 数据保护
bool data_encryption; // 数据加密
bool secure_communication; // 安全通信（TLS）
bool data_integrity_check; // 数据完整性检查
// 安全监控
bool audit_logging; // 审计日志
bool intrusion_detection; // 入侵检测
bool security_updates; // 安全更新机制
} Cybersecurity_Measures_t;
参考标准： - IEC 81001-5-1（网络安全） - IEC 62443（工业网络安全）
5. 软件更新
要求： - 定义更新策略 - 验证更新安全性 - 通知用户
满足方法：
文档要求：
必需文档：
├── 软件开发计划
├── 软件需求规格说明
├── 软件架构设计文档
├── 软件详细设计文档
├── 软件验证报告
├── 软件确认报告
├── 风险管理文件
├── 网络安全文档
└── 软件维护计划
知识点回顾：MDR对软件的要求主要通过IEC 62304和IEC 81001-5-1标准实现，核心是生命周期管理、风险管理和网络安全。
问题4：什么是UDI？如何为医疗器械软件实施UDI？
答案
UDI（Unique Device Identification）唯一器械标识：
定义： UDI是医疗器械的唯一标识符，类似于产品的"身份证"。
UDI组成：
UDI = UDI-DI + UDI-PI
UDI-DI（Device Identifier）：
- 识别制造商和器械型号
- 固定不变（除非设计变更）
- 示例：(01)04012345678901
UDI-PI（Production Identifier）：
- 批号、序列号、生产日期、失效日期
- 每批/每个器械不同
- 示例：(17)250531(10)ABC123
软件UDI特殊考虑：
1. 软件版本与UDI-DI
版本变更类型 是否需要新UDI-DI
├── 主版本变更 (1.0→2.0) → 是（功能重大变化）
├── 次版本变更 (1.0→1.1) → 是（新功能或重要修复）
├── 补丁版本 (1.0.0→1.0.1) → 否（小修复）
└── 安全补丁 → 可能需要（取决于影响）
2. 软件UDI实施示例
// 软件UDI数据结构
typedef struct {
char udi_di[50]; // 器械标识
char software_version[20]; // 软件版本
char release_date[10]; // 发布日期
char manufacturer[100]; // 制造商
char product_name[100]; // 产品名称
} Software_UDI_t;
// 示例
Software_UDI_t ecg_software_udi = {
.udi_di = "(01)04012345678901",
.software_version = "2.1.0",
.release_date = "2024-03-15",
.manufacturer = "ABC Medical Devices",
.product_name = "ECG Analysis Software"
};
// 在软件中显示UDI
void display_udi_info(void) {
printf("UDI-DI: %s\n", ecg_software_udi.udi_di);
printf("Version: %s\n", ecg_software_udi.software_version);
printf("Release Date: %s\n", ecg_software_udi.release_date);
}
3. UDI载体选择
对于软件： - 电子显示：在软件界面显示UDI - 文档：在使用说明书中包含UDI - 包装：如果有物理包装，使用条形码
4. EUDAMED注册
5. UDI实施步骤
步骤1：选择发证机构
├── GS1（全球最大）
├── HIBCC
├── ICCBBA
└── IFA
步骤2：申请UDI-DI
├── 注册制造商信息
├── 申请GTIN或其他标识符
└── 获得UDI-DI
步骤3：确定UDI-PI
├── 软件版本号
├── 发布日期
└── 其他生产标识
步骤4：实施UDI
├── 在软件中嵌入UDI
├── 在文档中包含UDI
├── 在包装上标注UDI
步骤5：注册EUDAMED
├── 上传UDI信息
├── 关联技术文档
└── 保持信息更新
6. UDI时间表
器械类别 UDI-DI要求 UDI-PI要求
├── III类/植入式 2021年5月 2021年5月
├── IIa/IIb类 2023年5月 2023年5月
└── I类 2025年5月 2027年5月
7. 软件更新与UDI
// 版本管理示例
typedef struct {
int major; // 主版本
int minor; // 次版本
int patch; // 补丁版本
} Software_Version_t;
// 判断是否需要新UDI-DI
bool requires_new_udi_di(Software_Version_t old_ver,
Software_Version_t new_ver) {
// 主版本或次版本变更需要新UDI-DI
if (new_ver.major != old_ver.major ||
new_ver.minor != old_ver.minor) {
return true;
}
// 补丁版本不需要新UDI-DI
return false;
}
知识点回顾：UDI是医疗器械的唯一标识，软件版本变更可能需要新的UDI-DI，必须在EUDAMED注册。
问题5：MDR与FDA法规有哪些主要区别？
答案
MDR与FDA法规主要区别：
| 方面 | MDR（欧盟） | FDA（美国） |
|---|---|---|
| 法规框架 | MDR 2017/745 | 21 CFR Part 820, 510(k), PMA |
| 分类系统 | I, IIa, IIb, III（4类） | I, II, III（3类） |
| 分类依据 | 22条规则 | 16个医疗专业小组 |
| 审批机构 | 公告机构（Notified Body） | FDA |
| 审批方式 | 第三方认证 | 政府审批 |
| I类器械 | 自我声明 | 510(k)豁免或510(k) |
| II类器械 | 公告机构参与 | 510(k) |
| III类器械 | 公告机构全面审核 | PMA |
| 临床证据 | 临床评价报告（CER） | 临床数据或文献 |
| 质量体系 | ISO 13485 | 21 CFR Part 820 (QSR) |
| 上市后监督 | 强制PMS和PSUR | MDR和PMS |
| UDI系统 | 强制，EUDAMED | 强制，GUDID |
| 软件标准 | IEC 62304 | IEC 62304（推荐） |
| 网络安全 | 强制要求 | 指南推荐 |
| 透明度 | EUDAMED公开 | 部分公开 |
具体差异示例：
1. 分类差异
示例：血糖监测系统
MDR分类：
- 血糖仪：IIb类（规则3：改变体液成分）
- 移动应用：IIa类（规则22：监测生理参数）
FDA分类：
- 血糖仪：II类（510(k)）
- 移动应用：II类（510(k)）或豁免
2. 审批流程差异
3. 临床证据要求
4. 软件特定差异
MDR：
- 明确软件分类规则
- 强制IEC 62304
- 强制网络安全要求
- 软件更新需评估
FDA：
- 软件分类较灵活
- IEC 62304推荐但非强制
- 网络安全指南
- 软件更新可能需要新510(k)
5. 上市后要求
MDR：
- 强制PMS计划
- 定期安全更新报告（PSUR）
- EUDAMED报告
- 严重事件48小时报告
FDA：
- MDR（医疗器械报告）
- 年度报告（某些器械）
- 召回报告
- 严重事件报告
双重认证策略：
同时满足MDR和FDA：
├── 质量体系：ISO 13485 + QSR
├── 软件开发：IEC 62304
├── 风险管理：ISO 14971
├── 可用性：IEC 62366
├── 网络安全：IEC 81001-5-1
├── 电气安全：IEC 60601-1
└── 文档：满足两者要求
知识点回顾：MDR和FDA法规在分类、审批、临床证据等方面有显著差异，但都强调质量、安全和有效性。
相关资源¶
- IVDR概述 - 体外诊断医疗器械法规
- CE认证流程 - CE标志申请流程
- 技术文档要求 - 技术文档编制
- 临床评价 - 临床评价报告
- 上市后监督 - PMS系统
- IEC 62304 - 软件生命周期标准
参考文献¶
- Regulation (EU) 2017/745 - Medical Device Regulation (MDR)
- MDCG 2019-11 - Guidance on Qualification and Classification of Software
- MDCG 2019-16 - Guidance on Cybersecurity for medical devices
- MDCG 2020-1 - Guidance on Clinical Evaluation
- ISO 13485:2016 - Medical devices - Quality management systems
- IEC 62304:2006+AMD1:2015 - Medical device software - Software life cycle processes
- IEC 81001-5-1:2021 - Health software and health IT systems safety - Security
- European Commission MDR Resources - https://ec.europa.eu/health/md_sector/overview_en
💬 讨论区
欢迎在这里分享您的想法、提出问题或参与讨论。需要 GitHub 账号登录。