Generate CE MDR-compliant Safety Data Report and/or Clinical Safety Parameters from FDA TPLC database. Supports any FDA product code with 5-year lookback. Now supports INTENDED USE text as primary input — auto-detects the correct product code via FDA classification/TPLC/510(k) search, then generates the report. Trigger: "TPLC报告", "FDA TPLC", "安全数据报告", "Safety Data Report", "Clinical Safety Parameters", "product code + safety", or when user provides an FDA product code and asks for post-market safety analysis, OR when user provides intended use/indication text and asks for FDA product code + TPLC report. (agent_created: true)
Generate CE MDR-compliant Safety Data Report and/or Clinical Safety Parameters from FDA TPLC database. Supports any FDA product code with 5-year lookback. Now supports INTENDED USE text as primary input — auto-detects the correct product code via FDA classification/TPLC/510(k) search, then generates the report. Trigger: "TPLC报告", "FDA TPLC", "安全数据报告", "Safety Data Report", "Clinical Safety Parameters", "product code + safety", or when user provides an FDA product code and asks for post-market safety analysis, OR when user provides intended use/indication text and asks for FDA product code + TPLC report. (agent_created: true)
Generate CE MDR 2017/745-compliant post-market safety documentation from FDA TPLC (Total Product Life Cycle) database data, supporting CER (Clinical Evaluation Report) and PSUR (Periodic Safety Update Report) authoring.
Trigger Conditions
User provides intended use / indication text (e.g., "continuous non-invasive monitoring of regional cerebral oxygen saturation...") → NEW: auto-detect product code
User provides an FDA product code (e.g., MHX, FGB, MUD) and requests safety data analysis
User provides a TPLC URL
User says "TPLC报告", "安全数据报告", "Safety Data Report", "Clinical Safety Parameters"
Input Parameters
Three input modes (in order of capability):
Intended Use Text (RECOMMENDED — primary upgrade)
User provides a device description / intended use string → skill extracts key terms, searches FDA databases, identifies product code(s), presents ranked candidates, generates report after confirmation.
Product Code
User provides product code directly → skip to Phase 1.
Both
User provides intended use + product code → validate consistency, then proceed.
Required parameters:
Intended Use / Indication Text OR Product Code (at least one)
Device Name (if known; otherwise auto-detect)
Optional parameters:
Data range: Default = last 5 years (current year − 5 to current year)
Output documents: Ask (SDR only / CSP only / both)
Manufacturer of interest: Specific manufacturer to highlight
Project reference: Project ID or client name for file naming
Workflow
Phase 0: Intended Use → Product Code Auto-Detection
Triggered automatically when user provides intended use text without a product code.
Step 0.1 — Extract Key Terms
Parse the intended use text and identify:
Found N potential product code(s) for the device:
1. [CODE] — [Device Name] — 21 CFR [XXX.XXXX] — [Panel] — Confidence: [HIGH/MEDIUM/LOW]
Rationale: [why this matches the intended use]
2. ...
3. [Directly proceed] — Use the top-ranked code and generate reports automatically
If user confirms one → proceed to Phase 1 with that code
If user selects "proceed automatically" → use top-ranked, add note in report
If user rejects all → ask for manual product code input
Extract ALL information: product code, device name, regulation number, panel,
classification, all MDR report counts (total reports, total events),
all recall records (firm name, date, classification, reason),
all device problem categories with counts,
all patient problem categories with counts,
all premarket submission information,
and any temporal/yearly breakdowns available.
Get every detail on the page.
Fetch Safety Statistics (if separate URL available):
Extract: top device problems with MDR counts, top patient problems with counts,
event types, outcome distributions (death/injury/malfunction),
and any trending data or additional safety statistics.
Search for Recall Details (supplement TPLC recall summary):
WebSearch: FDA recall {product code} {device name} {year} × top 3 recall firms
Note on recall sub-pages: TPLC recall/MDR sub-pages may return 404. If so, use the main TPLC page summary and supplement with WebSearch for each firm/date combination. Document this limitation in Section 8 (Data Gaps).
Phase 2: Data Analysis
Aggregate and categorize all MDR data by:
Patient outcome severity (death, serious injury, minor injury, malfunction only)
Device problem categories (alarm, software, communication, power, skin, etc.)
Temporal trends (yearly MDR report counts and recall counts)
Manufacturer distribution
Identify Safety Signals (typically 5-8):
Group related device problem categories into logical safety domains
Rank by frequency and severity
Link each signal to specific TPLC subsection data
Extract Clinical Safety Parameters:
Each safety signal → 1-2 measurable endpoints
Acceptance criteria from applicable IEC/ISO standards (use CURRENT versions including amendments)
Literature citations must be verified (PMID/DOI required)
Phase 3: Citation Verification
CRITICAL: Every reference must be verified before inclusion.
Standards: Verify current edition and amendment status via WebSearch
Format: IEC 60601-1:2005+AMD2:2020 (always include latest AMD)
If PMID cannot be verified, DO NOT include the reference
Numerical thresholds: Distinguish between:
Standard requirement: Explicit numerical value in a standard clause → cite standard + clause number
Industry benchmark: Consensus value from literature → cite source + "industry benchmark" or "clinical consensus"
Manufacturer internal: Do NOT present as standard requirement
Phase 4: Document Generation
Use the docx skill (call Skill with command: "docx") to generate Word documents.
Document A: Safety Data Report
Format specifications (matching step_06 reference):
Font: Times New Roman (Latin) + SimSun (East Asian)
Section heading: 24pt Bold, color #000000, line spacing 240
Sub-section heading: 22pt Bold, color #000000, line spacing 240
Body text: 21pt, indent 400 twips, justified, line spacing 240
Table headers: #F0F0F0 fill, 21pt Bold
Table borders: Single, 4pt, color #000000
Table layout: autofit
Page: A4 (11906 x 16838 twips), margins 1440 twips all sides
Chapter structure (numbering starts from user's section number):
Safety Data Overview — 5 numbered paragraphs covering: data scope, product code description, time period, manufacturer coverage, recall summary
Safety Database Search Results — Summary table: Database | Region | Search Strategy | Records Retrieved | Status
Same base format as Safety Data Report
Table 5-4 headers: #F0F0F0 fill (same as SDR tables)
Columns: No. | Safety objective | TPLC safety signal (data source) | Measurable endpoints | Acceptance criterion
Content rules:
Safety endpoints include BOTH:
(a) Direct safety failures: alarm failure, skin injury, device malfunction, communication failure
(b) Measurement accuracy failures that can cause patient harm — e.g., inaccurate rSO₂/SpO₂ readings that lead to missed hypoxic events or delayed intervention. When measurement inaccuracy is a top MDR complaint category, its accuracy validation IS a safety endpoint (linked to TPLC Signal: "Inaccurate readings" — largest MDR category). Acceptance criterion: ISO 80601-2-85:2021 Clause 201.12.1.101 (Ar₂ ≤ 10.0% for cerebral oximetry) and ISO 80601-2-61:2017 Clause 201.12.1.101 (Ar₂ ≤ 3.0% for pulse oximetry).
(c) Diagnostic specificity / therapeutic sensitivity — exclude (these are efficacy parameters, not safety)
Each endpoint MUST trace back to a specific TPLC safety signal with section reference and exact MDR count
Acceptance criteria from: (a) IEC/ISO standards with current edition, (b) verified literature with PMID, (c) clearly labeled industry benchmarks
FDA TPLC data covers US market only; EU vigilance data (EUDAMED) should be supplemented separately
MDR reports are reporter-submitted and do not establish causation
No denominator/exposure data available for incidence rate calculation
Partial current year data (note in report)
Product code is aggregate — cannot isolate specific models without manufacturer filtering
TPLC sub-pages may return 404: Recall detail and MDR detail sub-pages (tplcRecall.cfm, tplcMDR.cfm) frequently return 404 errors. Use the main TPLC page summary and supplement with WebSearch for recall details by firm/year. Document this in Section 8 (Data Gaps).
Auto-detection confidence: Phase 0 product code identification is probabilistic. Low-confidence matches (< 2 independent sources) must be confirmed with the user before proceeding. Add a "confidence level" note in the report header.
Multi-function devices: When a device spans multiple product codes (e.g., a patient monitor with ECG + SpO₂ + NIRS), generate one primary report for the main product code and note secondary codes. Full coverage of all codes may require multiple reports.
Coverage Note: This table covers common codes. For any device not listed, use Phase 0 intended use search. Update this table as new codes are discovered.
Intended Use → Product Code Mapping Knowledge
Use this as a quick-reference to skip Phase 0.2–0.3 for well-known device types:
"patient monitor" (general, multiparameter, no arrhythmia)
MSX
MEDIUM
"laser surgical" / "laser ablation"
KIP
HIGH
"electrosurgical" / "RF ablation" / "bipolar"
HIG
HIGH
"catheter introducer" / "vascular introducer"
NLE
HIGH
Any combination above
Highest-match code (primary) + second code (if multi-function device)
MEDIUM
Multi-function device rule: If the intended use covers multiple monitoring functions (e.g., rSO₂ + SpO₂ + ECG), identify the PRIMARY product code (highest clinical risk / primary intended function) as the main report target, and note the secondary code(s) in the SDR Section 1 overview. Both codes may need separate TPLC queries for completeness.
Prompting the Agent
When user triggers this skill, follow this decision tree:
User Input?
├── Has intended use text (no product code)
│ → Execute Phase 0 (auto-detect), then Phase 1–5
│ → Present ranked candidates → ask for confirmation
│ → On confirmation → proceed
│ → On "proceed automatically" → use top match
│
├── Has product code only
│ → Confirm device name via WebSearch if needed
│ → Execute Phase 1–5 directly
│
├── Has both (intended use + product code)
│ → Validate consistency (does the code match the intended use?)
│ → If yes → Phase 1–5 directly
│ → If no → flag discrepancy, ask user to confirm correct code
│
└── Neither provided
→ Ask user: "Please provide the device intended use description or FDA product code"
Phase execution summary:
Phase 0: Intended Use → Product Code (NEW — skip if code already provided)
