ERP for Medical Technology — software for MDR-compliant medical-device manufacturers
Medical technology — Medizintechnik — in DACH operates under the EU Medical Device Regulation 2017/745 (MDR), with full UDI obligations, batch genealogy down to the implantable component, an audit-ready QMS under ISO 13485 and validated systems under GAMP 5. An ERP for medical technology has to support all of that natively: a validated environment with a documented change-control regime, UDI generation, complete batch genealogy across multi-stage production, a design history file in PLM and an integration architecture that delivers regulatory submissions to BfArM, FDA and notified bodies on demand.
Requirements
The defining requirement is operating in a validated environment under GAMP 5. Every change to the ERP — configuration, custom code, master-data structures, integrations — runs through a documented change-control workflow with impact assessment, qualification testing (IQ, OQ, PQ) and approval. UDI obligations under MDR require the manufacturer to assign Basic UDI-DI and UDI-DI identifiers, register devices in EUDAMED and place UDI carriers on the label, packaging and (for reusable devices) the device itself. Batch genealogy must trace forward from raw material through every production step to the finished serialised device, and backward from any field complaint or vigilance report. The design history file (DHF), held primarily in PLM (Siemens Teamcenter, PTC Windchill, Aras Innovator, MasterControl), connects design intent, risk analysis (ISO 14971), verification, validation and post-market surveillance to the product master in the ERP. Regulatory documentation has to be ready for unannounced audits from notified bodies (TÜV Süd, BSI, DEKRA), the BfArM, the FDA and equivalent authorities in export markets.
Mandatory functions
Mandatory features start with a validated environment: documented IQ/OQ/PQ, change-control workflow, electronic-records and electronic-signatures compliance per FDA 21 CFR Part 11 and EU Annex 11. UDI generation, assignment and lifecycle management must be native, including the link to EUDAMED and to GS1, HIBCC or ICCBBA issuing-agency formats. Batch genealogy works through multi-stage production, sterilisation lots, packaging and serialisation, with sub-second trace queries in both directions. eQMS integration (MasterControl, Veeva Vault QMS, Sparta Systems TrackWise, ConSense IMS) connects deviations, CAPAs, complaints and change controls to the ERP transaction layer. Supplier-quality controls cover approved-vendor lists and certificate-of-conformance handling. Sales orders integrate with hospital purchasing flows and GMDN coding. DATEV interface, GoBD-compliant archive and IFRS / HGB dual-reporting close out the financial side.
Vendor landscape
The DACH medical-technology vertical has a tight set of established options. SAP S/4HANA for Life Sciences with the Pharma / MedTech industry add-ons is the de-facto upper-Mid-Market and large-enterprise choice, particularly where the company already runs a Teamcenter or Veeva-style PLM. Infor M3 with the MedTech accelerator (Industrios is the historical name) is a strong mid-market option. IFS Cloud appears at companies where service and field-installed-base management is as critical as production. abas ERP and proAlpha cover smaller Mid-Market MedTech makers with strong validation discipline. On the eQMS side — the second mandatory pillar — MasterControl, Sparta Systems TrackWise, Veeva Vault QMS, ConSense IMS and Roxtra dominate, and the ERP shortlist has to integrate with whichever eQMS the regulatory team has selected. Pure cloud SaaS ERPs are uncommon in the validated-environment space, although newer offerings (SAP S/4HANA Cloud Private Edition, Microsoft Dynamics 365 F&O in dedicated cloud) are gaining ground.
Trends and outlook
Three trends are reshaping selection criteria. First, MDR enforcement and EUDAMED maturity: as EUDAMED's mandatory modules come fully live, ERP-to-EUDAMED data flow becomes the operational backbone of compliance, not a once-a-year submission task. Second, IVDR (Regulation 2017/746 on in-vitro diagnostics) imposes a parallel regime on diagnostic device makers, with comparable UDI and post-market obligations. Third, cyber-security under MDCG 2019-16 and the upcoming EU Cyber Resilience Act applies to connected medical devices and to the manufacturing IT itself, which raises the security bar on the ERP and its integrations. 2026 selection projects in MedTech should explicitly test all three.
Related Topics
Frequently Asked Questions
What does running an ERP in a "validated environment" mean in practice?
It means every change to the ERP — configuration, integrations, master data structures, even some report changes — runs through a documented change-control workflow with impact assessment, IQ/OQ/PQ qualification testing and signed approvals. The implementation project includes formal validation deliverables, and post-go-live the ERP operates under that same regime indefinitely. The overhead is real but non-negotiable under MDR and ISO 13485.
How does UDI work end-to-end?
The manufacturer assigns a Basic UDI-DI per device family and a UDI-DI per specific device version, registers them in EUDAMED, places the UDI carrier (typically a GS1 Data Matrix or linear barcode) on label and packaging, and for reusable devices on the device itself. The ERP holds the UDI master, the link to EUDAMED records and the production-batch-to-UDI link, and produces the UDI label as part of the despatch process.
Can a generic manufacturing ERP work for MedTech?
For very small Class I device makers, possibly — with significant external validation effort and a tightly integrated eQMS. For Class IIa and above, a generic ERP without a medical-device industry add-on rarely passes the cost-benefit threshold once validation, UDI, batch genealogy and audit obligations are included. Most serious MedTech selections shortlist only ERPs with a credible MedTech reference base in DACH.
How tight is the link between ERP and eQMS?
Tight by design. Deviations, CAPAs, complaints and change controls in the eQMS frequently touch ERP transactions (batches, suppliers, customers). Integration is usually bidirectional with master-data synchronisation and event-based triggers. Treating the eQMS as a parallel island is a classic source of audit findings and regulatory delay.