I work in a 200-person, Class II med device shop where a single design change can spawn 30–60 document reviews across engineering, verification, RA, and suppliers. ISO 13485 §8.5.6 and FDA 21 CFR 820.70 make that work necessary, but the manual scramble to find every affected requirement, risk control, test case, and SOP is where teams burn time and introduce errors.
We built a lightweight automation pattern that turns a change record into an exact, auditable list of affected artifacts. The goal: one source of truth (the traceability graph), reproducible impact queries, and automated review task creation that includes diffs and links back to the change record.
Below is a practical walk-through you can adapt to your QMS / PLM / test-management stack.
Assumptions and constraints (our setup)
- We're a Class II shop; change records must document impact and approval (ISO 13485 §8.5.6 / 21 CFR 820.70).
- Our artifacts live in a mix: requirements tool (spreadsheet + IDs), design outputs (CAD files + IDs), test cases in a test tool, risk items in a risk register, and controlled docs in an eQMS (we use a commercial eQMS with API/export).
- The eQMS exposes document metadata and trace links via CSV/JSON export or an API. If your tool doesn’t, export to CSV and keep IDs consistent.
- Controlled assistance: every automated decision is captured in the change record; humans still sign off.
High-level pattern
- Identify the changed artifact(s) — the source nodes (unique IDs).
- Export the traceability graph (requirements ↔ design outputs ↔ risks ↔ tests ↔ docs) as structured data.
- Build a directed graph in memory and run an impact traversal from the source nodes.
- Apply rules to mark which artifact types require review (e.g., any downstream requirement, any upstream risk control, any linked test case).
- Auto-create review tasks in your task system / eQMS with contextual payload (diffs, links, change rationale).
- Record reviewer decisions back into the change record for audit.
Step-by-step practical walk-through
1) Mark the change source
- When you raise a Design Change record, associate the one or more artifact IDs (e.g., REQ-123, DWG-456).
- This simple metadata field is the seed for the whole analysis.
2) Export the graph
- From each system/export: produce rows like (source_id, target_id, relation_type, artifact_type).
- Example rows:
- REQ-123 -> DWG-456 (satisfies)
- DWG-456 -> TC-789 (verified-by)
- DWG-456 -> RISK-12 (implements-control)
- SOP-22 -> DWG-456 (references)
- Keep artifact types and version/status columns (e.g., Released/Controlled vs Draft).
3) Build and traverse (pseudo-Python)
- Load the edges into a graph library (networkx works fine for prototypes).
- Run a breadth-first traversal from each changed node, collecting visited nodes and the path that led there.
- Simple rule example: collect all nodes within N hops or all nodes of certain types encountered.
Pseudo:
import networkx as nx
G = nx.DiGraph()
# populate G with edges from CSV
impacted = set()
for src in change_seeds:
for node in nx.bfs_tree(G, src):
impacted.add(node)
- In practice add filters: stop traversal at "supplier boundary" nodes, or only follow certain relation types.
4) Apply impact rules
- Not every touched node needs a doc review. Use business rules:
- Tests: always review if linked to changed design or requirement.
- Risk controls: always trigger risk reassessment/CAPA-driven risk assessment if the change touches the control.
- Controlled docs (SOPs, IFUs): review if they reference impacted requirements or outputs.
- Flag each impacted node with "review_required", "risk_reassess", or "info_only".
5) Create review tasks automatically
- For nodes marked review_required:
- Create a review record in your eQMS or task queue.
- Attach: link to the change record, the diff (if available), the path showing why it was impacted, and a suggested reviewer group.
- If your QMS supports webhooks/APIs, post the tasks programmatically; otherwise generate a CSV import for the QMS batch-creation.
6) Capture decisions and close the loop
- When reviewers approve/reject, have their decisions recorded back into the change record automatically (or via a single “import review results” step).
- Store the traversal output (graph snapshot) with the change record so an auditor can reproduce the impact list.
Practical tips we learned the hard way
- Use stable, human-readable IDs. If IDs change, your trace graph becomes useless.
- Keep the trace direction consistent. Decide whether edges point "satisfies" forward or backward and stick to it.
- Include relation metadata (why two artifacts are linked). That helps rule-based filtering later.
- Version traces. A change should point to the graph snapshot at the time the change was evaluated.
- Start with a small, high-value scope: requirements → tests → design outputs. Add SOPs and supplier docs next.
On evidence and audits
- Save the graph snapshot (CSV/JSON) and the traversal results with the change record. Auditors want to see: what you considered, how you considered it, and who approved it.
- Tie the traversal to ISO 13485 §8.5.6 language in the change record: "impact analysis performed; linked artifacts and reviewer decisions attached."
Where automation should not replace judgment
- Automation finds links; it doesn’t define acceptability. A reviewer still interprets whether a linked test needs new acceptance criteria or just re-execution.
- For CAPA-driven risk assessment and high-risk controls, require explicit human sign-off (controlled assistance).
I built this flow incrementally: exports → local graph → scripted traversal → API-driven task creation. Took a few sprints, but it turned the two-day review scramble into a reproducible 30–90 minute process for most changes.
How have you wired impact mapping into your QMS/dev toolchain — any tricks for handling supplier-owned artifacts or binary diffs (CAD, firmware blobs) in the traversal?
