About this register
Curenium uses a small number of third-party services to deliver the platform. Where any of them process personal data on behalf of a customer organisation, they act as our subprocessors and are bound by written terms no less protective than those in our Data Processing Agreement. This register lists every subprocessor that may process personal data, what it is used for, and where processing takes place. We maintain it because a hospital cannot assess our processing without knowing who else is involved.
We will give customer organisations advance notice of any new subprocessor, so that an objection can be raised before the change takes effect.
Core infrastructure
These services hold or transmit patient data as part of normal operation.
- MongoDB Atlas — primary database. Stores all clinical records, including patient demographics, observations, notes, prescriptions and laboratory results. Encrypted at rest.
- Amazon Web Services (S3) — object storage for uploaded documents and imaging attached to patient records.
- Cloudflare — network delivery, and the Workers runtime that carries real-time messaging and notification traffic between clinicians.
- Cloudinary — storage and delivery of images and documents uploaded to patient records and staff profiles.
- Vercel — application hosting. Runs the Curenium web application and its API, which handle clinical data in transit.
- Sentry — crash and error reports from the Curenium mobile application. Configured not to collect personal identifiers or console output.
Messaging and notifications
These services carry alerts and messages. A notification may reference a patient by name or identifier — for example a critical laboratory result — so they are treated as processing personal data.
- Pusher — real-time delivery of clinical alerts, chat messages and status updates within the application.
- OneSignal — push notification delivery to mobile devices.
- Expo — push notification delivery to the Curenium mobile application.
- Resend — transactional email, including account verification, password reset and clinical notifications.
- Cloudflare (RealtimeKit) — real-time voice and video calls, including remote consultations. On the Pro plan, call audio is transcribed so that live captions are available, and recordings a clinician chooses to make are stored with Cloudinary. Calls are not recorded by default.
- Slack — Help & Support conversations are relayed to the Curenium support team. People are asked not to include patient names or details.
Artificial intelligence providers
Curenium uses AI models for clinical documentation assistance and decision support. Where a request includes clinical information, it is processed by Google (Gemini); dictated notes and consultation recordings are transcribed by AssemblyAI. No other AI provider receives clinical information. AI output is advisory only. No automated decision with a legal or similarly significant effect on a patient is taken without human review.
- Google (Gemini) — clinical documentation assistance and decision support.
- AssemblyAI — transcription of dictated clinical notes and consultation recordings, processed in the EU by default.
TWO PERMISSIONS ARE REQUIRED BEFORE ANY OF THIS HAPPENS. First, the organisation must enable AI assistance. It is off unless an administrator turns it on, and turning it off stops all of the above for everyone in that organisation. Second, each person must agree separately. Before anyone uses an AI feature we explain that the content of their request is sent to an external provider, and we ask. Declining is a real answer: every other part of Curenium continues to work unchanged, and the decision can be reversed at any time. We record who decided, when, and against which version of this disclosure — and if this section changes materially, we ask again rather than rely on an agreement to superseded terms. We send this information through providers' API endpoints rather than consumer products. Where a provider offers a setting that prevents API traffic being retained or used for training, our aim is to select providers that offer it and to enable it; we describe this as an aim rather than a guarantee because it depends on terms we do not control. Deterministic safety checks — allergy screening at prescribing and dispensing — run entirely within Curenium and do not depend on any AI provider.
Biometric processing
Amazon Web Services (Rekognition) is used for facial verification where an organisation enables identity verification for staff. Facial images processed for the purpose of uniquely identifying a person are biometric data and fall within Article 9 of the UK GDPR. This feature is off unless an organisation turns it on, and it is used for staff identity assurance rather than for patients.
An organisation enabling this feature becomes responsible for establishing an appropriate Article 9 condition for it, and should record it in their own assessment.
Billing
Stripe processes payments where an organisation uses Curenium billing. Stripe acts as an independent controller for payment data and applies its own terms; Curenium does not store full payment card details.
International transfers
Some subprocessors process data outside the United Kingdom. Where that happens we rely on UK adequacy regulations, or on the International Data Transfer Agreement or the UK Addendum to the EU Standard Contractual Clauses, together with a transfer risk assessment. Customer organisations that require data residency within a specific jurisdiction should raise this before deployment, as it affects which services can be used.
Questions and objections
To request our Data Processing Agreement, ask about a specific subprocessor, or object to a proposed change, contact support@plannorium.com. Written correspondence: Plannorium Ltd, 71-75 Shelton Street, London, WC2H 9JQ, United Kingdom.