[ OPERATING INTERSECTION ]
Product safety across the lifecycle
The continuity from design assumptions and clinical evidence to labeling, surveillance, and field action.
What this page does not claim
SPEQ synthesis for education. Confirm applicable law, current guidance, standards editions, contractual duties, and organization-specific controls before making a regulated decision.
The seam below, its failure modes and its decision boundaries are SPEQ’s practitioner framing — not a regulatory requirement, and not an assessment of any organization.
OPERATING QUESTION
Does new safety information reach design, benefit-risk, regulatory, and operating decisions?
Capabilities in the same decision
Why this is hard
A hazard analysis and a complaint are two descriptions of the same world, written by people who will never read each other’s documents. Development reasons forward — from a mechanism to a control to an accepted residual risk, in the vocabulary of predicted failure. Surveillance reasons backward — from something a patient or a clinician experienced, coded into a category built for trending and reportability, in the vocabulary of what was observed. Both disciplines can be excellent and the seam still fails, because the design conclusion carries no expiry date and the evidence that would overturn it never arrives in the shape the conclusion was written in. The occurrence estimate that justified accepting a residual risk was made before the product ever met its real population; five years of use holds a far better number, and nothing in the operating model routes it back. For a connected product the asymmetry is sharper still: the risk picture can move while the product itself does not move at all. A component the design embedded is disclosed as exploitable, no change control fires because nothing was changed, and the safety file goes on describing a control that was judged adequate against a threat picture that has since shifted underneath it.
How it fails
Each of these happens with every function doing its own job correctly. That is what makes them seam failures rather than performance problems.
The risk file closes at launch and is never reopened
Once the product is authorized, the risk-management documentation becomes an artifact that gets referenced in submissions rather than a live input to anything. Complaints accumulate, trending reports are produced, and the numbers that justified accepting each residual risk stay frozen at their pre-launch estimates for the life of the product, because no one holds a standing obligation to compare the two.
Complaint coding and hazard language never reconcile
Complaint categories are designed for reportability decisions and trend charts; hazards are described by mechanism. The same underlying failure arrives coded three different ways, so it never accumulates against a single threshold and never crosses the line that would trigger a re-evaluation. Each individual coding decision is defensible, and collectively they make a real signal statistically invisible.
A disclosed vulnerability changes risk without changing the product
Change control is built around a change. When the exposure of a marketed connected product shifts because a third-party component it already contains is newly known to be exploitable, nothing was modified, so nothing triggers. The route by which an external security disclosure becomes an input to a product-safety judgement often does not exist, and the two functions discover the gap during the incident.
Labeling absorbs the finding and design never hears it
Amending instructions for use or a warning is frequently the correct response and is almost always faster than a design change, so it becomes the standing answer. Over years the product accumulates a set of risks controlled by telling the user something, no one is tracking that total, and the weakest tier of control quietly becomes the dominant one without any single decision having chosen it.
What good looks like
The design risk documentation has a named owner after launch, not only during development, and that owner is expected to be wrong occasionally rather than merely custodial. A defined trigger list states which postmarket observations require a documented look back at the design assumptions — and the look-back is recorded even when the answer is that nothing changes, because the recorded negative is the evidence that the question was asked. Complaint categories carry a link back to the hazard they would evidence, so accumulation happens against the design’s own logic rather than against a taxonomy built for a different purpose. Occurrence assumptions used to justify residual risk are compared to observed rates on a defined cadence. Marketed connected products have an explicit path by which an external vulnerability disclosure enters the safety assessment despite no change having been made. And the set of risks currently controlled by instructions rather than by design or protection is visible in one place, so the drift toward the weakest control tier is a thing someone can see.
Who decides what
Development owns the hazard reasoning and, more importantly, owns the assumptions underneath it — the assumed use environment, user, and frequency that make an accepted risk acceptable. The safety function owns detection and the medical judgement about causality and seriousness. Regulatory owns what the authorized labeling and claims permit, and what must be reported to whom and by when. The authority that must be named in advance, because it defaults to nobody, is the one that concludes a postmarket observation does not change the design conclusion. That is a decision, not an absence of one, and if it is never assigned it is made by silence. The second contested authority is whether a security finding on a marketed product is a safety matter: security teams do not usually hold product-safety authority, safety teams do not usually read vulnerability disclosures, and the escalation between them has to exist before it is needed.
Questions practitioners ask
Does every safety signal require the design risk documentation to be reopened?
No, and treating each one as a reopening would exhaust the process that real changes depend on. What is required is that the determination is made by someone with the standing to make it, and that the conclusion is recorded. The failure mode is not the absence of a re-evaluation; it is the absence of the assessment that decided one was not warranted.
Who decides when a labeling change is sufficient rather than a design change?
Regulatory owns what the labeling can say and how the change is filed, but the judgement that instructing the user adequately controls the hazard belongs with the function that owns the risk reasoning. The practical test is cumulative rather than local: any single instruction may be sound, while a product whose accepted risks are mostly held by instructions has drifted somewhere no one chose to go.
Why does cybersecurity sit inside a product-safety intersection at all?
Because for a connected product the safety of the device depends on software behaving as intended, and some of that software was written by someone else. A loss of integrity or availability in a component can present clinically as a device failure. The security disclosure and the safety consequence arrive through entirely separate channels, which is exactly why the seam needs to be named.
Is this the same thing as postmarket surveillance?
No. Surveillance is one pillar of it — the detection layer, and usually the mature one. This intersection is the return path: whether what surveillance learns actually reaches the design assumptions, the benefit-risk position, and the labeled use, or stops at a trend report that satisfies its own procedure and travels no further.
Critical handoffs
- Development defines known risks and controls.
- Clinical and regulatory teams establish benefit-risk and authorized claims.
- Postmarket surveillance detects change and triggers product or field action.
Shared evidence
- Risk-management and design records
- Clinical safety and regulatory decisions
- Signals, complaints, labeling changes, and field actions