Data Residency and Hosting

Last reviewed: May 2026

Regenemm Healthcare is made in Australia and is designed for healthcare workflows where data residency, privacy, security, and clinical governance matter.

Our platform is built around a Hub-and-Spoke architecture. Regenemm Voice acts as the Hub and clinical control plane. Spokes provide bounded workflow surfaces. The Edge Connector securely ingests approved data flows. Regenemm Link supports patient-controlled records. Regenemm Connect supports standards-based interoperability. Agentic assistants operate only inside declared workflow, consent, audit, and review boundaries.

Data residency is not treated as an afterthought. It is part of Regenemm's clinical governance model.

Intended Posture

Regenemm's intended posture is to keep clinical data processing aligned with approved regions, approved providers, contractual obligations, and applicable privacy requirements.

Data residency is treated as a governance decision, not just an infrastructure setting. Hosting, processing, backups, observability, support access, AI runtimes, network paths, and provider dependencies should be considered before sensitive workflows are used.

Regenemm separates governance portability from clinical data portability. Care Graph Contracts, Spoke contracts, and role declarations may be designed to operate across approved deployment environments. Patient data, MHR-linked data, clinical evidence, audit trails, agent-run traces, credentials, and Hub-persistent state should remain bound to the tenant's declared residency, consent, and governance boundary.

Clinical Data Control

Regenemm Voice acts as the Hub and clinical control plane. Spokes provide bounded workflow surfaces and should not weaken Hub governance.

Sensitive workflows should declare:

• data classes processed;
• hosting and processing regions;
• provider and sub-processor boundaries;
• backup and audit-log regions;
• agentic runtime regions;
• support access regions;
• release and audit pathways;
• whether MHR-linked data is present.

No production clinical environment should be treated as approved until relevant hosting, region, provider, runtime, audit, and evidence mappings have been reviewed.

Australia-First Posture

For Australian healthcare workflows, Regenemm is designed with an Australia-first hosting and processing posture for:

• patient clinical information;
• Regenemm Link patient vault records;
• My Health Record-linked data where supported and authorised;
• clinical documents;
• pathology and radiology reports;
• audit and provenance records;
• agentic run traces containing patient information;
• credentials and integration secrets;
• Edge Connector ingestion events;
• interoperability records.

Where data is processed outside Australia, that pathway should be explicitly assessed, documented, contractually controlled, technically governed, and disclosed where appropriate.

Data classes and residency

Different data classes have different residency and control requirements.

MHR-Linked Data

MHR-related pathways require a stricter control profile.

Where Regenemm workflows involve data derived from, retrieved from, prepared for, or associated with My Health Record pathways, the intended posture is:

• Australian-resident storage by default;
• Australian-resident processing by default;
• explicit access logging;
• purpose-of-use enforcement;
• respect for patient access-control settings where applicable;
• no use in experimental agentic runtime pathways;
• no direct use in non-approved model-training pipelines;
• no offshore processing unless legally reviewed and explicitly approved;
• documented incident and breach assessment pathways.

MHR-linked data should remain separated from general agentic runtime experimentation.

Region and Deployment Control

Approved-region decisions are intended to consider the type of data processed, the provider, the service boundary, the deployment context, and the workflow purpose.

Region pinning may apply at tenant, organisation, environment, or workflow level where required.

Region controls may apply to:

• databases;
• object storage;
• document stores;
• vector stores;
• graph stores;
• logs;
• audit records;
• backups;
• credentials;
• agentic run traces;
• event streams;
• AI runtime providers;
• transcription providers;
• interoperability services.

Region choice should reflect customer requirements, legal obligations, clinical workflow risk, and the data classes being processed.

Provider Review

Hosting and infrastructure providers should be reviewed before use for clinical or operational workflows involving sensitive data.

Provider review should consider:

• service purpose;
• data classes processed;
• hosting and processing regions;
• support access regions;
• backup and disaster recovery posture;
• retention posture;
• logging and telemetry posture;
• security controls;
• contractual protections;
• incident notification pathways.

Provider and AI runtime decisions should be reflected in the relevant governance registers before sensitive workflows rely on them.

Cross-Border Handling

Cross-border disclosure or processing of health information requires purpose, authorisation, contractual review, and auditability.

Regenemm's intended posture is that cross-border processing should not be hidden inside analytics, observability, support tooling, AI provider calls, model telemetry, backups, or agentic runtime tooling.

Audit and provenance records should remain inside the declared residency boundary unless an approved disclosure pathway applies.

Customer-Controlled Deployment Options

Some healthcare organisations require stronger deployment boundaries.

Regenemm's architecture is designed to support future or customer-specific deployment patterns such as:

• dedicated cloud environments;
• customer-controlled cloud accounts;
• private network connectivity;
• customer-managed encryption keys;
• controlled egress;
• local Edge Connector deployment;
• private integration paths to EMR, PMS, pathology, radiology, or hospital systems;
• customer-specific retention policies;
• customer-specific audit export.

Support access should be time-bound, approved, logged, and reviewed after use.

These arrangements depend on customer requirements, platform maturity, commercial terms, and security review.

Edge Connector residency boundary

The Edge Connector may operate close to local clinical systems.

It may receive or observe approved data flows such as:

• HL7;
• HealthLink-related messages;
• pathology reports;
• radiology reports;
• practice management system signals;
• local server folders;
• approved clinical-system exports.

The Edge Connector feeds governed ingestion events into Regenemm Voice.

The Edge Connector should not become an ungoverned long-term clinical record store. Its role is secure ingestion, source attribution, message handling, audit creation, and Hub handoff.

Regenemm Link residency boundary

Regenemm Link is designed as the patient-controlled record and sharing surface.

Because Link may contain patient-owned health records, sharing grants, carer access rules, and home records, it requires strong residency, access, consent, and audit controls.

For Australian patients and Australian healthcare workflows, Link data should follow the Australia-first posture unless a different arrangement has been explicitly assessed and approved.

Regenemm Connect residency boundary

Regenemm Connect supports interoperability with external healthcare systems.

Connect may handle:

• SMART on FHIR;
• EMR-connected data;
• My Health Record-related pathways;
• structured data exchange;
• external system mappings.

Interoperability data should be handled according to the relevant system boundary, legal requirement, consent position, and residency obligation.

Agentic runtime residency

Agentic assistants may process patient information only when permitted by a declared workflow.

Where agentic run traces contain patient information, those traces are treated as controlled data.

Agentic runtime residency must consider:

• model provider;
• processing region;
• retention;
• logging;
• training use;
• sub-processors;
• access controls;
• contractual terms;
• auditability;
• deletion or retention review;
• compatibility with Australian healthcare workflows.

Identifiable patient records are not used to train foundation models by default.

Schema Portability Does Not Mean Data Portability

Regenemm may define portable workflow schemas, Spoke contracts, and Care Graph Contracts.

That does not mean clinical data is freely portable.

Clinical data, patient records, My Health Record-linked data, audit records, credentials, and agentic workflow traces remain bound to their declared governance, residency, access, consent, and retention rules.

Non-Negotiable Invariants

Regenemm's intended control posture is:

• Regenemm Voice governs clinical data permanence.
• Spokes do not own durable clinical truth.
• Edge Connector ingests but should not become a permanent record store.
• Link data is patient-controlled and consent-oriented.
• MHR-linked data requires strict Australian residency review.
• Agentic assistants cannot bypass consent, policy, audit, or human review.
• Runtime portability does not imply clinical data portability.
• Region configuration is infrastructure policy, not clinical data ownership.
• Audit and provenance must remain tied to the declared residency boundary.
• Offshore clinical processing requires explicit review and approval.

Schemas may be portable.
Clinical data remains governed.
The Hub controls permanence.
Spokes contextualise.
Audit persists.
Patients control Link-mediated sharing.

Contact

For data residency, hosting, procurement, or security review enquiries:

• security@regenemm.com
• privacy@regenemm.com
• legal@regenemm.com