Structured regulatory assessment for EU MDR 2017/745 medical device technical files
Upload your documentation, receive a block by block assessment with finding level verdicts, regulatory traceability, and cross document consistency verification in hours.
End-to-end processing sequence
Three principles govern the module: the system structures the assessment while the reviewer owns every decision; partial coverage is treated as zero coverage; and every output carries its regulatory reference. The audit follows this sequence:
Device name, class, classification rule, intended purpose, and MD codes are entered. This profile defines the reference frame for the entire audit — including which conditional assessment blocks are activated.
Technical documentation is uploaded under 14 pre-defined structural categories (TD01–TD14). Missing mandatory categories are flagged as structural gaps. Documents are parsed and indexed through a dual-path pipeline.
Questions are processed sequentially through each evaluation block. Each question evaluation includes the verdicts and assessments of all preceding questions in context — the model sees and builds on its previous answers.
Each completed block produces structured, device-specific outputs that are carried forward into downstream evaluations — ensuring later blocks build on verified upstream results, not isolated assessments.
Each block ends with its own internal consistency check — the final summary question synthesises all preceding verdicts and actively detects contradictions among the assessments within the block.
After all blocks are complete, a final cross-block scan compares all question verdicts and assessments across the entire audit — detecting contradictions and inconsistencies that only become visible once every block has been processed.
The system produces a populated question list, a findings report with MDR references and source locations, and an audit summary report with proposed scope definition.
Each identified finding can be carried into a structured resolution workflow — recording corrective actions, linked evidence, and affected sections against the original finding and its regulatory reference.
Audit Overview screen showing device profile, identifiers, and activated assessment blocks
13 evaluation blocks across the full regulatory scope
Core blocks run on every audit. Conditional blocks activate automatically based on the verified device profile.
Document control, identification, scope
Risk management, usability engineering
Biocompatibility, physical/chemical testing
Clinical data, equivalence, PMCF
IFU, labelling, implant card
PMS plan, PSUR, vigilance
Design verification, process validation
Activated when device is supplied sterile
Activated when device contains software
CMR, endocrine disruptors, medicinal substances
Absorbable or resorbable material content
Devices within scope of 2006/42/EC
Devices with clinical measurement function
Conditional blocks are activated based on the device profile declared by the user at audit initiation.
What makes this an audit, not a checklist
The mechanisms that bring the assessment closer to a real conformity review.
Adequacy, Not Existence
The system doesn't check whether a section exists. It evaluates whether the content addresses all required endpoints for this device type, contact duration, and nature of body contact.
Verified Device Profile
The TDAR block extracts a 20+ field device profile directly from the uploaded documents. Downstream blocks measure consistency against what the files actually state — not what the user declared.
Session Memory
Critical outputs from upstream blocks — the residual risk list from RAU, claimed performance from CER — are carried forward as structured context into downstream evaluations.
Plausibility Concerns
The model can flag regulatory-knowledge-based concerns even when document evidence alone doesn't support a formal Finding. The reviewer can convert any plausibility concern into a Finding.
Reviewer Authority at Every Step
Every system output remains draft until the reviewer confirms. Answers can be edited, findings added or removed, verdicts changed — all before the block is locked.
Cumulative Context
Each question is evaluated with full visibility of all preceding verdicts and assessments. The model sees and builds on its previous answers — coherent, non-contradictory progression.
Additional mechanisms include a 4-layer N/A determination model, cross-document consistency checks, and question-level re-run capability. The underlying model is constrained to retrieved document content — it cannot reference external knowledge or generate claims beyond what the evidence base contains. Every output is verified against source location, and remains draft until the reviewer confirms.
RAU block showing conforming questions with evidence-based evaluation and reviewer approval.
What the simulation produces
Three structured deliverables at the end of every completed audit.
Every question receives a verdict — Conforming, Finding, N/A with reasoning, Requires Human Assessment, or Technical Failure. The complete list serves as the detailed audit record.
A structured cover document with scope definition, documents reviewed, finding counts, and technical notes. Factual fields only — no system-generated narrative.
Each finding includes a description, the regulatory reference it's measured against, and the source document location. Structured for direct use — no additional interpretation needed.
Beyond detection: structured resolution
The same engine is used to evaluate how findings are closed. Each identified non-conformity can be carried into a structured resolution workflow — recording the corrective action, the linked evidence, and the affected sections against the original finding and its regulatory reference.
Audit Summary Report showing device information, audit metadata, and assessment overview.
"The system structures and accelerates the pre-assessment — so that when the reviewer applies final judgment, the material has already been systematically interrogated."
Designed from a regulatory assessment perspective — not a software product team.
See it on your own technical file
Leave your details and we'll reach out to discuss how ReGentra applies to your technical documentation.