When A Medical Device Becomes A System: Bridging The Gaps Between Subsystems
By Prabagar Sankar, Senior Engineer, Intuitive Surgical
Every subsystem passes its verification tests. The mechanical assembly meets its specifications, the electronics perform within their limits, and the software executes its functions correctly. Yet, during integrated testing, the medical system does not respond as intended when operation is interrupted and restarted. The subsystem test reports are complete. The system-level question remains open.
This challenge is relevant to complex medical systems whose intended functions depend on coordinated behavior across hardware, software, accessories, and user interfaces. Consider a fictional interruption-and-restart scenario: One subsystem resets its operating state, another retains a previous command, and the user interface displays a status that does not reflect the complete system. Each behavior follows a local specification, while their combination reveals an unresolved assumption.
From my perspective as a biomedical engineer, the engineering challenge is maintaining the connection between the intended medical function and the contributions of each subsystem. Teams need to define what must happen across subsystem boundaries, assign responsibility for that behavior, and establish evidence that the complete system performs as intended.
Start With The Complete Use Sequence
Development teams need to divide complex work among engineering disciplines. Mechanical, electrical, software, and other specialists require clear responsibilities and manageable specifications. The difficulty arises when that division becomes the only way the program describes the medical system.
Start with the complete use sequence: preparation, setup, activation, normal operation, interruption, recovery, and completion. Identify which subsystems participate at each stage and what conditions permit the system to proceed.
In the illustrative scenario, restarting requires more than restoring power or clearing a software message. The system may need to confirm that physical conditions remain acceptable, previous commands no longer remain active, and the user has completed the required recovery actions.
A familiar pain point is that teams define readiness differently. One subsystem considers itself ready after completing an internal check. Another assumes readiness means the complete system can resume operation. Both definitions can survive document reviews until integration exposes the disagreement.
Create a shared description of operating states and transitions. Define what each state means, which conditions permit entry, and which events prevent or interrupt operation. Include the user’s role.
Review that description across engineering, usability, risk management, and verification. It gives teams a common account of the intended behavior before they translate it into separate designs.
Give Interfaces Ownership And Meaning
An interface can have two contributing teams and no clear owner for the relationship between them. One team implements an output, another implements an input, and each assumes the other will address abnormal conditions.
Assign an owner to coordinate each significant interface. That person should maintain agreed expectations, resolve differences, and bring affected teams together when the interface changes.
Define more than the connection itself. Depending on the design, an interface specification may need to address mechanical loads, tolerances, energy transfer, timing, information meaning, compatibility, and operating states.
For electronic interfaces, the FDA’s guidance on interoperable medical devices recommends considering information-exchange characteristics, associated risks, and appropriate verification and validation.1 Its scope is electronic interoperability. Teams should separately evaluate the physical and other interactions relevant to their system.
In the restart scenario, the important interface question is what a “ready” message means. Does it confirm that a subsystem has completed its internal checks? Does it also confirm that previous commands have been cleared? How long does that confirmation remain valid?
Agree on these meanings explicitly. Specify what happens when information is missing, inconsistent, or no longer applicable.
I consider interface ownership useful when it leads to resolved engineering decisions. Documenting an uncertainty in several places creates visibility, but the team still needs an agreed answer.
Allocate Requirements Without Losing The Outcome
Requirement allocation helps teams translate system needs into engineering work. It also creates a potential blind spot: completed subsystem requirements can make an unresolved system requirement appear finished.
Suppose the medical system must enter a defined safe state within a specified interval after an interruption. Detection, communication, software processing, and physical response may each contribute to that interval.
Assigning the full allowable response time to every subsystem would not establish that the combined response meets the system requirement. Allocate a timing budget, account for relevant variation, and document the assumptions behind it.
Some actions may occur in parallel; others depend on completion of an earlier action. The allocation should reflect the actual sequence rather than simply dividing a number among teams.
Apply similar reasoning to other distributed characteristics, such as positioning accuracy or output performance. Explain how individual contributions combine and where the complete characteristic will be evaluated.
Keep the parent requirement visible during reviews. Ask whether the allocated requirements collectively support the intended outcome and whether the evidence establishes that outcome at the appropriate level.
Subsystem test completion should inform this decision to close the parent requirement. It should not replace the engineering reasoning needed to close the system requirement.
Follow Risk Across Subsystem Boundaries
Risk analysis can become fragmented when teams organize it around individual assemblies or disciplines. Local analyses provide valuable information, but a hazardous sequence may extend across several subsystems.
For the interruption-and-restart scenario, examine the sequence from the initiating event through recovery. What state does each subsystem enter? Which commands remain active? What does the user see? What conditions permit operation to resume?
Select credible sequences based on the design, intended use, and reasonably foreseeable misuse. Avoid treating every imaginable combination as equally relevant.
Identify the hazardous situation and potential harm, then determine where the design can prevent or interrupt the sequence. If a control requires several subsystems to act together, define their coordinated responsibilities.
For example, one subsystem may detect an interruption, another may inhibit an active function, and the user interface may communicate the required recovery action. Each contribution needs an implementable requirement. The complete response needs an accountable owner and supporting evidence.
Examine shared dependencies as well. Protective functions may rely on the same power source, communication path, or software service. Teams should assess how those relationships affect the intended protection.
The ownership gap is often the practical problem. Every team can complete its assigned control while no one evaluates whether the combined response addresses the hazardous sequence.
Integrate Before Assumptions Become Expensive
Late integration findings can reopen requirements, design outputs, risk assessments, and test plans simultaneously. By that point, several teams may have built around an assumption that nobody evaluated directly.
Plan integration while developing the architecture. Identify uncertain interactions whose consequences could affect safety or substantial downstream work.
The NASA Systems Engineering Handbook describes integration planning through assembly sequencing, interface compatibility, and checks as elements come together.2 These general principles offer a useful reference, although medical-device teams must tailor their activities to their products and quality processes.
In the illustrative scenario, early integration could evaluate how subsystems respond to interruption and whether their recovery states remain consistent. The purpose is to answer a focused question before the recovery sequence becomes embedded in separate designs.
Use prototypes, representative assemblies, or simulators where appropriate. Document what they represent and what they omit. A simulator may reproduce messages accurately while omitting physical response delays that matter to the complete behavior.
Keep exploratory results distinct from formal verification evidence. Early work can expose defects and refine requirements. Formal verification requires configurations, methods, and records appropriate to the conclusion.
I would prioritize early integration by the consequence of an incorrect assumption. An uncertain interaction that could force several designs to change deserves attention before a well-understood connection with limited downstream effects.
Verify Transitions And Recovery
Normal-operation tests can leave important system behavior unexplored. Transitions deserve explicit attention because different subsystems may change state under different conditions or at different times.
Build the integrated verification strategy from system requirements, interface expectations, and risk analysis. Identify relevant configurations and operating conditions, with a rationale for their selection.
For interruption and restart, evaluate the behavior before, during, and after the event. Introduce the interruption at justified points in the operating sequence. Observe whether the system reaches the required state and whether recovery follows the specified conditions.
Write acceptance criteria before execution. “The system restarts correctly” leaves interpretation to the tester. Specify the permitted behavior, response time, operating state, and user indication, where applicable.
Coordinate observations across subsystems. A software status message alone may not establish that a physical function has stopped. Likewise, a physical response may occur correctly while the interface gives the user misleading information.
Distinguish verification from validation. Verification evaluates whether the design meets specified requirements. Validation evaluates whether the device meets user needs and intended uses. Technical tests of a recovery sequence do not, by themselves, establish that users can understand and perform it appropriately. The evidence strategy should address both questions without treating them as interchangeable.
Assess Changes Through System Consequences
A change can appear small within one team’s scope while affecting assumptions elsewhere. A software revision may change the recovery sequence. An electrical revision may alter startup timing. A mechanical change may affect how quickly an assembly reaches a required state. Each could influence the interruption response without changing the team’s primary performance specification.
Start the impact assessment with the behavior affected by the change. Follow its relationships to interface assumptions, allocated requirements, risk controls, design outputs, and evidence.
Traceability helps when the links represent meaningful engineering relationships. A test report can remain correctly linked while no longer representing the updated configuration.
Ask whether existing evidence still supports the original conclusion. Document what remains applicable, which activities need repetition, and which new conditions require evaluation.
Bring affected disciplines into the assessment. Separate local approvals can leave the integrated effect unresolved. The program needs a shared conclusion about the complete system.
Five Questions Before Closing An Interaction
A focused interaction review can bring this work together without creating a separate documentation exercise. Use existing records to connect the intended behavior, participating subsystems, assumptions, requirements, risk controls, and evidence.
Before closing a significant interaction, ask:
- Do the contributing teams agree on the interface? Confirm meanings, limits, operating states, and abnormal behavior.
- Do the allocated requirements support the system outcome? Examine combined contributions, relevant variation, and margin.
- Have we evaluated transitions and shared dependencies? Address credible interruptions, recovery conditions, and dependencies affecting protection.
- Does the evidence represent the behavior and configuration? Check tested conditions and the limits of the conclusions.
- Does every unresolved issue have an owner and disposition? Make the next action and closure decision explicit.
Scale the depth of review to risk and complexity. A straightforward interaction may need a brief assessment. One that affects a protective function may require detailed analysis and integrated testing.
These questions help biomedical engineers preserve the connection between the intended medical function and the work produced by separate disciplines. They also challenge a misleading signal of progress: a collection of completed subsystem reports.
A system requirement remains open until evidence supports the system-level conclusion. When acceptance depends on integrated behavior, the team must establish that behavior. Every subsystem can pass while the system still has work to do.
References:
- U.S. Food and Drug Administration. Design Considerations and Pre-market Submission Recommendations for Interoperable Medical Devices. Guidance for Industry and Food and Drug Administration Staff. Sept. 6, 2017.
- National Aeronautics and Space Administration. NASA Systems Engineering Handbook, Revision 2. Section 5.2, Product Integration. NASA/SP-2016-6105 Rev2. 2016.
About The Author:
Prabagar Sankar is a biomedical engineer and senior engineer at Intuitive Surgical, working in new product development and quality. His experience spans biomedical research, wearable sensing, hearing technology, and surgical and interventional medical devices. His work includes requirements engineering, design controls, risk management, verification and validation, and traceability. He holds a master’s degree in biomedical engineering from Drexel University.