Legal document

Subprocessor List.

The third-party providers Miraa uses to host, secure, transcribe, generate, and deliver the service, and where each processes data.

m
Miraa Team
Effective 10 September 2026
10 min read Australian law
On this page

Key points

  • Subprocessors are used only where needed to provide, secure, or deliver the service.
  • AI note and document drafting and clinical email process in Australia (ap-southeast-2), and so does Miraa's server transcription batch. Consultation transcription is not always that batch, and this is the one place the Australian claim does not hold. On Miraa's iPhone and iPad app every consult is transcribed by Apple's own recogniser and that text is saved as the consult's transcript, so the Australian batch is not run for it; in the web app the same happens on Safari whenever Miraa's own in-browser model is unavailable. Apple may perform that recognition on its own servers rather than on the device - on iPhone and iPad Miraa records which of the two happened, and in the web app it can establish neither, so it records that transcript's residency as unknown. "How to read this list" below sets this out.
  • No clinical content is sent to a provider Miraa engages outside Australia by default, with two exceptions on the audio path, both of them recognisers built into the clinician's own browser or device. Where Miraa's on-device dictation model is unavailable, clinician dictation in the web app falls back to the browser's own speech recognition, which on Chrome and Edge sends that audio to the browser vendor in the United States. And consultation audio reaches Apple's recogniser - on iPhone and iPad for every consult, and in the web app on Safari whenever Miraa's own in-browser model is unavailable - which Apple may run on its servers rather than on the device. Both are set out under "How to read this list" below, and the web app's side of them in the Data Processing & Security Schedule.
  • Identifiable patient health information is never used to train AI models by Miraa or by any provider Miraa engages. The two recognisers under "How to read this list" are outside that commitment: Miraa neither contracts with them nor can observe what they do with the audio, so it cannot give this assurance on their behalf.
Section 01

How to read this list

Each entry names the provider, what it does, the data it may receive, and the processing region. This list covers the providers that handle clinic or patient information; providers that receive no clinical content, such as payment and product-analytics services, are covered by the Privacy Policy rather than named here.

Two audio paths reach a recipient that is not named as an entry below, and a clinic should assess them alongside this list. Both use speech recognition already built into the clinician's own browser or device rather than a service Miraa engages, so Miraa neither contracts with the recipient nor can observe what it does with the audio. First, where Miraa's on-device dictation model is unavailable, clinician dictation in the web app falls back to the browser's own recogniser, which on Chrome and Edge sends that dictated audio to the browser vendor in the United States. Second, consultation audio itself reaches Apple's recogniser: on Miraa's iPhone and iPad app for every consult, and in the web app on Safari whenever Miraa's own in-browser model is unavailable. Apple may perform that recognition on its own servers rather than on the device. What it produces is not only a preview - Miraa keeps that text as the consultation's transcript and drafts the note from it, and the Australian transcription batch is not run for that consult. On iPhone and iPad Miraa records for each transcript whether recognition stayed on the device or ran on Apple's servers; in the web app it can establish neither, and records that transcript's residency as unknown. The web app's side of both paths is described in the Data Processing & Security Schedule, and the AI Processing Notice describes the Apple path on both surfaces. Whether to name Apple and the browser vendors as subprocessors here is under review.

Miraa may update subprocessors as vendors, infrastructure, regions, or product features change. Material changes affecting clinical data handling will be communicated through a reasonable channel.

Section 02

AI inference and transcription (Australia)

Amazon Web Services - Amazon Bedrock (ap-southeast-2, Sydney): all AI note generation, document drafting, summarisation, extraction, and assistant features. Data processed may include prompts, transcripts, clinical context, and generated drafts. Miraa invokes models through Australia-only inference profiles and the account is configured for zero data retention, so request and response content is not retained by AWS or shared with the model provider. Miraa operates under an AWS Business Associate Addendum.

Amazon Web Services - Amazon Transcribe and Amazon S3 (ap-southeast-2, Sydney): server batch transcription of consultation and telehealth audio, including speaker diarisation. Data processed includes recorded consultation audio and the resulting transcript text. Amazon S3 holds the audio for the length of a batch job and it is deleted when the job ends; the durable copy of a recording lives in Miraa's Australian storage, listed under hosting below. This batch is not run for every consult. Where a live in-consult transcript has already been produced on the clinician's own device or browser, Miraa keeps that text as the consult's record and sends no audio to Amazon Transcribe for it; on Miraa's iPhone and iPad app that is what happens on every consult. Telehealth consults and any consult with no usable live transcript do run the batch.

Section 03

Speech recognition on your device or in your browser

Apple (United States): speech recognition built into iOS and into Safari, used only to produce the live in-consultation preview transcript. Data processed is consultation audio. On the Miraa iPhone app, where the device supports on-device recognition the audio stays on the device; where it does not, Apple processes that audio on its servers, and clinics should treat that as an overseas disclosure under Australian Privacy Principle 8. In Safari on the web, Apple describes this recognition as running on the device, but the browser gives Miraa no way to require or confirm it.

Miraa's own speech model, which runs inside your browser or inside the Miraa desktop app, is not a subprocessor: it runs on the clinician's device, and no audio, transcript, or patient information is sent to any provider. The model files are downloaded once from the Hugging Face Hub, a public model host outside Australia, which receives no clinical content. On Chrome and Edge the fallback preview uses the browser's own on-device recognition, which Miraa starts only after the browser confirms it can recognise speech on the device.

Section 04

Providers configured but not receiving clinical data

OpenAI (United States): retained in the codebase for cloud dictation clips, and refused at the provider boundary. Miraa's clinical-data register records OpenAI as unapproved pending an executed data-processing agreement and zero-retention tier, and the transcription path asserts that approval before any upload, so no audio is sent. That refusal can only be lifted by a deliberate, reviewed compliance approval configured in the deployment, and lifting it would be a change to Miraa's processing that a clinic should be told about. The consultation transcription fallback that previously used this provider has been removed outright: if the Australian service cannot complete a job, the consult is not transcribed.

Google Gemini (United States): retained as a configured alternative model provider. Network egress to this provider is disabled, so no clinical data is sent to it. That block is two independent refusals, and each is lifted only by a deliberate, reviewed compliance approval configured in the deployment: a blanket transport switch on the Gemini client, and Miraa's clinical-data register, which records Google as unapproved pending an executed data-processing agreement and subprocessor disclosure. Lifting either would be a change to Miraa's processing that a clinic should be told about. Both providers are listed because the configuration exists and would become active only on a deliberate compliance decision.

Section 05

Hosting, database, storage, and authentication

Supabase (ap-southeast-2, Australia): authentication, database, file storage, row-level access controls, and related backend services. Data processed may include account data, clinic workspace data, patient records, audio objects, transcripts, generated outputs, audit records, and technical logs.

Vercel (syd1, Sydney): application hosting and serverless execution. Clinical data passes through this layer in transit.

Section 06

Patient communication

Amazon Web Services - Amazon SES and Amazon SNS (ap-southeast-2, Sydney): delivery of clinical email to patients, next of kin, and referral recipients, including after-visit letters and referral letters, and the delivery and bounce events returned for those messages. Data processed includes recipient email addresses and the clinical content of the letter. Amazon SES is the only clinical email transport Miraa will use: the code accepts no other provider for this traffic and has no fallback, so a delivery failure is reported rather than re-routed. Delivery to the recipient's mail server requires TLS: a server that cannot negotiate TLS receives no mail at all, rather than a plaintext copy of a patient letter. Clinics should note that Miraa is confirming the scope of its AWS Business Associate Addendum for this service.

Resend (United States): system and operational mail that carries no patient clinical content - for example clinic invitations, referral-programme messages, notification digests sent to clinicians, and Miraa's own operational alerts and test sends. Resend is not a permitted transport for clinical email and is not used for patient, next-of-kin, or referral letters. This is a description of a category rather than a closed list; clinics should treat any information they place in a message of that kind as leaving Australia.

Twilio (United States): SMS for appointment confirmations, reminders, and patient messaging where the clinic enables it. Data processed may include patient phone numbers and message content the clinic composes or approves.

ElevenLabs (United States): voice for the AI receptionist where a clinic enables Miraa Connect. Data processed may include patient voice audio, the caller's name, and the appointment or call context needed to answer the call. Miraa has not yet executed a data-processing agreement with this provider or obtained zero-data-retention terms, and the provider offers no Australian processing region, so clinics should treat AI receptionist calls as an overseas disclosure under Australian Privacy Principle 8 and confirm the position with Miraa before enabling Miraa Connect.

Section 07

Clinic-enabled integrations

These integrations process data only when a clinic enables and authorises them, and only for the clinic that enabled them. Practice management and clinical record systems: Cliniko (Australia), Splose (Australia), Nookal (Australia), MediRecords (Australia), and Epic or Oracle Cerner via FHIR (hosted by the clinic or its health service). Data processed may include patient demographics, appointments, and clinical notes pushed to the clinic's own record system.

Secure clinical messaging: HealthLink (Australia and New Zealand), used to deliver referrals and clinical documents to other providers.

Google Workspace Connected Apps (United States), where a clinician connects their own Gmail, Calendar, Contacts or Google Tasks. Data may include email and draft content, correspondence metadata, calendar events, attendee details, contact names or addresses, and task titles and notes; these sources may contain clinical information.

Microsoft 365 Connected Apps, reached through Microsoft Graph (United States, unless the clinician's own Microsoft 365 tenant is configured for another region), where a clinician connects their own Outlook mailbox, calendar or contacts, Microsoft Teams chat, or Microsoft To Do list. Data may include email subjects, bodies and drafts, the names and types of attachments, correspondence metadata, calendar events and attendee details, contact names, email addresses and phone numbers, Teams chat messages and the people in those chats, and to-do task titles and notes; these sources may contain clinical information. Miraa reads these sources and, where the clinician approves the action, can save a draft in Outlook, create a calendar event, or add an item to the clinician's own to-do list. Miraa does not download attachment contents, does not send email from the mailbox, and does not post in Teams; it does not hold the Microsoft permissions that would allow sending or posting.

Third-party integrations are also governed by the third party's terms, privacy practices, permissions, availability, and security controls. Clinics should review those terms before enabling an integration.

Section 08

Support and incident handling

Miraa may use support, monitoring, email, or incident-response tools to diagnose issues and communicate with clinics. Support channels should avoid identifiable patient information unless it is necessary, authorised, and handled through an appropriate channel.