值得注意地是，医疗器械严重依赖第三方和早期软件，亦即“未知系谱的软件（SOUP）。该SOUP构成了新发展的基础，其现在可能符合新医疗器械要求或者政府推行的现代编码标准、客户需求或者仅仅是开发组织内的持续改进政策。
EIC 62304和SOUP
可重新用于新器件开发的SOUP软件已流行起来，因为医疗器械现在倾向于采用通用嵌入式硬件，以及操作系统，面向USB、以太网或制图的器件驱动器、文件系统、网络堆栈等。在医疗器械中使用SOUP有其优势，因为制造商可以将精力集中在应用软件上。
然而，由于应用需要运行专用功能，所以医疗器械内的SOUP增加了挑战难度。大多数SOUP模块都由第三方供应商提供，而他们不遵守任何软件过程和软件标准，甚至不记录代码。虽然它解决了平台挑战，但SOUP是在紧迫的时间表内开发而来，并且强调的是生产率，而不是标准兼容性。在进行系统测试以便检验功能性时，SOUP项目通常表现出代码覆盖率极差的特点，并且留下了很多未使用的代码路径。
欧洲软件和系统提案之“利用经验驱动测试（PET）检验误码性能计划调查了这种现象，并且同意采用的代码通常带有很多误码的观点。为了克服这种潜在弱点，需要进行详细的结构覆盖率分析，以确保早期软件内不存在未使用的代码。IEC62304要求测试早期软件的功能覆盖率和结构覆盖率，还要详细分析增加这类软件可能引入的风险。功能覆盖率确保软件能够按照系统设计要求运行，而结构覆盖率则确保使用了所有代码并且能够正常运行。
IEC62304软件开发过程始于软件开发规划，包括所用SOUP项目的详细计划。这些细节介绍了如何将SOUP项目整合到现有系统中、如何管理SOUP相关风险和软件配置、以及变更管理如何影响系统。
紧接着是软件需求管理、架构设计、集成测试、系统测试、风险管理、维护和变更管理阶段。在软件开发生命周期的各个阶段，都需要保持所有阶段之间的可追踪性。
传统的软件开发观点表明了各个阶段如何进入下一个阶段，可能还带有前几个阶段的反馈信息，以及配置管理与过程的周边架构。可追踪性被视为各个阶段间关系的一部分。然而，很少规定记录跟踪链路的机制。
实际上，虽然由于先进工具技术投资，各个阶段都能够有效实施，但是这些工具很少能够自动提高阶段间可追踪性。因此，在整个项目进行的过程中，其间链路的维护就变得越来越差。最终的结果就是需求与设计之间的交叉检验缺失或者流于表面，以及最终系统的机能不全。为了获得真正的自动可追踪性，则需要需求跟踪矩阵（RTM）。RTM是各个项目的核心，是很多开发标准（包括IEC62304）的关键所在。