医疗设备软件开发--模型驱动

在当今的互连世界，医疗设备理所当然地容纳了更多具有智能功能的创新性能。这些新型性能通常采用软件进行设计；因此，用于实现这些新功能的软件日益复杂。同时，FDA及其它管理机构也逐步对医疗设备制造商施加压力，以确保产品安全和有关医疗设备报告信息的准确性。

　　市场上面临产品复杂性增加、上市压力、产品安全和监管，对于医疗设备公司来说应对这些挑战成为良好的商业常识。本文探究一种开发医疗设备软件的模型驱动方法。

　　设备制造商正处于软件开发的转折点，几种工具可能会帮助他们改良生产率和质量。一种模型驱动的开发流程集成了产品开发的多样阶段，从需求分析到系统设计、实现、文档制作和测试。此工作流程有助于使复杂的需求和架构能图形化地以图表形式表示，因此减少了复杂性，并且还能帮助股东之间就需求和设计进行交流。图表具有语义并且互连，有助于实现直接从设计要求到设计的可追踪性。更进一步的是，该软件实现可由模型直接生成，提供了从设计要求到设计到实现的追踪检查。

交付设备软件

　　在医疗设备市场，交付创新技术的推动力非常现实，智能设备无处不在。在这一领域，是软件提供了使高技术世界成为可能的功能。医疗设备的软件被用于执行以往可能以硬件实现的功能：例如，诊断设备上的物理旋钮和按钮经常被触摸屏显示所替代，或者医疗图像如X光和MRI逐渐以数字格式而不是物理胶片交付。

　　医疗市场竞争残酷，而且产品在竞争到来之前上市至关重要。完成上市销售前的活动（如510(k)流程）和随后的药品生产和质量管理(GMP)对设备引入市场并占领强劲市场份额必不可少。但是，在速度和病人安全之间必须取得平衡以避免耗费大的产品召回。策略之一是为上市前活动重复使用现有的大量的等效编程代码，尤其是当与软件协同工作进行生命攸关的手术时。实现成功软件的关键路径是通过理解；在一些情况下，软件可能已老化，编程人员也早已不在公司，即为什么有效复用取决于文档可理解。

文档！文档！文档！

　　能发挥其知识产权(IP)效用的组织——并能复用——在工程设计新型医疗设备软件时已领先一步。对于复用，没有什么比药品文档编制更为重要，它还具有其它的效用。对于维护项目信息，一个设计历史文件(DHF)被用于储存项目成果。FDA通过需要一个DHF的质量系统监控(QSR)——21 联邦管理代码（CFR) Part 820.30来管理面向美国市场开发的产品。该DHF包含有关的信息，从多种源，包括诸如需求、系统规范、风险管理和其它正式文档在内的项目。也可能包括笔记、草图或其它零碎信息。具备一个DHF背后的基本原理是提供可追踪性和文档，以显示设备被用于特定目的，其设计实现了所有要求。然而，如何实现在某种程度上实属偶然：一些公司使用源代码打印清单以证明全部实现设计要求。当然，用源代码作为沟通方法仅在读者能读懂代码的条件下有效。非技术股东可能缺乏所需读懂源代码的技能，从而产生了潜在的危险的沟通真空。

可视软件开发

　　模型驱动开发(MDD)为软件交付创建了一种可视化开发环境。MDD的基础是源于对象管理组织的统一建模语言(UML)。MDD环境使复杂的设计输入可视化，促进了各种各样股东之间的沟通。开发团队能用比源代码更易使股东理解的格式表述设计要求、架构、结构、设计和行为。UML定义了几种不同的图表来获得系统或应用的机构、架构和行为。与UML类似的是，系统建模语言(SysML)基于UML，但是是为系统工程设计需求而量身定做。

　　UML图表内的信息被存储在一个模型储存库内，这极大地扩展了图表原仅作为插图之用的作用(见图1)。一张图表上的信息变化被模型储存库所反映，并传送给其它图表以反映同样的信息。例如，假定设计中有一级名为“Pump”，同一级出现在两个不同的图表内。在一张图中把“Pump”名改为“InfusionPump”将会在另一张图中自动变化过来。

图1：以状态图形式描述的设备操作模式。

追踪设计要求到模型元件

　　对医疗设备的要求通常以文本文件而规定，或存在于用作设计输入的需求管理工具内。尽管文本能交流大量需要完成的细节，它也会易受误解。更为重要的是，没有滤波器或流程来防止有冲突的设计要求在最开始就被记录下来。通过把需求拆分为产品内每个元件更进一步的细节要求，执行需求分析能帮助解决冲突。建模能通过文本需求以图表的形式可视化来辅助这一过程，并且提供到设计和实现的可追踪性。

追踪需求到模型元件的第一步是将文本需求与建模环境相关起来。模型内的一个需求元件储存需求，并保持除其它相关信息如需求ID、优先级、安全完整性级别及风险等之外的描述需求的文本。对能储存的数据类型没有限制。需求和模型之间保持同步化，从而任何一方的更改都能反映到另一方。从需求到满足这些需求的模型元件的可追踪性能在模型内表述出来。凭借这些信息，能生成需求覆盖报告或进行设计改变的影响分析。例如，能生成一个UML资料，定义了故障树分析图表。模型内还能进行安全性和风险分析。图2展示了故障如何被追踪到与故障相关的设计要求。可进行更进一步的模型信息分析来说明覆盖鸿沟。

图2：关系追踪需求到满足设计要求的模型元件。