案例研究：血糖监测系统CE认证¶
案例概述¶
公司背景： - 公司名称：MediTech Solutions GmbH（虚构） - 成立时间：2018年 - 员工规模：50人 - 主营业务：糖尿病管理解决方案
产品信息： - 产品名称：GlucoSmart Pro血糖监测系统 - 组成：血糖仪硬件 + 移动应用 + 云平台 - 预期用途：糖尿病患者的血糖自我监测和管理 - 目标市场：欧盟、美国
项目目标： - 获得CE认证（MDR） - 同时准备FDA 510(k) - 18个月内上市
产品技术规格¶
硬件规格¶
// 血糖仪硬件规格
typedef struct {
// 测量性能
char measurement_method[50]; // "电化学法"
float measuring_range_min; // 20 mg/dL
float measuring_range_max; // 600 mg/dL
float accuracy; // ±15% vs 参考方法
int measurement_time_sec; // 5秒
float sample_volume_ul; // 0.5 µL
// 技术参数
char display[50]; // "2.4英寸彩色LCD"
char connectivity[100]; // "蓝牙5.0, USB-C"
int memory_capacity; // 500次测量
char power_source[50]; // "可充电锂电池"
int battery_life_days; // 30天
// 环境条件
float operating_temp_min; // 10°C
float operating_temp_max; // 40°C
float operating_humidity_min; // 20% RH
float operating_humidity_max; // 80% RH
// 尺寸和重量
float length_mm; // 95mm
float width_mm; // 55mm
float height_mm; // 15mm
float weight_g; // 45g
} GlucoSmart_Hardware_Spec_t;
软件架构¶
GlucoSmart Pro系统架构：
┌─────────────────────────────────────────┐
│ 移动应用（iOS/Android） │
│ ├── 数据显示和可视化 │
│ ├── 趋势分析 │
│ ├── 报警管理 │
│ └── 用户设置 │
└──────────────┬──────────────────────────┘
│ 蓝牙BLE
┌──────────────▼──────────────────────────┐
│ 血糖仪嵌入式软件 │
│ ├── 测量控制 │
│ ├── 数据处理 │
│ ├── 质量控制 │
│ └── 通信协议 │
└──────────────┬──────────────────────────┘
│ HTTPS/TLS
┌──────────────▼──────────────────────────┐
│ 云平台后端 │
│ ├── 数据存储 │
│ ├── 数据分析 │
│ ├── 医生门户 │
│ └── 报告生成 │
└─────────────────────────────────────────┘
分类和合规策略¶
器械分类¶
MDR分类分析：
血糖仪硬件：
├── 规则3：改变体液生物或化学成分的器械
│ └── 血糖测量涉及血液样本分析
├── 分类：IIb类
└── 依据：MDR附录VIII规则3
移动应用：
├── 规则22：软件
│ ├── 提供信息支持诊断/治疗决策
│ ├── 疾病：糖尿病（中等严重）
│ └── 决策影响：中等（监测和管理）
├── 分类：IIa类
└── 依据：MDR附录VIII规则22
系统整体分类：
└── IIb类（取最高分类）
FDA分类（对比）： - 血糖仪：Class II（510(k)） - 移动应用：Class II或豁免
合规策略¶
选择的合格评定程序： - MDR附录IX第2部分（完整QMS）+ 附录II第2部分（技术文档） - 需要公告机构参与
适用标准清单：
// 适用标准
typedef struct {
// 核心标准
char iso_13485[50]; // "ISO 13485:2016"
char iec_62304[50]; // "IEC 62304:2006+AMD1:2015"
char iso_14971[50]; // "ISO 14971:2019"
char iec_62366[50]; // "IEC 62366-1:2015"
char iec_81001_5_1[50]; // "IEC 81001-5-1:2021"
// 电气安全
char iec_60601_1[50]; // "IEC 60601-1:2005+AMD1:2012"
char iec_60601_1_2[50]; // "IEC 60601-1-2:2014"
char iec_60601_1_11[50]; // "IEC 60601-1-11:2015"
// IVD相关
char iso_15197[50]; // "ISO 15197:2013"
// 其他
char iso_15223_1[50]; // "ISO 15223-1:2016"
char iso_10993_1[50]; // "ISO 10993-1:2018"
} Applicable_Standards_t;
项目时间线¶
实际项目时间线（18个月）¶
月份 0-3：准备阶段
├── 月份0：项目启动
│ ├── 组建团队（监管、质量、研发）
│ ├── 制定项目计划
│ ├── 预算批准（€150,000）
│ └── 聘请顾问
├── 月份1-2：QMS建立
│ ├── 编制ISO 13485文档
│ ├── 培训员工
│ ├── 试运行
│ └── 内部审核
└── 月份3：技术文档启动
├── 设计文档整理
├── 风险管理启动
└── 软件文档编制
月份4-9：技术文档编制
├── 月份4-5：设计和验证
│ ├── 设计输入/输出
│ ├── 设计验证
│ ├── 设计确认
│ └── 追溯矩阵
├── 月份6-7：风险管理和软件
│ ├── 风险分析（FMEA）
│ ├── 风险评估
│ ├── 风险控制
│ ├── IEC 62304文档
│ └── 软件验证确认
├── 月份8：临床评价
│ ├── 文献检索
│ ├── 等效器械分析
│ ├── 临床数据收集
│ └── 临床评价报告
└── 月份9：测试和文档完成
├── 性能测试
├── 安全测试
├── EMC测试
└── 技术文档汇总
月份10-15：公告机构审核
├── 月份10：公告机构选择和申请
│ ├── 评估5个候选机构
│ ├── 选择TÜV SÜD
│ ├── 准备申请包
│ └── 提交申请（€35,000）
├── 月份11-13：文档审核
│ ├── 初步审查（2周）
│ ├── 详细审查（8周）
│ ├── 第1轮问题（45个问题）
│ └── 补充材料提交
├── 月份14：现场审核
│ ├── 审核准备（3周）
│ ├── 现场审核（2天）
│ ├── 7个不符合项
│ └── 纠正措施实施
└── 月份15：证书颁发
├── 不符合项关闭验证
├── 技术委员会批准
└── 证书签发
月份16-18：上市准备
├── 月份16：符合性声明
│ ├── 编制EU DoC
│ ├── 加贴CE标志
│ └── 准备标签
├── 月份17：EUDAMED注册
│ ├── 演员注册
│ ├── UDI注册
│ ├── 器械注册
│ └── 证书关联
└── 月份18：上市
├── 生产准备
├── 分销渠道
└── 市场推广
关键挑战和解决方案¶
挑战1：软件分类不确定¶
问题描述： 移动应用的分类不明确，不确定是IIa类还是IIb类。
分析过程：
// 软件分类评估
typedef struct {
char feature[100];
char risk_level[20];
char classification[10];
char rationale[200];
} Software_Feature_Classification_t;
Software_Feature_Classification_t features[] = {
{
.feature = "血糖数据显示",
.risk_level = "低",
.classification = "I类",
.rationale = "仅显示数据，无诊断功能"
},
{
.feature = "趋势分析和图表",
.risk_level = "低-中",
.classification = "IIa类",
.rationale = "提供信息支持，但不直接诊断"
},
{
.feature = "高/低血糖报警",
.risk_level = "中",
.classification = "IIa类",
.rationale = "监测生理参数，非关键生命参数"
},
{
.feature = "胰岛素剂量建议",
.risk_level = "高",
.classification = "IIb类",
.rationale = "影响治疗决策，糖尿病为中等严重疾病"
}
};
解决方案： 1. 咨询公告机构和顾问 2. 参考MDCG 2019-11指南 3. 决定：移动应用分类为IIa类（不包含胰岛素剂量建议功能） 4. 将胰岛素剂量建议作为未来功能，单独认证
经验教训： - 早期与公告机构沟通分类问题 - 功能模块化设计，便于分阶段认证 - 保留分类决策的文档记录
挑战2：临床证据不足¶
问题描述： 公告机构要求更多的临床数据，文献综述不够充分。
初始方案（不足）： - 文献综述：仅20篇文献 - 临床数据：仅内部测试数据（30例） - 等效器械：未充分证明等效性
公告机构反馈：
审核发现 #12（主要不符合项）：
类别：临床评价
描述：临床评价报告不符合MDCG 2020-13要求
- 文献检索策略不充分
- 等效器械分析缺失关键信息
- 临床数据样本量不足
要求：
1. 扩展文献综述（至少50篇相关文献）
2. 完善等效器械分析
3. 补充临床数据（至少100例）
改进方案：
1. 文献综述增强（2个月）：
├── 系统文献检索
│ ├── 数据库：PubMed, Embase, Cochrane
│ ├── 关键词：glucose meter, self-monitoring, accuracy
│ ├── 时间范围：2013-2023（10年）
│ └── 纳入标准：明确定义
├── 文献筛选
│ ├── 初筛：200篇
│ ├── 全文评估：80篇
│ └── 最终纳入：55篇
└── 证据综合
├── 准确性证据
├── 安全性证据
└── 临床有效性证据
2. 等效器械分析（1个月）：
├── 识别等效器械
│ ├── 器械A：Accu-Chek Guide
│ ├── 器械B：OneTouch Verio
│ └── 器械C：FreeStyle Libre
├── 技术特征对比
│ ├── 测量方法
│ ├── 准确性
│ ├── 测量范围
│ └── 样本量
└── 临床性能对比
├── 临床研究数据
├── 上市后数据
└── 差异分析
3. 临床数据补充（3个月）：
├── 临床研究设计
│ ├── 研究类型：前瞻性比较研究
│ ├── 样本量：120例
│ ├── 参考方法：实验室YSI分析仪
│ └── 统计分析：ISO 15197:2013
├── 研究实施
│ ├── 伦理批准
│ ├── 受试者招募
│ ├── 数据收集
│ └── 质量控制
└── 数据分析
├── 准确性分析
├── 精密度分析
└── 用户性能评估
结果： - 临床评价报告从50页扩展到150页 - 文献综述：55篇高质量文献 - 临床数据：120例受试者，1200个数据点 - 准确性：98.5%符合ISO 15197标准 - 公告机构接受
经验教训： - 不要低估临床评价的工作量 - 早期规划临床研究 - 预留足够的时间和预算 - 参考MDCG指南文件
挑战3：软件文档不完整¶
问题描述： 软件文档不符合IEC 62304要求，缺少关键文档。
审核发现：
审核发现 #8（主要不符合项）：
类别：软件开发
描述：软件文档不符合IEC 62304:2015要求
缺失文档：
1. 软件开发计划不完整
2. 软件需求规格说明缺少追溯
3. 软件架构设计文档不充分
4. 软件单元测试覆盖率不足（仅65%）
5. SOUP管理不充分
6. 软件配置管理计划缺失
解决方案：
// 软件文档完整性检查清单
typedef struct {
// IEC 62304必需文档
bool software_development_plan;
bool software_requirements_spec;
bool software_architecture_design;
bool software_detailed_design;
bool software_unit_implementation;
bool software_integration_plan;
bool software_integration_testing;
bool software_system_testing;
bool software_release;
// 支持文档
bool software_risk_management;
bool software_configuration_management;
bool software_problem_resolution;
bool soup_list_and_evaluation;
// 验证确认
bool software_verification_report;
bool software_validation_report;
float unit_test_coverage; // 目标：100%
float integration_test_coverage; // 目标：100%
// 网络安全
bool cybersecurity_risk_assessment;
bool security_controls_documentation;
bool penetration_test_report;
} Software_Documentation_Checklist_t;
改进措施（2个月）：
- 补充软件开发计划：
- 添加软件安全分类（Class B）
- 明确开发生命周期模型
-
定义验证确认策略
-
完善需求规格说明：
- 添加需求ID
- 建立追溯矩阵（需求→设计→代码→测试）
-
补充非功能需求
-
增强架构设计：
- 绘制详细架构图
- 说明模块间接口
-
文档化设计决策
-
提高测试覆盖率：
-
SOUP管理：
// SOUP清单示例 typedef struct { char soup_name[100]; char version[20]; char manufacturer[100]; char purpose[200]; char risk_level[20]; bool anomaly_list_reviewed; char mitigation[200]; } SOUP_Item_t; SOUP_Item_t soup_list[] = { { .soup_name = "FreeRTOS", .version = "10.4.3", .manufacturer = "Amazon Web Services", .purpose = "实时操作系统", .risk_level = "中", .anomaly_list_reviewed = true, .mitigation = "使用稳定版本，定期更新，测试验证" }, { .soup_name = "Mbed TLS", .version = "2.28.0", .manufacturer = "ARM", .purpose = "加密通信库", .risk_level = "高", .anomaly_list_reviewed = true, .mitigation = "安全配置，定期更新，渗透测试" } // ... 其他SOUP };
结果： - 软件文档从200页增加到500页 - 单元测试覆盖率：100% - 追溯矩阵：完整 - SOUP清单：15个项目，全部评估 - 公告机构接受
经验教训： - 从项目开始就遵循IEC 62304 - 使用工具自动化追溯和覆盖率 - SOUP管理不能忽视 - 软件文档是审核重点
挑战4：网络安全要求¶
问题描述： MDR强制要求网络安全文档，但团队缺乏经验。
初始状态： - 无系统的网络安全风险评估 - 无威胁建模 - 安全控制措施文档不完整 - 无渗透测试
公告机构要求：
审核发现 #15（主要不符合项）：
类别：网络安全（IEC 81001-5-1）
描述：网络安全文档不符合MDR附录I第17.4条要求
要求：
1. 进行系统的威胁建模（STRIDE）
2. 实施安全控制措施
3. 进行渗透测试
4. 建立安全更新机制
5. 文档化所有安全措施
解决方案（3个月）：
1. 威胁建模（STRIDE）：
// 威胁建模示例
typedef struct {
char threat_category[20]; // STRIDE类别
char threat[200];
char asset[100];
int severity; // 1-5
int likelihood; // 1-5
int risk_level; // severity * likelihood
char mitigation[300];
int residual_risk;
} Threat_Model_t;
Threat_Model_t threats[] = {
{
.threat_category = "Spoofing",
.threat = "攻击者伪装成合法血糖仪",
.asset = "移动应用",
.severity = 4,
.likelihood = 3,
.risk_level = 12,
.mitigation = "蓝牙配对认证，设备证书验证，加密通信",
.residual_risk = 4
},
{
.threat_category = "Tampering",
.threat = "攻击者篡改传输中的血糖数据",
.asset = "通信数据",
.severity = 5,
.likelihood = 3,
.risk_level = 15,
.mitigation = "TLS加密，数字签名，完整性校验",
.residual_risk = 3
},
{
.threat_category = "Repudiation",
.threat = "用户否认进行了某次测量",
.asset = "测量记录",
.severity = 2,
.likelihood = 2,
.risk_level = 4,
.mitigation = "审计日志，时间戳，数字签名",
.residual_risk = 2
},
{
.threat_category = "Information Disclosure",
.threat = "未授权访问患者健康数据",
.asset = "云端数据库",
.severity = 5,
.likelihood = 3,
.risk_level = 15,
.mitigation = "数据加密（静态和传输），访问控制，审计",
.residual_risk = 3
},
{
.threat_category = "Denial of Service",
.threat = "攻击导致系统不可用",
.asset = "云平台",
.severity = 3,
.likelihood = 2,
.risk_level = 6,
.mitigation = "速率限制，负载均衡，冗余设计",
.residual_risk = 2
},
{
.threat_category = "Elevation of Privilege",
.threat = "普通用户获得管理员权限",
.asset = "云平台",
.severity = 4,
.likelihood = 2,
.risk_level = 8,
.mitigation = "最小权限原则，角色基础访问控制，定期审计",
.residual_risk = 2
}
};
2. 安全控制措施实施：
// 安全控制措施
typedef struct {
// 身份认证和访问控制
bool user_authentication; // 用户名/密码 + 生物识别
bool device_authentication; // 设备证书
bool role_based_access_control; // RBAC
bool session_management; // 会话超时
// 数据保护
bool data_encryption_at_rest; // AES-256
bool data_encryption_in_transit; // TLS 1.3
bool data_integrity_check; // HMAC
bool secure_key_storage; // 硬件安全模块
// 通信安全
bool secure_bluetooth; // BLE安全配对
bool secure_https; // TLS 1.3
bool certificate_pinning; // 证书固定
// 安全监控
bool audit_logging; // 审计日志
bool intrusion_detection; // 异常检测
bool security_event_monitoring; // 安全事件监控
// 安全更新
bool secure_firmware_update; // 签名验证
bool secure_software_update; // 应用更新
bool update_rollback; // 回滚机制
// 物理安全
bool tamper_detection; // 篡改检测
bool secure_boot; // 安全启动
} Security_Controls_t;
3. 渗透测试：
渗透测试范围：
├── 血糖仪固件
│ ├── 固件逆向工程
│ ├── 调试接口测试
│ ├── 固件更新安全
│ └── 密钥存储安全
├── 蓝牙通信
│ ├── 配对过程
│ ├── 加密强度
│ ├── 重放攻击
│ └── 中间人攻击
├── 移动应用
│ ├── 代码混淆
│ ├── 本地数据存储
│ ├── API安全
│ └── 会话管理
└── 云平台
├── API安全
├── 身份认证
├── 授权机制
├── SQL注入
├── XSS攻击
└── CSRF攻击
渗透测试结果：
├── 高危漏洞：0个
├── 中危漏洞：3个（已修复）
├── 低危漏洞：5个（已修复）
└── 信息性发现：8个（已记录）
4. 安全更新机制：
// 安全更新流程
typedef struct {
// 更新检查
bool automatic_update_check;
int check_frequency_days; // 每7天
// 更新验证
bool digital_signature_verification;
bool version_check;
bool compatibility_check;
// 更新安装
bool secure_download; // HTTPS
bool integrity_verification; // SHA-256
bool backup_before_update;
bool rollback_capability;
// 更新通知
bool user_notification;
bool update_log;
bool security_advisory;
} Security_Update_Mechanism_t;
结果： - 威胁模型：识别25个威胁，全部缓解 - 安全控制：实施20项安全措施 - 渗透测试：所有高危和中危漏洞已修复 - 安全文档：200页网络安全文档 - 公告机构接受
经验教训： - 网络安全是MDR强制要求，不能忽视 - 早期进行威胁建模 - 聘请专业安全测试团队 - 建立持续的安全更新机制
成本分析¶
总成本明细¶
项目总成本：€185,000
1. 人力成本：€95,000
├── 监管事务经理（12个月）：€45,000
├── 质量工程师（12个月）：€35,000
└── 技术文档编写（6个月）：€15,000
2. 公告机构费用：€45,000
├── 申请费：€5,000
├── QMS审核：€15,000
├── 技术文档审核：€20,000
└── 现场审核：€5,000
3. 测试费用：€25,000
├── 性能测试：€8,000
├── 电气安全测试：€6,000
├── EMC测试：€7,000
└── 生物相容性测试：€4,000
4. 临床研究：€15,000
├── 伦理批准：€2,000
├── 受试者招募：€5,000
├── 数据收集和分析：€6,000
└── 报告编制：€2,000
5. 顾问费用：€20,000
├── 法规顾问：€12,000
├── 网络安全顾问：€8,000
6. 其他费用：€10,000
├── 差旅费：€4,000
├── 翻译费：€3,000
├── 软件工具：€2,000
└── 杂费：€1,000
成本优化建议¶
可优化项目：
├── 内部能力建设
│ ├── 培训内部人员（减少顾问依赖）
│ ├── 建立模板库（提高效率）
│ └── 使用开源工具（降低软件成本）
├── 测试优化
│ ├── 选择性价比高的实验室
│ ├── 合并测试项目
│ └── 利用供应商测试数据
└── 公告机构谈判
├── 多器械打包
├── 长期合作折扣
└── 合理安排审核时间
潜在节省：€30,000-50,000（20-30%）
关键成功因素¶
1. 团队组建¶
核心团队（5人）：
├── 监管事务经理（全职）
│ ├── 职责：整体项目管理，公告机构沟通
│ ├── 经验：5年医疗器械法规经验
│ └── 关键：MDR和IEC 62304知识
├── 质量工程师（全职）
│ ├── 职责：QMS建立，文档控制
│ ├── 经验：ISO 13485审核员资格
│ └── 关键：注重细节，流程导向
├── 软件工程师（兼职50%）
│ ├── 职责：软件文档，测试
│ ├── 经验：IEC 62304实施经验
│ └── 关键：文档化能力
├── 临床专家（顾问）
│ ├── 职责：临床评价，文献综述
│ ├── 经验：糖尿病领域专家
│ └── 关键：临床研究设计
└── 网络安全专家（顾问）
├── 职责：威胁建模，渗透测试
├── 经验：医疗器械网络安全
└── 关键：IEC 81001-5-1知识
2. 项目管理¶
// 项目管理最佳实践
typedef struct {
// 计划
bool detailed_project_plan;
bool risk_register;
bool resource_allocation;
// 执行
bool weekly_team_meetings;
bool milestone_tracking;
bool issue_log;
// 沟通
bool regular_nb_communication;
bool stakeholder_updates;
bool documentation_reviews;
// 质量
bool internal_audits;
bool peer_reviews;
bool lessons_learned;
} Project_Management_Best_Practices_t;
3. 文档管理¶
文档管理系统：
├── 版本控制
│ ├── 使用Git进行版本控制
│ ├── 明确的版本命名规则
│ └── 变更历史记录
├── 文档模板
│ ├── 标准化模板
│ ├── 检查清单
│ └── 示例文档
├── 追溯系统
│ ├── 需求追溯矩阵
│ ├── 风险追溯
│ └── 测试追溯
└── 文档审查
├── 同行评审
├── 技术审查
└── 管理评审
经验教训总结¶
做得好的方面¶
- 早期规划：
- 项目开始前6个月就开始准备
- 详细的项目计划和时间表
-
充足的预算预留
-
专业团队：
- 聘请有经验的监管事务经理
- 使用专业顾问
-
团队培训充分
-
主动沟通：
- 与公告机构保持定期沟通
- 及时回应审核问题
-
透明和合作的态度
-
质量优先：
- 不走捷径
- 彻底的内部审核
- 高质量的文档
需要改进的方面¶
- 临床评价准备不足：
- 应该更早开始文献综述
- 应该提前规划临床研究
-
低估了临床评价的工作量
-
软件文档初期不完整：
- 应该从开发开始就遵循IEC 62304
- 应该使用自动化工具
-
追溯矩阵应该持续维护
-
网络安全经验不足：
- 应该更早聘请安全专家
- 应该在设计阶段就考虑安全
-
威胁建模应该更早进行
-
成本控制：
- 实际成本超出预算15%
- 应该预留更多应急预算
- 某些测试可以优化
给其他公司的建议¶
关键建议：
├── 1. 时间规划
│ ├── 预留18-24个月
│ ├── 不要低估文档工作量
│ └── 预留缓冲时间
├── 2. 预算规划
│ ├── IIb类器械：€150,000-200,000
│ ├── 预留20-30%应急预算
│ └── 考虑隐性成本
├── 3. 团队建设
│ ├── 聘请有经验的人员
│ ├── 投资培训
│ └── 使用顾问
├── 4. 公告机构
│ ├── 选择有经验的机构
│ ├── 早期沟通
│ └── 建立长期关系
├── 5. 文档质量
│ ├── 使用模板和检查清单
│ ├── 彻底的内部审核
│ └── 同行评审
└── 6. 持续改进
├── 记录经验教训
├── 建立知识库
└── 流程优化
项目成果¶
认证结果¶
CE认证：
├── 证书编号：NB0123-MD-2024-001
├── 颁发日期：2024-03-15
├── 有效期：5年（至2029-03-14）
├── 公告机构：TÜV SÜD (0123)
└── 分类：MDR Class IIb
EUDAMED注册：
├── SRN：DE-MF-000012345
├── Basic UDI-DI：(01)04012345678901
├── 注册日期：2024-04-01
└── 状态：活跃
市场表现¶
上市后6个月：
├── 销售：5,000台
├── 市场反馈：积极
├── 不良事件：0起
├── 投诉：12起（全部已解决）
└── 客户满意度：4.5/5.0
上市后监督：
├── PMS计划：正常执行
├── PMCF：进行中
├── 趋势分析：无安全信号
└── 下一次PSUR：2026年3月
ROI分析¶
投资回报：
├── 总投资：€185,000
├── 开发成本：€500,000
├── 总成本：€685,000
├── 预计年销售：€2,000,000
├── 毛利率：40%
├── 年毛利：€800,000
└── 回收期：<1年
相关资源¶
参考文献¶
- Regulation (EU) 2017/745 - Medical Device Regulation (MDR)
- ISO 13485:2016 - Medical devices - Quality management systems
- IEC 62304:2006+AMD1:2015 - Medical device software
- ISO 14971:2019 - Application of risk management to medical devices
- IEC 62366-1:2015 - Medical devices - Usability engineering
- IEC 81001-5-1:2021 - Health software and health IT systems safety - Security
- ISO 15197:2013 - In vitro diagnostic test systems - Requirements for blood-glucose monitoring systems
- MDCG 2019-11 - Guidance on Qualification and Classification of Software
- MDCG 2020-13 - Clinical Evaluation Assessment Report Template
- MDCG 2019-16 - Guidance on Cybersecurity for medical devices
💬 讨论区
欢迎在这里分享您的想法、提出问题或参与讨论。需要 GitHub 账号登录。