ERP for Medical Device Manufacturers: ISO 13485, EU MDR 2017/745, UDI and GAMP 5 Validation

A generic ERP manages orders, invoices, and inventory. In the medical device industry, those functions cover only a fraction of what is actually required. The real question is not “which ERP to choose?” but rather “which ERP can demonstrate — during an audit by a notified body — that every implant, every diagnostic device, every surgical consumable delivered is traceable from raw material to patient, that its Technical File is current, and that every system configuration change has been subject to documented validation?”

Regulation (EU) 2017/745, which entered full application on 26 May 2021 for Class III and implantable devices (OJ L 117, 5.5.2017, EUR-Lex), fundamentally raised the regulatory bar in Europe: strengthened technical documentation requirements, mandatory UDI, EUDAMED as the central registry, and structured post-market clinical follow-up. For manufacturers, these obligations are not boxes to tick — they reshape the architecture of the entire information system, and above all, the ERP.

Why Medical Device Manufacturers Need a Specialised ERP

Medical Devices vs. Pharmaceuticals: Two Distinct Regulatory Frameworks

The pharmaceutical and medical device industries are often grouped together under the “life sciences” label. Their regulatory frameworks are nonetheless distinct, and their information system requirements diverge on several key points.

In pharma, the cornerstone of compliance is GMP (Good Manufacturing Practice), with the FDA’s 21 CFR Part 11 for the US market and Annex 11 of EU GMP for Europe. In medical devices, the product compliance pivot is EU MDR 2017/745, and the quality system standard is ISO 13485:2016. Both texts have direct implications for what an ERP must do natively.

Another key distinction: whereas a pharmaceutical product is a mass-produced item uniform within a batch, a medical device can be a custom-manufactured implant produced individually (Class III) or a consumable manufactured in the millions (Class I). The ERP must accommodate both extremes while maintaining flawless traceability.

Two sub-frameworks must also be distinguished within medical devices: EU MDR 2017/745 covers traditional medical devices (implants, surgical instruments, diagnostic imaging equipment), while Regulation (EU) 2017/746 (IVDR) covers in vitro diagnostic devices (laboratory tests, reagents). This guide focuses on EU MDR; IVD manufacturers face similar requirements with different transition timelines.

The Five EU MDR 2017/745 Obligations That Directly Impact the ERP

Regulation (EU) 2017/745 imposes five obligations that directly affect the functional scope of the ERP:

1. Unique Device Identification (UDI): every device placed on the EU market must carry a unique identifier (Article 27) and its data must be registered in EUDAMED.
2. Technical Documentation (TD): the manufacturer must compile and maintain complete technical documentation (Annex II) covering the device description, design, manufacturing, and clinical evaluation.
3. Quality Management System (QMS): the manufacturer must implement a documented QMS (Article 10(9)) covering the entire device lifecycle.
4. Post-Market Surveillance (PMS): systematic collection and analysis of post-market data, with Periodic Safety Update Reports (PSUR) and technical documentation updates.
5. Traceability of Implantable Devices: healthcare institutions implanting Class III devices must retain UDI data in the patient record (Article 27(7)).

ISO 13485: The Medtech-Specific Quality Management Standard

ISO 13485:2016 is the international reference standard for quality management systems in the medical device industry (ISO, ISO 13485:2016). It superseded the 2003 version and aligns with the requirements of EU MDR and FDA 21 CFR Part 820 (Quality System Regulation).

ISO 13485 certification is not strictly mandatory under EU MDR, but it constitutes a presumption of conformity with the quality requirements of Article 10. In practice, all manufacturers operating under EU MDR work with a notified body certified to ISO 17065, which verifies ISO 13485 compliance as a prerequisite to CE marking.

The sections of the standard with the greatest ERP impact are:

• Section 4.2: Documentation requirements — the ERP or its integrated DMS must manage document tiers (quality policy, procedures, records)
• Section 7.3: Design and development — requires documented change control, which the ERP must reflect in its Change Control module
• Section 7.5: Production and service provision — raw material traceability, measurement equipment management, non-conformance control
• Section 8.5.2: Corrective and preventive actions (CAPA) — documented CAPA workflow with records maintained in the ERP

UDI (Unique Device Identification): Mandatory Traceability in the ERP

UDI Structure: DI (Device Identifier) and PI (Production Identifier)

The UDI consists of two complementary elements, both of which must be managed in the ERP:

• DI (Device Identifier): identifies the product category. It is fixed for a given model from a given manufacturer, assigned by an accredited issuing organisation (GS1, HIBCC, ICCBBA) and registered in EUDAMED. The DI is equivalent to the GTIN in GS1 nomenclature.
• PI (Production Identifier): identifies a specific production instance. Depending on the device type, it contains the lot number (LOT), serial number (SN), manufacturing date, and expiry date. The PI is generated dynamically at the time of manufacture.

In the ERP, the DI is typically managed as an attribute of the item master, while the PI is generated and recorded at the production or packaging stage. The complete UDI (DI + PI) must appear on the device label in human-readable form and as a 2D Datamatrix barcode (or a linear barcode for certain Class I devices).

EUDAMED: The EU Database and How the ERP Feeds the Registry

EUDAMED (European Database on Medical Devices) is the centralised platform of the European Commission that aggregates data on medical devices placed on the EU market (EUDAMED, European Commission). Manufacturers must register their DIs in EUDAMED before placing devices on the market.

The obligation to register UDI/DI data in EUDAMED follows the EU MDR implementation schedule as defined in Article 123(3)(f) of the Regulation:

• Class III and implantable devices: since 26 May 2021
• Class IIa and IIb: since 26 May 2023
• Class I: since 26 May 2025

In practice, the ERP must be capable of exporting product data in the format expected by EUDAMED (import via REST API or structured CSV file). This interface is not native in all ERPs: it frequently requires bespoke development or a data transformation middleware.

Lot-to-Patient Traceability: Why the ERP Must Track Every Component

For implantable devices, EU MDR Article 27(7) requires that the UDI identifier appear in the patient’s medical record. This obligation creates a traceability chain that the ERP must support end-to-end: from raw material receipt through to the receiving hospital.

In concrete terms, a medtech ERP must be able to answer two critical questions within minutes:

• Forward traceability: which patients received devices containing lot X of component recalled by my supplier?
• Backward traceability: what raw materials were used to manufacture implant Y delivered to hospital Z on 15 March?

This bidirectional traceability is not merely a regulatory requirement — it is a critical operational capability in any Field Safety Corrective Action (FSCA).

UDI Configuration in Leading Industrial ERP Platforms

Industrial ERP platforms positioned in life sciences have integrated UDI management into their dedicated modules:

• SAP S/4HANA: UDI management is covered by the SAP Extended Warehouse Management (EWM) module combined with SAP Batch Management. SAP provides pre-validated configuration templates through its Industry Cloud for Life Sciences.
• Oracle Cloud ERP: UDI integration runs through Oracle Product Information Management (PIM) for the DI and Oracle Manufacturing Cloud for PI generation at production.
• Infor LN: lot and serial traceability is native to Infor LN Manufacturing, which offers a Quality Management module certifiable to ISO 13485.

Technical Documentation and Document Management in the ERP

Mandatory Content of the EU MDR Technical Documentation

Annex II of EU MDR 2017/745 defines the content of the Technical Documentation. It encompasses: the device description and specification, design and manufacturing information, general safety and performance requirements (GSPR), benefit-risk analysis, device verification and validation, and clinical evaluation.

This documentation must be maintained and updated throughout the device lifecycle. Any significant change to design, materials, or manufacturing processes requires documented revision and a regulatory impact assessment.

Version and Revision Control in the ERP

The ERP must manage a strict document control system: each document carries a version number, approval date, controlled distribution list, and revision history. Obsolete documents must be withdrawn from operational access while remaining archived.

The minimum retention period is set out in Article 10(8) of EU MDR: at least the lifetime of the device, with a minimum of 10 years after the last manufactured device was placed on the market (15 years for implantable devices). For implants with indefinite lifespans, this can represent archiving constraints spanning 20 to 30 years.

ERP Alone or ERP + PLM?

For manufacturers of complex devices (active implants, imaging equipment, surgical robots), managing design and Technical Documentation often exceeds the capabilities of a standard ERP. A PLM (Product Lifecycle Management) system — Siemens Teamcenter, PTC Windchill, or Dassault Systèmes ENOVIA — handles the design side, while the ERP manages manufacturing, inventory, and sales.

The interface between PLM and ERP is critical: a validated bill-of-materials change in the PLM must automatically propagate to the ERP without manual re-entry. This bidirectional integration must be included in the ERP project scope from the outset, with a GAMP 5 validation of the interface itself.

For SMEs manufacturing less complex devices (Class I or IIa), an ERP with an integrated DMS (Document Management System) may be sufficient, provided that module supports versioning, document access control, and long-term archiving.

Change Control: Workflow in the ERP

Change Control is the formal process for evaluating, approving, and documenting any modification affecting the product, process, or quality system. In an EU MDR environment, this process must follow a sequence tracked in the ERP:

1. Formal Change Request with description of the proposed modification
2. Assessment by a quality manager for regulatory impact (is re-certification required?)
3. Approval by relevant functions (R&D, production, quality, regulatory affairs)
4. Implementation according to a documented verification and validation plan
5. Closure with evidence of effectiveness and Technical Documentation update

The ERP must support this workflow with records that are non-modifiable after closure and a full audit trail of each approval step.

Non-Conformance and Product Recall Management

CAPA (Corrective and Preventive Action) in the ERP: Standard Workflow

The CAPA system is the operational core of ISO 13485:2016 (Section 8.5.2). Every incident, product non-conformance, or customer complaint must trigger a documented root cause analysis and a corrective and preventive action plan, tracked in the ERP.

A standard CAPA workflow in a medtech ERP includes:

• Non-conformance registration (source: production, customer, internal audit)
• Root cause analysis (Ishikawa, 5 Whys, or other documented method)
• Definition of corrective and preventive actions with owners and deadlines
• Implementation and monitoring
• Effectiveness verification with measurable criteria
• Closure with immutable record

Medical Device Vigilance: Reporting Serious Incidents to Competent Authorities

EU MDR Article 87 requires manufacturers to report to the national competent authority (MHRA in the UK, BfArM in Germany, ANSM in France) any serious incident or Field Safety Corrective Action (FSCA) within defined timescales: 15 days for most serious incidents, 2 days for incidents that immediately endanger a patient’s life.

The ERP must enable rapid identification of the incident’s scope: which lots are affected, what quantities have been placed on the market, which distributors and hospitals have received deliveries. This rapid-response capability is directly tied to the quality of lot-to-customer traceability in the system.

Lot Recall and Field Safety Corrective Action (FSCA)

An FSCA is the corrective action initiated by the manufacturer on devices already on the market to reduce the risk of injury or death. The ERP must enable rapid location of all devices from a given lot and automatically generate recipient lists by customer, hospital, or distributor.

The speed of this response is not only a regulatory obligation — it is an ethical and commercial imperative. A manufacturer unable to locate its products within hours of detecting an incident risks regulatory enforcement action and lasting reputational damage with hospital procurement teams.

GAMP 5 Computer System Validation: What to Validate and How

The Five GAMP 5 Categories and Where an ERP Sits

GAMP 5 (Good Automated Manufacturing Practice, 5th edition, ISPE) is the validation framework for computerised systems used in GxP-regulated environments and, by extension, in ISO 13485 environments. It classifies software into five categories according to complexity and risk (ISPE, GAMP 5 Guide):

• Category 1: Infrastructure (operating systems, virtual machines) — lightweight validation on the infrastructure
• Category 3: Non-configured software with fixed functionality
• Category 4: Configured software — this is where the majority of standard ERPs deployed with business-specific parameters sit. Validation focuses on configuration, not source code.
• Category 5: Custom software or bespoke modules — specifically developed source code, requiring exhaustive validation

A standard ERP such as SAP S/4HANA or Oracle Cloud deployed with business parameters is typically Category 4. Connector modules or bespoke developments (EUDAMED interface, UDI generator, custom forms) may be Category 5 and require more rigorous validation covering the source code.

Computerised System Validation (CSV) Plan: Required Documents

Validating an ERP in an ISO 13485 and GAMP 5 environment rests on a structured documentation corpus:

1. Validation Plan: validation scope, risk-benefit approach, resources, schedule
2. User Requirements Specification (URS): functional and non-functional user requirements
3. Functional Specification (FS): how the system meets the URS
4. Design Specification (DS): technical architecture, configuration
5. Traceability Matrix: URS/FS/Test traceability matrix
6. IQ/OQ/PQ Test Scripts: detailed test protocols
7. Validation Summary Report: test summary, non-conformances, and formal acceptance

IQ/OQ/PQ Tests: Installation, Operational, and Performance Qualification

Validation testing follows three levels:

• IQ (Installation Qualification): verifies that the system is installed correctly (software version, infrastructure parameters, configuration data integrity)
• OQ (Operational Qualification): verifies that the system functions in accordance with its specifications under defined conditions of use (testing by critical function: lot management, traceability, audit trail, access management, CAPA)
• PQ (Performance Qualification): verifies that the system operates continuously and reproducibly under real-world conditions of use

These tests must be executed in a qualification environment separate from production, using test data representative of real use cases.

Post-Validation Change Management: Patches, ERP Upgrades and Re-Validation

Every change made to a validated ERP must go through an impact assessment process before being deployed to production:

1. Impact Assessment: does the change affect a validated critical function?
2. If yes: re-test the affected functions (partial re-validation), update documentation
3. QA approval before production deployment

A security patch applied without prior impact assessment can invalidate the validated state of the system. IT teams at medical device manufacturers must embed this principle in their patch management and IT change management processes.

Audit Trail: Configuration in the ERP (EU MDR and FDA 21 CFR Part 11)

The audit trail is a central requirement of EU MDR (Article 10(9)(d)) and of FDA 21 CFR Part 11 for export markets. It must record, in a non-modifiable and timestamped manner, every creation, modification, or deletion of critical records in the system.

A compliant audit trail in the ERP must capture: the operator’s identity, the date and time of the action (server-side timestamp, non-modifiable), the values before and after modification, and the justification for the modification where required. It must be read-accessible to auditors without being modifiable by users, including system administrators.

Comparison: The Best-Positioned ERPs for Medtech Manufacturers

SAP S/4HANA + Life Sciences: Strengths and Positioning

SAP S/4HANA is the reference ERP for large and internationally operating medtech groups. Its Life Sciences module natively integrates lot management, audit trail, CAPA, and Change Control. SAP offers Industry Cloud for Life Sciences configuration templates, reducing initial validation effort for standard functions.

The main watch point: total cost of ownership (TCO) is high and implementing a quality-grade SAP S/4HANA project for a medtech manufacturer typically takes 18 to 36 months. SAP is suited to manufacturers whose operations have reached a level of complexity that justifies this investment (multi-site, multi-country, diversified device portfolio).

Oracle Cloud ERP: Well-Suited to International Mid-Market Manufacturers

Oracle Cloud ERP, coupled with Oracle Health Sciences modules, delivers a cloud-native platform with traceability, incident management, and regulatory reporting capabilities. Migration to Oracle Cloud provides isolated test environments, which simplifies OQ/PQ qualification and post-validation update management.

Oracle is particularly well-suited to manufacturers operating simultaneously in the United States and Europe, subject to both FDA 21 CFR Part 820 (Quality System Regulation) and EU MDR.

Infor LN / CloudSuite Industrial: Regulated Manufacturing Specialist

Infor LN is an ERP built for complex manufacturing, notably in aerospace (AS9100), defence, and medical sectors. Its Quality Management module is certifiable to ISO 13485 and natively manages CAPA workflows, Change Control, and bidirectional traceability by lot and serial number.

Infor LN is particularly well-suited to mid-sized medtech manufacturers producing complex devices with long routing operations.

SYSPRO: SME Alternative for Smaller Medtech Manufacturers

SYSPRO is a manufacturing ERP whose medtech version integrates quality management, traceability, and audit trail modules compatible with ISO 13485. Its SME positioning and more accessible licensing model make it a credible alternative to the major SAP and Oracle platforms for manufacturers of Class I and IIa devices.

SYSPRO has published GAMP 5 validation guides and offers documentary support for IQ/OQ/PQ, which reduces the validation workload for quality teams.

Odoo: With Important Limitations for Regulated Medtech

Odoo Community and Odoo Enterprise are sometimes considered by medtech start-ups for their low entry cost and flexibility. Two important caveats apply:

• Limited native audit trail: in the standard version, Odoo does not generate a 21 CFR Part 11-compliant audit trail without significant additional development
• GAMP 5 validation: Odoo’s open-source nature and frequent release cadence make validation and post-validation change management more complex and more costly than with a controlled-release ERP

Odoo may be suitable for manufacturers of lightly regulated Class I devices, but is not recommended for any device requiring full GAMP 5 validation or a rigorous audit trail.

Comparison Table: Key Functionality for Medtech

Criterion	SAP S/4HANA	Oracle Cloud	Infor LN	SYSPRO	Odoo
Native ISO 13485	Yes	Yes	Yes	Yes	Partial
Native UDI management	Yes	Yes	Partial	Partial	No
Integrated CAPA	Yes	Yes	Yes	Yes	Third-party module
Compliant audit trail	Yes	Yes	Yes	Yes	Dev required
Documented GAMP 5 support	Yes	Yes	Yes	Yes	No
Target profile	Large/International	International mid-market	Manufacturing mid-market	SME	Class I start-up

Checklist: 12 ERP Requirements for a Medical Device Manufacturer

1. Bidirectional lot and serial number traceability down to the purchased component level
2. Native UDI management (DI managed on the item master, PI generated at production)
3. EUDAMED interface or export (REST API or CSV file) for DI registration
4. CAPA module with configurable workflow, non-modifiable records, and documented closure
5. Integrated Change Control within the quality system, with Impact Assessment and QA approval
6. Document Management System integrated or connected (versioning, access control, long-term archiving)
7. Comprehensive audit trail on critical data (QMS, production, release) compliant with EU MDR and 21 CFR Part 11
8. Role-based access control (RBAC) with login and access-attempt logging
9. Lot recall module enabling rapid identification of all recipients of a given lot
10. Separate environments (production, qualification, development) for post-validation change management
11. Validation documentation provided or supported by the vendor (IQ/OQ/PQ templates, traceability matrix)
12. Supplier qualification in the ERP, with supplier audit records and certificates of analysis

---

To explore regulatory requirements in adjacent industries, see our healthcare and pharma ERP guide and our chemistry and life sciences ERP comparison. For IT leaders managing both compliance and cybersecurity on their industrial ERP, our article ERP and cybersecurity covers best practices for protecting the management system.