Sovereign, Non-U.S. Multi-Region Cloud Architecture for HAM Global Exchange.

Executive Summary

This proposal responds to the architecture you shared for HAM Global Exchange: a hospital-centric medical device data platform spanning a European consortium (EU MDR) and an Indian/APAC consortium (Indian MDR), bridged by a Notified Body function — Maltasia — that accelerates India-generated clinical device data toward EU market access. Data currently flows from AWS Europe and AWS APAC through two regional entities, HAM Global (Europe) Ltd and HAM Global (Asia-Pacific) Ltd, into HAM Global Exchange, where it is transformed into specialty registries (MSK, PCI, Urology, with Vascular and Oncology planned), each exposed through a Data Access Portal.

You asked us to redesign this onto multi-region infrastructure with no U.S. dependency — physically separate regions for high availability and disaster recovery, and no reliance on U.S.-controlled infrastructure or jurisdiction. This document sets out: (2) our understanding of the system as shown in your architecture slides, (3) a non-U.S. architecture proposal covering both the Europe and APAC legs, (4) how the registries and data access portals map onto that architecture, (5) plain-language explanations of AWS Lambda, DynamoDB, and Aurora, (6) an honest note on which non-U.S. cloud services we would deploy and why, (7) the regulatory and cross-border considerations specific to a Notified Body / multi-jurisdiction clinical data platform, and (8) our data confidentiality and team accountability framework.

Our Understanding of the HAM Global Exchange Architecture

Based on the architecture materials you shared, we understand the system as follows:

• HAM Global Exchange is the central platform — "Health Activity Modelling for Medical Device Analytics" — that receives data from two regional acquisition programmes and transforms it into specialty registries.
• HAM Global (Europe) Ltd runs the European hospital-centric data acquisition programme on AWS Europe, drawing from a consortium of EU MDR-compliant hospitals anchored by Mater Dei Hospital, Malta, acting as the lead User Group.
• HAM Global (Asia-Pacific) Ltd runs the equivalent India/APAC programme on AWS APAC, drawing from a consortium of Indian MDR-compliant hospitals — including AIMS Mohali, CMC Ludhiana, CMC Vellore, Manipal Hospitals, Sancheti, and Apollo.
• Both consortiums are organized by medical specialty (orthopaedics, cardiology, vascular, with urology and oncology also in scope), each with its own Principal Investigators and its own linked medical device manufacturers.
• Maltasia operates as a Notified Body function — performing Conformity Assessments and Clinical Evaluations, overseen by per-specialty Scientific Committees — using Malta's EU standing to accelerate market access into the EU for devices with India-generated clinical evidence.
• HAM Global Exchange transforms the incoming hospital/device data into specialty registries — MSK Global Registry, PCI Global Registry, and Urology Global Registry today, with Vascular and Oncology registries planned — each with its own Data Access Portal for authorized manufacturers, investigators, and the Notified Body.
• A "Super Registry" layer sits alongside the Notified Body function as the aggregated master data view supporting conformity assessment and clinical evaluation work across specialties.

The diagram below shows how we propose to re-host this exact flow on non-U.S. infrastructure, without changing the logical structure you've already built.

Fig. 1 — Proposed non-U.S. multi-region data flow

Proposed Non-U.S. Multi-Region Architecture

An important clarification, because it shapes every recommendation below: geography and legal jurisdiction are two separate problems. Hosting in an AWS Europe or AWS APAC data center reduces latency and gives physical separation for disaster recovery, but it does not by itself remove a U.S. parent company's legal exposure under U.S. law — most relevantly the U.S. CLOUD Act, which can in some circumstances compel a U.S.-headquartered provider to produce data it controls, regardless of where that data physically sits. Since HAM Global Exchange already operates two distinct regional legs (Europe and APAC), we propose treating each leg separately.

3.1 Europe leg — replacing AWS Europe

• Option A: AWS European Sovereign Cloud — launched in general availability in January 2026, physically and logically separate from standard AWS regions, operated by a distinct EU-based legal entity run by EU citizens (currently Brandenburg, Germany, expanding to Belgium, the Netherlands, and Portugal). This gives you the closest match to your current AWS-based workflow with materially reduced U.S. corporate exposure. We would need to confirm Lambda/DynamoDB/Aurora-equivalent service availability in-region before committing, given the sovereign cloud's still-expanding service catalog.
• Option B: fully independent EU providers with no U.S. parent at all — OVHcloud or Scaleway (France), Hetzner or Open Telekom Cloud/IONOS (Germany), or Exoscale (Switzerland, outside EU/US jurisdiction entirely under Swiss data protection law). This removes U.S. exposure completely but requires re-architecting the Lambda/DynamoDB/Aurora-equivalent pieces onto open-source or provider-native services.
• Given Mater Dei Hospital's role as lead European User Group and Malta's position as home of the Maltasia Notified Body, we'd suggest hosting the EU leg in a nearby EU sovereign region (e.g., Frankfurt/Brandenburg or Milan) rather than expecting hyperscale infrastructure to exist on Malta itself, while keeping the Notified Body's legal seat in Malta unaffected.

3.2 APAC leg — replacing AWS APAC

• Standard AWS APAC regions (e.g., Mumbai, Singapore) remain under the same U.S. parent company as AWS Europe, so they don't resolve the U.S.-dependency concern on their own — the same CLOUD Act exposure applies regardless of region.
• For genuine non-U.S. hosting of the Indian hospital consortium's data, we'd recommend India-owned, MeitY-empanelled cloud providers (for example CtrlS, Yotta Data Services, or Tata Communications) or NTT's Asia data center network (Japan-owned, not U.S.), which also supports alignment with India's Digital Personal Data Protection Act (DPDP Act, 2023) data-localization expectations for Indian hospital data.
• This mirrors the EU leg's logic: a regional acquisition programme (HAM Global (Asia-Pacific) Ltd) hosted on infrastructure with no U.S. corporate ownership, feeding the same central transformation pipeline.

3.3 Central HAM Global Exchange layer

• The transformation engine and specialty registries sit centrally, hosted in the same EU sovereign/independent region chosen for the Europe leg, since this is also where the Notified Body's conformity-assessment and clinical-evaluation work is anchored.
• Cross-region replication between the EU and APAC legs and the central Exchange is encrypted in transit and routed only between the chosen non-U.S. regions — never transiting or caching in a U.S. region.
• An active-passive (or active-active, budget permitting) secondary region within the same non-U.S. footprint provides disaster recovery against a full regional outage.

Registries and Data Access Portals

Each specialty registry (MSK, PCI, Urology, and the planned Vascular/Oncology registries) should be logically isolated within the shared infrastructure, so that a fault or breach in one registry cannot cascade into another, and so that each Data Access Portal can enforce specialty-specific and manufacturer-specific access rules:

• Row-level and tenant-level isolation per registry, keyed to specialty and, where relevant, to the individual device manufacturer's data.
• Separate access control lists per Data Access Portal, distinguishing Principal Investigators, manufacturers, the Notified Body/scientific committees, and any regulator access, each scoped to only the specialty and records they're entitled to see.
• Data-residency tagging at the record level, so you can demonstrate — to a manufacturer, a hospital's ethics committee, or a regulator — exactly which region a given record has ever touched, which is also useful evidence for the Notified Body's conformity assessment process.
• Immutable audit trails on every registry read/write, since Notified Body conformity assessments and clinical evaluations typically require a defensible chain of custody for the underlying data.

Technology Primer — What You Asked About

You asked specifically about AWS Lambda, Amazon DynamoDB, and AWS Aurora. Here's a plain-language explanation of each, mapped to where they'd sit in your data acquisition → transformation → registry pipeline, and what to use instead on the fully independent path.

Non-U.S. Cloud Stack We Would Use

• Compute (transformation engine): AWS European Sovereign Cloud or Scaleway/OVHcloud Functions for the EU leg; India-owned provider functions or self-hosted event processing for the APAC leg.
• Database (registry records): Aurora-compatible or managed PostgreSQL, isolated per registry, hosted in the same non-U.S. region as the Exchange.
• Database (high-volume device/usage events): DynamoDB-compatible service where available, or ScyllaDB/Cassandra self-managed on non-U.S. infrastructure.
• Object storage: EU-region S3-compatible storage or OVHcloud/Scaleway Object Storage for the EU leg; India-owned equivalent for the APAC leg.
• CDN/edge for the Data Access Portals: Cloudflare or Fastly, configured to serve exclusively from non-U.S. points of presence.
• Backups, monitoring, and key management: held entirely within the same non-U.S. regions, with encryption keys managed by an EU-based (and, for the APAC leg, India-based) key management service — never a U.S.-controlled one.

Regulatory and Cross-Border Data Considerations

Because HAM Global Exchange sits at the intersection of two hospital consortiums, two device regulatory regimes, and a Notified Body function, the architecture needs to account for regulatory obligations as much as infrastructure:

• EU MDR (Regulation (EU) 2017/745) governs the European consortium's clinical data and the Maltasia Notified Body's conformity assessment and clinical evaluation output — data handling, retention, and traceability need to meet MDR's post-market clinical follow-up expectations.
• Indian MDR (Medical Devices Rules, 2017, as amended) governs the Indian consortium's hospital data and device compliance obligations on that side.
• Where Indian-generated clinical evidence is being used to support EU market access via the Notified Body, cross-border transfer of that data into the EU leg should be backed by appropriate legal transfer mechanisms (e.g., Standard Contractual Clauses) and, wherever the registries don't need patient-identifiable data, pseudonymization or anonymization before the data leaves the originating consortium.
• India's Digital Personal Data Protection Act (DPDP Act, 2023) informs data-localization and consent requirements for the Indian hospital consortium's data, which is part of why we've recommended India-owned infrastructure for that leg rather than a non-Indian APAC region.
• Each hospital's own ethics committee/IRB approvals and patient consent scope should determine what data is permitted to leave the originating hospital system at all, independent of the cloud architecture — this is worth confirming hospital-by-hospital before migration.

Data Confidentiality and Team Accountability

This is the section that matters most for trust, so we've broken it into what we commit to contractually, technically, and operationally.

8.1 Contractual commitments

• A signed Non-Disclosure Agreement (NDA) with Kretoss Technology as the contracting entity before any data or credentials are shared, covering the company and every individual team member assigned to the project.
• A Data Processing Agreement (DPA), aligned to GDPR Article 28 and, for the Indian leg, DPDP Act obligations, defining exactly what data we can access, for what purpose, for how long, and the obligation to delete or return it at engagement end.
• A right-to-audit clause allowing you, a manufacturer partner, or the Notified Body's auditors to review our access logs, security controls, and subprocessor list on reasonable notice.
• A named subprocessor list — every third-party tool or hosting provider that will ever touch registry data, disclosed in writing, with no additions without your prior approval.

8.2 Technical controls

• Least-privilege access: team members only get access to the specific registries and consortium legs their task requires, never blanket access across MSK, PCI, Urology, and future registries at once.
• Encryption in transit (TLS 1.2+) and at rest (AES-256), with encryption keys held in region-appropriate, non-U.S. key management services.
• Time-boxed credentials provisioned per task/sprint and revoked automatically at project milestones.
• Full audit logging of every access event, exportable to you or the Notified Body's auditors on request.
• No production access from personal devices; no data ever copied to local machines, personal cloud storage, or non-approved tools.

8.3 Personnel and process controls

• Every engineer assigned to hospital- or registry-data work signs an individual confidentiality undertaking in addition to the company-level NDA.
• Background verification for any team member with production data access, to the extent permitted by local employment law.
• Same-day access revocation when a team member rotates off the project.
• Mandatory security and data-handling training, including awareness of MDR/DPDP obligations, before any team member is granted access to client systems.

Suggested Next Steps

• Confirm which Europe-leg option (AWS European Sovereign Cloud vs. fully independent EU providers) and which India-owned/APAC provider best match your budget and existing AWS familiarity.
• Share current data volumes per registry, hospital count per consortium, and manufacturer count so we can size the infrastructure and provide a fixed-scope estimate.
• Execute the mutual NDA so we can review your current AWS Europe/APAC setup in detail and produce a firm migration plan and timeline.
• Schedule a technical call to walk through this document together, including how the Maltasia Notified Body's data requirements should shape the central Exchange design.

Our Team

This is the core team we would assign to the HAM Global Exchange engagement, covering infrastructure, data, security, and the client-facing portals end to end.