Skip to main content

​
Summary

SOP Product Registration and Certification establishes the systematic processes for taking your medical device from completed development through regulatory approval and market entry. This Standard Operating Procedure (SOP) covers technical file creation, conformity assessment procedures, Unique Device Identification (UDI) registration, declaration of conformity creation, and product release protocols for both European Union (EU) and United States (US) markets.

​
Why is SOP Product Registration and Certification important?

Product registration and certification represents the critical gateway between your completed medical device and commercial market access. Without proper certification, your device cannot be legally marketed or sold in regulated jurisdictions like the EU or US. This SOP ensures you systematically navigate complex regulatory requirements while avoiding costly delays, rejections, or legal compliance issues. The certification process validates that your device meets essential safety and performance requirements, protecting both patients and healthcare providers. Proper documentation and process adherence prevents market withdrawal due to regulatory non-compliance, safeguards against liability issues, and establishes the foundation for post-market surveillance activities. For software medical devices particularly, this SOP addresses unique challenges around UDI management, version control, and ongoing compliance obligations.

​
Regulatory Context

  • FDA
  • MDR
Under 21 CFR Part 820 (Quality System Regulation) and relevant FDA guidance:
  • Medical devices must receive Premarket Approval (PMA) or 510(k) clearance before commercialization
  • Unique Device Identification (UDI) registration in Global Unique Device Identification Database (GUDID) is mandatory
  • Manufacturers must establish device establishment registration and device listing (21 CFR Part 807)
  • Declaration of Conformity must document compliance with applicable FDA regulations
Special attention required for:
  • Software as Medical Device (SaMD) classification and submission requirements
  • Cybersecurity documentation per FDA Guidance (2022)
  • Quality System Regulation compliance (21 CFR Part 820)
  • Post-market reporting obligations under Medical Device Reporting (MDR) regulation

​
Guide

​
Creating Technical Documentation

Compile comprehensive technical documentation that serves as the foundation for your certification process. Your technical file must demonstrate compliance with essential requirements and include device specifications, design documentation, risk management files, verification and validation reports, clinical evaluation data, and post-market surveillance plans. Structure your technical file systematically following regulatory annexes. Include device descriptions with all variants and accessories, information supplied to users (Instructions for Use, labels, packaging), complete design and manufacturing information, general safety and performance requirements documentation, benefit-risk analysis results, verification and validation evidence, pre-clinical and clinical data where applicable, and post-market surveillance frameworks. Maintain document traceability throughout your technical file. Reference supporting documents clearly and ensure all information is current and accurately reflects your final device design. Your technical file can contain full documentation or executive summaries with appropriate cross-references to detailed supporting documents.

​
EU Certification Pathway

Confirm your device classification before initiating conformity assessment procedures. Verify your MDR/IVDR classification according to Annex VIII rules and determine the appropriate MDR/IVDR codes following current guidance. Your classification determines your conformity assessment route and whether Notified Body involvement is required. For Class I devices (non-sterile, non-measuring, non-reusable surgical), you can self-certify once technical documentation is complete. Draft and sign your EU Declaration of Conformity confirming compliance with all applicable MDR requirements. No Notified Body assessment is required for these devices. For higher-class devices, select and engage an appropriate Notified Body. Research Notified Bodies designated for your device’s MDR/IVDR codes, evaluate their capacity, timelines, and costs, then initiate formal engagement. Provide comprehensive technical documentation and coordinate throughout the conformity assessment process. Address any non-conformities systematically with supporting evidence and corrective actions. Prepare your EU Declaration of Conformity following Annex IV requirements. Include manufacturer identification and Single Registration Number (SRN), basic UDI-DI information, complete product identification and traceability data, device risk classification, conformity statements, applicable harmonized standards references, Notified Body details where applicable, and authorized signatory information.

​
US Certification Pathway

Determine your FDA submission pathway based on device classification and predicate device availability. Class I devices may qualify for exemptions, Class II devices typically require 510(k) clearance, and Class III devices need Premarket Approval (PMA). Consider pre-submission meetings with FDA to confirm regulatory strategy and submission requirements. Prepare comprehensive submission documentation including device description and intended use, substantial equivalence comparison for 510(k) submissions, performance testing data, software documentation for software-containing devices, labeling including Instructions for Use, risk analysis documentation, and quality system compliance evidence. Create US Declaration of Conformity following FDA requirements. Document manufacturer information, product identification and traceability, risk classification, FDA regulation compliance statements, and authorized signatory details. Ensure alignment with your FDA submission content and approved labeling.

​
UDI Creation and Registration

Generate UDI components systematically using designated issuing entities (GS1, HIBCC, ICCBBA, or IFA). Create Basic UDI-DI from your full UDI-DI using issuing entity calculators. Assign UDI-PI reflecting software version or production date following issuing entity guidance. Register UDI information in appropriate databases. For EU market, register in Eudamed once fully functional (use national systems during transition period). For US market, register in FDA’s Global Unique Device Identification Database (GUDID) before commercialization. Establish UDI change management procedures. New UDI-DI required for changes affecting device identification or traceability including name changes, new features, interoperability modifications, user interface changes, new operating systems, programming language updates, algorithm modifications, and architecture changes. New UDI-PI required for version updates, bug fixes, patches, and cosmetic user interface changes.

​
Product Release Procedures

Complete final release verification through systematic checklist review. For software medical devices, verify software release checklist completion, all documentation updates reflecting final software version, UDI-PI assignment matching release version, and change documentation for any modifications since previous release. For hardware-containing devices, complete hardware release checklist verification, manufacturing validation documentation, design transfer confirmation, and supplier qualification verification. Authorize final product release only after confirming technical file completeness, declaration of conformity approval, UDI registration completion, regulatory submission acceptance or approval, and all quality management system requirements fulfillment.

​
Example

Scenario: You develop a mobile application for diabetes management that connects to a glucose meter via Bluetooth. The software analyzes glucose trends and provides recommendations to users. You’re preparing for EU MDR certification as a Class IIa medical device and US FDA 510(k) clearance.

​
Technical File Creation

You compile technical documentation including your software development plan, system and software requirements, software architecture documentation, risk management file with cybersecurity analysis, usability evaluation report, clinical evaluation report demonstrating safety and performance, and post-market surveillance plan.

​
EU Certification Process

Since your device is Class IIa, you research Notified Bodies designated for software medical devices under MDR codes M0104 (medical device software) and select one based on capacity and expertise. You submit technical documentation and undergo conformity assessment including QMS certification and technical file review. After addressing minor observations about your cybersecurity documentation, you receive your CE certificate.

​
UDI Registration

You purchase a GS1 company prefix and generate UDI-DI for your device family. Your Basic UDI-DI becomes the primary identifier for your device across all versions. You assign UDI-PI based on software version (e.g., “1.2.3”) and register both in Eudamed and GUDID databases.

​
US FDA Process

You submit a 510(k) comparing your device to an FDA-cleared diabetes management app predicate. Your submission includes software documentation, cybersecurity analysis, usability testing results, and clinical validation data. FDA issues clearance after standard review cycle.

​
Final Release

You complete software release checklist verifying all documentation accuracy, approve updated Instructions for Use in English and required local languages, finalize EU Declaration of Conformity with CE marking authorization, update device labeling with UDI and regulatory statements, and authorize commercial release following final management review.

​
Q&A

Technical documentation encompasses all documents supporting your device’s safety and performance. A technical file is the compiled collection of this documentation organized according to regulatory requirements. The technical file can contain complete documents or summaries with references to detailed supporting documentation stored separately.
Class I devices (non-sterile, non-measuring, non-reusable surgical) can self-certify without Notified Body involvement. All other device classes (Class Is, Im, Ir, IIa, IIb, III for MDR; Class A sterile, B, C, D for IVDR) require Notified Body conformity assessment before placing devices on the EU market.
New UDI-DI is required for changes affecting device identification or traceability: name changes, new features, interoperability modifications, significant user interface changes, new operating systems, programming languages, algorithms, or architecture changes. New UDI-PI is sufficient for bug fixes, patches, minor UI updates, and version increments without functional changes.
Classification changes may require different conformity assessment procedures, additional Notified Body involvement, or modified submission pathways. Document the classification change rationale, update technical documentation accordingly, and consult with your Notified Body or regulatory authority about required procedural modifications.
You can pursue parallel certification pathways with staggered market releases. Ensure UDI registration covers all intended markets, prepare market-specific labeling and Instructions for Use, maintain separate release documentation for each jurisdiction, and implement appropriate post-market surveillance for released markets while completing certification for others.
For GUDID: Obtain FDA establishment registration, create FURLS account, prepare device information including DI/PI and FDA product codes, submit via web interface or HL7 SPL format, and validate submission accuracy. For Eudamed: Obtain SRN registration, access Eudamed portal when fully functional, prepare device information with Basic UDI-DI, submit device registration, and maintain current information throughout device lifecycle.
Document software lifecycle processes following IEC 62304, provide verification and validation evidence demonstrating requirements compliance, include cybersecurity validation per relevant guidance, document usability validation results, maintain software bill of materials (SOUP list), and provide evidence of software quality management system implementation throughout development.
Provide complete technical file per Annex II/III requirements, quality management system documentation, device classification justification, risk management documentation, clinical evaluation or performance evaluation data, post-market surveillance plan, declaration of conformity draft, and any additional information specific to your Notified Body’s review procedures.
⌘I