Cloud Modernisation for Medical Device Manufacturers (MDR)

Introduction: MDR as a Modernisation Catalyst

EU MDR (Regulation 2017/745), fully in force since May 2021, introduced the most significant changes to medical device regulation in Europe in decades. For IT departments at medical device manufacturers, the impact has been profound: new obligations around Post-Market Surveillance, PMCF, UDI, EUDAMED integration, and enhanced QMS documentation cannot be fulfilled by legacy monolithic systems without substantial investment.

The Notified Bodies that conduct conformity assessments now review QMS documentation digitally. EUDAMED requires API-capable systems. Audit trails must be tamper-evident. PMCF data pipelines must be structured, reproducible, and documented. These are fundamentally cloud-native capabilities — and they are why MDR is driving a wave of cloud modernisation across the medical device industry in the DACH region.

Storm Reply has supported multiple DACH medical device manufacturers through MDR-compliant cloud migrations. The patterns and pitfalls we have observed form the basis of this article.

Key Concepts: MDR, QMS, and Cloud Migration

EU MDR (Medical Device Regulation)

Regulation 2017/745 of the European Parliament and Council. Applies to medical devices placed on the EU market since May 2021. Replaces the Medical Device Directive (MDD 93/42/EEC). Key new requirements: enhanced clinical evidence, mandatory PMCF for higher-risk devices, UDI, EUDAMED registration, and stricter QMS requirements under Article 10.

QMS (Quality Management System)

For medical device manufacturers, a QMS certified to ISO 13485 is required under EU MDR Article 10(9). The QMS covers design controls, risk management (ISO 14971), document control, CAPA (Corrective and Preventive Actions), supplier qualification, and post-market activities. MDR significantly expanded QMS scope compared to the legacy MDD framework.

SaMD (Software as a Medical Device)

Software intended for one or more medical purposes without being part of a hardware medical device. Regulated under EU MDR Article 2(1) and MDCG guidance. SaMD must follow software lifecycle processes per IEC 62304, usability engineering per IEC 62366, and cybersecurity guidance from MDCG 2019-16.

UDI (Unique Device Identification)

EU MDR Article 27 mandates a unique device identifier on all medical devices, enabling traceability through the supply chain and in clinical use. UDI data must be registered in EUDAMED. Managing UDI master data across product variants is a significant IT challenge for manufacturers with large portfolios.

EUDAMED

European Database on Medical Devices — the EU's central registry for medical devices. Manufacturers must register their devices, economic operator details, UDIs, Notified Body certificates, and vigilance reports via EUDAMED's API. API-capable IT systems are therefore a regulatory requirement under EU MDR.

Strangler-Fig Pattern

Architectural pattern for incrementally replacing a legacy system: new functionality is built alongside the legacy system and gradually takes over until the legacy system is fully decommissioned. Ideal for regulated environments because it avoids big-bang migrations that risk compliance continuity during transition.

IEC 62304

International standard for medical device software lifecycle processes. Defines requirements for software development, maintenance, risk management, and configuration management for software classified as Class A (no harm), B (non-serious harm), or C (serious harm or death). A prerequisite for SaMD CE marking under EU MDR.

The MDR IT Challenge: Why Legacy Systems Fall Short

Document Control and Audit Trails

EU MDR Article 10(8) and ISO 13485 §4.2 require document control with version history, approval workflows, and tamper-evident audit trails. Many legacy document management systems lack versioning or structured audit capability. AWS addresses this through S3 versioning, CloudTrail, and Step Functions-based approval workflows with full audit history.

EUDAMED API Integration

EUDAMED requires machine-readable registration of devices, UDIs, certificates, and vigilance reports. Legacy systems typically have no API layer — data is entered manually. AWS API Gateway and Lambda provide the EUDAMED integration layer without requiring replacement of the entire QMS, enabling the Strangler-Fig approach.

UDI Master Data Management

UDI requires managing product identifiers at model/configuration level and individual device level (for implants). Amazon DynamoDB provides a flexible, scalable UDI data store with full history and the API access needed for EUDAMED synchronisation — capabilities that generic QMS platforms handle poorly.

AWS Modernisation Architecture for MDR Compliance

Storm Reply's MDR modernisation framework maps regulatory requirements to specific AWS services:

The Strangler-Fig Migration in Four Phases

1. Phase 1 — API Facade (Months 1-3): Deploy AWS API Gateway in front of the legacy QMS. New modules (CAPA tracking, EUDAMED connector, UDI data store) are built as Lambda functions and exposed via the Gateway. The legacy system remains active but is progressively bypassed.
2. Phase 2 — Data Migration with Validation (Months 3-9): Master data is migrated to DynamoDB and S3. Each migration phase is validated with IQ/OQ protocols. Parallel operation continues until data is fully validated and accepted by the Notified Body review process.
3. Phase 3 — Legacy Decommissioning (Months 9-18): Legacy modules are shut down once cloud-native replacements are validated. Full PQ validation of the complete architecture. Regulatory change notification to Notified Body as required by the QMS change control process.
4. Phase 4 — Continuous Compliance (Month 18+): Infrastructure as Code enables reproducible environments and accelerates re-validation on major changes. AWS Config and Security Hub provide continuous compliance monitoring. Periodic revalidation reviews aligned with QMS change control calendar.

SaMD Development on AWS: IEC 62304-Compliant DevSecOps

Requirements Traceability

Software requirements are maintained as version-controlled artefacts in AWS CodeCommit or GitHub (via AWS). Traceability matrices linking requirements to design, code, and test cases are generated automatically from repository metadata. Every requirement change triggers a validated change control workflow in Step Functions, ensuring that impact is assessed before implementation begins.

Automated Security Testing

Amazon Inspector performs continuous vulnerability scanning of application dependencies. AWS CodeGuru Reviewer performs static code analysis. Security findings above a defined severity threshold block deployment — enforcing the security gate required by MDCG 2019-16. All findings and resolutions are archived as validation evidence in S3 with Object Lock retention.

Software Bill of Materials (SBOM)

MDCG 2019-16 requires manufacturers to maintain a current SBOM for SaMD. Amazon Inspector generates SBOMs from dependency graphs automatically, with CVE monitoring alerting teams to new vulnerabilities in listed components within hours of public disclosure.

Common Pitfalls and How to Avoid Them

Pitfall 1: Validation Effort Underestimated

Teams that treat CSV as an afterthought regularly experience 6-12 month delays when Notified Bodies require evidence that does not yet exist. Solution: validation planning from day one, with IaC-generated IQ evidence and automated OQ test suites built into the project plan from the start.

Pitfall 2: Notified Body Not Engaged Early

Manufacturers who complete their migration before engaging the Notified Body frequently discover that the NB has specific requirements that require rework. Solution: pre-assessment workshop with the Notified Body before Phase 1, documenting the modernisation strategy as a formal QMS change notification.

Pitfall 3: AWS Supplier Qualification Overlooked

ISO 13485 §7.4 requires formal supplier evaluation for critical suppliers. AWS must be qualified as a supplier. Storm Reply provides pre-built AWS supplier qualification packages based on AWS Artifact reports, reducing supplier qualification from weeks to days.

Storm Reply: MDR Modernisation Expertise in DACH

Storm Reply is an AWS Premier Consulting Partner in the DACH market with a dedicated Medical Device practice. Our consultants combine AWS architecture expertise with direct knowledge of EU MDR, ISO 13485, IEC 62304, and GAMP 5 — understanding not just the technical requirements but the regulatory rationale behind them.

Our MDR modernisation projects apply three consistent principles: validation-readiness before speed, Infrastructure as Code as the primary validation accelerator, and early Notified Body engagement. Storm Reply holds 16 AWS Competencies as part of the Reply Group, with AWS Premier Partner status since 2014. Our Life Science practice is active across Germany, Austria, and Switzerland.

Use Cases: MDR Cloud Modernisation in the DACH Region

Implant Manufacturer: QMS Modernisation with EUDAMED Integration

A southern German orthopaedic implant manufacturer operated a 15-year-old on-premises QMS that could not meet EU MDR's EUDAMED API requirements or UDI data management obligations. Storm Reply executed an 18-month Strangler-Fig migration: EUDAMED connector as Lambda, UDI master data in DynamoDB, PMCF pipeline in HealthLake. The legacy system was fully decommissioned after 18 months. Validation effort was 40% lower than comparable on-premises modernisations, enabled by IaC-based IQ acceleration.

Diagnostics Manufacturer: New SaMD on AWS

An Austrian in-vitro diagnostics manufacturer developed a new AI-powered image analysis software as Class IIb SaMD. Development followed IEC 62304 on AWS CodePipeline, with Amazon SageMaker for ML model training and validation, and automated SBOM generation via Amazon Inspector. MDR conformity assessment by BSI Berlin (Notified Body) was completed successfully, with the AWS-generated traceability and validation evidence accepted without revision requests.

MDR Readiness Assessment Service

Storm Reply offers structured MDR Readiness Assessments: gap analysis between current IT state and MDR requirements, prioritisation of modernisation measures, AWS migration cost estimation including validation effort, and a roadmap for Notified Body audit readiness. Output: a 90-day action plan with clear owners, budget, and milestones.

Benefits and Challenges

Strategic Benefits

• API-native EUDAMED integration without middleware complexity
• Scalable PMCF and vigilance pipelines for growing product portfolios
• 40-50% validation effort reduction through Infrastructure as Code
• Automated SaMD cybersecurity monitoring meeting MDCG 2019-16 requirements
• Tamper-evident records immediately accessible for Notified Body inspections

Challenges

• Parallel operation overhead: Maintaining two systems simultaneously is resource-intensive. Mitigation: clear role separation and a time-boxed migration schedule with milestone-based legacy decommissioning.
• Regulatory Affairs skill gap: Cloud concepts are unfamiliar to many Regulatory Affairs teams. Mitigation: integrated training programme as part of the project.
• AWS supplier qualification: AWS must be formally qualified under ISO 13485 §7.4. Storm Reply's pre-built supplier qualification packages based on AWS Artifact reduce this from weeks to days.

Frequently Asked Questions

How do you modernise a QMS while maintaining EU MDR compliance?

The Strangler-Fig pattern is most effective: new capabilities are built in parallel as cloud-native services while the legacy system is gradually decommissioned. Each new component is CSV-validated (IQ/OQ/PQ) before go-live, preserving MDR compliance throughout the migration.

What is Software as a Medical Device (SaMD) and how does it affect AWS development?

SaMD is software intended for one or more medical purposes without being part of a hardware medical device. Under EU MDR, SaMD is classified by risk class, requiring ISO 13485, IEC 62304 software lifecycle processes, and proportionate clinical evidence. AWS DevSecOps pipelines automate MDR-compliant CI/CD with built-in IEC 62304 traceability.

How long does an MDR-compliant cloud migration take?

Typically 12-24 months depending on portfolio size, legacy complexity, and internal validation capability. With the Strangler-Fig approach, first productive modules can go live after 3-4 months while the full migration completes incrementally. Infrastructure as Code reduces IQ/OQ effort by 40-50%.