Design transfer for connected cardiovascular devices
A cardiovascular device company has a working development unit, a manufacturing partner and a launch plan. The engineering team can assemble the device, load the software and demonstrate the intended functions. Yet production still calls an engineer to choose a firmware version, interpret an unexpected test result or explain an adjustment that never reached the work instruction.
Those calls reveal a question that a successful development build cannot answer: can the intended production team consistently build, identify and accept the device without recreating the design team's judgments?
That is the practical work of design transfer. For a connected device, the handover spans physical components, software and the methods used to decide whether the resulting combination is acceptable. If those elements do not agree, a company can have a well-documented design and still struggle to release a repeatable product.
Transfer the decisions behind the working unit
During development, an engineer may know that a particular board revision needs a particular firmware release, or that an unusual result came from the test setup. That knowledge can be useful while the design is evolving. It becomes a production dependency when another person cannot distinguish an acceptable device from an unresolved engineering problem.
Zaliance's approach is to examine where judgment still substitutes for a released method. The aim is to make the necessary decisions explicit: which configuration is authorized, how it is assembled and loaded, what evidence supports acceptance, and how an exception is handled. A larger document package does not resolve an ambiguous decision by itself.
For US manufacturers subject to Part 820, the current regulatory framework is the Quality Management System Regulation, effective February 2, 2026. Section 820.10 requires a documented quality management system meeting applicable ISO 13485 requirements and the other applicable provisions of Part 820.[1,2] That obligation should be distinguished from Zaliance's practical recommendations for demonstrating that a particular handover works.
The MDSAP Audit Approach offers a useful official audit perspective: its transfer task examines how the design becomes production specifications and compares significant manufacturing elements with approved design outputs.[3] The operating question is whether the production system preserves what the design established.
A connected console illustrates the gap
Consider a hypothetical cardiovascular monitoring console with a replaceable acquisition module, embedded firmware and a receiving application. The development team has established the supported combination and can demonstrate its operation. Manufacturing receives the module drawing, an assembly instruction and a software installer.
Each item may be correct in isolation. The gap appears if the installer can load more than one released version, but the production record does not establish which version belongs with the installed module. A module acceptance test could pass while leaving that compatibility question unanswered. Nor does a screen displaying plausible information, by itself, establish that the intended combination has been released.
The transfer problem is therefore more specific than “improve the documentation.” Production needs an unambiguous definition of the combination being built and a reliable way to establish that the unit matches it. That could involve controlled version selection, configuration identification and an acceptance method that addresses the relevant interface. The appropriate implementation follows the device's design and risks; the example does not prescribe a universal test sequence.
This distinction matters when planning time and cost. If the combination remains an engineering decision at every build, adding production staff does not remove the bottleneck. The company is scaling its dependence on the people who remember how the development unit was made to work.
Acceptance methods have to support a release decision
A development test and a production acceptance activity can use similar equipment while answering different questions. Development may explore behavior across configurations and conditions. Production needs a controlled basis for deciding whether the unit being released meets its specified acceptance criteria.
For the hypothetical console, a successful test is useful only if its result can be related to the identified unit and configuration. An unexplained pass is weak evidence when the operator cannot establish which software was tested or whether the setup exercised the relevant interface.
This is also why transferring a numerical limit without its method can leave substantial work unfinished. Setup, equipment and interpretation affect what the result means. If an operator needs to improvise a setting or repeat a test until it passes, the team needs to understand that behavior before treating the method as ready for routine use. A retest may be justified, but its justification cannot depend on an undocumented habit.
Automating acceptance moves part of that judgment into software. The embedded firmware and the program running the production test have different roles: one is part of the device; the other helps decide whether the device can be released. FDA's February 2026 computer software assurance guidance recommends a risk-based approach for production and quality management system software. It expressly excludes recommendations for design-and-development verification or validation of device software functions.[4] It is relevant to the test automation, not a basis for reducing verification of the console's firmware.
Suppliers and service expose the same unresolved assumptions
A supplier handoff deserves attention at the point where its output enters the build. In the console example, knowing the module's part number may be insufficient if its revision affects the supported configuration. The manufacturer needs to establish what information accompanies the supplied item and how production uses that information. This is a transfer question about preserving the defined product, rather than a complete supplier qualification program.
Operator competence matters for the same reason. Training can explain a sound method, but it cannot settle an engineering decision that the method leaves open. Observing the intended team perform the work can reveal whether the instructions are executable or whether success still depends on coaching from their author.
Service tests the durability of that handover. If the console's module is replaced later, the service process needs a basis for restoring an appropriate supported configuration and determining whether the device can return to use. Reinstalling the newest available software is not, by itself, evidence that the replacement combination is suitable. The relationship established during transfer has to remain usable after the original build.
Make readiness visible before committing to output
Transfer can develop in stages as the design matures; the MDSAP audit approach explicitly recognizes this.[3] Waiting until the end to discover that production cannot execute an acceptance method leaves less room to change equipment, instructions or the design itself.
Zaliance recommends exercising the intended build, acceptance and relevant service pathways with the people and resources expected to perform them. The purpose is to expose unresolved decisions while they can still be addressed within the development plan. This is an implementation recommendation, not a prescribed FDA trial-batch requirement or proof that every necessary validation is complete.
The useful outcome is a clear account of what the production team can now do, which evidence supports that conclusion and what remains unresolved. That gives leadership a better basis for committing to delivery dates and production capacity. A working device is an essential milestone. Transfer makes its successful manufacture, release and support reproducible beyond the development team.
References
[1] FDA. Quality Management System Regulation (QMSR). Update February 2, 2026. https://www.fda.gov/medical-devices/postmarket-requirements-devices/quality-management-system-regulation-qmsr
[2] 21 CFR 820.10(a), Requirements for a quality management system. Current eCFR text, accessed October 20, 2026. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-820/subpart-A/section-820.10
[3] MDSAP Audit Approach, MDSAP AU P0002.011, revision August 3, 2026. Chapter 5, Task 16, printed p. 94 (PDF p. 94). https://www.mdsap.global/sites/default/files/2026-07/MDSAP%20AU%20P0002.011%20MDSAP%20Audit%20Approach.pdf
[4] FDA. Computer Software Assurance for Production and Quality Management System Software. Issued February 3, 2026. Section III, printed p. 4 (PDF p. 7); Section V, printed p. 5 (PDF p. 8). https://www.fda.gov/media/188844/download