医疗设备行业的软件架构师从来没有轻松过片刻。 在严格的监管环境中实现创新绝非易事，这在数字时代更加复杂：连接型设备提供了很大的潜力，但它们无法与外部风险完全隔离。

一方面，制造商正在努力实现新产品和产品更新的无缝、频繁的要求；另一方面，他们的工作必须获得监管部门的批准。在数字时代，后者越来越复杂， 因为还包括了网络安全以及用户和患者的安全。 这给医疗设备软件架构师带来了新的挑战。

连接软件的兴起提供了大量机会，但它是一把双刃剑。在分离的、未连接的设备中，软件代码被嵌入并包含在单个功能单元中。使用自上而下的方法可以拥有端到端的代码开发，并控制风险。但是，对于连接型设备、图形用户界面（GUI）、网络应用程序和移动应用程序，它们有着不同的开发者，具有不同的业务、运营和监管问题。

您无法在此环境中掌控一切，所以，您必须权衡选择。微软和甲骨文等公司提供了大量现成的软件组件，可以加速医疗设备的开发。但是这些组件是未知来源的软件（SOUP），因为它们的开发并未根据医学标准。 你能安全地在你的设备中使用它们吗？ 你能不使用它们，并承担从头开始构建一切的成本和风险吗？ 大多数软件架构师需要在某种程度上做出最合理的选择。秘诀就是要了解何时利用第三方软件将带来适当 且有益的帮助，同时控制相关风险。

1.前期决策至关重要：明智而谨慎地做出选择。

前端软件架构始终是最重要的，在医疗设备领域尤其如此。该决策会影响产品在市场获得成功的可能性。选择错误的操作系统或编程语言会大大降低监管机构批准的可能性。我们必须考虑外科工具控制系统的潜在风险。如果在非实时操作系统中构建，则不太可能获得批准。

这是一个极端的例子，说明软件架构师必须选择各种技术，从编程语言和操作系统，到数据库、数据 / 信息交换协议以及潜在的云端 / 主机选项。所有选择都需要考虑规则、软件寿命、安全性、网络安全性和 可用性。最终做出的决定必须平衡并利用好可用的技术，并确保代码的安全 / 控制得到严密保护。

2.安全是王道：包括风险决策

协调好创新和安全之间的“对立”，需要采用基于风险的软件架构方法。医疗标准 IEC 62304 具有用于医疗设备软件的 A/B/C 分类系统，主要与可能对用户或患者造成伤害的潜在危险有关。架构师需要解构系统架构并将其隔离，以便可以对每个软件项 / 单元进行适当分类。这使得架构师能够在系统的某些部分应用经过良好测试的软件，同时在其他部分部署更高级别的安全和控制，例如可能导致死亡或严重伤害的“C 级”要素。

文档也是风险管理的一个重要方面。对于我们咨询机构而言，这是至关重要的，因为除非有着有效记录， 否则客户无法正确地审查架构。必须建立清晰的轮廓， 包括基于 A/B/C 软件分类的分段可追溯性，以及系统 的哪个部分执行哪个功能，这些都是必不可少的。对每种技术选择都要有相应的层次结构和风险案例，并能对风险管理方式的解释提供强有力的理由。例如， 某些功能（例如设备配置、升级或校准）可能只能在没有患者的情况下使用。通过设计，这些功能在治疗期间就不会被无意激活。

国际标准 IEC 62304 适用于医疗设备软件的开发 和维护，它要求制造商根据软件可能导致伤害的风险水平对其进行分类，包括：Class A：不可能造成人身 伤害或健康损害；Class B：可能造成非严重伤害；Class C： 可能导致死亡或重伤。

3.面向未来：你永远不能确定今天做出的选择在十年后仍然是理想的。

在很多方面，要做到“面向未来” 似乎是矛盾的。这是医疗设备软件与标准软件不同的另一个领域，前者时间范围要长得多。没有人认为个人消费设备， 如电话、可穿戴设备、应用程序在十年后仍然可以投入使用。这些产品通常最多保持三到五年的过时周期。然而，医疗产品的周期时间可以延长至 10 年甚至 20 年。在这种开发环境下，软件架构师需要确认更重要的趋势，同时留出未来发展的空间。

我们没有完美的方法，但是仍然有一些关键原则可以遵循：

谨防锁定：专有软件（通常由小型、 专业或小众供应商提供）可能是非常有限的，即使它声称能解决 90％的当前 问题。一些供应商和咨询公司将客户绑定到 IP 保护技术堆栈。如果您按照此路径，未来开发自己的产品时可能会受到限制，因为您将受制于第三方公司的升级路径和产品投资。

寻找基于标准和开源的内容：当您确定架构的哪些部分可以使用商业软件时，请做出尽可能开放的选择。任何基于标准的技术堆栈和它可以读 / 写的数据标准，都应该能为您提供灵活性并支持未来的开发。尽量避免任何不必要的偏见。

评估软件的普遍性和原则：尝试评估它在市场中的使用范围、受欢迎程度、 应用时间长短，以及关键的行业参与者对该技术的承诺。

4.可用性：考虑架构决策的影响。

专家要考虑的不仅仅是人为因素， 还必须考虑使用或可能发生的误用医疗设备的情况。软件架构师的决策也会影响可用性，无论用户体验设计师多么有才能，都无法解决所有问题。系统性能在很大程度上取决于体系结构，这会影响响应性，而这对获得最佳的用户体验至关重要。同样，架构决策会影响稳健性，从而对易用性和安全性产生影响。

还必须评估系统的 GUI 的可用性以及与更广泛的架构的兼容性。我们应该仔细考虑各种用户群体的需求，以及它们将要接触的特定接口，毕竟临床医生的要求与维护人员和制造商的要求完全不同。即使是软件开发人员和测试人员也希望能获得良好的用户体验。

另一个重要的考虑因素是这些最终用户访问系统的平台。当验证软件时， 我们必须在给定的平台上进行，而客户有时会忘记这一点。但即使是简单的手机应用程序也必须考虑设备的平台不同，例如不同的屏幕尺寸和分辨率，不 同的硬件平台和不同版本的操作系统。

当功能特性受到软件平台的影响时，您必须非常仔细地考虑可用性。 例如一个采用可实时向用户显示信息的系统，如果它部署在没有实时操作系统的医院电脑上会发生什么？用户 以为他们正在使用最新的数据，而实际上机器有时候是存在延迟的，如何避免这样的情况？事实上，这是我们的一位客户遇到的真实情况。我们通过在屏幕上放置一个“闹钟”来解 决这个问题，这样用户可以立即检测 到系统何时延迟，以及在解除延迟时收到提醒。有时，架构的考虑（需要实时操作系统）会受到环境现实的影响（您不能对机器有强制要求），因此必须在 GUI 设计上进行弥补

5.软件安全：从头开始构建。

连接型医疗设备不可避免地暴露于网络威胁中。在这种复杂的环境中，人 员、设备、软件和服务与全球分布式物理信息和通信技术的支持相互作用。

自 FDA 于 2014 年首次引入指南以来，对于任何医疗设备，如果使用无线网络、互联网和网络连接来交换健康相关信息，有效的网络安全已成为必要条 件。该指南于 2018 年得到更新，包括了医疗设备上市前在设备设计、标签和 文档方面的有关网络安全风险的建议。

传统的 IT 系统有完善的风险管理框架，例如 NIST 800-30。然而，众所周知的是，很少有指导可用于管理医疗设备的网络安全风险。2016 年，医疗器械促进协会（AAMI）迈出了欢欣鼓舞的一步——让医疗设备制造商转向一致的安全风险管理框架。根据 AAMI 的“TIR57：2016 医疗设备安全原则” 报告，其中的风险管理提供了有关管理与安全威胁相关的风险以及这些风险对 数据、机密性、完整性和设备可用性的 影响的指导。

建议制造商与现有的基于 ANSI/ AAMI/ISO 14971 的安全风险管理流程一起建立配套的安全风险管理流程。安全风险涉及到评估导致危害的可能性及其严重性。但是，安全风险会评估威胁能成功利用设备漏洞的可能性。这种性质的事件可能会危及系统的机密性、完 整性和 / 或可用性。

最后，向 FDA 提交的设备现在可 以利用 UL 2900-2-1 的测试和合规性声明，来简化产品评审。FDA 在 2017 年宣布认可 UL 2900 标准为 FDA 公认标准，这为制造商和开发商提供了一种方法来满足对减轻医疗设备网络安全风险的不断变化的要求。

对制造商的建议如下：采用基于风险的方法设计和开发基于 ISO 14971 的适当网络安全保护的医疗设备；通过评估整个产品生命周期中的风险和采取缓解措施，来对设备的网络安全应用整体的解决方案；创建一个能够解决 FDA 指南中的网络安全设计建议的支持架构：识别和保护、检测、响应、恢复。

面对快速发展的网络犯罪，需要定期进行安全升级，以缓解紧急威胁。鉴于许多医疗设备的预期使用寿命较长， 因此将其作为主要功能来进行架构是至关重要的。

结论：取得适当的平衡

医疗设备软件架构师在早期做出重大决策：从定义技术框架和做出必要的选择，到选择技术集。前期架构选择会影响所有的后续工作，并对项目是否能按时地在预算范围内完成产生重要影响，超期或预算超支会产生重大的成本损失和不便。 在数字时代，医疗设备需要充分利用连接性，同时降低相关风险。在不忽视安全性的情况下获得更好的结果，这需要高度的实用主义和观念。

作者：Paulo Pinheiro 和 Anthony

Hayward Sagentia 公司电子、软件与系统部门