这就是问题所在。

医疗器械制造商因终端用户的压力实施变更。尤其是医疗器械软件（SaMD），使用者习惯每周或每月接受新版本。因此，依据MDCG 2020-3，I类MDD SaMD制造商必须设法将其软件变更认定为非实质性变更，否则，他们会因受到致命MDR规则11及其IIa类陷阱的阻碍，无法向终端用户交付新版本。

MDCG 2020-3图表C或图表B

困难的步骤显然是MDCG 2020-3的图表C，标准聚焦于软件。至少可以说，我们的处境很艰难。但是，与我们最初的想法相反，当软件变更为微小的详细设计变更和源代码变更但不触动操作系统（OS）、组件、通用图形用户界面（GUI）布局等时，可以对问题C1至C5回答“否”。

然而，我们在B图B2的问题上遇到困难：新风险是否需要采取控制措施，或现有风险是否受到负面影响？

实际上，当我们对软件行为进行更改时，这种更改不应带来新的风险。

例如：可以通过姓名、姓氏、出生日期对患者进行排序。我们加上重量和尺寸，不会带来新的风险。可根据风险对患者进行分类。

没有跳出任何新风险，并且现有的缓解措施没有受到影响。我们可以对问题B2回答“否”。

但是，如果我们实现一个新功能，即使是详细设计和源代码方面的小功能，也会带来新的风险。

例如：可以修改分类表中的患者数据。已经可以在软件的一些其它面板中修改患者数据。该小变更易于实现，软件已经能够修改患者数据。用户修改数据时会增加风险，修改后会更改排序顺序。缓解措施是在修改后自动对数据进行排序，并将焦点留在之前修改的行上。

新风险跳出。尽管图表C中的变更较小，但由于我们必须在风险评定矩阵中增加一行，因此根据问题B2，其为主要变更。

新风险、重大变更

当您对软件进行更改时，很容易发现新的风险！这可能使每次变更都成为重大变更。

一个解决方案是重用风险管理文件中的现有风险，其或多或少与新风险相似；前提是风险可接受性未发生改变。在这种情况下，没有新风险。

这有点像与MDCG捉迷藏。但这是一种可能性。

同样，新变更所带来的风险被评价为非常低或处于最低风险系数。在这种情况下，我们可以认为没有增加新风险。我们可以通过修改示例中的数据来实现这一点。

无论如何，这有点像捉迷藏，要么试图重用风险，要么无视极低的风险。

网络安全

MDCG中的一个通行证是将变更归类为网络安全措施。如果可行，可根据问题C6进行变更。将SOUP版本的变更归类为网络安全措施几乎总是可行。新版本将关闭已知漏洞。

即使我们有问题C1：操作系统或任何组件的新变更或重大变更？由于存在网络安全理由，变更SOUP版本属于微小变更。更广泛地说，留下已知的漏洞是站不住脚的，MDCG确实考虑了这种情况。

一些SaMD制造商可能会发布一些隐藏在网络安全更新流程中的其他变更，这些变更很少或没有记录。这是我们不建议的解决方案：-）。

结论

我们有一些小的可能性将用户要求的变更鉴定为次要变更。即使在MDCG 2020-3中打开了这个小窗口，I类SaMD制造商将不得不发布有重大变更的新版本。这一天即将到来，2024年是软件的永恒。

我们是否应该坚持这样一个事实：将SaMD锁定在一个版本中的法规会剥夺用户所要求的变更？这种方法错过了以轻微风险（请求变更的不良副作用）为代价为患者带来一些受益（请求变更的新版本）的机会。轻微风险，即由医学专业人士（有时是非专业人士）使用且之前归类为I类MDD的不与患者接触且无测量功能的SaMD不会对患者或终端用户造成重大风险。

MDR 锁定降低了 I 类 MDD SaMD 的风险/收益平衡。