我父亲过去常说，有富有经验的飞行员，也有大胆的飞行员，但没有多少又富有经验又大胆的飞行员。在本博文中，我们可以用医疗器械（MD）和体外诊断（IVD）程序员来代替飞行员。编程很有趣！它为有针对性的创造性活动带来了切实成果。电脑屏幕上的“Hello World！”或电路板上闪烁的LED灯会让您立刻感到满足，您已经具备了基本的运行能力，而在那之后，天空就是极限！
特技飞行——早期在我早期的设计生涯中，我在电子设计和嵌入式软件设计（又名固件）之间来回切换。对我来说，随着时间的推移，我感觉到到固件更让人开心——置于仪器内部并真正将其整合在一起可能任务艰巨，但从开发的角度来看，是有些宽容的。所有的重点都将放在编码上，有严格的时间限制和多维方面，如中断和任务切换。在开发过程中犯了错误，通常您可以快速纠正、重新编译并有很小的进度影响。而另一方面，硬件则没有那么宽容，犯了一个错误，它要么是一个“cut-n-jump”，附添“死虫”集成电路（IC），要么是印刷电路板的设计返工——呃——对项目进度和预算来说有太大影响！
所以在过去，软件/固件非常灵活，因为除了代码之外，几乎没有什么要改变的。然后是医疗器械软件开发。这需要我们所理解的许多人工制品设计，它们随后为软件开发过程增加了一些惯性思维。现在，我们需要计划、规范、验证，如果出现问题，要返工并进行大量文档更改，再加上回归测试和正式再一次进行的V&V。我们需要正式管理配置、bug异常、发布过程和OTS/SOUP。与“游戏后期”的MD&IVD硬件变更相比，仍然没那么糟糕，但也没有过去那么“敏捷”。
编队飞行——不仅仅关注软件我已经停留太久，注意到那些以软件为中心过程时代已经过去了。MD和IVD软件开发现在明显更加全面，具有相应的附加过程。它已经变得如此全面，以至于从任务的角度来看，编码工作在开发中所占的比例与硬件原理图设计在产品实现中所涉及的其他过程中所占比例大致相同。这一点的关键是，现在有大量的标准被设立和认可，为MD和IVD软件的可接受性设置了“高门槛”。将这些标准视为老飞行员的智慧向大胆飞行员的分享（尽管老家伙也需要学习）。这些标准的广泛性往往源于现实世界的问题，并成为强制要求。关注这些标准，你的努力就能继续，忽视它们，或者对它们“口头应酬”，你就会彻底失败。
有关标准的挑战是它们相当孤立。这些标准旨在解决某个特定的问题，尽管它们试图协调一致，但实际应用这些标准可能非常困难。
这些标准由不同的组织（ISO、IEC、AAMI等）提出，它们相互参考和指引，试图帮消费者（即制造商）将它们联系在一起。此外，世界各地不同的监管机构认可不同的版本，这使得全球市场更具挑战性（Qserve在这方面富有经验）。因我们在这里关注的是软件，让我们应用一个通用的软件状态图来显示这些不同的标准如何转化为制造商的开发活动。 | 
图1：标准筒仓 |
图2：制造商开发人员标准应用行为状态图。
当我们开发医疗器械软件时，无论它是否为嵌入式医疗器械或IVD软件，都被考虑为医疗器械（SaMD/AI），或者可能是医疗器械的附件，我们必须努力解决标准最终如何影响我们的软件流程、需求、架构、V&V等。这可能是小型器械制造商面临的主要挑战，具体取决于其资源和背景。即使是大型组织，也可能倾向于通过指定主题专家（SME）到特定领域来加强，在特定领域，他们的关注点局限于他们的专业知识，以及他们对整个领域和其他标准领域的了解。这可能导致“打地鼠”（图2）式的合规方法。我们有时倾向于用条条框框的思维来关注各个方面；让我们看看可用性，让我们看看网络安全，让我们看风险，让我们来看看软件等。我们可以从一个领域到另一个领域解决标准的各个方面，在解决方案和补救措施上，有时会在事后“创可贴”，来希望满足需求。
编队飞行——建造支撑结构
多年来，我开始接受并大力支持系统观点。从交通模式到我们的法律制定，以及MD和IVD设计开发，我相信在选择解决方案路径之前，系统观点至关重要。公平地说，基本标准需要一个规划阶段——这实际上意味着——退后一步，制定计划！没有经验的人可能会低估这一点。我们没有时间！正如那句古老的谚语所说，“永远没有时间正确地做事，却总是有时间重来一遍”！
好的，我已经用上述问题挖了个洞。我在这里的动机是1）认识现实（上述），2）解决方案一瞥（下文）。首先是我们公司的一段话：Qserve每天都与全球市场上的许多不同客户一起处理这个问题。我们的务实途径可以是一些建议，评审/审核，让工作启动，让其进行。无论如何，如果您有一个可行的有效医疗器械或IVD，我们希望帮助您提供给那些可以受益的人们，这意味着产品实现！
| 为了解决这种“筒仓”现状，需要由制造商/开发商进行校准过程。因为设计控制是核心，所以它们最好作为自我组织的框架。我们需要了解我们的预期用途、使用者和市场，因为这些基本的、核心的顶层要求为我们的规划，最终也为我们应用标准的严格程度提供了依据。 | 
Figure 3: AI is software too! |
在这个练习中，我将人工智能归结为软件。还有一些额外的考虑因素（AI框架：https://www.qservegroup.com/eu/en/i1249/intelligently-applied-artificial-intelligencemachine-learning---establishing-a-framework），但请记住——AI是软件，因此受软件开发标准的约束。
由于博文空间有限，且这里旨在帮助鼓励系统观点，我将只介绍一些概念。从适当的主要设计控制内容的表格（Excel）开始，我们从标准中提取各组要求，并将其作为占位符。这里的目标是将标准要求调整为过程结构，然后我们可以将其添加到流程/程序和模板中，以便在开发过程中同时解决。一些标准很容易适用，如62304这一过程标准。其他标准则不行，例如60601-1（还记得基本性能吗？），但其交付成果与设计控制阶段保持一致。此外，各个制造商都有自己的领域，需要对该领域进行定制/调整的练习。如果没有别的，就开始策划。若您的计划（风险管理、可用性、网络安全、软件开发等）是标准驱动的，且您遵循了您的计划，您就将获得符合标准的结果！
若您的目标是全球市场，请在标准类别下的列标题中使用地理位置上公认的标准。例如，普遍认可的可以是绿色，而那些独特要求的，如FDA指南是蓝色。如果我们深入各个阶段——（这里只是说明策划，我没有列出其他策划要素），我们可以在相应的设计阶段全面涵盖相关标准的各个方面。
Product Realization Stage 13485 FDA Guidance Design Controls | General SW 62304 FDA Guide SW Val. | Risk 14971 80001-1 | SW Risk TIR 80002-1 AMI TIR34 | SW Cybersecurity EN IEC 62443-2 (11073-40102) 60601-4-5 TIR57 | Usability 62366-1 FDA HF/UE Guidance |
Process 810001-5-1 TIR57 | Network 80001-1 | Product EN IEC 62443-2 60601-4-5 |
Planning | Project Plan SW Dev. Planüü | Risk Management Plan SW Risk Management Plan üü | Process (Manf. Cybersecurity Plan Plan Req. üü | Usability Engineering Plan üü |
Design Input | üüEtc. | üüEtc. | üüEtc. | üüEtc. | üüNetwork (Responsible Org.) Requirements | üü Product Capability Requirements | üüEtc. |
在软件的高阶层次上，我们可以得到类似下图列出标准中的要素。这些计划捕捉产品开发项目中的必要要素，设计控制程序/模板交叉检查。
图4：标准校准设计控制过程
该描述是针对一个带有软件的器械。如果它是医疗器械软件（SaMD-AI），不会有太大的不同，只是与因软件是考虑因素之一使用青色不同，它会更为绿色，因为软件（SaMD-AI）是系统，因此需要完整的系统视角。涉及到软件的这些标准鼓励系统观点，但这往往不被重视。顺便问一下：您能看到这个开发中的编码任务在哪里吗？显然，上面的每一个框内都有更多颗粒度，但如果您的计划、流程/过程和模板跨越了这个领域，并拾取了所用标准的颗粒度，那么您的研发也会如此！所以，若我没有给您留下其他东西，请看看天空，让几代人的智慧提醒您，如果您想走的远一点，编队飞行和特技飞行是我们MD和IVD编程的现状！MD和IVD软件开发，系统视角——转换之时？
图5：软件V图-系统视角