The hazard created at the interface

A device surface may be selected for grip while a reprocessing method is developed against a different material or geometry assumption. Either decision can appear acceptable alone; their interface may introduce a contamination or cleaning risk that neither analysis represents.

The risk model must connect intended use, design, manufacturing, usability, cleaning, sterilization, software, cybersecurity, labeling, service, and disposal rather than collecting isolated spreadsheets from each discipline.

The risk analysis you filed with your submission reflects what you knew at the time. It was thorough. Your team spent months on it. The problem is that it's frozen. A document that captured your assumptions on the day you signed it.

Since then, complaints have arrived about issues that weren't in the file. Post-market surveillance has revealed hazards at frequencies different from your estimates. Your design has been modified through multiple change orders. But the risk file sits in a document management system, disconnected from all of it.

Most organizations update the risk file periodically. Maybe annually, maybe during design changes. In between updates, the file and reality diverge. A complaint about an unanticipated hazard gets investigated by the post-market team. The risk management team doesn't see it unless someone remembers to forward it. By the time the annual review happens, the connection between the complaint and the risk analysis has gone cold.

Seal connects the risk file to production and post-production information. Complaints and events can be assessed against existing hazardous situations and harms; unexpected patterns can identify a gap; and observed frequencies can challenge estimates. Qualified reviewers decide whether the evidence changes the risk evaluation.

The risk file stops being a document you update and becomes a living model that evolves with your product.

"What is the probability of harm?" Different reviewers can give different answers when the population, exposure, sequence, and category definitions are unclear. What does remote mean for this device, use environment, and period? A colored cell can appear rigorous while hiding incompatible assumptions.

This is the core problem with spreadsheet-based risk management. The tool doesn't enforce consistency. Two teams evaluating the same hazard can reach different conclusions because their probability definitions are vague. Severity scales that say "serious injury" without defining the threshold invite interpretation. The matrix produces a green cell, everyone moves on, and nobody questions the assumptions.

Seal defines probability and severity criteria per product type. When an analyst selects P3, they see the specific definition and must cite the basis. Clinical data, complaint history, literature, or engineering analysis. The same hazard evaluated by different teams reaches the same conclusion because the criteria constrain the answer, not the analyst's judgment.

This matters during audits and submissions. When a notified body or FDA reviewer asks "how did you determine this probability?", the answer is a documented rationale tied to defined criteria. Not "the team discussed it and agreed."

The device overheats during extended use. Engineering's proposed control: a warning label. "Do not use for more than 30 minutes continuously." Users will ignore it. They'll use it for 45 minutes because they're almost done. The label absolves the company on paper while the patient gets burned.

ISO 14971 is explicit about control hierarchy: inherent safety first, then protective measures, then information for safety. If you can design out the overheating. Automatic shutoff at a safe threshold. A warning label isn't an acceptable primary control. It's what you add after you've exhausted design and protective options.

Seal enforces this hierarchy structurally. When an analyst proposes a warning label as a control, the system asks: was a design control considered? If yes, why was it rejected? The rationale is documented. If no design control was considered, the analyst must explain why. And that explanation is visible to reviewers.

This doesn't prevent teams from using warning labels when appropriate. It prevents them from defaulting to the easiest control without considering alternatives. The risk file shows not just what controls you chose, but what you considered and rejected. When a regulator asks "why didn't you design this out?", the answer is already documented.

Risk management in isolation is an academic exercise. It becomes powerful when it connects to the systems that generate evidence about whether your risk estimates were right.

In Seal, the risk file connects to complaints, CAPAs, design controls, and post-market surveillance. Because they're all on the same platform. A complaint about a new hazard triggers a risk file update. A CAPA that modifies a risk control triggers re-evaluation of the affected risk. A design change triggers impact assessment against the risk analysis.

These connections aren't manual forwarding between departments. They're structural links in the platform. The design engineer who changes a component sees the hazards associated with it. The quality engineer reviewing a complaint sees the pre-market risk estimate for that hazard. The regulatory team preparing a periodic safety update has current occurrence data, not data they assembled from five different sources.

This is what a living risk file actually means. Not a document that someone updates periodically, but a model that reflects current knowledge because it's connected to the systems generating that knowledge.

Product or process scope, lifecycle stages, responsibilities, review authorities, activities, criteria, verification, production and post-production sources, periodic review, deliverables, methods, records, and change triggers define the plan.

Criteria are established for the relevant context. The software does not invent universal acceptability thresholds.

Users, patients, indications, environments, workflows, interfaces, operating principle, duration, contact, training, maintenance, reprocessing, transport, installation, service, disposal, and reasonably foreseeable misuse form the use model.

Hazards are assessed against realistic sequences and exposures rather than generic product labels.

Hazard source, initiating event, sequence or combination of events, exposure, hazardous situation, affected person or asset, harm, severity, probability elements, detectability where methodologically appropriate, and supporting evidence form the risk scenario.

Keeping these concepts separate prevents a failure mode, cause, hazard, and harm from being collapsed into one ambiguous row.

Preliminary hazard analysis, use-related analysis, design FMEA, process FMEA, fault tree, HACCP, security threat analysis, contamination-control assessment, and other tools can contribute evidence.

They retain their method-specific fields while linking to shared functions, hazards, scenarios, harms, controls, requirements, and residual-risk decisions.

Severity and probability category, quantitative estimate where supportable, exposure or use denominator, time horizon, data source, uncertainty, assumptions, rationale, reviewer, criterion version, and evaluation outcome remain attached.

Post-production data can be compared with the original estimate without pretending spontaneous reports automatically supply incidence.

Inherent safety by design, protective measures, process or manufacturing controls, detection, and information for safety are considered according to the applicable framework. Selected and rejected options retain feasibility, new risks, implementation, rationale, owner, and approval.

A warning can remain appropriate for residual risk, but the record shows whether stronger options were considered.

Risk-control requirement, design or process output, implementation evidence, verification method, protocol, acceptance criteria, sample and environment, result, deviation, conclusion, approver, and effective version remain linked.

Implemented is not synonymous with effective. The evidence must show the control achieves the intended risk reduction and does not introduce unacceptable new risk.

Each scenario retains the post-control estimate and acceptability decision. Overall residual risk considers the product or process as a whole, interactions among residual risks, aggregate exposure, uncertainty, benefit, user information, production evidence, and planned monitoring.

Where required, benefit-risk analysis states the benefits, populations, evidence, residual risks, uncertainty, alternatives, rationale, approvers, and communication.

Nonconformances, deviations, complaints, adverse events, service, returns, trends, CAPAs, supplier issues, process monitoring, literature, regulatory communication, security information, and field actions can become risk evidence.

The review records applicability, case or event mapping, denominator limits, observed pattern, comparison, conclusion, action, and whether the risk file changes.

Design, material, supplier, software, cybersecurity, process, equipment, method, packaging, sterilization, labeling, use environment, service, regulation, complaint trend, or field action can affect scenarios, estimates, controls, verification, benefit-risk, and submissions.

The impact assessment identifies which decisions must be revisited before implementation.

ISO 14971 provides the medical-device lifecycle risk framework; ICH Q9 quality risk management supports pharmaceutical quality decisions. They can use different terminology, methods, criteria, deliverables, and regulatory contexts.

Seal shares governance, evidence, actions, review, audit trail, and change linkage while preserving the configured method appropriate to each process.

For every unacceptable or controlled risk, Seal can show the use context, scenario, evidence, criteria, estimate, considered options, selected controls, implementation, verification, residual and overall decisions, real-world monitoring, changes, and accountable approvals.

That is more useful than a current PDF because it explains not only the conclusion, but how the conclusion evolved.