1Give the team one model of the product.
A device change can reach requirements, risk controls, software, components, manufacturing instructions and units already in the field. When those relationships live in separate files, the team must reconstruct the scope before it can decide what to do. Seal makes them part of the work: engineering defines the product, operations records what was built, and quality follows the evidence across both.
Consider an illustrative infusion-device requirement, REQ-047, for flow accuracy. Its design output, verification protocol and recorded result need to remain identifiable together. Verification must confirm that design outputs meet design inputs and retain the evidence of that confirmation.¹²
Follow the requirement into its evidence.
Within ±3% across the specified range
- Design output
- DV-103 · Impeller specification
- Verification
- VER-047 · Bench verification
2.1%Reported deviation across the tested range
Open the test points, operating conditions and equipment records to assess coverage of the specified range. The summary belongs to this tested configuration.
An impeller revision brings this requirement, its protocol and the affected device configurations into the change assessment.
The value extends beyond an audit. A proposed component revision can identify which tests and configurations need assessment. A field report can be followed back to the unit’s actual build. Neil can prepare the linked work, and your team can improve the review and manufacturing workflows that handle the next change.
2Build traceability into the records.
A verification protocol in Seal is created against the requirement it tests. The link is a relationship between records, not a cell reference: the protocol identifies the requirement it verifies, and the requirement lists the protocols that verify it. Test results attach to the protocol execution with their data and outcome. Design outputs work the same way: a drawing or specification is linked to the requirements it implements, and its version history keeps the link.
Open requirement 47 and its rationale, source (user need, standard or risk control) and the design reviews that evaluated it are on the same record. Follow it forward to the design output specifying the pump mechanism, the bench protocol and the results with their data. Follow it to risk to see that it controls HAZ-023, incorrect dosing and what residual risk remains, and to the general safety and performance requirement it supports.
When a design changes after certification, the same links show which verification may need repeating, which risk controls are affected and whether the technical documentation needs updating. The design-change assessment starts from those relationships; the team decides what the change requires.
3Carry the design into manufacturing and the field.
Design traceability becomes more valuable when it reaches the device that was built. Model the product definition, approved configuration, component specifications, supplier parts, manufacturing route, tests and released units. Each lot or serialised device should identify the versions and actual inputs used in its manufacture.
Configure the manufacturing traveller around the work: material acceptance, component identity, equipment readiness, assembly steps, measurements, inspection and review. Required checks can act at the point of use. The execution retains actual values and exceptions so a reviewer can distinguish completed work from an approved disposition.
A design change may affect only some configurations, component revisions or software versions. Represent that applicability explicitly. When the team assesses a field issue, it can follow the serial or lot through the as-built configuration, component lots, manufacturing results and relevant design decisions. A current drawing alone cannot explain a unit made under an earlier revision.
| Record | Design connection | Manufacturing or field connection |
|---|---|---|
| Component specification | Design output and requirements it implements | Received supplier lots, acceptance evidence and units that consumed them |
| Test method | Requirement or risk control being verified | Method version, equipment, execution data and reviewed outcome |
| Software configuration | Requirements, interfaces, risks and verification | Released version installed on the affected device configuration |
| Change assessment | Rationale, affected outputs and verification scope | Effective version, implementation evidence and affected lots or serials |
Explore electronic batch records and inventory management.
4Follow supplier changes through the product.
A supplier approval, a component acceptance and a product release answer different questions. Keep the approved supplier scope, quality agreement, specification, received lot and acceptance evidence connected. Record concessions or nonconformances against the material and the manufacturing work they affect.
When a supplier changes a material, manufacturing method or component revision, start the impact assessment from the affected specifications and product configurations. Identify design outputs, risk controls, manufacturing validations and incoming tests that may need review. Preserve the source notice, assessment, decisions and implementation evidence.
The same relationships support containment. The team can identify which stock, work in progress, finished units and distributions used the affected lot, then record the authorised disposition and follow-up. Source data may remain in an ERP or manufacturing system; retain its identifiers and the time of the extract or connection so the scope can be reconciled.
5Manage software and configuration as part of the device.
For a device with software, connect each release to its requirements, architecture or design outputs, interfaces, verification, unresolved anomalies and risk assessment. Record which hardware and accessory configurations are covered. A test result needs the build and environment it evaluated, not just the name of the test.
When an interface, dependency or cybersecurity finding changes the assessment, follow the affected configuration and requirements into verification and the release package. Engineering and quality decide the necessary work and acceptance criteria. Neil can assemble the linked records and identify missing evidence for that review.
Keep released evidence identifiable even as development continues. A later passing test does not silently replace a failed result for an earlier build. Reusable verification procedures can improve across products, while each execution retains the configuration, inputs and evidence specific to the device tested.
6Keep risk management current with the device.
ISO 14971 describes a risk management process: identify hazards, analyse hazardous situations, estimate risk, implement controls and evaluate residual risk. It is often treated as a file prepared during development, approved and then updated only when required. But the hazards identified during development were the best estimate before anyone used the device, and field experience can reveal use errors, failure modes and conditions that were not anticipated.
Seal holds risk as connected records. Each hazard links to its hazardous situations and potential harms, with probability and severity. Risk controls link to the hazards they address and to the verification of their effectiveness. When a complaint suggests a new hazard, the team adds it and reviews what it touches: the requirements that address it, the controls that might mitigate it and where in the design it arises. A design review then uses the current risk picture rather than a copy.
The benefit-risk determination required under EU MDR is maintained the same way. Clinical benefits are documented with evidence, risks are characterised from the current analysis, and when new clinical data or adverse events require an update, the team updates those sources and revises the determination from them.
7Render technical documentation from the records.
Prepare the next package. Preserve the submitted one.
| Source | Retained in PKG-014 | Proposed next basis | Work still required |
|---|---|---|---|
| Device configuration | DEV-014 · v04 | v05 draft | Assess the proposed design and its affected configurations. |
| Risk analysis | RM-023 · v04 | v05 draft | Review the changed controls and the evidence for their effectiveness. |
| Verification | VER-047 · v02 | Revised protocol proposed | Agree coverage, run the required tests and review the results. |
Neil can assemble the revised source set and draft the affected sections. The team reviews the evidence and approves the package; the earlier submission retains its original sources.
Assembling technical documentation often means pulling documents from shared drives, working out which version is current and discovering inconsistencies, such as a clinical evaluation that references an older risk analysis. Development continues while the file is assembled, so the submitted version can already be behind the device.
Seal renders the EU MDR Annex II sections from the underlying records: the device description from the master record, design information from the design history file, GSPR conformity from the mapping between requirements and regulations, risk analysis from the current risk records and clinical evaluation from the CER with its linked literature and post-market data. An FDA 510(k) needs a different structure over the same device description, risk analysis and clinical evidence, so one source serves several submissions without parallel copies. Qualified people remain responsible for reviewing and approving what is submitted.
8Detect post-market signals across every source.
Post-market surveillance under EU MDR is active: the manufacturer gathers and analyses data to identify problems, describes how in the PMS plan and reports the results in the PSUR (or the PMS report for Class I devices).³ The data arrives from many places: complaints through customer service, vigilance reports through regulatory affairs, literature through medical affairs, registry data through clinical teams and PMCF results through R&D. Finding patterns across them depends on manual aggregation that happens infrequently.
Seal brings these sources into one surveillance record. Complaints are entered as structured data (product identifier, event, patient outcome and investigation findings), so trends are queryable without reading every complaint. Statistical methods can run as the data accumulates: when alarm-related complaints exceed their historical baseline, for example, the trend is surfaced for review rather than noticed in a quarterly report.
When a signal is confirmed, the response starts from connected records: the complaint trend, the affected products with lot numbers and distribution records, and the risk analysis that needs updating. FSCA documentation can be prepared from that information. The team assesses the signal and decides the action.
9Use Neil to structure the work and surface gaps.
Describe the device to Neil, Seal’s AI, for example “Class IIb infusion pump with wireless connectivity”. Neil can propose a design-control framework, with requirement categories mapped to EU MDR general safety and performance requirements, a risk analysis structure following ISO 14971 and a technical documentation outline following Annex II. It can suggest hazard categories for the device type and intended use. The team reviews the proposal rather than starting from blank templates, and adds what is specific to the device.
During development, Neil can identify gaps: a requirement without linked verification, a risk control without effectiveness evidence or a GSPR without supporting documentation. Those gaps are then addressed in design reviews rather than before an audit. People approve the content and the decisions.
10Build a reusable product platform with AI.
Device families often share assemblies, software components, test methods and manufacturing operations. Represent those common elements in a controlled library, with the configurations and intended uses to which they apply. A new product can start from established work while recording its own requirements and differences.
Reuse needs an applicability decision. A verification method may be reusable even when an earlier result is not evidence for the new device. A risk control may need different effectiveness evidence for a changed population, environment or use scenario. Record that reasoning so a copied document does not become an unexamined claim of coverage.
Neil can help build and revise the operating workflows around these records. Ask it to prepare a design-change assessment, configure a review path that checks requirement coverage, or assemble manufacturing evidence for a specified configuration. The team can turn repeated review findings into better checks and reusable work methods.
Persistent memory gives the agent context from previous work and decisions; versioned skills provide a repeatable method. A design-review skill might require the intended use, affected requirements, configuration, risk assessment and verification scope before it prepares the package. Review and refine that method using known cases, including missing evidence and changed applicability.
Keep customer designs, supplier intellectual property, restricted test data and identifiable complaint information within their authorised scope. A shared skill can encode the method for checking trace coverage without carrying another customer’s requirement text or results. Memories, attachments and examples need the same review for permitted reuse as a document prepared by a person.
11Keep the quality system capable of change.
A useful quality system should become better as the organisation learns. A recurring nonconformance may justify a new inspection step; a design review may reveal that interface requirements need a different structure; a field investigation may identify a missing follow-up state. Configure those improvements as assessed changes to the workflows people run.
For each revision, identify its intended use, affected records, access rules, calculations, integrations and outputs. Verify the normal path and meaningful exceptions, then record review, approval and effective use. Earlier executions retain the instructions and evidence under which the work was performed.
The US Quality Management System Regulation became effective on 2 February 2026 and incorporates ISO 13485:2016 by reference. Map the configured quality system to the requirements that apply to your device and operation; the presence of a workflow does not itself demonstrate conformity.⁴
12Evaluate the complete chain on a real change.
Choose a device and a proposed change with consequences beyond one document. Import the affected requirements and configuration, link the available design and verification evidence, and follow the change into manufacturing and post-market records. Give engineering, quality and operations the access needed to review their part of the decision.
Exercise missing verification, an obsolete test version, a restricted supplier record, an affected serial range and an unresolved anomaly. Check that the reviewer can locate the source, distinguish planned work from completed evidence and identify who must decide. Assess how much effort is required to configure the next product or change using the same foundation.
References
- 1ISO 13485:2016, Medical devices — Quality management systems — Requirements for regulatory purposes.
- 221 CFR Part 820, Quality Management System Regulation: incorporates ISO 13485:2016 by reference, effective 2 February 2026. eCFR
- 3Regulation (EU) 2017/745, Medical Device Regulation. EUR-Lex
- 4FDA, Quality Management System Regulation (QMSR), updated 2 February 2026. FDA
AQuestions and answers
Does this replace our existing eQMS?
Seal covers the core QMS workflows (document control, training, CAPA, complaints and audits) alongside device-specific work such as design controls, risk management and technical documentation. Whether it replaces an existing eQMS or connects to it is a scoping decision for your system landscape and validation plan.
How do you handle EU MDR and FDA requirements?
The core quality system is shared, and market-specific requirements sit on top of it. EU MDR technical documentation, an FDA 510(k) and Health Canada submissions use different structures over the same device description, risk analysis and clinical evidence. One source serves several submissions without parallel copies.
What about legacy devices with existing documentation?
Existing documentation can be imported and linked to the device records, so history is connected rather than recreated. New work is structured from then on. Legacy devices usually move over as they undergo design changes.
How does UDI work for device families?
The UDI-DI identifies the model and the UDI-PI the production unit or lot. Device families share a Basic UDI-DI, with separate UDI-DIs for configurations. Production records link each unit to its UDI-PI.
Can we manage combination products?
Yes. A combination product can define its device and drug constituents with their own requirements and the interactions between them. Documentation for each regulatory framework is prepared from those records and reviewed by your team.
What about Notified Body submissions?
Technical documentation can be exported in a form suitable for Notified Body review and submitted through the Notified Body’s preferred channel. Later updates are prepared the same way from the current records.
How do you handle design changes after certification?
The change is assessed against the linked requirements and risk analysis. The links show which verification may need repeating, which risk controls are affected and whether the technical documentation needs updating. Your team decides the scope of the change from that assessment.
Does this support software as a medical device (SaMD)?
Yes. Software requirements, such as the IEC 62304 lifecycle, cybersecurity documentation and algorithm validation, fit into the same design-control structure. Software versions trace through the same links as hardware.
How do you detect post-market signals?
Complaints are recorded as structured data, so statistical methods can run as the data accumulates. When a trend exceeds its historical baseline, it is surfaced for review rather than noticed in a quarterly report. The team assesses the signal and decides the action.
What about IVDR for diagnostic devices?
IVDR requirements can use the same platform. Performance evaluation takes the place of clinical evaluation, and the classification rules differ. The underlying structure of design controls, risk management and technical documentation serves both MDR and IVDR devices.