⏱ 5 min read
EUDAMED as a Regulatory Data Platform
An Enterprise Architecture Whitepaper for Pharma and MedTech Organizations
Executive Summary
The European Database on Medical Devices (EUDAMED), established under the Medical Device Regulation (MDR) and In Vitro Diagnostic Regulation (IVDR), represents a fundamental transformation in regulatory data governance within the European Union. architecture decision records
While often treated as a compliance portal, EUDAMED is structurally a regulatory data platform built around identity, hierarchy, lifecycle traceability, and cross-actor transparency.
For pharmaceutical organizations --- especially those developing combination products, companion diagnostics, or digital therapeutics --- EUDAMED intersects directly with medicinal product data governance frameworks such as IDMP (Identification of Medicinal Products, ISO 11615/11616/11238/11239/11240). ArchiMate modeling standards
This whitepaper analyzes EUDAMED from an enterprise architecture perspective, introduces its formal logical model, explains canonical integration patterns, and compares its structural logic with IDMP. Sparx EA best practices
The goal is not to explain submission mechanics, but to help organizations architect a unified regulatory data strategy.
1. The Regulatory Digital Transformation in Europe
European regulation is moving toward structured, interoperable, lifecycle-managed data ecosystems.
Historically: - Medicinal products were governed through EMA-centric systems and national agencies. - Medical devices were managed largely through decentralized and document-heavy processes.
Today: - EUDAMED centralizes structured device data. - IDMP standardizes structured medicinal product data.
Both initiatives signal a shared direction: Structured regulatory master data replaces document-driven compliance.
2. EUDAMED Logical Architecture Overview
EUDAMED is built around three structural pillars:
- Actor Identity (SRN-based)
- Device Identity (Basic UDI-DI → UDI-DI hierarchy)
- Lifecycle Events (Certificates, Clinical, Vigilance)
These elements form a regulatory graph rather than a flat database.
2.1 Actor Domain
Actor ├─ SRN (Single Registration Number) ├─ Legal Name ├─ Roles ├─ Addresses └─ Status
The SRN becomes the authoritative external identifier across modules.
Architectural implication: SRN must be treated as governed master data inside enterprise systems.
2.2 Device Identity Model
Basic UDI-DI (Device Family)
DeviceFamily ├─ Basic UDI-DI ├─ Manufacturer SRN ├─ Intended Purpose ├─ Risk Class └─ Lifecycle Status
UDI-DI (Market Instance)
- Device ├─ UDI-DI ├─ Basic UDI-DI (FK) ├─ Commercial Name ├─ Version └─ Status
- Relationship:
- DeviceFamily (1) → Device (n)
- This enforces a family-instance separation similar to IDMP's product modeling.
3. IDMP Overview (ISO Identification of Medicinal Products)
IDMP is a family of ISO standards defining structured data for medicinal products.
Core standards include:
- ISO 11615: Medicinal Product
- ISO 11616: Pharmaceutical Product
- ISO 11238: Substance
- ISO 11239: Pharmaceutical Dose Form, Units
- ISO 11240: Units of Measurement
IDMP introduces structured identifiers such as:
- MPID (Medicinal Product ID)
- PhPID (Pharmaceutical Product ID)
- Substance identifiers
- Referential controlled vocabularies
IDMP separates:
- Substance
- Pharmaceutical Product
- Medicinal Product
- Packaged Product
This multi-layer identity structure strongly mirrors EUDAMED's family-instance model.
4. Structural Similarities Between EUDAMED and IDMP
4.1 Identity Anchoring
EUDAMED: Basic UDI-DI → UDI-DI
IDMP: PhPID → MPID → Packaged Product
Both frameworks:
- Separate regulatory definition from marketed instance.
- Enforce structured identifiers.
- Require referential integrity across lifecycle events.
4.2 Actor and Organization Modeling
EUDAMED: SRN identifies economic operators.
IDMP: Organizations are identified via structured identifiers within SPOR (Substance, Product, Organisation, Referentials).
Both require:
- Structured organization master data
- Role modeling
- Cross-system identity resolution
4.3 Lifecycle Traceability
EUDAMED: Certificates, vigilance, investigations link back to device identity.
IDMP: Variations, pharmacovigilance, manufacturing changes link back to MPID/PhPID.
Both implement a lifecycle graph model rather than static records.
4.4 Referential Governance
Both rely heavily on:
- Controlled vocabularies
- Referential datasets
- Validation rules
This requires strong data governance layers in enterprise architecture. free Sparx EA maturity assessment
5. Canonical Data Architecture Strategy
Organizations managing both medicinal and device products should implement a unified Canonical Regulatory Data Model (CRDM).
Core canonical entities:
- Organization (Actor / SPOR Org)
- ProductFamily (Basic UDI-DI equivalent)
- Product (UDI-DI / MPID equivalent)
- Substance
- Packaging
- Certificate
- RegulatoryEvent
The objective:
Avoid siloed device vs medicinal data architectures.
6. Integration Blueprint
Authoring Systems (RIM / Safety / QMS) ↓ Canonical Regulatory Hub ↓ Validation & Referential Engine ↓ EUDAMED Gateway / IDMP Submission Gateway
Key principle:
Submission systems must be decoupled from authoring systems.
7. Strategic Convergence
- EUDAMED and IDMP are not isolated initiatives.
- They represent the early stages of:
- A unified European regulatory data fabric.
- Architectural readiness today prevents re-architecture tomorrow.
Conclusion
EUDAMED and IDMP share structural DNA:
- Hierarchical identity models
- Master data enforcement
- Lifecycle event linkage
- Referential governance
- External identifier anchoring
For enterprise architects, the strategic decision is clear:
Design a unified regulatory master data architecture capable of supporting both device and medicinal ecosystems.
Organizations that architect for convergence will achieve:
- Reduced compliance risk
- Faster regulatory cycles
- Improved audit readiness
- Long-term architectural stability
For expert guidance on enterprise architecture, explore our TOGAF training, ArchiMate training, Sparx EA training, and consulting services. Get in touch.
Frequently Asked Questions
What is enterprise architecture?
Enterprise architecture is a discipline that aligns an organisation's strategy, business operations, information systems, and technology infrastructure. It provides a structured framework for understanding how an enterprise works today, where it needs to go, and how to manage the transition.
How is ArchiMate used in enterprise architecture practice?
ArchiMate is used as the standard modeling language in enterprise architecture practice. It enables architects to create consistent, layered models covering business capabilities, application services, data flows, and technology infrastructure — all traceable from strategic goals to implementation.
What tools are used for enterprise architecture modeling?
Common enterprise architecture modeling tools include Sparx Enterprise Architect (Sparx EA), Archi, BiZZdesign Enterprise Studio, LeanIX, and Orbus iServer. Sparx EA is widely used for its ArchiMate, UML, BPMN and SysML support combined with powerful automation and scripting capabilities.